Transport Area Working Group                                  B. Briscoe
Internet-Draft                                                        BT
Updates: 3168, 4301                                        July 24, 2009
(if approved)
Intended status: Standards Track                          March 24, 2009
Expires: September January 25, 2009 2010

             Tunnelling of Explicit Congestion Notification
                     draft-ietf-tsvwg-ecn-tunnel-02
                     draft-ietf-tsvwg-ecn-tunnel-03

Status of this This Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September January 25, 2009. 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This document redefines how the explicit congestion notification
   (ECN) field of the IP header should be constructed on entry to and
   exit from any IP in IP tunnel.  On encapsulation it brings updates RFC3168
   to bring all IP in IP tunnels (v4 or v6) into line with the way RFC4301 IPsec tunnels
   now construct the
   ECN field. processing.  On decapsulation it redefines how the
   ECN field in the forwarded IP header should be calculated updates both RFC3168 and RFC4301
   to add new behaviours for two previously invalid unused combinations of incoming inner and
   outer headers,
   in order that these combinations may header.  The new rules propagate the ECN field whether it is
   used to signal one or two severity levels of congestion, whereas
   before they propagated only one.  Tunnel endpoints can be usefully employed updated in future
   standards actions.  It includes a
   any order without affecting pre-existing uses of the ECN field
   (backward compatible).  Nonetheless, operators wanting to support two
   severity levels (e.g. for pre-congestion notification--PCN) can
   require compliance with this new specification.  A thorough analysis
   of the reasoning for these changes and the implications. implications is included.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  6  8
     1.1.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     1.2.  Document Roadmap . . . . . . . . . . . . . . . .  9
   2.  Terminology  . . . . .  9
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .  9 10
   3.  Summary of Pre-Existing RFCs . . . . . . . . . . . . . . . . . 10 11
     3.1.  Encapsulation at Tunnel Ingress  . . . . . . . . . . . . . 10 11
     3.2.  Decapsulation at Tunnel Egress . . . . . . . . . . . . . . 12
   4.  New ECN Tunnelling Rules . . . . . . . . . . . . . . . . . . . 13
     4.1.  Default Tunnel Ingress Behaviour . . . . . . . . . . . . . 14 13
     4.2.  Default Tunnel Egress Behaviour  . . . . . . . . . . . . . 14
     4.3.  Design Principles for Future Non-Default Schemes  Encapsulation Modes  . . . . . 16
   5.  Backward Compatibility . . . . . . . . . . . . . . 16
     4.4.  Single Mode of Decapsulation . . . . . . 17
     5.1.  Non-Issues Upgrading Any Tunnel Decapsulation . . . . . . 18
     5.2.  Non-Issues for RFC4301 IPsec Encapsulation . . . 17
   5.  Changes from Earlier RFCs  . . . . . . . 18
     5.3.  Upgrading Other IP in IP Tunnel Encapsulators . . . . . . 19
   6.  Changes from Earlier RFCs . . . . . 18
     5.1.  Changes to RFC4301 ECN processing  . . . . . . . . . . . . 18
     5.2.  Changes to RFC3168 ECN processing  . 20
   7.  IANA Considerations . . . . . . . . . . . 19
     5.3.  Motivation for Changes . . . . . . . . . . 21
   8.  Security Considerations . . . . . . . . 19
       5.3.1.  Motivation for Changing Encapsulation  . . . . . . . . 20
       5.3.2.  Motivation for Changing Decapsulation  . . . 21
   9.  Conclusions . . . . . 21
   6.  Backward Compatibility . . . . . . . . . . . . . . . . . . . . 23
   10. Acknowledgements
     6.1.  Non-Issues Updating Decapsulation  . . . . . . . . . . . . 23
     6.2.  Non-Update of RFC4301 IPsec Encapsulation  . . . . . . . . 23
     6.3.  Update to RFC3168 Encapsulation  . . . 24
   11. Comments Solicited . . . . . . . . . . 24
   7.  Design Principles for Future Non-Default Schemes . . . . . . . 24
   8.  IANA Considerations  . . . . . 25
   12. References . . . . . . . . . . . . . . . . 26
   9.  Security Considerations  . . . . . . . . . . 25
     12.1. Normative References . . . . . . . . . 26
   10. Conclusions  . . . . . . . . . . 25
     12.2. Informative References . . . . . . . . . . . . . . . 27
   11. Acknowledgements . . . . . . 25
   Appendix A.  Design Constraints . . . . . . . . . . . . . . . . . 28
     A.1.  Security Constraints
   12. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 28
     A.2.  Control Constraints
   13. References . . . . . . . . . . . . . . . . . . . . . 30
     A.3.  Management Constraints . . . . . 29
     13.1. Normative References . . . . . . . . . . . . . 31 . . . . . . 29
     13.2. Informative References . . . . . . . . . . . . . . . . . . 29
   Appendix B.  Relative Placement of A.  Early ECN Tunnelling and In-Path Load
                Regulation RFCs . . . . . . . . . . . . . . 31
   Appendix B.  Design Constraints  . . . . . . . . 32
     B.1.  Identifiers and In-Path Load Regulators . . . . . . . . . 32
     B.2.  Non-Dependence of Tunnelling on In-path Load Regulation
     B.1.  Security Constraints . 33
     B.3.  Dependence of In-Path Load Regulation on Tunnelling . . . 34
   Appendix C.  Contribution to Congestion across a Tunnel . . . . . 37
   Appendix D.  Why Not Propagating ECT(1) on Decapsulation
                Impedes PCN . . . . . . . . . . 32
     B.2.  Control Constraints  . . . . . . . . . . . 38
     D.1.  Alternative Ways to Introduce the New Decapsulation
           Rules . . . . . . . . 34
     B.3.  Management Constraints . . . . . . . . . . . . . . . . . . 39 35
   Appendix C.  Contribution to Congestion across a Tunnel  . . . . . 36
   Appendix D.  Why Losing ECT(1) on Decapsulation Impedes PCN  . . . 36
   Appendix E.  Why Resetting CE ECN on Encapsulation Impedes PCN  . . . . 40
   Author's Address . 38
   Appendix F.  Compromise on Decap with ECT(1) Inner and ECT(0)
                Outer . . . . . . . . . . . . . . . . . . . . . . . . 40 39

Request to the RFC Editor (to be removed on publication):

   In the RFC index, RFC3168 should be identified as an update to
   RFC2481, RFC2401 and RFC2003.  RFC4301 should be identified as an
   update to RFC3168.

Changes from previous drafts (to be removed by the RFC Editor)

   Full text differences between IETF draft versions are available at
   <http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-ecn-tunnel/>, and
   between earlier individual draft versions at
   <http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html#ecn-tunnel>
   <http://www.briscoe.net/pubs.html#ecn-tunnel>

   From ietf-01 to ietf-02 to ietf-03 (current):

      *  Scope reduced from any encapsulation of an IP packet to solely
         IP  Functional changes:

         +  Corrected errors in IP tunnelled encapsulation.  Consequently changed title
         and removed whole section 'Design Guidelines for New
         Encapsulations recap of previous RFCs, which wrongly
            stated the different decapsulation behaviours of RFC3168 &
            RFC4301 with a Not-ECT inner header.  This also required
            corrections to the "Changes from Earlier RFCs" and the
            Motivations for these changes.

         +  Mandated that any future standards action SHOULD NOT use the
            ECT(0) codepoint as an indication of congestion, without
            giving strong reasons.

         +  Added optional alarm when decapsulating ECT(1) outer,
            ECT(0), but noted it would need to be disabled for
            2-severity level congestion (e.g.  PCN).

      *  Structural changes:

         +  Removed Document Roadmap which merely repeated the Contents
            (previously Section 1.2).

         +  Moved "Changes from Earlier RFCs" (Section 5) before
            Section 6 on Backward Compatibility and internally organised
            both by RFC, rather than by ingress then egress.

         +  Moved motivation for changing existing RFCs (Section 5.3) to
            after the changes are specified.

         +  Moved informative "Design Principles for Future Non-Default
            Schemes" after all the normative sections.

         +  Added Appendix A on early history of ECN tunnelling RFCs.

         +  Removed specialist appendix on "Relative Placement of
            Tunnelling and In-Path Load Regulation" (Appendix D in the
            -02 draft)

         +  Moved and updated specialist text on "Compromise on Decap
            with ECT(1) Inner and ECT(0) Outer" from Security
            Considerations to Appendix F

      *  Textual changes:

         +  Simplified vocabulary for non-native-english speakers

         +  Simplified Introduction and defined regularly used terms in
            an expanded Terminology section.

         +  More clearly distinguished statically configured tunnels
            from dynamic tunnel endpoint discovery, before explaining
            operating modes.

         +  Simplified, cut-down and clarified throughout

         +  Updated references.

   From ietf-01 to ietf-02:

      *  Scope reduced from any encapsulation of an IP packet to solely
         IP in IP tunnelled encapsulation.  Consequently changed title
         and removed whole section 'Design Guidelines for New
         Encapsulations of Congestion Notification' (to be included in a
         future companion informational document).

      *  Included a new normative decapsulation rule for ECT(0) inner
         and ECT(1) outer that had previously only been outlined in the
         non-normative appendix 'Comprehensive Decapsulation Rules'.
         Consequently:

         +  The Introduction has been completely re-written to motivate
            this change to decapsulation along with the existing change
            to encapsulation.

         +  The tentative text in the appendix that first proposed this
            change has been split between normative standards text in
            Section 4 and Appendix D, which explains specifically why
            this change would streamline PCN.  New text on the logic of
            the resulting decap rules added.

      *  If inner/outer is Not-ECT/ECT(0), changed decapsulation to
         propagate Not-ECT rather than drop the packet; and added
         reasoning.

      *  Considerably restructured:

         +  "Design Constraints" analysis moved to an appendix
            (Appendix A); B);

         +  Added Section 3 to summarise relevant existing RFCs;

         +  Structured Section 4 and Section 5 6 into subsections.

         +  Added tables to sections on old and new rules, for precision
            and comparison.

         +  Moved Section 4.3 7 on Design Principles to the end of the
            section specifying the new default normative tunnelling
            behaviour.  Rewritten and shifted text on identifiers and
            in-path load regulators to Appendix B.1. B.1 [deleted in revision
            -03].

   From ietf-00 to ietf-01:

      *  Identified two additional alarm states in the decapsulation
         rules (Figure 4) if ECT(X) in outer and inner contradict each
         other.

      *  Altered Comprehensive Decapsulation Rules (Appendix D) so that
         ECT(0) in the outer no longer overrides ECT(1) in the inner.
         Used the term 'Comprehensive' instead of 'Ideal'.  And
         considerably updated the text in this appendix.

      *  Added Appendix D.1 (removed again in a later revision) to weigh
         up the various ways the Comprehensive Decapsulation Rules might
         be introduced.  This replaces the previous contradictory
         statements saying complex backwards compatibility interactions
         would be introduced while also saying there would be no
         backwards compatibility issues.

      *  Updated references.

   From briscoe-01 to ietf-00:

      *  Re-wrote Appendix C giving much simpler technique to measure
         contribution to congestion across a tunnel.

      *  Added discussion of backward compatibility of the ideal
         decapsulation scheme in Appendix D

      *  Updated references.  Minor corrections & clarifications
         throughout.

   From -00 briscoe-00 to -01: briscoe-01:

      *  Related everything conceptually to the uniform and pipe models
         of RFC2983 on Diffserv Tunnels, and completely removed the
         dependence of tunnelling behaviour on the presence of any in-
         path load regulation by using the [1 - Before] [2 - Outer]
         function placement concepts from RFC2983;

      *  Added specific cases where the existing standards limit new
         proposals, particularly Appendix E;

      *  Added sub-structure to Introduction (Need for Rationalisation,
         Roadmap), added new Introductory subsection on "Scope" and
         improved clarity;

      *  Added Design Guidelines for New Encapsulations of Congestion
         Notification;

      *  Considerably clarified the Backward Compatibility section
         (Section 5); 6);

      *  Considerably extended the Security Considerations section
         (Section 8); 9);

      *  Summarised the primary rationale much better in the
         conclusions;

      *  Added numerous extra acknowledgements;

      *  Added Appendix E.  "Why resetting CE on encapsulation harms
         PCN", Appendix C.  "Contribution to Congestion across a Tunnel"
         and Appendix D.  "Ideal Decapsulation Rules";

      *  Re-wrote Appendix B.2, B [deleted in a later revision], explaining
         how tunnel encapsulation no longer depends on in-path load-regulation load-
         regulation (changed title from "In-path Load Regulation" to
         "Non-Dependence of Tunnelling on In-path Load Regulation"), but
         explained how an in-path load regulation function must be
         carefully placed with respect to tunnel encapsulation (in a new
         sub-section entitled "Dependence of In-Path Load Regulation on
         Tunnelling").

1.  Introduction

   This document redefines how the explicit

   Explicit congestion notification
   (ECN) field [RFC3168] in the IP header should be constructed for all
   IP in IP tunnelling.  Previously, tunnel endpoints blocked visibility
   of transitions of the ECN field except the minimum necessary to allow
   the basic ECN mechanism to work.  Three main change are defined, one
   on entry to and two on exit from any IP in IP tunnel.  The newly
   specified behaviours make all transitions to the ECN field visible
   across tunnel end-points, so tunnels no longer restrict new uses of
   the ECN field that were not envisaged when ECN was first designed.

   The immediate motivation for opening up the ECN behaviour of tunnels
   is because otherwise they impede the introduction of pre-congestion
   notification (PCN [I-D.ietf-pcn-marking-behaviour]) in networks with
   tunnels (Appendix E explains why).  But these changes are not just
   intended to ease the introduction of PCN; care has been taken to
   ensure the resulting ECN tunnelling behaviour is simple and generic
   for other potential future uses.

   Given this is a change to behaviour at 'the neck of the hourglass',
   an extensive analysis of the trade-offs between control, management
   and security constraints has been conducted in order to minimise
   unexpected side-effects both now and in the future.  Care has also
   been taken to ensure the changes are fully backwards compatible with
   all previous tunnelling behaviours.

   The ECN protocol (ECN [RFC3168]) allows a forwarding
   element to notify the onset of congestion of its resources without having to drop
   packets.  Instead it can explicitly mark a proportion of packets by setting the
   congestion experienced (CE) codepoint in
   the 2-bit ECN field in the IP header (see Table (Table 1 for a recap of recaps the ECN
   codepoints).

     +------------------+----------------+---------------------------+
     | Binary codepoint | Codepoint name | Meaning                   |
     +------------------+----------------+---------------------------+
     |        00        | Not-ECT        | Not ECN-capable transport |
     |        01        | ECT(1)         | ECN-capable transport     |
     |        10        | ECT(0)         | ECN-capable transport     |
     |        11        | CE             | Congestion experienced    |
     +------------------+----------------+---------------------------+

     Table 1: Recap of Codepoints of the ECN Field [RFC3168] in the IP
                                  Header

   The outer header

   The outer header of an IP packet can encapsulate one (or more)
   additional or more IP
   headers tunnelled within it. for tunnelling.  A forwarding element that
   is using ECN to signify
   congestion will only mark the outer IP header
   that is immediately visible to it. outer IP header.
   When a tunnel decapsulator later removes this outer header, it must follow
   follows rules to ensure propagate congestion markings by combining the marking
   is propagated into ECN
   fields of the inner and outer IP header being forwarded onwards, otherwise
   congestion notifications will disappear into a black hole leading to
   potential congestion collapse.

   The one outgoing IP header.

   This document updates those rules for constructing the ECN field IPsec [RFC4301] and non-IPsec
   [RFC3168] tunnels to be forwarded after tunnel
   decapsulation ensure this happens, but they are not wholly
   straightforward, add new behaviours for previously unused
   combinations of inner and neither are outer header.  It also updates the rules for encapsulating one IP
   header in another on entry tunnel
   ingress behaviour of RFC3168 to a tunnel.  The factor match that has
   introduced most complication at both ends of a RFC4301.  The updated
   rules are backward compatible with RFC4301 and RFC3168 when
   interworking with any other tunnel has been endpoint complying with any
   earlier specification.

   When ECN and its tunnelling was defined in RFC3168, only the
   possibility that minimum
   necessary changes to the ECN field might be used as a covert channel to
   compromise the integrity of an IPsec tunnel.

   A common use for IPsec is to create a secure were propagated through tunnel between two
   secure sites across
   endpoints--just enough for the public Internet.  A field like basic ECN mechanism to work.  This was
   due to concerns that can
   change as it traverses the Internet cannot be covered by IPsec's
   integrity mechanisms.  Therefore, the ECN field might be toggled
   (with two bits per packet) to communicate
   between a secure site and someone on the public Internet--a covert
   channel.

   Over the years covert channel restrictions have been added  This was because a mutable field like ECN cannot be
   protected by IPsec's integrity mechanisms--it has to be able to
   change as it traverses the
   design of ECN (with consequent backward compatibility complications).
   However Internet.

   Nonetheless, the latest IPsec architecture [RFC4301] takes the view that
   simplicity is more important than closing off the considers a
   bandwidth limit of 2 bits per packet on a covert channel
   threat, which makes it deems a
   manageable given its bandwidth is limited risk.  Therefore, for simplicity, an RFC4301 ingress
   copies the whole ECN field to
   two bits per packet.

   As encapsulate a result, an unfortunate sequence of standards actions has left us packet.  It also
   dispenses with nearly the worst of all possible combinations of outcomes,
   despite the best endeavours two modes of everyone concerned.  The new IPsec
   architecture [RFC4301] only updates RFC3168, one which partially copied
   the earlier specification of ECN
   tunnelling behaviour [RFC3168] for the case of IPsec tunnels.  For field, and the case other which blocked all propagation of non-IPsec tunnels the earlier RFC3168 specification still
   applies.  At the time RFC3168 was standardised, covert channels
   through the ECN field were restricted, whether or not IPsec was being
   used.  The
   changes.

   Unfortunately, this entirely reasonable sequence of standards actions
   resulted in a perverse position now is that outcome; non-IPsec tunnels restrict (RFC3168) blocked
   the 2-bit covert channels, channel, while IPsec tunnels don't.

   Actually, this statement needs some qualification.  IPsec tunnels
   only don't restrict the ECN covert channel (RFC4301) did not--at
   least not at the ingress.  At the
   tunnel egress, both IPsec and non-IPsec
   tunnels still partially restricted propagation of the presumption that the full ECN covert channel should be
   restricted has not been removed from any tunnelling specifications,
   whether IPsec or not.

   Now that these historic 2-bit covert channel constraints are impeding field.

   The trigger for the changes in this document was the introduction of PCN, this specification is designed
   pre-congestion notification (PCN [I-D.ietf-pcn-marking-behaviour]) to remove
   them and at
   the same time streamline IETF standards track.  PCN needs the whole ECN behaviour for the
   future.

1.1.  Scope

   This document only concerns wire protocol processing field to be copied at a
   tunnel
   endpoints ingress and makes no changes or recommendations concerning
   algorithms for it needs four states of congestion signalling to
   be propagated at the egress, but pre-existing tunnels only propagate
   three in the ECN field.

   This document draws on currently unused (CU) combinations of inner
   and outer headers to add tunnelling of four-state congestion
   signalling to RFC3168 and RFC4301.  Operators of tunnels who
   specifically want to support four states can require that all their
   tunnels comply with this specification.  Nonetheless, all tunnel
   endpoint implementations (RFC4301, RFC3168, RFC2481, RFC2401,
   RFC2003) can safely be updated to this new specification as part of
   general code maintenance.  This will gradually add support for four
   congestion states to the Internet.  Existing three state schemes will
   continue to work as before.

   At the same time as harmonising covert channel constraints, the
   opportunity has been taken to draw together diverging tunnel
   specifications into a single consistent behaviour.  Then any tunnel
   can be deployed unilaterally, and it will support the full range of
   congestion control and management schemes without any modes or
   configuration.  Further, any host or router can expect the ECN field
   to behave in the same way, whatever type of tunnel might intervene in
   the path.

1.1.  Scope

   This document only concerns wire protocol processing of the ECN field
   at tunnel endpoints and makes no changes or recommendations
   concerning algorithms for congestion marking or congestion response.

   This document specifies common, default common ECN field processing at encapsulation
   and decapsulation for any IP in IP tunnelling. tunnelling, whether IPsec or non-
   IPsec tunnels.  It applies irrespective of whether IPv4 or IPv6 is
   used for either of the inner and outer headers.  It applies to for
   packets with any destination address type, whether unicast or
   multicast.  It applies as the default for all Diffserv per-hop
   behaviours (PHBs), unless stated otherwise in the specification of a
   PHB.  It is intended to be a good trade off between somewhat
   conflicting security, control and management requirements.

   Nonetheless, if necessary, an alternate congestion encapsulation
   behaviour can be introduced as part of the definition of an alternate
   congestion marking scheme used by

   [RFC2983] is a specific Diffserv PHB (see S.5 of
   [RFC3168] and [RFC4774]).  When designing such new encapsulation
   schemes, the principles in Section 4.3 should be followed as closely
   as possible.  There is no requirement for a PHB to state anything
   about ECN tunnelling behaviour if the new default behaviour is
   sufficient.

   [RFC2983] is a comprehensive primer on differentiated services comprehensive primer on differentiated services and
   tunnels.  Given ECN raises similar issues to differentiated services
   when interacting with tunnels, useful concepts introduced in RFC2983
   are used throughout, with brief recaps of the explanations where
   necessary.

1.2.  Document Roadmap

   The body of the document focuses solely on standards actions
   impacting implementation.  Appendices record the analysis that
   motivates and justifies these actions.  The whole document is
   organised as follows:

   o  Section 3 recaps relevant existing RFCs and explains exactly why
      changes are needed, referring to Appendix D and Appendix E in
      order to explain in detail why current tunnelling behaviours
      impede PCN deployment, at egress and ingress respectively.

   o  Section 4 uses precise standards terminology to specify the new
      ECN tunnelling behaviours.  It refers to Appendix A for analysis
      of the trade-offs between security, control and management design
      constraints that led to these particular standards actions.

   o  Extending the new IPsec tunnel ingress behaviour to all IP in IP
      tunnels requires consideration of backwards compatibility, which
      is covered in Section 5 and detailed changes from earlier RFCs are
      brought together in Section 6.

   o  Finally, a number of security considerations are discussed and
      conclusions are drawn.

   o  Additional specialist issues are deferred to appendices in
      addition to those already referred to above, in particular
      Appendix B discusses specialist tunnelling issues that could arise
      when ECN is fed back to a load regulation function on a middlebox,
      rather than at the source of the path.

2.  Requirements Language  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

3.  Summary of Pre-Existing RFCs

   This section is informative not normative.  It merely

   Table 1 recaps pre-
   existing RFCs to help motivate changing these behaviours.  Earlier
   relevant RFCs that were either experimental or incomplete with
   respect to the names of the ECN tunnelling (RFC2481, RFC2401 and RFC2003) are not
   discussed, although the backwards compatibility considerations in
   Section 5 take them into account.  The question codepoints [RFC3168].

     +------------------+----------------+---------------------------+
     | Binary codepoint | Codepoint name | Meaning                   |
     +------------------+----------------+---------------------------+
     |        00        | Not-ECT        | Not ECN-capable transport |
     |        01        | ECT(1)         | ECN-capable transport     |
     |        10        | ECT(0)         | ECN-capable transport     |
     |        11        | CE             | Congestion experienced    |
     +------------------+----------------+---------------------------+

     Table 1: Recap of whether tunnel
   implementations used Codepoints of the ECN Field [RFC3168] in the Internet comply with any of these RFCs is
   also not discussed.

3.1.  Encapsulation at Tunnel Ingress IP
                                  Header

   Further terminology used within this document:

   Encapsulator:  The controversy at tunnel ingress has been over whether endpoint function that adds an outer IP
      header to propagate
   information about congestion experienced on the path upstream of tunnel a packet (also termed the 'ingress tunnel ingress into
      endpoint' or just the outer header of 'ingress' where the tunnel.

   Specifically, RFC3168 says that, if a context is clear).

   Decapsulator:  The tunnel fully supports ECN
   (termed endpoint function that removes an outer IP
      header from a 'full-functionality' ECN tunnel in [RFC3168]), tunnelled packet (also termed the 'egress tunnel
   ingress must not copy a CE marking from
      endpoint' or just the inner 'egress' where the context is clear).

   Incoming header:  The header into of an arriving packet before
      encapsulation.

   Outer header:  The header added to encapsulate a tunnelled packet.

   Inner header:  The header encapsulated by the outer header.

   Outgoing header:  The header constructed by the decapsulator using
      logic that it creates.  Instead combines the tunnel ingress must set fields in the outer and inner headers.

   Copying ECN:  On encapsulation, setting the ECN field of the new
      outer header to ECT(0) (i.e. codepoint 10) if be a copy of the ECN field is
   marked CE (codepoint 11) in the arriving IP incoming header.  We term this
   'resetting' a CE codepoint.

   However,

   Zeroing ECN:  On encapsulation, clearing the ECN field of the new
      outer header to Not-ECT ("00").

   Resetting ECN:  On encapsulation, setting the ECN field of the new
      outer header to be a copy of the ECN field in the incoming header
      except the outer ECN field is set to the ECT(0) codepoint if the
      incoming ECN field is CE ("11").

3.  Summary of Pre-Existing RFCs

   This section is informative not normative, as it recaps pre-existing
   RFCs.  Earlier relevant RFCs that were either experimental or
   incomplete with respect to ECN tunnelling (RFC2481, RFC2401 and
   RFC2003) are briefly outlined inAppendix A.  The question of whether
   tunnel implementations used in the Internet comply with any of these
   RFCs is not discussed.

3.1.  Encapsulation at Tunnel Ingress

   At the encapsulator, the controversy has been over whether to
   propagate information about congestion experienced on the path so far
   into the outer header of the tunnel.

   Specifically, RFC3168 says that, if a tunnel fully supports ECN
   (termed a 'full-functionality' ECN tunnel in [RFC3168]), the
   encapsulator must not copy a CE marking from the inner header into
   the outer header that it creates.  Instead the encapsulator must set
   the outer header to ECT(0) if the ECN field is marked CE in the
   arriving IP header.  We term this 'resetting' a CE codepoint.

   However, the new IPsec architecture in [RFC4301] reverses this rule,
   stating that the tunnel ingress encapsulator must simply copy the ECN field from the arriving
   incoming header to the outer header.  The main purpose of the present
   specification is to carry the new behaviour of IPsec over to all IP
   in IP tunnels, so all tunnel ingress nodes consistently copy the ECN
   field.

   RFC3168 also provided a Limited Functionality mode that turns off ECN
   processing over the scope of the tunnel.  This is necessary if the
   ingress does not know whether the tunnel egress supports propagation
   of by setting the outer header
   to Not-ECT ("00").  Then such packets will be dropped to indicate
   congestion rather than marked with ECN.  This is necessary for the
   ingress to interwork with legacy decapsulators ([RFC2481], [RFC2401]
   and [RFC2003]) that do not propagate ECN markings. markings added to the outer
   header.  Otherwise such legacy decapsulators would throw away
   congestion notifications before they reached the transport layer.

   Neither Limited Functionality mode nor Full Functionality mode are
   used in by an RFC4301 IPsec. IPsec encapsulator, which simply copies the
   incoming ECN field into the outer header.  An earlier key-exchange
   phase ensures an RFC4301 ingress will not have to interwork with a
   legacy egress that does not support ECN.

   These pre-existing behaviours are summarised in Figure 1.

    +-----------------+-----------------------------------------------+
    | Incoming Header |             Outgoing Outer Header             |
    | (also equal to  +---------------+---------------+---------------+
    | Outgoing Inner  |  RFC3168 ECN  |  RFC3168 ECN  | RFC4301 IPsec |
    |     Header)     |    Limited    |     Full      |               |
    |                 | Functionality | Functionality |               |
    +-----------------+---------------+---------------+---------------+
    |    Not-ECT      |   Not-ECT     |   Not-ECT     |   Not-ECT     |
    |     ECT(0)      |   Not-ECT     |    ECT(0)     |    ECT(0)     |
    |     ECT(1)      |   Not-ECT     |    ECT(1)     |    ECT(1)     |
    |       CE        |   Not-ECT     |    ECT(0)     |      CE       e|       |
    +-----------------+---------------+---------------+---------------+

    Figure 1: IP in IP Encapsulation: Recap of Pre-existing Behaviours

   For encapsulation,

3.2.  Decapsulation at Tunnel Egress

   RFC3168 and RFC4301 specify the specification decapsulation behaviour summarised in Section 4 below brings all IP
   Figure 2.  The ECN field in IP tunnels (v4 or v6) into line with the way IPsec tunnels
   [RFC4301] now construct outgoing header is set to the ECN field, except where a legacy tunnel
   egress might not understand ECN
   codepoint at all.  This removes the now
   redundant full functionality mode in the middle column intersection of Figure 1.
   Wherever possible it ensures that the outer appropriate incoming inner
   header reveals any
   congestion experienced so far on the whole path, not just since the
   last tunnel ingress.

   Why does it matter if we have different ECN encapsulation behaviours
   for IPsec and non-IPsec tunnels?  A general answer is that gratuitous
   inconsistency constrains the available design space and makes it
   harder to design networks (row) and new protocols that work predictably.

   But there is also a specific need not to reset the incoming outer header (column).
            +---------+------------------------------------------------+
            |Incoming |            Incoming Outer Header               |
            |   Inner +---------+------------+------------+------------+
            |  Header | Not-ECT | ECT(0)     | ECT(1)     |     CE codepoint.  The
   standards track proposal for excess rate pre-congestion notification
   (PCN [I-D.ietf-pcn-marking-behaviour]) only works correctly in the
   presence of RFC4301 IPsec encapsulation or [RFC5129] MPLS
   encapsulation, but not with RFC3168 IP in IP encapsulation
   (Appendix E explains why).  The PCN architecture
   [I-D.ietf-pcn-architecture] states that the regular RFC3168 rules for
   IP in IP tunnelling of the ECN field should not be used for PCN.  But
   if non-IPsec tunnels are already present within a network to which
   PCN is being added, that is not particularly helpful advice.

   The present specification provides a clean solution to this problem,
   so that network operators who want to use PCN and tunnels can specify
   that all tunnel endpoints in a PCN region need to be upgraded to
   comply with this specification.  Also, whether using PCN or not, as
   more tunnel endpoints comply with this specification, it should make
   ECN behaviour simpler, faster and more predictable.

   To ensure copying rather than resetting CE on ingress will not cause
   unintended side-effects, Appendix A assesses whether either harm any
   security, control or management functions.  It finds that resetting
   CE makes life difficult in a number of directions, while copying CE
   harms nothing (other than opening a low bit-rate covert channel
   vulnerability which the IETF Security Area now deems is manageable).

3.2.  Decapsulation at Tunnel Egress

   Both RFC3168 and RFC4301 specify the decapsulation behaviour
   summarised in Figure 2.  The ECN field in the outgoing header is set
   to the codepoint at the intersection of the appropriate incoming
   inner header (row) and incoming outer header (column).
    +------------------+----------------------------------------------+
    |  Incoming Inner  |             Incoming Outer Header            |
    |      Header      +---------+------------+------------+----------+
    |     |
            +---------+---------+------------+------------+------------+
   RFC3168->| Not-ECT |   ECT(0)   |   ECT(1)   |    CE Not-ECT |Not-ECT     |Not-ECT     |
    +------------------+---------+------------+------------+----------+   drop     |
   RFC4301->| Not-ECT | Not-ECT |Not-ECT     |Not-ECT     |Not-ECT     |   drop(!!!)|   drop(!!!)| drop(!!!)|
            |  ECT(0) |  ECT(0) | ECT(0)     | ECT(0)     |     CE     |
            |  ECT(1) |  ECT(1) | ECT(1)     | ECT(1)     |     CE     |
            |    CE   |      CE |     CE     |     CE     |     CE     |
    +------------------+---------+------------+------------+----------+
            +---------+---------+------------+------------+------------+
                      |               Outgoing Header                  |
                       +----------------------------------------------+
                      +------------------------------------------------+

     Figure 2: IP in IP Decapsulation; Recap of Pre-existing Behaviour

   The behaviour in the table derives from the logic given in RFC3168,
   briefly recapped RFC3168
   and RFC4301, briefly recapped as follows:

   o  On decapsulation, if the inner ECN field is Not-ECT but the outer
      ECN field is anything except Not-ECT
      discarded.  RFC3168 (but not RFC4301) also specified that the
      decapsulator must drop
      the packet.  Drop is mandated because known legal protocol
      transitions should not be able to lead to these cases (indicated a packet with a Not-ECT inner and CE in the table by '(!!!)'), therefore the decapsulator may also
      raise an alarm;
      outer.

   o  In all other cases, if the outer is CE, the outgoing ECN field is
      set to the more
      severe marking of CE, but otherwise the outer is ignored and the inner is
      used for the outgoing ECN fields, where field.

   RFC3168 also made it an auditable event for an IPsec tunnel "if the
      ranking of severity from highest to lowest
   ECN Field is CE, ECT, Not-ECT;

   o  ECT(0) and ECT(1) are considered of equal severity (indicated by
      just 'ECT' changed inappropriately within an IPsec tunnel...".
   Inappropriate changes were not specifically enumerated.  RFC4301 did
   not mention inappropriate ECN changes.

4.  New ECN Tunnelling Rules

   The standards actions below in the rank order above).  Where the inner Section 4.1 (ingress encapsulation)
   and outer Section 4.2 (egress decapsulation) define new default ECN fields are both ECT but they differ, the tunnel
   processing rules for any IP packet is forwarded (v4 or v6) with the codepoint any Diffserv
   codepoint.

   If absolutely necessary, an alternate congestion encapsulation
   behaviour can be introduced as part of the inner ECN field, which prevents ECT
      codepoints being definition of an alternate
   congestion marking scheme used for by a covert channel.

   The specification for decapsulation specific Diffserv PHB (see S.5 of
   [RFC3168] and [RFC4774]).  When designing such new encapsulation
   schemes, the principles in Section 4 fixes two problems
   with this pre-existing behaviour:

   o  Firstly, forwarding 7 should be followed.  However,
   alternate ECN tunnelling schemes are NOT RECOMMENDED as the codepoint
   deployment burden of the inner header handling exceptional PHBs in the cases
      where both inner and outer are different values implementations of ECT effectively
      implies that any distinction between ECT(0) and ECT(1) cannot
   all affected tunnels should not be
      introduced in the future wherever underestimated.  There is no
   requirement for a tunnel might be deployed.
      Therefore, the currently specified tunnel decapsulation PHB definition to state anything about ECN
   tunnelling behaviour
      unnecessarily wastes one of four codepoints (effectively wasting
      half a bit) in if the IP (v4 & v6) header.  As explained default behaviour in
      Appendix A.1, the original reason present
   specification is sufficient.

4.1.  Default Tunnel Ingress Behaviour

   Two modes of encapsulation are defined here; `normal mode' and
   `compatibility mode', which is for backward compatibility with tunnel
   decapsulators that do not using the outer ECT
      codepoints for onward forwarding was to limit understand ECN.  Section 4.3 explains why
   two modes are necessary and specifies the covert channel
      across a decapsulator circumstances in which it
   is sufficient to 1 bit per packet.  However, now solely implement normal mode.  Note that these are
   modes of the
      IETF Security Area has deemed that a 2-bit covert channel through ingress tunnel endpoint only, not the whole tunnel.

   Whatever the mode, an encapsulator is a manageable risk, forwards the same should be true for
      a decapsulator.

      As well as being a general future-proofing issue, this problem is
      immediately pressing for standardisation of pre-congestion
      notification (PCN).  PCN solutions generally require three
      encoding states in addition to Not-ECT: one for 'not marked' and
      two increasingly severe levels of marking.  Although inner header without
   changing the ECN field
      gives sufficient codepoints for these three states, they cannot
      all be used for PCN because a change between ECT(0) and ECT(1) in
      any tunnelled packet would be lost when field.

   In normal mode an encapsulator compliant with this specification MUST
   construct the outer encapsulating IP header was
      decapsulated, dangerously discarding congestion signalling.  A
      number of wasteful or convoluted work-rounds to this problem are
      being considered for standardisation by the PCN working group (see
      Appendix D), but by far the simplest approach is just to remove copying the covert channel blockages from tunnelling behaviour, that are
      now deemed unnecessary anyway.  Not only will this streamline PCN
      standardisation, but it could also streamline other future uses of
      these codepoints.

   o  Secondly, mandating drop is not always a good idea just because a
      combination 2-bit ECN
   field of headers seems invalid.  There are many cases where the incoming IP header.  In compatibility mode it has become nearly impossible to deploy new standards because
      legacy middleboxes drop packets carrying header values they don't
      expect.  Where possible, clears the new decapsulation behaviour specified
      in Section 4 below is more liberal
   ECN field in its response the outer header to unexpected
      combinations of headers.

4.  New ECN Tunnelling Rules

   The ECN tunnel processing the Not-ECT codepoint.  These rules below in Section 4.1 (ingress
   encapsulation) and Section 4.2 (egress decapsulation)
   are the default tabulated for a packet with any DSCP.  If required, different ECN encapsulation
   rules MAY be defined as part of the definition of an appropriate
   Diffserv PHB using the guidelines that follow in Section 4.3.
   However, the deployment burden of handling exceptional PHBs convenience in
   implementations of all affected tunnels and lower layer link
   protocols should not be underestimated.

4.1.  Default Tunnel Ingress Behaviour

   A tunnel ingress compliant with this specification MUST implement a
   `normal mode'.  It might also need to implement a `compatibility
   mode' for backward compatibility with legacy tunnel egresses that do
   not understand ECN (see Section 5 for when compatibility mode is
   required).  Note that these are modes of the ingress tunnel endpoint
   only, not the tunnel as a whole.

   Whatever the mode, the tunnel ingress forwards the inner header
   without changing the ECN field.  In normal mode a tunnel ingress
   compliant with this specification MUST construct the outer
   encapsulating IP header by copying the 2-bit ECN field of the
   arriving IP header.  In compatibility mode it clears the ECN field in
   the outer header to the Not-ECT codepoint.  These rules are tabulated
   for convenience in Figure 3.
            +-----------------+-------------------------------+
            | Incoming Header |     Outgoing Outer Header     |
            | (also equal Figure 3.

            +-----------------+-------------------------------+
            | Incoming Header |     Outgoing Outer Header     |
            | (also equal to  +---------------+---------------+
            | Outgoing Inner  | Compatibility |    Normal     |
            |     Header)     |     Mode      |     Mode      |
            +-----------------+---------------+---------------+
            |    Not-ECT      |   Not-ECT     |   Not-ECT     |
            |     ECT(0)      |   Not-ECT     |    ECT(0)     |
            |     ECT(1)      |   Not-ECT     |    ECT(1)     |
            |       CE        |   Not-ECT     |      CE       |
            +-----------------+---------------+---------------+

              Figure 3: New IP in IP Encapsulation Behaviours

   Compatibility

   An ingress in compatibility mode is the same per packet behaviour as the encapsulates packets identically to
   an ingress
   end of in RFC3168's limited functionality mode.  Normal mode is the same
   per packet behaviour as the  An ingress end of in
   normal mode encapsulates packets identically to an RFC4301 IPsec. IPsec
   ingress.

4.2.  Default Tunnel Egress Behaviour

   To decapsulate the inner header at the tunnel egress, a compliant
   tunnel egress MUST set the outgoing ECN field to the codepoint at the
   intersection of the appropriate incoming inner header (row) and outer
   header (column) in Figure 4.

    +------------------+----------------------------------------------+
    |  Incoming Inner 4 (the IPv4 header checksum also changes
   whenever the ECN field is changed).  There is no need for more than
   one mode of decapsulation, as these rules cater for all known
   requirements.
            +---------+------------------------------------------------+
            |Incoming |            Incoming Outer Header               |
            |      Header      +---------+------------+------------+----------+   Inner +---------+------------+------------+------------+
            |  Header | Not-ECT | ECT(0)     | ECT(1)     |     CE     |
    +------------------+---------+------------+------------+----------+
            +---------+---------+------------+------------+------------+
            | Not-ECT | Not-ECT |Not-ECT(!!!)|   drop(!!!)|   drop(!!!)|
            |  ECT(0) |  ECT(0) | ECT(0)     | ECT(1)     | ECT(1)(!!!)|     CE     |
            |  ECT(1) |  ECT(1) | ECT(1)(!!!)| ECT(1)     |     CE     |
            |    CE   |      CE |     CE     |     CE(!!!)|     CE     |
    +------------------+---------+------------+------------+----------+
            +---------+---------+------------+------------+------------+
                      |               Outgoing Header                  |
                       +----------------------------------------------+
                      +------------------------------------------------+
             Unexpected combinations are indicated by '(!!!)'

              Figure 4: New IP in IP Decapsulation Behaviour

   This table for decapsulation behaviour is derived from the following
   logic:

   o  If the inner ECN field is Not-ECT the decapsulator MUST NOT
      propagate any other ECN codepoint in the outer header onwards.  This is because the
      inner Not-ECT marking is set by transports that use drop as an
      indication of congestion and would not understand the or respond to
      any other ECN protocol.  Instead: codepoint [RFC4774].  In addition:

      *  If the inner ECN field is Not-ECT and the outer ECN field is
         ECT(1) or CE the decapsulator MUST drop the packet.
         Reasoning: these combinations of codepoints either imply some
         illegal protocol transition has occurred within

      *  If the tunnel, or
         that some locally defined mechanism inner ECN field is being used within the
         tunnel that might be signalling congestion.  In either case,
         the only appropriate signal to the transport is a packet drop.
         It would have been nice to allow packets with ECT(1) in the
         outer to be forwarded, but drop has had to be mandated in case
         future multi-level ECN schemes are defined.  Then ECT(1) and CE
         can be used in the future to signify two levels of congestion
         severity.

      *  If the inner ECN field is Not-ECT and Not-ECT and the outer ECN field is
         ECT(0) or Not-ECT the decapsulator MUST forward the outgoing
         packet with the ECN field cleared to Not-ECT.
         Reasoning: Although no known legal protocol transition would
         lead to ECT(0) in the outer and Not-ECT in

      *  This specification mandates that any future standards action
         SHOULD NOT use the inner, no known
         or proposed protocol uses ECT(0) codepoint as a congestion signal either.
         Therefore in this case an indication of
         congestion, without giving strong reasons, given the packet can be forwarded rather than
         dropped, which will allow future standards actions to use this
         combination. above rule
         forwards an ECT(0) outer as Not-ECT.

   o  In all other cases, cases where the inner supports ECN, the outgoing ECN
      field is set to the more severe marking of the outer and inner ECN
      fields, where the ranking of severity from highest to lowest is
      CE, ECT(1), ECT(0),
      Not-ECT;

   o  There are Not-ECT.  This in no way precludes cases where no
      ECT(1) and ECT(0) have the same severity;

   o  Certain combinations of inner and outer ECN fields cannot result
      from any currently legal used transition in any current or previous ECN
      tunneling specification would result in certain
      combinations of inner and outer ECN fields. specification.  These cases are indicated in Figure 4 by
      '(!!!)').  In these cases, the decapsulator SHOULD log the event
      and MAY also raise an alarm, but
      not alarm.  Alarms should be rate-limited so often
      that the illegal combinations would will not amplify into a flood of
      alarm messages.  It MUST be possible to suppress alarms or
      logging, e.g. if it becomes apparent that a combination that
      previously was not used has started to be used for legitimate
      purposes such as a new standards action.  An example is an ECT(0)
      inner combined with an ECT(1) outer, which is proposed as a legal
      combination for PCN [I-D.ietf-pcn-3-in-1-encoding], so an operator
      that deploys support for PCN should turn off logging and alarms in
      this case.

   The above logic allows for ECT(0) and ECT(1) to both represent the
   same severity of congestion marking (e.g. "not congestion marked").
   But it also allows future schemes to be defined where ECT(1) is a
   more severe marking than ECT(0).  This approach is discussed in
   Appendix D and in the discussion of the ECN nonce [RFC3540] in
   Section 8. 9, which in turn refers to Appendix F.

4.3.  Design Principles for Future Non-Default Schemes

   This section is informative not normative.

   S.5  Encapsulation Modes

   Section 4.1 introduces two encapsulation modes, normal mode and
   compatibility mode, defining their encapsulation behaviour (i.e.
   header copying or zeroing respectively).  Note that these are modes
   of RFC3168 permits the Diffserv codepoint (DSCP)[RFC2474] to
   'switch in' different behaviours for marking ingress tunnel endpoint only, not the ECN field, just tunnel as
   it switches in different per-hop behaviours (PHBs) for scheduling.
   Therefore here we give guidance for designing possibly different
   marking schemes.

   In one word the guidance is "Don't".  If a scheme requires tunnels to whole.

   A tunnel ingress MUST at least implement special processing of the ECN field for certain DSCPs, `normal mode' and, if it
   is highly unlikely that every implementer of every
   might be used with legacy tunnel will want
   to add the required exception and that operators will want to deploy egress nodes (RFC2003, RFC2401 or
   RFC2481 or the required configuration options.  Therefore limited functionality mode of RFC3168), it is highly likely
   that some tunnels within a network will not MUST also
   implement this special
   case.  Therefore, designers should avoid non-default tunnelling
   schemes if at all possible.

   That said, if a non-default scheme `compatibility mode' for processing the ECN field is
   really required, the following guidelines may prove useful in its
   design:

   o  For any new scheme, a backward compatibility with tunnel ingress should
   egresses that do not set propagate explicit congestion notifications
   [RFC4774].  If the egress does support propagation of ECN field (full
   functionality mode of RFC3168 or RFC4301 or the outer header if it cannot guarantee that any corresponding
      tunnel egress will understand how present
   specification), the ingress SHOULD use normal mode, in order to handle such an
   support ECN field.

   o  On encapsulation in any new scheme, where possible.

   We can categorise the way that an outer header capable ingress tunnel endpoint is paired
   with an egress as either:

   static:   those paired together by prior configuration or;

   dynamically discovered:  those paired together by some form of
      carrying congestion markings should reflect accumulated congestion
      since tunnel
      endpoint discovery, typically driven by the last interface designed path taken by arriving
      packets.

   Static: Some implementations of encapsulator might be constrained to regulate load (see
      Appendix A.2 for
   be statically deployed, and constrained to never be paired with a
   legacy decapsulator (RFC2003, RFC2401 or RFC2481 or the definition limited
   functionality mode of RFC3168).  In such a Load Regulator, case, only normal mode
   needs to be implemented.

   For instance, RFC4301-compatible IPsec tunnel endpoints invariably
   use IKEv2 [RFC4306] for key exchange, which was introduced alongside
   RFC4301.  Therefore both endpoints of an RFC4301 tunnel can be sure
   that the other end is
      usually but not always RFC4301-compatible, because the data source).  This implies that new
      schemes for tunnelling congestion notification should copy
      congestion notification into tunnel is only
   formed after IKEv2 key management has completed, at which point both
   ends will be RFC4301-compliant by definition.  Further, an RFC4301
   encapsulator behaves identically to the outer header normal mode of each new
      encapsulating header that supports it.

      Reasoning: The constraints from the three perspectives of
      security, control present
   specification and management in Appendix A are somewhat in
      tension does not need to implement compatibility mode as it
   will never interact with legacy ECN tunnels.

   Dynamic Discovery: This specification does not require or recommend
   dynamic discovery and it does not define how dynamic negotiation
   might be done, but it recognises that proprietary tunnel endpoint
   discovery protocols exist.  It therefore sets down some constraints
   on discovery protocols to whether a ensure safe interworking.

   If dynamic tunnel endpoint discovery might pair an ingress should copy congestion
      markings into the outer header it creates with a
   legacy egress (RFC2003, RFC2401 or RFC2481 or reset them.  From the
      control perspective either copying or resetting works for existing
      arrangements, but copying has more potential for simplifying
      control.  From the management perspective copying is preferable.
      From limited
   functionality mode of RFC3168), the security perspective resetting is preferable but copying
      is now considered acceptable given ingress MUST implement both
   normal and compatibility mode.  If the bandwidth of a 2-bit covert
      channel can be managed.  Therefore, on balance, copying tunnel discovery process is simpler
      and more useful than resetting and does minimal harm.

   o  For any new scheme,
   arranged to only ever find a tunnel egress should not forward any that propagates ECN
      codepoint if the arriving inner header implies
   (RFC3168 full functionality mode, RFC4301 or this present
   specification), then a tunnel ingress can be complaint with the transport will
      not understand how to process it.

   o  On decapsulation in any new scheme, if
   present specification without implementing compatibility mode.

   If a combination of inner and
      outer headers compliant tunnel ingress is encountered that should not have been possible,
      this event should be logged and discovering an alarm raised.  But egress, it MUST send
   packets in compatibility mode in case the packet
      should still be forwarded with egress it discovers is a safe codepoint setting if at all
      possible.  This increases
   legacy egress.  If, through the chances of 'forward compatibility'
      with possible future protocol extensions.

   o  On decapsulation in any new scheme, discovery protocol, the ECN field egress
   indicates that it is compliant with the tunnel
      egress forwards should reflect present specification, with
   RFC4301 or with RFC3168 full functionality mode, the more severe congestion marking
      of ingress can
   switch itself into normal mode.  If the arriving inner and outer headers.

5.  Backward Compatibility

   Note: in RFC3168, a whole tunnel was considered in one egress denies compliance with
   any of two modes:
   limited functionality these or full functionality.  The new modes defined returns an error that implies it does not understand
   a request to work to any of these ECN specifications, the tunnel
   ingress MUST remain in compatibility mode.

   An ingress cannot claim compliance with this specification are only modes of simply by
   disabling ECN processing across the tunnel ingress.  The new
   tunnel egress behaviour has (i.e. only one mode and doesn't need to know
   what mode the implementing
   compatibility mode).  It is true that such a tunnel ingress is in.

5.1.  Non-Issues Upgrading Any Tunnel Decapsulation

   This specification only changes the egress per-packet calculation of at
   least safe with the ECN field for combinations behaviour of inner and outer headers that have
   so far not been used in any IETF protocols.  Therefore, a tunnel egress complying with any previous specification (RFC4301, both modes
   of RFC3168, both modes it may encounter, but
   it does not meet the aim of RFC2481, RFC2401 and RFC2003) can be
   upgraded introducing ECN support to comply with this new decapsulation specification without
   any backwards compatibility issues.

   The proposed tunnel egress behaviour also requires no additional mode
   or option configuration at tunnels.

   Implementation note: if a compliant node is the ingress or for multiple
   tunnels, a mode setting will need to be stored for each tunnel
   ingress.  However, if a node is the egress nor any additional
   negotiation with for multiple tunnels, none
   of the ingress.  A tunnels will need to store a mode setting, because a compliant tunnel
   egress merely needs
   to implement the one behaviour can only be in Section 4.  The reduction to one mode.

4.4.  Single Mode of Decapsulation

   A compliant decapsulator only has one mode at the of operation.  However, if
   a complaint egress has no backwards compatibility issues, because
   previously the egress produced the same output whichever mode the is implemented to be dynamically discoverable, it
   may need to respond to discovery requests from various types of
   legacy tunnel was in.

   These new decapsulation rules have been defined in such ingress.  This specification does not define how
   dynamic negotiation might be done by (proprietary) discovery
   protocols, but it sets down some constraints to ensure safe
   interworking.

   Through the discovery protocol, a way that
   congestion control will still work safely if any of tunnel ingress compliant with the earlier
   versions of ECN processing are used unilaterally at
   present specification might ask if the encapsulating
   ingress of egress is compliant with the tunnel (any of RFC2003, RFC2401, either mode of
   RFC2481, either mode of RFC3168, RFC4301 and this
   present
   specification).  If a specification, with RFC4301 or with RFC3168 full
   functionality mode.  Or an RFC3168 tunnel ingress tries might try to
   negotiate to use limited functionality mode or full functionality mode [RFC3168],
   [RFC3168].  In all these cases, a decapsulating tunnel egress
   compliant with this specification MUST agree to either request, as its behaviour any of these
   requests, since it will be the same behave identically in both all these cases.

   For 'forward compatibility', a compliant tunnel egress SHOULD raise a
   warning about any requests to enter modes it doesn't recognise, but
   it can continue operating.

   If no ECN-related mode is requested, a compliant tunnel egress can MUST
   continue without raising any error or warning as its egress behaviour
   is compatible with all the legacy ingress behaviours that don't do not
   negotiate capabilities.

5.2.  Non-Issues for

   For 'forward compatibility', a compliant tunnel egress SHOULD raise a
   warning alarm about any requests to enter modes it does not
   recognise, but it SHOULD continue operating.

5.  Changes from Earlier RFCs

5.1.  Changes to RFC4301 ECN processing

   Ingress:  An RFC4301 IPsec Encapsulation encapsulator is not changed at all by the
      present specification

   Egress:  The new normal mode of ingress decapsulation behaviour defined above (Section 4.1)
   brings all IP in IP tunnels into line with [RFC4301].  If one end Figure 4 updates RFC4301.
      However, it solely updates combinations of
   an IPsec tunnel is compliant with [RFC4301], inner and outer that
      have never been used on the other end is
   guaranteed to also be RFC4301-compliant (there could be corner cases
   where manual keying is used, but Internet, even though they will be set aside here).
   Therefore were
      defined in RFC4301 for completeness.  Therefore, the present
      specification adds new normal ingress behaviour introduces no backward
   compatibility isses behaviours to RFC4301 decapsulation without
      altering existing behaviours.  The following specific updates have
      been made:

      *  The outer, not the inner, is propagated when the outer is
         ECT(1) and the inner is ECT(0);

      *  A packet with IKEv2 [RFC4306] IPsec [RFC4301] tunnels, Not-ECT in the inner and
   no need for any new modes, options an outer of ECT(1) or configuration.

5.3.  Upgrading Other IP in IP Tunnel Encapsulators

   At CE
         is dropped rather than forwarded as Not-ECT;

      *  Certain combinations of inner and outer ECN field have been
         identified as currently unused.  These can trigger logging
         and/or raise alarms.

   Modes:  RFC4301 does not need modes and is not updated by the tunnel ingress, this specification effectively extends modes
      in the
   scope present specification.  The normal mode of RFC4301's encapsulation is
      unchanged from RFC4301 encapsulation and an RFC4301 IPsec ingress behaviour to any IP
      will never need compatibility mode as explained in IP tunnel.  If any
   other IP Section 4.3
      (except in IP tunnel one corner-case described below).
      One corner case can exist where an RFC4301 ingress (i.e. does not use
      IKEv2, but uses manual keying instead.  Then an RFC4301 IPsec) is upgraded to ingress
      could conceivably be compliant with this specification, it has configured to cater tunnel to an egress with
      limited functionality ECN handling.  Strictly, for this corner-
      case, the
   possibility that it is talking requirement to use compatibility mode in this
      specification updates RFC4301.  However, this is such a legacy tunnel egress that may not
   know how remote
      possibility that in general RFC4301 IPsec implementations are NOT
      REQUIRED to process the ECN field.  If implement compatibility mode.

5.2.  Changes to RFC3168 ECN capable outer headers were
   sent towards processing

   Ingress:  On encapsulation, the new rule in Figure 3 that a legacy (e.g.  [RFC2003]) egress, it would most likely
   simply disregard normal
      mode tunnel ingress copies any ECN field into the outer headers, dangerously discarding
   information about congestion experienced within header
      updates the tunnel.  ECN-
   capable traffic sources would not see any congestion feedback and
   instead continually ratchet up their share ingress behaviour of RFC3168.  Nonetheless, the bandwidth without
   realising that cross-flows from other ECN sources were continually
   having to ratchet down.

   This specification introduces no new backward
      compatibility issues
   when a compliant ingress talks with a legacy egress, but it has to
   provide similar sfaeguards to those already defined in RFC3168.
   Therefore, mode is identical to comply with this specification, a tunnel ingress that
   does not always know the ECN capability of its tunnel egress MUST
   implement a 'normal' limited functionality mode and a 'compatibility' mode, and for safety
   it MUST initiate each negotiated tunnel
      of RFC3168.

   Egress:  The new decapsulation behaviour in compatibility mode. Figure 4 updates RFC3168.
      However, a tunnel ingress can be compliant even if it only implements the 'normal mode' present specification solely updates combinations of encapsulation behaviour, but only as long as it
   is designed or configured so
      inner and outer that all possible tunnel egress nodes it
   will ever talk to will have at least full ECN functionality
   (complying with either never been used on the Internet, even
      though they were defined in RFC3168 full functionality mode, RFC4301 or
   this for completeness.  Therefore,
      the present specification).

   Before switching specification adds new behaviours to normal mode, a compliant tunnel ingress that does
   not know the egress ECN capability MUST negotiate with the tunnel
   egress.  If RFC3168
      decapsulation without altering existing behaviours.  The following
      specific updates have been made:

      *  The outer, not the egress says it inner, is compliant with this specification
   or propagated when the outer is
         ECT(1) and the inner is ECT(0);

      *  A packet with Not-ECT in the inner and an outer of ECT(1) is
         dropped rather than forwarded as Not-ECT;

      *  Certain combinations of inner and outer ECN field have been
         identified as currently unused.  These can trigger logging
         and/or raise alarms.

   Modes:  RFC3168 defines a (required) limited functionality mode and
      an (optional) full functionality mode, mode for a tunnel.  In RFC3168,
      modes applied to both ends of the ingress puts itself into
   normal mode.  If tunnel, while in the present
      specification, modes are only used at the ingress--a single egress denies compliance with
      behaviour covers all cases.  The normal mode of these or
   doesn't understand the question, encapsulation
      updates the tunnel ingress MUST remain in
   compatibility mode.

   The encapsulation rules for normal behaviour of the full functionality mode and
      of RFC3168.  The compatibility mode are
   defined in Section 4 (i.e. header copying or zeroing respectively).

   An ingress cannot claim compliance with this specification simply by
   disabling ECN processing across the tunnel (only implementing
   compatibility mode).  Although such a tunnel ingress of encapsulation is at least safe
   with identical
      to the ECN encapsulation behaviour of any egress it may encounter (any of
   RFC2003, RFC2401, either mode of RFC2481 and RFC3168's the limited functionality mode), it doesn't meet the aim mode
      of introducing ECN.

   Therefore, a compliant tunnel ingress MUST at least implement `normal
   mode' and, if it might be used with arbitrary RFC3168.  The constraints on how tunnel egress nodes, it
   MUST also implement `compatibility mode'.

   Implementation note: if a compliant node is the ingress for multiple
   tunnels, a mode setting will need discovery protocols set
      modes in Section 4.3 and Section 4.4 are an update to be stored RFC3168.

5.3.  Motivation for each tunnel
   ingress.  However, if a node Changes

   An overriding goal is to ensure the egress for multiple tunnels, none
   of same ECN signals can mean the
   same thing whatever tunnels will need happen to store a mode setting, because a compliant
   egress can only be in one mode.

6.  Changes from Earlier RFCs

   On encapsulation, encapsulate an IP packet flow.
   This removes gratuitous inconsistency, which otherwise constrains the rule
   available design space and makes it harder to design networks and new
   protocols that a work predictably.

5.3.1.  Motivation for Changing Encapsulation

   The normal mode tunnel ingress MUST
   copy any ECN field into the outer header is a change in Section 4 updates RFC3168 to the ingress
   behaviour make all IP in IP
   encapsulation of RFC3168, but it is the same as ECN field consistent--consistent with the rules for way
   both RFC4301 IPsec
   tunnels [RFC4301] and IP in RFC4301.

   On decapsulation, the rules for calculating MPLS or MPLS in MPLS
   encapsulation [RFC5129] construct the outgoing ECN field at field.

   Compatibility mode has also been defined so a non-RFC4301 ingress can
   still switch to using drop across a tunnel egress are similar for backwards
   compatibility with legacy decapsulators that do not propagate ECN
   correctly.

   The trigger that motivated this update to RFC3168 encapsulation was a
   standards track proposal for pre-congestion notification (PCN
   [I-D.ietf-pcn-marking-behaviour]).  PCN excess rate marking only
   works correctly if the full functionality mode of ECN field is copied on encapsulation (as in
   RFC3168
   RFC4301 and to RFC4301, with the following exceptions:

   o  The outer, RFC5129); it does not the inner, work if ECN is propagated when the outer reset (as in
   RFC3168).  This is ECT(1)
      and the inner is ECT(0);

   o  A packet with Not-ECT in the inner may be forwarded as Not-ECT
      rather than dropped, if because PCN excess rate marking depends on the
   outer is ECT(0);

   o  The following extra illegal combinations have been identified,
      which may require logging and/or an alarm: outer ECT(1) with inner
      CE; outer ECT(0) with inner ECT(1)

   The rules header revealing any congestion experienced so far on the whole
   path, not just since the last tunnel ingress (see Appendix E for how a tunnel establishes whether the egress has
   full
   functionality ECN capabilities are an update explanation).

   PCN allows a network operator to RFC3168.  For all add flow admission and termination
   for inelastic traffic at the edges of a Diffserv domain, but without
   any per-flow mechanisms in the interior and without the generous
   provisioning typical cases, RFC4301 is not updated by of Diffserv, aiming to significantly reduce
   costs.  The PCN architecture [RFC5559] states that RFC3168 IP in IP
   tunnelling of the ECN capability check field cannot be used for any tunnel ingress in
   this
   a PCN domain.  Prior to the present specification, because this left a typical RFC4301 tunnel ingress will
   have already established that it is talking stark
   choice between not being able to an RFC4301 tunnel
   egress (e.g. if it uses IKEv2).  However, there may be some corner
   cases (e.g. manual keying) where an RFC4301 tunnel ingress talks with
   an egress with limited functionality ECN handling.  Strictly, use PCN for
   such corner cases, the requirement inelastic traffic
   control or not being able to use compatibility mode in this the many tunnels already deployed
   for Mobile IP, VPNs and so forth.

   The present specification updates RFC4301, but this is unlikely to be necessary provides a clean solution to implement for this corner case in practice.

   The optional ECN Tunnel field in the IPsec security association
   database (SAD) and the optional ECN Tunnel Security Association
   Attribute defined in RFC3168 are no longer needed.  The security
   association (SA) has no policy on ECN usage, because all RFC4301
   tunnels now support ECN without any policy choice.

   RFC3168 defines a (required) limited functionality mode problem,
   so that network operators who want to use both PCN and an
   (optional) full functionality mode for a tunnel, but RFC4301 doesn't
   need modes.  In this specification only the tunnels can
   specify that every tunnel ingress might need two
   modes: in a normal mode (required) PCN region must comply with
   this latest specification.

   Rather than allow tunnel specifications to fragment further into one
   for PCN, one for IPsec and a compatibility mode (required in
   some scenarios, optional in others).  The egress needs only one mode
   which correctly handles any ingress ECN behaviour.

Additional changes for other tunnels, the opportunity has
   been taken to consolidate the RFC Index (to be removed diverging specifications back into a
   single tunnelling behaviour.  Resetting ECN was originally motivated
   by a covert channel concern that has been deliberately set aside in
   RFC4301 IPsec.  Therefore the RFC Editor):

   In the RFC index, reset behaviour of RFC3168 should be identified as is an update
   anomaly that we do not need to
   RFC2003.  RFC4301 should keep.  Copying ECN on encapsulation is
   anyway simpler than resetting.  So, as more tunnel endpoints comply
   with this single consistent specification, encapsulation will be identified
   simpler as an update to RFC3168.

   This specification updates RFC3168 and RFC4301.

7.  IANA Considerations

   This memo includes no request to IANA.

8.  Security Considerations well as more predictable.

   Appendix A.1 discusses the security constraints imposed B assesses whether copying rather than resetting CE on ECN tunnel
   processing.  The new rules for ECN tunnel processing (Section 4)
   trade-off between security (covert channels) and congestion
   monitoring & control.  In fact, ensuring congestion markings are not
   lost is itself another aspect
   ingress will cause any unintended side-effects, from the three
   perspectives of security, because if we allowed
   congestion notification to be lost, any attempt to enforce a response
   to congestion would be much harder.

   If alternate congestion notification semantics are defined control and management.  In summary this
   analysis finds that:

   o  From the control perspective either copying or resetting works for a
   certain PHB (e.g.
      existing arrangements, but copying has more potential for
      simplifying control and resetting breaks at least one proposal
      already on the pre-congestion notification architecture
   [I-D.ietf-pcn-architecture]), standards track.

   o  From the scope management and monitoring perspective copying is
      preferable.

   o  From the traffic security perspective (enforcing congestion
      control, mitigating denial of service etc) copying is preferable.

   o  From the alternate semantics
   might typically be bounded by information security perspective resetting is preferable,
      but the limits IETF Security Area now considers copying acceptable given
      the bandwidth of a Diffserv region or
   regions, as envisaged in [RFC4774]. 2-bit covert channel can be managed.

   Therefore there are two points against resetting CE on ingress while
   copying CE causes no harm (other than opening a 2-bit covert channel
   that is deemed manageable).

5.3.2.  Motivation for Changing Decapsulation

   The inner headers specification for decapsulation in tunnels
   crossing Section 4 fixes three problems
   with the boundary pre-existing behaviours of such a Diffserv region but ending within the
   region can potentially leak the external congestion notification
   semantics into the region, or leak both RFC3168 and RFC4301:

   1.  The pre-existing rules prevented the internal introduction of alternate
       ECN semantics out to signal more than one severity level of
       congestion [RFC4774], [RFC5559].  The four states of the
   region.  [RFC2983] discusses the need 2-bit
       ECN field provide room for Diffserv traffic
   conditioning signalling two severity levels in
       addition to be applied at these tunnel endpoints as if they are
   at the edge of not-congested and not-ECN-capable states.  But, the Diffserv region.  Similar concerns apply to any
   processing or propagation
       pre-existing rules assumed that two of the ECN field at the edges of a Diffserv
   region with alternate ECN semantics.  Such edge processing must also
   be applied at states (ECT(0) and
       ECT(1)) are always equivalent.  This unnecessarily restricts the endpoints
       use of tunnels with one end inside and the
   other outside the domain.  [I-D.ietf-pcn-architecture] gives specific
   advice on this for the PCN case, but other definitions of alternate
   semantics will need to discuss the specific security implications in
   each case.

   With the decapsulation rules as they stood in RFC3168 and RFC4301, four codepoints (half a
   small part of the protection of bit) in the ECN nonce [RFC3540] was
   compromised. IP (v4 & v6)
       header.  The new decapsulation rules do not solve this problem.

   The minor problem is as follows: The ECN nonce was defined to enable
   the data source are designed to detect if a CE marking had been applied then
   subsequently removed.  The source could detect this by weaving a
   pseudo-random sequence of ECT(0) and work in either case;
       whether ECT(1) values into a stream of
   packets, which is termed an ECN nonce.  By the decapsulation rules more severe than or equivalent to ECT(0).

       As explained in
   RFC3168 and RFC4301, if Appendix B.1, the original reason for not
       forwarding the inner and outer headers carry
   contradictory ECT values only codepoints was to limit the inner header is preserved for
   onward forwarding.  So if covert
       channel across a CE marking added decapsulator to 1 bit per packet.  However, now
       that the outer ECN field
   in a tunnel IETF Security Area has been illegally (or accidentally) suppressed by deemed that a
   subsequent node in the tunnel, the decapsulator will revert the ECN
   field to its value before tampering, hiding all evidence of the crime
   from the onward feedback loop.  We chose not to close this minor
   loophole for all the following reasons:

   1.  This loophole 2-bit covert
       channel through an encapsulator is only applicable in the corner case where the
       attacker controls a network node downstream of a congested node
       in manageable risk, the same tunnel;

   2.  In tunnelling scenarios, the ECN nonce
       should be true for a decapsulator.

       As well as being useful for general future-proofing, this problem
       is already vulnerable to
       suppression by nodes downstream immediately pressing for standardisation of pre-congestion
       notification (PCN), which uses two severity levels of congestion.
       If a congested node in the same
       tunnel, if they can copy the ECT value queue used ECT(1) in the inner header to the outer header (any node in to signal
       more severe congestion than ECT(0), the tunnel can do pre-existing
       decapsulation rules would have thrown away this if the inner
       header is not encrypted, and an IPsec tunnel egress can do congestion
       signal, preventing tunnelled traffic from ever knowing that it
       whether
       should reduce its load.

       The PCN working group has had to consider a number of wasteful or not
       convoluted work-rounds to this problem (see Appendix D).  But by
       far the tunnel simplest approach is encrypted);

   3.  Although just to remove the new decapsulation behaviour removes evidence of
       congestion suppression covert channel
       blockages from the onward feedback loop, the
       decapsulator itself tunnelling behaviour--now deemed unnecessary
       anyway.  Then network operators that want to support two
       congestion severity-levels for PCN can at least detect specify that every tunnel
       egress in a PCN region must comply with this latest
       specification.

       Not only does this make two congestion within severity-levels available
       for PCN standardisation, but also for other potential uses of the tunnel has been suppressed;

   4.  The
       extra ECN nonce [RFC3540] currently has experimental status and
       there has been no evidence codepoint (e.g.  [VCP]).

   2.  Cases are documented where a middlebox (e.g. a firewall) drops
       packets with header values that anyone has implemented it beyond were currently unused (CU) when
       the author's prototype.

   We could have fixed this loophole by specifying that box was deployed, often on the outer header
   should always grounds that anything
       unexpected might be propagated onwards if an attack.  This tends to bar future use of
       CU values.  The new decapsulation rules specify optional logging
       and/or alarms for specific combinations of inner and outer header
       that are both ECT.
   Although this would close currently unused.  The aim is to give implementers a
       recourse other than drop if they are concerned about the minor loophole in security
       of CU values.  It recognises legitimate security concerns about
       CU values but still eases their future use.  If the nonce, it would
   raise alarms are
       interpreted as an attack (e.g. by a minor safety issue management system) the
       offending packets can be dropped.  But alarms can be turned off
       if multilevel ECN or PCN were used.  A
   less severe marking in these combinations come into use (e.g. a through a future
       standards action).

   3.  While reviewing currently unused combinations of inner and outer,
       the opportunity was taken to define a single consistent behaviour
       for the cases with a Not-ECT inner header would override but a more severe
   one in the different outer.  Both are corner cases so
       RFC3168 and RFC4301 had diverged in this respect.  These
       combinations should not result from known Internet protocols.
       So, for safety, it is difficult was decided to decide
   which is more important:

   1.  The loophole drop a packet if the outer
       carries codepoints CE or ECT(1) that respectively signal
       congestion or could potentially signal congestion in a scheme
       progressing through the nonce is IETF [I-D.ietf-pcn-3-in-1-encoding].
       Given an inner of Not-ECT implies the transport only for understands
       drop as a minor case signal of one tunnel
       node attacking another in congestion, this was the same tunnel;

   2.  The severity inversion for multilevel congestion notification safest course of
       action.

   Problems 2 & 3 alone would not result from any legal codepoint transition.

   We decided safety against misconfiguration was slightly more
   important than securing against an attack that has little, if any,
   clear motivation.

   If a legacy security policy configures a legacy tunnel ingress to
   negotiate to turn off ECN processing, warrant a compliant tunnel egress will
   agree to a request change to turn off ECN processing decapsulation, but
   it will actually
   still copy CE markings from was decided they are worth fixing and making consistent at the outer
   same time as decapsulation code is changed to fix problem 1 (two
   congestion severity-levels).

6.  Backward Compatibility

   A tunnel endpoint compliant with the forwarded header.
   Although the present specification is
   backward compatible when paired with any tunnel ingress 'I' endpoint compliant
   with any previous tunnelling RFC, whether RFC4301, RFC3168 (see
   Section 3) or the earlier RFCs summarised in Figure 5 (Appendix A.1) will set
   all Appendix A (RFC2481,
   RFC2401 and RFC2003).  Each case is enumerated below.

6.1.  Non-Issues Updating Decapsulation

   At the egress, this specification only augments the per-packet
   calculation of the ECN fields in field (RFC3168 and RFC4301) for combinations
   of inner and outer headers that have so far not been used in any IETF
   protocols.

   Therefore, all other things being equal, if an RFC4301 IPsec egress
   is updated to Not-ECT, 'M' could comply with the new rules, it will still toggle CE
   on interwork with
   any RFC4301 compliant ingress and off the packet outputs will be
   identical to communicate covertly with 'B', because we have
   specified that 'E' only has one mode regardless of what mode it says those it has negotiated.  We could have specified that 'E' should would have a
   limited functionality mode and check for such behaviour.  But we
   decided not output before (fully backward
   compatible).

   And, all other things being equal, if an RFC3168 egress is updated to add
   comply with the extra complexity of two modes on a same new rules, it will still interwork with any
   ingress complying with any previous specification (both modes of
   RFC3168, both modes of RFC2481, RFC2401 and RFC2003) and the packet
   outputs will be identical to those it would have output before (fully
   backward compatible).

   A compliant tunnel egress merely needs to cater for a legacy security concern that is
   now considered manageable.

9.  Conclusions

   This document updates implement the ingress tunnelling encapsulation of RFC3168
   ECN for all IP one behaviour
   in IP tunnels to bring it into line Section 4 with no additional mode or option configuration at the new
   behaviour in
   ingress or egress nor any additional negotiation with the IPsec architecture of RFC4301.  It copies rather
   than resets a congestion experienced (CE) marking when creating outer
   headers.

   It also specifies ingress.
   The new decapsulation rules have been defined in such a way that update both RFC3168 and RFC4301 for
   calculating
   congestion control will still work safely if any of the outgoing earlier
   versions of ECN field on processing are used unilaterally at the encapsulating
   ingress of the tunnel decapsulation.  The (any of RFC2003, RFC2401, either mode of
   RFC2481, either mode of RFC3168, RFC4301 and this present
   specification).

6.2.  Non-Update of RFC4301 IPsec Encapsulation

   An RFC4301 IPsec ingress can comply with this new
   rules specification
   without any update egress behaviour for two specific combinations of inner and outer header that have it has no current legal usage, but need for any new modes, options or
   configuration.  So, all other things being equal, it will now be
   possible continue to use in future standards actions, rather than being wasted
   by current tunnelling behaviour.

   The new rules propagate changes
   interwork identically with any egress it worked with before (fully
   backward compatible).

6.3.  Update to RFC3168 Encapsulation

   The encapsulation behaviour of the ECN field across tunnel end-
   points that were previously blocked due to a perceived covert channel
   vulnerability.  The new IPsec architecture deems the two-bit covert
   channel that normal mode copies the ECN
   field opens up is a manageable threat, so these
   new rules bring whereas RFC3168 full functionality mode reset it.  However, all IP in IP tunnelling into line with this new more
   permissive attitude.  The result
   other things being equal, if RFC3168 ingress is a single specification for all
   future tunnelling of ECN, whether IPsec or not.  Then equipment can
   be specified against a single ECN behaviour and ECN markings can have
   a well-defined meaning wherever they are measured in a network.  This
   new certainty will enable new uses of updated to the ECN field that would
   otherwise
   present specification, the outgoing packets from any tunnel egress
   will still be confounded by ambiguity.

   The immediate motivation for making these changes unchanged.  This is to allow the
   introduction because all variants of multi-level pre-congestion notification (PCN).  But
   great care has been taken to ensure the resulting ECN tunnelling
   behaviour is simple
   at either end (RFC4301, both modes of RFC3168, both modes of RFC2481,
   RFC2401, RFC2003 and generic for other potential future uses.

   The change to encapsulation has been analysed from the three
   perspectives of security, control present specification) have always
   propagated an incoming CE marking through the inner header and management.  They are somewhat
   in tension as to whether a tunnel ingress should copy congestion
   markings onward
   into the outgoing header, whether the outer header it creates or is reset them.  From the
   control perspective either copying or resetting works for existing
   arrangements, but copying has more potential for simplifying control
   and resetting breaks at least one proposal already on the standards
   track.  From
   copied.  Therefore, If the management and monitoring perspective copying tunnel is
   preferable.  From the network security perspective (theft of service
   etc) copying is preferable.  From the information security
   perspective resetting is preferable, but the IETF Security Area now
   considers copying acceptable given the bandwidth of considered as a 2-bit covert
   channel can black box, the
   packets output from any egress will be managed.  Therefore there are no points against
   copying and a number against resetting CE on identical with or without an
   update to the ingress.

   The only downside of  Nonetheless, if packets are observed within
   the changes to decapsulation is that black box (between the same
   2-bit covert channel is opened up as at tunnel endpoints), CE markings copied by
   the ingress, but this is now
   deemed to updated ingress will be a manageable threat.  The changes at decapsulation visible within the black box, whereas
   they would not have been found before.  Therefore, the update to
   encapsulation can be free of any termed 'black-box backwards compatible' (i.e.
   identical unless you look inside the tunnel).

   This specification introduces no new backward compatibility issues.

10.  Acknowledgements

   Thanks to Anil Agawaal for pointing out a case where it's safe for issues
   when a
   tunnel decapsulator to forward compliant ingress talks with a combination of headers legacy egress, but it doesn't
   understand.  Thanks to David Black for explaining a better way to
   think about function placement and to Louise Burness for a better way has to think about multilayer transports and networks, having read
   [Patterns_Arch].  Also thanks
   provide similar safeguards to Arnaud Jacquet for the idea for
   Appendix C.  Thanks those already defined in RFC3168.
   RFC3168 laid down rules to Michael Menth, Bruce Davie, Toby Moncaster,
   Gorry Fairhurst, Sally Floyd, Alfred Hoenes and Gabriele Corliano for
   their thoughts and careful review comments.

   Bob Briscoe ensure that an RFC3168 ingress turns off
   ECN (limited functionality mode) if it is partly funded by Trilogy, paired with a research project (ICT-
   216372) supported by the European Community under its Seventh
   Framework Programme. legacy egress
   (RFC 2481, RFC2401 or RFC2003), which would not propagate ECN
   correctly.  The views expressed here are present specification carries forward those of the
   author only.

11.  Comments Solicited

   Comments rules
   (Section 4.3).  It uses compatibility mode whenever RFC3168 would
   have used limited functionality mode, and questions their per-packet behaviours
   are encouraged and very welcome.  They can be
   addressed to identical.  Therefore, all other things being equal, an ingress
   using the IETF Transport Area working group mailing list
   <tsvwg@ietf.org>, and/or to new rules will interwork with any legacy tunnel egress in
   exactly the authors.

12.  References

12.1.  Normative References

   [RFC2003]  Perkins, C., "IP Encapsulation within IP", RFC 2003,
              October 1996.

   [RFC2119]  Bradner, S., "Key words same way as an RFC3168 ingress (still black-box backward
   compatible).

7.  Design Principles for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
              "Definition Future Non-Default Schemes

   This section is informative not normative.

   S.5 of RFC3168 permits the Differentiated Services Field (DS
              Field) in the IPv4 and IPv6 Headers", RFC 2474,
              December 1998.

   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
              of Explicit Congestion Notification (ECN) Diffserv codepoint (DSCP)[RFC2474] to IP",
              RFC 3168, September 2001.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture
   'switch in' alternative behaviours for marking the
              Internet Protocol", RFC 4301, December 2005.

12.2.  Informative References

   [I-D.briscoe-pcn-3-in-1-encoding]
              Briscoe, B., "PCN 3-State Encoding Extension in a single
              DSCP", draft-briscoe-pcn-3-in-1-encoding-00 (work ECN field, just as
   it switches in
              progress), October 2008.

   [I-D.charny-pcn-single-marking]
              Charny, A., Zhang, X., Faucheur, F., and V. Liatsos, "Pre-
              Congestion Notification Using Single Marking different per-hop behaviours (PHBs) for Admission
              and  Termination", draft-charny-pcn-single-marking-03
              (work in progress), November 2007.

   [I-D.ietf-pcn-architecture]
              Eardley, P., "Pre-Congestion Notification (PCN)
              Architecture", draft-ietf-pcn-architecture-10 (work in
              progress), March 2009.

   [I-D.ietf-pcn-baseline-encoding]
              Moncaster, T., Briscoe, B., scheduling.
   [RFC4774] gives best current practice for designing such alternative
   ECN semantics and M. Menth, "Baseline
              Encoding very briefly mentions that tunnelling should be
   considered.  Here we give additional guidance on designing alternate
   ECN semantics that would also require alternate tunnelling semantics.

   In one word the guidance is "Don't".  If a scheme requires tunnels to
   implement special processing of the ECN field for certain DSCPs, it
   is highly unlikely that every implementer of every tunnel will want
   to add the required exception and Transport that operators will want to deploy
   the required configuration options.  Therefore it is highly likely
   that some tunnels within a network will not implement the required
   special case.  Therefore, designers of Pre-Congestion Information",
              draft-ietf-pcn-baseline-encoding-02 (work new protocols should avoid
   non-default tunnelling schemes if at all possible.

   That said, if a non-default scheme for tunnelling the ECN field is
   really required, the following guidelines may prove useful in progress),
              February 2009.

   [I-D.ietf-pcn-marking-behaviour]
              Eardley, P., "Marking behaviour its
   design:

   On encapsulation in any new scheme:

      1.  The ECN field of PCN-nodes",
              draft-ietf-pcn-marking-behaviour-02 (work the outer header should be cleared to Not-ECT
          ("00") unless it is guaranteed that the corresponding tunnel
          egress will correctly propagate congestion markings introduced
          across the tunnel in progress),
              March 2009.

   [I-D.ietf-pwe3-congestion-frmwk]
              Bryant, S., Davie, B., Martini, L., the outer header.

      2.  If it has established that ECN will be correctly propagated,
          an encapsulator should also copy incoming congestion
          notification into the outer header.  The general principle
          here is that the outer header should reflect congestion
          accumulated along the whole upstream path, not just since the
          tunnel ingress (Appendix B.3 on management and E. Rosen,
              "Pseudowire Congestion Control Framework",
              draft-ietf-pwe3-congestion-frmwk-01 (work in progress),
              May 2008.

   [I-D.menth-pcn-psdm-encoding]
              Menth, M., Babiarz, J., Moncaster, T., monitoring
          explains).

          In some circumstances (e.g. pseudowires, PCN), the whole path
          is divided into segments, each with its own congestion
          notification and B. Briscoe,
              "PCN Encoding feedback loop.  In these cases, the function
          that regulates load at the start of each segment will need to
          reset congestion notification for Packet-Specific Dual Marking (PSDM)",
              draft-menth-pcn-psdm-encoding-00 (work in progress),
              July 2008.

   [I-D.moncaster-pcn-3-state-encoding]
              Moncaster, T., Briscoe, B., its segment.  Often the
          point where congestion notification is reset will also be
          located at the start of a tunnel.  However, the resetting
          function should be thought of as being applied to packets
          after the encapsulation function--two logically separate
          functions even though they might run on the same physical box.
          Then the code module doing encapsulation can keep to the
          copying rule and M. Menth, "A three state
              extended PCN encoding scheme",
              draft-moncaster-pcn-3-state-encoding-01 (work the load regulator module can reset
          congestion, without any code in
              progress), March 2009.

   [I-D.satoh-pcn-st-marking]
              Satoh, D., Maeda, Y., Phanachet, O., and H. Ueno, "Single
              PCN Threshold Marking by using PCN baseline encoding for
              both  admission and termination controls",
              draft-satoh-pcn-st-marking-01 (work either module being
          conditional on whether the other is there.

   On decapsulation in progress),
              March 2009.

   [IEEE802.1au]
              IEEE, "IEEE Standard for Local any new scheme:

      1.  If the arriving inner header is Not-ECT it implies the
          transport will not understand other ECN codepoints.  If the
          outer header carries an explicit congestion marking, the
          packet should be dropped--the only indication of congestion
          the transport will understand.  If the outer carries any other
          ECN codepoint the packet can be forwarded, but only as Not-
          ECT.

      2.  If the arriving inner header is other than Not-ECT, the ECN
          field that the tunnel egress forwards should reflect the more
          severe congestion marking of the arriving inner and Metropolitan Area
              Networks--Virtual Bridged Local Area Networks - Amendment
              10: Congestion Notification", 2008,
              <http://www.ieee802.org/1/pages/802.1au.html>.

              (Work in Progress; Access Controlled link within page)

   [ITU-T.I.371]
              ITU-T, "Traffic Control outer
          headers.

      3.  If a combination of inner and Congestion Control outer headers is encountered
          that is not currently used in B-ISDN",
              ITU-T Rec. I.371 (03/04), March 2004.

   [PCNcharter]
              IETF, "Congestion known standards, this event
          should be logged and Pre-Congestion Notification (pcn)",
              IETF w-g charter , Feb 2007,
              <http://www.ietf.org/html.charters/pcn-charter.html>.

   [Patterns_Arch]
              Day, J., "Patterns in Network Architecture: A Return an alarm raised.  This is a preferable
          approach to
              Fundamentals", Pub: Prentice Hall ISBN-13: 9780132252423,
              Jan 2008.

   [RFC1254]  Mankin, A. and K. Ramakrishnan, "Gateway Congestion
              Control Survey", RFC 1254, August 1991.

   [RFC2205]  Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
              Functional Specification", RFC 2205, September 1997.

   [RFC2983]  Black, D., "Differentiated Services and Tunnels",
              RFC 2983, October 2000.

   [RFC3426]  Floyd, S., "General Architectural and Policy
              Considerations", RFC 3426, November 2002.

   [RFC3540]  Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
              Congestion Notification (ECN) Signaling with Nonces",
              RFC 3540, June 2003.

   [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
              RFC 4306, December 2005.

   [RFC4423]  Moskowitz, R. and P. Nikander, "Host Identity Protocol
              (HIP) Architecture", RFC 4423, May 2006.

   [RFC4774]  Floyd, S., "Specifying Alternate Semantics for the
              Explicit Congestion Notification (ECN) Field", BCP 124,
              RFC 4774, November 2006.

   [RFC5129]  Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion
              Marking dropping currently unused combinations in MPLS", RFC 5129, January 2008.

   [Shayman]  "Using ECN to Signal Congestion Within case
          they represent an MPLS Domain",
              2000, <http://www.ee.umd.edu/~shayman/papers.d/
              draft-shayman-mpls-ecn-00.txt>.

              (Expired) attack.  The new scheme should try to define
          a way to forward such packets, but only if a safe outgoing
          codepoint can be defined.

8.  IANA Considerations

   This memo includes no request to IANA.

9.  Security Considerations

   Appendix A.  Design Constraints

   Tunnel B.1 discusses the security constraints imposed on ECN tunnel
   processing.  The new rules for ECN tunnel processing (Section 4)
   trade-off between information security (covert channels) and
   congestion monitoring & control.  In fact, ensuring congestion
   markings are not lost is itself another aspect of a security, because
   if we allowed congestion notification field has to meet be lost, any attempt to
   enforce a response to congestion control and management needs without creating new
   information security vulnerabilities (if information would be much harder.

   Specialist security is
   required).  This appendix documents issues:

   Tunnels intersecting Diffserv regions with alternate ECN semantics:
      If alternate congestion notification semantics are defined for a
      certain Diffserv PHB, the analysis scope of the tradeoffs
   between these factors that led to the new encapsulation rules in
   Section 4.1.

A.1.  Security Constraints

   Information security can alternate semantics might
      typically be assured bounded by using various end to end
   security solutions (including IPsec the limits of a Diffserv region or
      regions, as envisaged in transport mode [RFC4301]), but [RFC4774] (e.g. the pre-congestion
      notification architecture [RFC5559]).  The inner headers in
      tunnels crossing the boundary of such a commonly used scenario involves Diffserv region but ending
      within the need to communicate between two
   physically protected domains across region can potentially leak the public Internet.  In this
   case there are certain management advantages external congestion
      notification semantics into the region, or leak the internal
      semantics out of the region.  [RFC2983] discusses the need for
      Diffserv traffic conditioning to using IPsec in be applied at these tunnel
   mode solely across
      endpoints as if they are at the publicly accessible part edge of the path.  The
   path followed by a packet then crosses security 'domains'; the ones
   protected by physical Diffserv region.
      Similar concerns apply to any processing or other means before and after propagation of the tunnel ECN
      field at the edges of a Diffserv region with alternate ECN
      semantics.  Such edge processing must also be applied at the
      endpoints of tunnels with one end inside and the one protected by an IPsec tunnel across other outside the otherwise unprotected
      domain.  We  [RFC5559] gives specific advice on this for the PCN case,
      but other definitions of alternate semantics will use need to discuss
      the scenario specific security implications in Figure 5 where endpoints 'A' and
   'B' communicate through a tunnel.  The each case.

   ECN nonce tunnel ingress 'I' and egress
   'E' are within physically protected edge domains, while coverage:  The new decapsulation rules improve the tunnel
   spans an unprotected internetwork where there may be 'men in
      coverage of the
   middle', M.

                physically       unprotected     physically
            <-protected domain-><--domain--><-protected domain->
            +------------------+            +------------------+
            |                  |      M     |                  |
            |    A-------->I=========>==========>E-------->B   |
            |                  |            |                  |
            +------------------+            +------------------+
                                <----IPsec secured---->
                                        tunnel

                      Figure 5: IPsec Tunnel Scenario

   IPsec encryption is typically used to prevent 'M' seeing messages
   from 'A' ECN nonce [RFC3540] relative to 'B'.  IPsec authentication the previous rules
      in RFC3168 and RFC4301.  However, nonce coverage is used to prevent 'M'
   masquerading still not
      perfect, as the sender of messages from 'A' to 'B' or altering
   their contents.  But 'I' can also use IPsec tunnel mode to allow 'A'
   to communicate with 'B', but impose encryption this would have led to prevent 'A' leaking
   information a safety problem in another
      case.  Both are corner-cases, so discussion of the compromise
      between them is deferred to 'M'.  Or 'E' can insist that 'I' uses Appendix F.

   Covert channel not turned off:  A legacy (RFC3168) tunnel mode
   authentication to prevent 'M' communicating information ingress
      could ask an RFC3168 egress to 'B'.
   Mutable IP header fields such as the turn off ECN field (as processing as well as
      itself turning off ECN.  An egress compliant with the present
      specification will agree to such a request from a legacy ingress,
      but it relies on the TTL/
   Hop Limit and DS fields) cannot be included ingress solely sending Not-ECT in the cryptographic
   calculations of IPsec.  Therefore, if 'I' copies these mutable fields
   into outer.
      If the outer header that is exposed across egress receives other ECN codepoints in the tunnel outer it will have
   allowed a covert channel
      process them as normal, so it will actually still copy congestion
      markings from 'A' the outer to M that bypasses its encryption
   of the inner outgoing header.  And if 'E' copies these fields from  Referring for
      example to Figure 5 (Appendix B.1), although the tunnel ingress
      'I' will set all ECN fields in outer
   header headers to the inner, even if Not-ECT, 'M' could
      still toggle CE or ECT(1) on and off to communicate covertly with
      'B', because we have specified that 'E' only has one mode
      regardless of what mode it validates authentication from 'I', says it
   will has negotiated.  We could have
      specified that 'E' should have allowed a covert channel from 'M' limited functionality mode and
      check for such behaviour.  But we decided not to 'B'.

   ECN at add the IP layer is designed to carry information about congestion
   from a congested resource towards downstream nodes.  Typically extra
      complexity of two modes on a
   downstream transport might feed the information back somehow compliant tunnel egress merely to the
   point upstream of the congestion
      cater for an historic security concern that can regulate the load on the
   congested resource, but other actions are possible (see [RFC3168]
   S.6).  In terms is now considered
      manageable.

10.  Conclusions

   This document uses previously unused combinations of inner and outer
   header to augment the rules for calculating the above unicast scenario, ECN is typically
   intended to create an information channel from 'M' to 'B' (for 'B' to
   feed back to 'A').  Therefore field when
   decapsulating IP packets at the goals egress of IPsec (RFC4301) and ECN are mutually
   incompatible.

   With respect non-
   IPsec (RFC3168) tunnels.  In this way it allows tunnels to the DS or ECN fields, S.5.1.2 propagate
   an extra level of RFC4301 says,
   "controls are provided to manage congestion severity.

   This document also updates the bandwidth ingress tunnelling encapsulation of this [covert]
   channel".  Using the
   RFC3168 ECN processing rules of RFC4301, the channel
   bandwidth is two bits per datagram from 'A' to 'M' and one bit per
   datagram from 'M' to 'A' (because 'E' limits bring all IP in IP tunnels into line with the combinations new
   behaviour in the IPsec architecture of RFC4301, which copies rather
   than resets the
   2-bit ECN field that it will copy).  In when creating outer headers.

   The need for both cases the covert channel
   bandwidth is further reduced by noise from any real congestion
   marking.  RFC4301 therefore implies that these covert channels are
   sufficiently limited to be considered a manageable threat.  However,
   with respect to the larger (6b) DS field, updated behaviours was triggered by the same section
   introduction of RFC4301
   says not copying is pre-congestion notification (PCN) onto the default, but a configuration option can allow
   copying "to allow a local administrator IETF
   standards track.  Operators wanting to decide whether the covert
   channel provided by copying these bits outweighs the benefits of
   copying".  Of course, support PCN or other alternate
   ECN schemes that use an administrator considering copying extra severity level can require that their
   tunnels comply with the present specification.  Nonetheless, as part
   of the DS
   field has general code maintenance, any tunnel can safely be updated to take into account that
   comply with this specification, because it could be concatenated is backward compatible
   with all previous tunnelling behaviours which will continue to work
   as before--just using one severity level.

   The new rules propagate changes to the ECN field giving an 8b per datagram across tunnel end-
   points that previously blocked them to restrict the bandwidth of a
   potential covert channel.

   Thus, for tunnelling  But limiting the 6b Diffserv field two conceptual models have
   had channel's bandwidth to be defined so that administrators can trade off security
   against 2
   bits per packet is now considered sufficient.

   At the needs of traffic conditioning [RFC2983]:

   The uniform model:  where same time as removing these legacy constraints, the DIffserv field is preserved end-to-end
      by copying
   opportunity has been taken to draw together diverging tunnel
   specifications into the outer header on encapsulation a single consistent behaviour.  Then any tunnel
   can be deployed unilaterally, and copying from
      the outer header on decapsulation.

   The pipe model:  where the outer header is independent of that in the
      inner header so it hides will support the Diffserv field full range of the inner header
      from
   congestion control and management schemes without any interaction with nodes along the tunnel.

   However, for ECN, modes or
   configuration.  Further, any host or router can expect the new IPsec security architecture in RFC4301 only
   standardised one tunnelling model equivalent ECN field
   to behave in the uniform model.
   It deemed that simplicity was more important than allowing
   administrators the option same way, whatever type of a tiny increment tunnel might intervene in security, especially
   given not copying congestion indications could seriously harm
   everyone's network service.

A.2.  Control Constraints

   Congestion control requires
   the path.  This new certainty could enable new uses of the ECN field
   that any congestion notification marked
   into packets by a resource will would otherwise be able confounded by ambiguity.

11.  Acknowledgements

   Thanks to traverse Anil Agawaal for pointing out a feedback loop
   back case where it's safe for a
   tunnel decapsulator to forward a function capable combination of controlling the load on that resource.
   To be precise, rather than calling this function the data source, we
   will call headers it the Load Regulator.  This will allow us to deal with
   exceptional cases where load is does not regulated by the data source, but
   usually the two terms will be synonymous.  Note the term "a function
   _capable of_ controlling the load" deliberately includes a source
   application that doesn't actually control the load but ought
   understand.  Thanks to (e.g.
   an application without congestion control that uses UDP).

                 A--->R--->I=========>M=========>E-------->B

                     Figure 6: Simple Tunnel Scenario

   We now consider David Black for explaining a similar tunnelling scenario better way to
   think about function placement.  Also thanks to Arnaud Jacquet for
   the IPsec one just
   described, but without idea for Appendix C.  Thanks to Michael Menth, Bruce Davie, Toby
   Moncaster, Gorry Fairhurst, Sally Floyd, Alfred Hoenes, Gabriele
   Corliano, Ingemar Johansson and David Black for their thoughts and
   careful review comments.

   Bob Briscoe is partly funded by Trilogy, a research project (ICT-
   216372) supported by the different security domains so we can just
   focus on ensuring European Community under its Seventh
   Framework Programme.  The views expressed here are those of the control loop
   author only.

12.  Comments Solicited

   Comments and management monitoring questions are encouraged and very welcome.  They can work
   (Figure 6).  If we want resources in be
   addressed to the tunnel IETF Transport Area working group mailing list
   <tsvwg@ietf.org>, and/or to be able the authors.

13.  References

13.1.  Normative References

   [RFC2003]                         Perkins, C., "IP Encapsulation
                                     within IP", RFC 2003, October 1996.

   [RFC2119]                         Bradner, S., "Key words for use in
                                     RFCs to
   explicitly notify congestion Indicate Requirement
                                     Levels", BCP 14, RFC 2119,
                                     March 1997.

   [RFC3168]                         Ramakrishnan, K., Floyd, S., and the feedback path is from 'B' D.
                                     Black, "The Addition of Explicit
                                     Congestion Notification (ECN) to
   'A', it will certainly be necessary
                                     IP", RFC 3168, September 2001.

   [RFC4301]                         Kent, S. and K. Seo, "Security
                                     Architecture for 'E' the Internet
                                     Protocol", RFC 4301, December 2005.

13.2.  Informative References

   [I-D.ietf-pcn-3-in-1-encoding]    Briscoe, B. and T. Moncaster, "PCN
                                     3-State Encoding Extension in a
                                     single DSCP",
                                     draft-ietf-pcn-3-in-1-encoding-00
                                     (work in progress), July 2009.

   [I-D.ietf-pcn-3-state-encoding]   Moncaster, T., Briscoe, B., and M.
                                     Menth, "A PCN encoding using 2
                                     DSCPs to copy any CE provide 3 or more states",
                                     draft-ietf-pcn-3-state-encoding-00
                                     (work in progress), April 2009.

   [I-D.ietf-pcn-baseline-encoding]  Moncaster, T., Briscoe, B., and M.
                                     Menth, "Baseline Encoding and
                                     Transport of Pre-Congestion
                                     Information",
                                     draft-ietf-pcn-baseline-encoding-04
                                     (work in progress), May 2009.

   [I-D.ietf-pcn-marking-behaviour]  Eardley, P., "Metering and marking
   from
                                     behaviour of PCN-nodes",
                                     draft-ietf-pcn-marking-behaviour-04
                                     (work in progress), June 2009.

   [I-D.ietf-pcn-psdm-encoding]      Menth, M., Babiarz, J., Moncaster,
                                     T., and B. Briscoe, "PCN Encoding
                                     for Packet-Specific Dual Marking
                                     (PSDM)",
                                     draft-ietf-pcn-psdm-encoding-00
                                     (work in progress), June 2009.

   [I-D.ietf-pcn-sm-edge-behaviour]  Charny, A., Karagiannis, G., Menth,
                                     M., and T. Taylor, "PCN Boundary
                                     Node Behaviour for the Single
                                     Marking (SM) Mode of Operation",
                                     draft-ietf-pcn-sm-edge-behaviour-00
                                     (work in progress), July 2009.

   [I-D.satoh-pcn-st-marking]        Satoh, D., Maeda, Y., Phanachet,
                                     O., and H. Ueno, "Single PCN
                                     Threshold Marking by using PCN
                                     baseline encoding for both
                                     admission and termination
                                     controls",
                                     draft-satoh-pcn-st-marking-01 (work
                                     in progress), March 2009.

   [RFC2401]                         Kent, S. and R. Atkinson, "Security
                                     Architecture for the Internet
                                     Protocol", RFC 2401, November 1998.

   [RFC2474]                         Nichols, K., Blake, S., Baker, F.,
                                     and D. Black, "Definition of the outer header to
                                     Differentiated Services Field (DS
                                     Field) in the inner header for onward transmission IPv4 and IPv6
                                     Headers", RFC 2474, December 1998.

   [RFC2481]                         Ramakrishnan, K. and S. Floyd, "A
                                     Proposal to
   'B', otherwise congestion notification from resources like 'M' cannot
   be fed back add Explicit Congestion
                                     Notification (ECN) to the Load Regulator ('A').  But it doesn't seem
   necessary IP",
                                     RFC 2481, January 1999.

   [RFC2983]                         Black, D., "Differentiated Services
                                     and Tunnels", RFC 2983,
                                     October 2000.

   [RFC3540]                         Spring, N., Wetherall, D., and D.
                                     Ely, "Robust Explicit Congestion
                                     Notification (ECN) Signaling with
                                     Nonces", RFC 3540, June 2003.

   [RFC4306]                         Kaufman, C., "Internet Key Exchange
                                     (IKEv2) Protocol", RFC 4306,
                                     December 2005.

   [RFC4774]                         Floyd, S., "Specifying Alternate
                                     Semantics for 'I' to copy CE markings from the inner to the outer
   header.  For instance, if resource 'R' Explicit
                                     Congestion Notification (ECN)
                                     Field", BCP 124, RFC 4774,
                                     November 2006.

   [RFC5129]                         Davie, B., Briscoe, B., and J. Tay,
                                     "Explicit Congestion Marking in
                                     MPLS", RFC 5129, January 2008.

   [RFC5559]                         Eardley, P., "Pre-Congestion
                                     Notification (PCN) Architecture",
                                     RFC 5559, June 2009.

   [VCP]                             Xia, Y., Subramanian, L., Stoica,
                                     I., and S. Kalyanaraman, "One more
                                     bit is congested, it can send
   congestion information to 'B' using the congestion field enough", Proc. SIGCOMM'05,
                                     ACM CCR 35(4)37--48, 2005, <http://
                                     doi.acm.org/10.1145/
                                     1080091.1080098>.

Appendix A.  Early ECN Tunnelling RFCs

   IP in IP tunnelling was originally defined in [RFC2003].  On
   encapsulation, the inner incoming header without 'I' copying the congestion field into was copied to the outer header and 'E' copying it back to the inner header.  'E' can still write any
   additional congestion marking introduced across on
   decapsulation the tunnel into outer was simply discarded.  Initially, IPsec
   tunnelling [RFC2401] followed the same behaviour.

   When ECN was introduced experimentally in [RFC2481], legacy (RFC2003
   or RFC2401) tunnels would have discarded any congestion field of markings
   added to the inner header.

   It might be useful outer header, so RFC2481 introduced rules for
   calculating the tunnel egress to be able to tell whether
   congestion occurred across outgoing header from a tunnel or upstream combination of it.  If outer
   header congestion marking was reset by the tunnel ingress ('I'), at the end of inner and
   outer on decapsulation.  RC2481 also introduced a tunnel ('E') second mode for
   IPsec tunnels, which turned off ECN processing in the outer headers header
   (Not-ECT) on encapsulation because an RFC2401 decapsulator would indicate congestion
   experienced across
   discard the tunnel ('I' to 'E'), while outer on decapsulation.  For RFC2401 IPsec this had the inner header
   would indicate congestion upstream
   side-effect of 'I'.  But similar information
   can be gleaned even if completely blocking the tunnel ingress copies covert channel.

   In RFC2481 the inner ECN field was defined as two separate bits.  But when
   ECN moved from the experimental to the
   outer headers.  At standards track [RFC3168], the end
   ECN field was redefined as four codepoints.  This required a
   different calculation of the tunnel ('E'), any packet with an
   _extra_ mark ECN field from that used in RFC2481 on
   decapsulation.  RFC3168 also had two modes; a 'full functionality
   mode' that restricted the outer header relative covert channel as much as possible but
   still allowed ECN to the inner header
   indicates congestion be used with IPsec, and another that completely
   turned off ECN processing across the tunnel ('I' tunnel.  This 'limited
   functionality mode' both offered a way for operators to 'E'), while completely
   block the inner
   header would still indicate congestion upstream of ('I').  Appendix C
   gives a simple covert channel and precise method for allowed an RFC3168 ingress to interwork
   with a legacy tunnel egress (RFC2481, RFC2401 or RFC2003).

   The present specification includes a tunnel egress similar compatibility mode to infer the
   congestion level introduced across
   interwork safely with tunnels compliant with any of these three
   earlier RFCs.  However, unlike RFC3168, it is only a tunnel.

   All this shows that 'E' can preserve the control loop irrespective mode of
   whether 'I' copies congestion notification into the outer header or
   resets it.

   That
   ingress, as decapsulation behaviour is the situation for existing control arrangements but, because
   copying reveals more information, it would open up possibilities for
   better control system designs.  For instance, same in either case.

Appendix E describes
   how resetting CE marking at a tunnel ingress confuses B.  Design Constraints

   Tunnel processing of a proposed congestion marking scheme on the standards track.  It ends up
   removing excessive amounts of traffic unnecessarily.  Whereas copying
   CE markings at ingress leads notification field has to the correct meet
   congestion control behaviour.

A.3.  Management Constraints

   As well as control, there are also management constraints.
   Specifically, a and management system may monitor congestion markings in
   passing packets, perhaps at the border between networks as part of a
   service level agreement.  For instance, monitors at needs without creating new
   information security vulnerabilities (if information security is
   required).  This appendix documents the borders analysis of
   autonomous systems may need to measure how much congestion has
   accumulated since the original source, perhaps to determine tradeoffs
   between
   them how much of these factors that led to the congestion is contributed new encapsulation rules in
   Section 4.1.

B.1.  Security Constraints

   Information security can be assured by each domain.

   Therefore, when monitoring the middle of using various end to end
   security solutions (including IPsec in transport mode [RFC4301]), but
   a path, it should be
   possible commonly used scenario involves the need to establish how far back in communicate between two
   physically protected domains across the path congestion markings
   have accumulated from. public Internet.  In this document we term this
   case there are certain management advantages to using IPsec in tunnel
   mode solely across the baseline publicly accessible part of
   congestion marking (or the Congestion Baseline), i.e. path.  The
   path followed by a packet then crosses security 'domains'; the source of ones
   protected by physical or other means before and after the layer that last reset (or created) tunnel and
   the congestion notification
   field.  Given some tunnels cross domain borders (e.g. consider M one protected by an IPsec tunnel across the otherwise unprotected
   domain.  We will use the scenario in Figure 6 is monitoring 5 where endpoints 'A' and
   'B' communicate through a border), it would therefore be desirable for
   'I' to copy congestion accumulated so far into the outer headers
   exposed across the tunnel.

   Appendix B.2 discusses various scenarios where the Load Regulator
   lies in-path, not at  The tunnel ingress 'I' and egress
   'E' are within physically protected edge domains, while the source host as we would typically expect.
   It concludes that a Congestion Baseline is determined by tunnel
   spans an unprotected internetwork where the
   Load Regulator function is, which should there may be identified in the
   transport layer, not by addresses 'men in network layer headers.  This
   applies whether the Load Regulator
   middle', M.

                physically       unprotected     physically
            <-protected domain-><--domain--><-protected domain->
            +------------------+            +------------------+
            |                  |      M     |                  |
            |    A-------->I=========>==========>E-------->B   |
            |                  |            |                  |
            +------------------+            +------------------+
                                <----IPsec secured---->
                                        tunnel

                      Figure 5: IPsec Tunnel Scenario

   IPsec encryption is at typically used to prevent 'M' seeing messages
   from 'A' to 'B'.  IPsec authentication is used to prevent 'M'
   masquerading as the source host sender of messages from 'A' to 'B' or within
   the path.  The appendix altering
   their contents.  But 'I' can also discusses where a Load Regulator
   function should be located relative to a local use IPsec tunnel encapsulation
   function.

Appendix B.  Relative Placement of Tunnelling and In-Path Load
             Regulation

B.1.  Identifiers and In-Path Load Regulators

   The Load Regulator is the node mode to which congestion feedback should be
   returned by the next downstream node allow 'A'
   to communicate with a transport layer feedback
   function (typically but not always the data receiver).  The Load
   Regulator is often, 'B', but not always the data source.  It is not always
   (or even typically) the same thing impose encryption to prevent 'A' leaking
   information to 'M'.  Or 'E' can insist that 'I' uses tunnel mode
   authentication to prevent 'M' communicating information to 'B'.
   Mutable IP header fields such as the node identified by the
   source address of ECN field (as well as the outermost exposed header.  In general TTL/
   Hop Limit and DS fields) cannot be included in the
   addressing cryptographic
   calculations of IPsec.  Therefore, if 'I' copies these mutable fields
   into the outermost encapsulation outer header says nothing about
   the identifiers of either the upstream or the downstream transport
   layer functions.  As long as that is exposed across the transport functions know each
   other's addresses, they don't tunnel it will have to be identified in the network
   layer or in any link layer.  It was only a convenience that
   allowed a TCP
   receiver assumed covert channel from 'A' to M that the address bypasses its encryption
   of the source transport is inner header.  And if 'E' copies these fields from the same
   as outer
   header to the network layer source address of an IP packet inner, even if it receives.

   More generally, the return transport address for feedback could be
   identified solely in validates authentication from 'I', it
   will have allowed a covert channel from 'M' to 'B'.

   ECN at the transport IP layer protocol.  For instance, is designed to carry information about congestion
   from a
   signalling protocol like RSVP [RFC2205] breaks up congested resource towards downstream nodes.  Typically a path into
   downstream transport layer hops and informs each hop of might feed the address of its
   transport layer neighbour without any need information back somehow to identify these hops in the network layer.  RSVP can be arranged so
   point upstream of the congestion that these transport
   layer hops are bigger than can regulate the underlying network layer hops.  The
   host identity protocol (HIP) architecture [RFC4423] also supports load on the
   same principled separation (for mobility amongst
   congested resource, but other things), where actions are possible (see [RFC3168]
   S.6).  In terms of the transport layer sender identifies its transport address for
   feedback above unicast scenario, ECN effectively
   intends to be sent to, using create an identifier provided by a shim below
   the transport layer.

   Keeping information channel (for congestion signalling)
   from 'M' to this layering principle deliberately doesn't require a
   network layer packet header 'B' (for 'B' to reveal the origin address from where
   congestion notification accumulates (its Congestion Baseline).  It is
   not necessary for the network and lower layers feed back to know 'A').  Therefore the address goals
   of
   the Load Regulator.  Only the destination transport needs to know
   that.  With forward congestion notification, the network IPsec and link
   layers only notify congestion forwards; they aren't involved in
   feeding it backwards.  If they ECN are (e.g. backward congestion
   notification (BCN) in Ethernet [IEEE802.1au] or EFCI in ATM
   [ITU-T.I.371]), that should be considered as a transport function
   added mutually incompatible.

   With respect to the lower layer, which must sort out its own addressing.
   Indeed, this is one reason why ICMP source quench is now deprecated
   [RFC1254]; when congestion occurs within a tunnel it is complex
   (particularly in the case DS or ECN fields, S.5.1.2 of IPsec tunnels) RFC4301 says,
   "controls are provided to return manage the ICMP
   messages beyond bandwidth of this [covert]
   channel".  Using the tunnel ingress back to ECN processing rules of RFC4301, the Load Regulator.

   Similarly, if a management system channel
   bandwidth is monitoring congestion two bits per datagram from 'A' to 'M' and needs one bit per
   datagram from 'M' to know the Congestion Baseline, 'A' (because 'E' limits the management system has to find
   this out from combinations of the transport; in general
   2-bit ECN field that it cannot tell solely by
   looking at will copy).  In both cases the network or link layer headers.

B.2.  Non-Dependence of Tunnelling on In-path Load Regulation

   We have said that at covert channel
   bandwidth is further reduced by noise from any point in a network, the Congestion Baseline
   (where real congestion notification starts from zero) should be the
   previous upstream Load Regulator.  We have also said
   marking.  RFC4301 implies that the ingress
   of an IP in IP tunnel must copy congestion indications these covert channels are sufficiently
   limited to be considered a manageable threat.  However, with respect
   to the
   encapsulating outer headers it creates.  If larger (6b) DS field, the Load Regulator same section of RFC4301 says not
   copying is in-
   path rather than at the source, and also default, but a tunnel ingress, configuration option can allow copying
   "to allow a local administrator to decide whether the covert channel
   provided by copying these two
   requirements seem bits outweighs the benefits of copying".
   Of course, an administrator considering copying of the DS field has
   to take into account that it could be contradictory.  A tunnel ingress must not
   reset incoming congestion, but a Load Regulator must concatenated with the ECN field
   giving an 8b per datagram covert channel.

   For tunnelling the 6b Diffserv field two conceptual models have had
   to be defined so that administrators can trade off security against
   the
   Congestion Baseline, implying it needs to reset incoming congestion.

   In fact, of traffic conditioning [RFC2983]:

   The uniform model:  where the two requirements are not contradictory, because a Load
   Regulator Diffserv field is preserved end-to-end
      by copying into the outer header on encapsulation and a tunnel ingress are not copying from
      the names of machines, but outer header on decapsulation.

   The pipe model:  where the
   names outer header is independent of functions within a machine that typically occur in sequence
   on a stream the
      inner header so it hides the Diffserv field of packets, not at the same point.  Figure 7 is borrowed inner header
      from [RFC2983] (which was making a similar point about any interaction with nodes along the location
   of Diffserv traffic conditioning relative tunnel.

   However, for ECN, the new IPsec security architecture in RFC4301 only
   standardised one tunnelling model equivalent to the encapsulation
   function uniform model.
   It deemed that simplicity was more important than allowing
   administrators the option of a tunnel).  An in-path Load Regulator can act on packets
   either at [1 - Before] encapsulation or at [2 - Outer] after
   encapsulation.  Load Regulation does tiny increment in security, especially
   given not ever need to copying congestion indications could seriously harm
   everyone's network service.

B.2.  Control Constraints

   Congestion control requires that any congestion notification marked
   into packets by a resource will be integrated
   with the [Encapsulate] able to traverse a feedback loop
   back to a function (but it can be for efficiency).
   Therefore we can still mandate that capable of controlling the [Encapsulate] function always
   copies CE into load on that resource.
   To be precise, rather than calling this function the data source, we
   will call it the outer header.

     >>-----[1 - Before]--------[Encapsulate]----[3 - Inner]---------->>
                                         \
                                          \
                                           +--------[2 - Outer]------->>

     Figure 7: Placement of In-Path Load Regulator Relative Regulator.  This will allow us to Tunnel
                                  Ingress

   Then separately, if there deal with
   exceptional cases where load is a Load Regulator at location [2 -
   Outer], it might reset CE to ECT(0), say.  Then not regulated by the Congestion
   Baseline for data source, but
   usually the lower layer (outer) two terms will be [2 - Outer], while synonymous.  Note the
   Congestion Baseline of term "a function
   _capable of_ controlling the inner layer will be unchanged.  But how
   encapsulation works has nothing to do with whether load" deliberately includes a Load Regulator
   is present or where it is.

   If on source
   application that doesn't actually control the other hand load but ought to (e.g.
   an application without congestion control that uses UDP).

                 A--->R--->I=========>M=========>E-------->B

                     Figure 6: Simple Tunnel Scenario

   We now consider a Load Regulator resets CE at [1 - Before], similar tunnelling scenario to the
   Congestion Baseline of both IPsec one just
   described, but without the inner different security domains so we can just
   focus on ensuring the control loop and outer headers will management monitoring can work
   (Figure 6).  If we want resources in the tunnel to be [1 -
   Before].  But again, encapsulation is independent of load regulation.

B.3.  Dependence of In-Path Load Regulation on Tunnelling

   Although encapsulation doesn't need able to depend on in-path load
   regulation,
   explicitly notify congestion and the reverse feedback path is not true.  The placement of an in-path
   Load Regulator must be carefully considered relative from 'B' to
   encapsulation.  Some examples are given in the following
   'A', it will certainly be necessary for
   guidance.

   In 'E' to copy any CE marking
   from the traditional Internet architecture one tends outer header to think of the
   source host as inner header for onward transmission to
   'B', otherwise congestion notification from resources like 'M' cannot
   be fed back to the Load Regulator for a path.  It is generally ('A').  But it does not
   desirable or practical seem
   necessary for a node part way along the path 'I' to regulate
   the load.  However, various reasonable proposals for in-path load
   regulation have been made copy CE markings from time to time (e.g. fair queuing,
   traffic engineering, flow admission control).  The IETF has recently
   chartered a working group the inner to standardise admission control across a
   part of a path using pre-congestion notification (PCN) [PCNcharter].
   This the outer
   header.  For instance, if resource 'R' is of particular relevance here because it involves congestion
   notification with an in-path Load Regulator, congested, it can involve
   tunnelling and it certainly involves encapsulation more generally.

   We will use send
   congestion information to 'B' using the more complex scenario congestion field in Figure 8 to tease out all the issues that arise when combining inner
   header without 'I' copying the congestion notification and
   tunnelling with various possible in-path load regulation schemes.  In
   this case 'I1' field into the outer header
   and 'E2' break up 'E' copying it back to the path into three separate inner header.  'E' can still write any
   additional congestion control loops.  The feedback for these loops is shown
   going right to left marking introduced across the top of the figure.  The 'V's are arrow
   heads representing tunnel into the direction
   congestion field of feedback, not letters.  But there
   are also two tunnels within the middle control loop: 'I1' to 'E1' and
   'I2' to 'E2'.  The two tunnels inner header.

   It might be VPNs, perhaps over two MPLS
   core networks.  M is a congestion monitoring point, perhaps between
   two border routers where useful for the same tunnel continues unbroken egress to be able to tell whether
   congestion occurred across
   the border.
        ______     _______________________________________      _____
       /      \   /                                        \   /     \
      V        \ V                                M         \ V       \
      A--->R--->I1===========>E1----->I2=========>==========>E2------->B

                     Figure 8: Complex Tunnel Scenario

   The question is, should the a tunnel or upstream of it.  If outer
   header congestion markings in marking was reset by the outer exposed
   headers tunnel ingress ('I'), at
   the end of a tunnel represent ('E') the outer headers would indicate congestion only since
   experienced across the tunnel
   ingress or over ('I' to 'E'), while the whole inner header
   would indicate congestion upstream path from the source of 'I'.  But similar information
   can be gleaned even if the inner
   header (whatever that may mean)?  Or put another way, should 'I1' and
   'I2' copy or reset CE markings?
   Based on tunnel ingress copies the design principles in Section 4.3, inner to the answer is that
   outer headers.  At the
   Congestion Baseline should be end of the nearest upstream interface designed
   to regulate traffic load--the Load Regulator.  In Figure 8 'A', 'I1'
   or 'E2' are all Load Regulators.  We have shown tunnel ('E'), any packet with an
   _extra_ mark in the feedback loops
   returning outer header relative to each of these nodes so that they can regulate the load
   causing the inner header
   indicates congestion notification.  So across the Congestion Baseline
   exposed tunnel ('I' to M should be 'I1' (the Load Regulator), not 'I2'.
   Therefore I1 should reset any arriving CE markings.  In this case,
   'I1' knows 'E'), while the inner
   header would still indicate congestion upstream of ('I').  Appendix C
   gives a simple and precise method for a tunnel egress to 'E1' is unrelated to its load regulation
   function.  So infer the load regulation function within 'I1' should be
   placed at [1 - Before] tunnel encapsulation within 'I1' (using
   congestion level introduced across a tunnel.

   All this shows that 'E' can preserve the
   terminology control loop irrespective of Figure 7).  Then the Congestion Baseline all across
   whether 'I' copies congestion notification into the networks from 'I1' to 'E2' in both inner and outer headers will
   be 'I1'.

   The following further examples illustrate how this answer might be
   applied:

   o  We argued in header or
   resets it.

   That is the situation for existing control arrangements but, because
   copying reveals more information, it would open up possibilities for
   better control system designs.  For instance, Appendix E that describes
   how resetting CE marking on encapsulation could
      harm PCN excess rate marking, which marks excess traffic for
      removal in subsequent round trips.  This breaks a proposed
   congestion marking relies scheme on not
      marking packets if another node upstream has already marked them
      for removal.  If the standards track.  It ends up
   removing excessive amounts of traffic unnecessarily.  Whereas copying
   CE markings at ingress leads to the correct control behaviour.

B.3.  Management Constraints

   As well as control, there were are also management constraints.
   Specifically, a tunnel ingress between management system may monitor congestion markings in
   passing packets, perhaps at the two which
      reset CE markings, it would confuse border between networks as part of a
   service level agreement.  For instance, monitors at the downstream node into
      marking borders of
   autonomous systems may need to measure how much congestion has
   accumulated so far too along the path, perhaps to determine between them
   how much traffic for removal.  So why do we say that
      'I1' should reset CE, while a tunnel ingress shouldn't?  The
      answer is that it is of the Load Regulator function at 'I1' that congestion is
      resetting CE, not contributed by each domain.

   In this document we define the tunnel encapsulator.  The Load Regulator
      needs to set itself as baseline of congestion marking (or the
   Congestion Baseline, so Baseline) as the feedback source of the layer that created (or most
   recently reset) the congestion notification field.  When monitoring
   congestion it would be desirable if the Congestion Baseline did not
   depend on whether packets were tunnelled or not.  Given some tunnels
   cross domain borders (e.g. consider M in Figure 6 is monitoring a
   border), it
      gets will only would therefore be about desirable for 'I' to copy congestion on links it can relieve itself
      (by regulating the load
   accumulated so far into them).  When it resets CE markings,
      it knows that something else upstream will have dealt with the
      congestion notifications it removes, given outer headers, so that it is part of an end-
      to-end admission control signalling loop.  It therefore knows that
      previous hops will be covered by other Load Regulators.
      Meanwhile, exposed
   across the tunnel.

Appendix C.  Contribution to Congestion across a Tunnel

   This specification mandates that a tunnel ingresses at both 'I1' and 'I2' should
      follow ingress determines the ECN
   field of each new rule outer tunnel header by copying the arriving header.
   Concern has been expressed that this will make it difficult for any the
   tunnel ingress and copy egress to monitor congestion
      marking into introduced only along a tunnel,
   which is easy if the outer ECN field is reset at a tunnel header.  The ingress
   (RFC3168 full functionality mode).  However, in fact copying CE marks
   at 'I1' ingress will
      happen to copy headers that have already been reset just
      beforehand.  But still make it doesn't need easy for the egress to know that.

   o  [Shayman] suggested feedback of ECN accumulated measure
   congestion introduced across an MPLS
      domain could cause a tunnel, as illustrated below.

   Consider 100 packets measured at the egress.  Say it measures that 30
   are CE marked in the inner and outer headers and 12 have additional
   CE marks in the outer but not the inner.  This means packets arriving
   at the ingress to trigger re-routing to mitigate had already experienced 30% congestion.  This case is more like  However, it
   does not mean there was 12% congestion across the simple scenario tunnel.  The
   correct calculation of
      Figure 6, with a feedback loop congestion across the MPLS domain ('E' back tunnel is p_t = 12/
   (100-30) = 12/70 = 17%.  This is easy for the egress to
      'I').  I is a Load Regulator because re-routing around congestion measure.  It
   is a load regulation function.  But in this case 'I' should only
      reset itself as simply the Congestion Baseline packets with additional CE marking in the outer headers, header
   (12) as it is a proportion of packets not handling congestion outside its domain, so it must preserve marked in the end-to-end congestion feedback loop for something else to
      handle (probably inner header (70).

   Figure 7 illustrates this in a combinatorial probability diagram.
   The square represents 100 packets.  The 30% division along the data source).  Therefore bottom
   represents marking before the Load Regulator
      within 'I' should be placed at [2 - Outer] to reset CE markings
      just after ingress, and the tunnel ingress has copied them from arriving
      headers.  Again, p_t division up the tunnel encapsulation function at 'I' simply
      copies incoming headers, unaware that
   side represents marking introduced across the load regulator will
      subsequently reset its tunnel.

        ^ outer headers.

   o header marking
        |
   100% +-----+---------+       The PWE3 working group large square
        |     |         |       represents 100 packets
        | 30  |         |
        |     |         |   p_t = 12/(100-30)
    p_t +     +---------+       = 12/70
        |     |   12    |       = 17%
      0 +-----+---------+--->
        0    30%       100%  inner header marking

       Figure 7: Tunnel Marking of the IETF Packets Already Marked at Ingress

Appendix D.  Why Losing ECT(1) on Decapsulation Impedes PCN

   Congestion notification with two severity levels is considering currently on the problem of
      how
   IETF's standards track agenda in the Congestion and whether an aggregate edge-to-edge pseudo-wire emulation
      should respond to Pre-Congestion
   Notification (PCN) working group.  The PCN working group requires
   four congestion states (not PCN-enabled, not marked and two
   increasingly severe levels of congestion [I-D.ietf-pwe3-congestion-frmwk].
      Although the study marking--see [RFC5559]).
   The aim is still at the requirements stage, some
      (controversial) solution proposals include in-path load regulation
      at for the ingress less severe level of marking to stop admitting new
   traffic and the tunnel that could lead more severe level to tunnel
      arrangements with similar complexity terminate sufficient existing
   flows to that of Figure 8.

   These are not contrived scenarios--they could be a lot worse.  For
   instance, a host may create a tunnel for IPsec which is placed inside
   a tunnel for Mobile IP over bring a remote part of network back to its path.  And around
   this all we may have MPLS labels being pushed and popped as packets
   pass across different core networks.  Similarly, it is possible that
   subnets could be built from link technology (e.g. future Ethernet
   switches) so that operating point after a link headers being added and removed could involve
   failure.

   (Note on terminology: wherever this document counts four congestion notification in future Ethernet link headers with all
   states, the
   same issues PCN working group would count this as with IP in IP tunnels.

   One reason we introduced the concept of three PCN states
   plus a Load Regulator was to allow
   for in-path load regulation.  In not-PCN-enabled state.)

   Although the traditional Internet
   architecture one tends to think of a host and a Load Regulator as
   synonymous, but when considering tunnelling, even ECN field gives sufficient codepoints for four states,
   pre-existing ECN tunnelling RFCs prevented the definition of PCN working group from
   using four ECN states in case any tunnel decapsulations occur within
   a
   host is too fuzzy, whereas PCN region.  If a Load Regulator is node in a clearly defined
   function.  Similarly, tunnel changes the concept of innermost header is too fuzzy to
   be able ECN field to (wrongly) say that the source address of the innermost
   header should ECT(0)
   or ECT(1), this change would be the Congestion Baseline.  Which is the innermost
   header when multiple encapsulations may discarded by a tunnel egress
   compliant with RFC4301 or RFC3168.  This can be seen in use?  Where do we stop?
   If we say the original source Figure 2
   (Section 3.2), where ECT values in the above IPsec-Mobile IP case outer header are ignored
   unless the inner header is the host, how do we know it isn't tunnelling an encrypted packet
   stream on behalf same.  Effectively the decapsulation
   rules of another host in a p2p network?

   We have become used to thinking that only hosts regulate load.  The
   end to end design principle advises that this is RFC4301 and RFC3168 waste one ECT codepoint; they treat the
   ECT(0) and ECT(1) codepoints as a good idea
   [RFC3426], but it also advises that it is solely single codepoint.

   As a guiding principle
   intended to make consequence, the designer think very carefully before breaking
   it.  We do have proposals where load regulation functions sit within PCN w-g initially took the approach of a network path
   standards track baseline encoding for good, if sometimes controversial, reasons, e.g.
   PCN edge admission control gateways [I-D.ietf-pcn-architecture] or
   traffic engineering functions at domain borders three states
   [I-D.ietf-pcn-baseline-encoding] and a number of experimental
   alternatives to re-route around
   congestion [Shayman].  Whether add or not we want in-path load
   regulation, we have to work round avoid the fact that it will not go away.

Appendix C.  Contribution fourth state.  Without wishing to Congestion across a Tunnel

   This specification mandates that a tunnel ingress determines
   disparage the ECN
   field ingenuity of these work-rounds, none were chosen for
   the standards track because they were either somewhat wasteful,
   imprecise or complicated.  One uses a pair of Diffserv codepoint(s)
   in place of each new outer tunnel header by copying PCN DSCP to encode the arriving header.
   Concern extra state
   [I-D.ietf-pcn-3-state-encoding], using up the rapidly exhausting DSCP
   space while leaving an ECN codepoint unused.  Another PCN encoding
   has been expressed proposed that this will make it difficult for would survive tunnelling without an extra DSCP
   [I-D.ietf-pcn-psdm-encoding], but it requires the
   tunnel egress PCN edge gateways
   to monitor congestion introduced only along a tunnel,
   which is easy if share state out of band so the outer ECN field is reset at egress edge can know which marking
   a tunnel ingress
   (RFC3168 full functionality mode).  However, in fact copying CE marks packet started with at the ingress will still make it easy for edge.  Yet another work-round to
   the egress ECN tunnelling problem proposes a more involved marking algorithm
   in forwarding elements to measure encode the three congestion introduced across notification
   states using only two ECN codepoints [I-D.satoh-pcn-st-marking].  One
   work-round takes a tunnel, as illustrated below.

   Consider 100 packets measured at different approach; it compromises the egress.  It measures that 30 are
   CE marked in precision
   of the inner and outer headers and 12 have additional CE
   marks admission control mechanism in the outer some network scenarios, but not
   manages to work with just three encoding states and a single marking
   algorithm [I-D.ietf-pcn-sm-edge-behaviour].

   Rather than require the inner.  This means packets arriving at IETF to bless any of these experimental
   encoding work-rounds, the ingress had already experienced 30% congestion.  However, it does
   not mean there was 12% congestion across present specification fixes the tunnel.  The correct
   calculation root cause
   of congestion across the problem so that operators deploying PCN can simply require
   that tunnel is p_t = 12/(100-30) =
   12/70 = 17%.  This is easy for the egress to to measure.  It is the
   packets with additional CE marking in the outer header (12) as end-points within a
   proportion of packets not marked in the inner header (70).

   Figure 9 illustrates PCN region should comply with this
   new ECN tunnelling specification.  Universal compliance is feasible
   for PCN, because it is intended to be deployed in a combinatorial probability diagram.
   The square represents 100 packets.  The 30% division along the bottom
   represents marking before the ingress, and the p_t division up controlled
   Diffserv region.  Assuming tunnels within a PCN region will be
   required to comply with the
   side represents marking along present specification, the tunnel.

     +-----+---------+100%
     |     |         |
     | 30  |         |
     |     |         |       The large square
     |     +---------+p_t    represents 100 packets
     |     |   12    |
     +-----+---------+0
     0    30%       100%
     inner header marking

       Figure 9: Tunnel Marking of Packets Already Marked at Ingress PCN w-g is
   progressing a trivially simple four-state ECN encoding
   [I-D.ietf-pcn-3-in-1-encoding].

Appendix D. E.  Why Not Propagating ECT(1) Resetting ECN on Decapsulation Encapsulation Impedes PCN

   Multi-level congestion notification

   The PCN architecture says "...if encapsulation is currently on done within the IETF's
   standards track agenda in
   PCN-domain: Any PCN-marking is copied into the Congestion and Pre-Congestion
   Notification (PCN) working group. outer header.  Note: A
   tunnel will not provide this behaviour if it complies with [RFC3168]
   tunnelling in either mode, but it will if it complies with [RFC4301]
   IPsec tunnelling.  "

   The specific issue here concerns PCN working group eventually
   requires three congestion states (not marked and two increasingly
   severe levels of congestion marking) [I-D.ietf-pcn-architecture]. excess rate marking
   [I-D.ietf-pcn-marking-behaviour].  The aim is for the less severe level purpose of excess rate marking
   is to stop admitting new
   traffic and the more severe level to terminate sufficient existing
   flows to bring a network back to its operating point after provide a serious
   failure.

   Although the ECN field gives sufficient codepoints bulk mechanism for these three
   states, current ECN tunnelling RFCs prevent the PCN working group
   from using three ECN states in case any tunnel decapsulations occur interior nodes within a PCN region (see Appendix A of
   [I-D.ietf-pcn-baseline-encoding]).  If PCN domain
   to mark traffic that is exceeding a configured threshold bit-rate,
   perhaps after an unexpected event such as a node in reroute, a tunnel sets the
   ECN field to ECT(0) link or ECT(1), this change will be discarded by a
   tunnel egress compliant with RFC4301 node
   failure, or RFC3168.  This can be seen in
   Figure 2 (Section 3.2), where ECT values in the outer header are
   ignored unless the inner header a more widespread disaster.  PCN is intended for
   inelastic flows, so just removing marked packets would degrade every
   flow to the same.  Effectively one ECT
   codepoint is wasted; point of uselessness.  Instead, the ECT(0) and ECT(1) codepoints have to be
   treated as just one codepoint when they could otherwise have been
   used for their intended purpose edge nodes around a
   PCN domain terminate an equivalent amount of congestion notification. traffic, but at flow
   granularity.  As a consequence, well as protecting the PCN w-g has initially confined itself surviving inelastic flows,
   this also protects the share of capacity set aside for elastic
   traffic.  But users are very sensitive to two
   encoding states as their flows being
   terminated while in progress, therefore no more flows should be
   terminated than absolutely necessary.

   Re-routes are a baseline encoding
   [I-D.ietf-pcn-baseline-encoding].  And common cause of QoS degradation in IP networks.
   After re-routes it has had to propose an
   experimental extension using extra Diffserv codepoint(s) is common for multiple links in a network to encode
   the extra states [I-D.moncaster-pcn-3-state-encoding], using up the
   rapidly exhausting DSCP space while leaving ECN codepoints unused.
   Another
   become stressed at once.  Therefore, PCN encoding excess rate marking has been proposed that would survive tunnelling
   without an extra DSCP [I-D.menth-pcn-psdm-encoding], but it requires
   the PCN edge gateways
   carefully designed to somehow share state so the egress can
   determine which ensure traffic marked at one queue will not be
   counted again for marking a packet started with at subsequent queues (see the ingress.  Also a
   PCN `Excess
   traffic meter function' of [I-D.ietf-pcn-marking-behaviour]).

   However, if an RFC3168 tunnel ingress node can game the system by initiating packets with
   inappropriate markings.  Yet another work-round to intervenes, it resets the ECN tunnelling
   problem proposes a more involved marking algorithm
   field in all the forwarding
   plane outer headers.  This will cause excess traffic to encode the three congestion notification states using only
   two ECN codepoints [I-D.satoh-pcn-st-marking].  Still another
   proposal compromises be
   counted more than once, leading to many flows being removed that did
   not need to be removed at all.  This is why the precision of an RFC3168 tunnel
   ingress cannot be used in a PCN domain.

   The original reason an RFC3168 encapsulator reset the admission control
   mechanism, but manages ECN field was
   to work with just two encoding states and block a
   single marking algorithm [I-D.charny-pcn-single-marking].

   Rather than require covert channel (Appendix B.1), with the IETF to bless any overriding aim of these work-rounds, this
   specification fixes
   consistent behaviour between IPsec and non-IPsec tunnels.  But later
   RFC4301 IPsec encapsulation placed simplicity above the root cause of need to block
   the problem so that operators
   deploying PCN can covert channel, simply ask that tunnel end-points within a PCN
   region should comply with this new ECN tunnelling specification.

   Then PCN can use copying the trivially simple experimental 3-state ECN
   encoding defined field.

   The ECN reset in [I-D.briscoe-pcn-3-in-1-encoding].

D.1.  Alternative Ways RFC3168 is no longer deemed necessary, it is
   inconsistent with RFC4301, it is not as simple as RFC4301 and it is
   impeding deployment of new protocols like PCN.  The present
   specification corrects this perverse situation.

Appendix F.  Compromise on Decap with ECT(1) Inner and ECT(0) Outer

   A packet with an ECT(1) inner and an ECT(0) outer should never arise
   from any known IETF protocol.  Without giving a reason, RFC3168 and
   RFC4301 both say the outer should be ignored when decapsulating such
   a packet.  This appendix explains why it was decided not to Introduce change
   this advice.

   In summary, ECT(0) always means 'not congested' and ECT(1) may imply
   the New Decapsulation Rules

   There are same [RFC3168] or it may imply a number of ways for higher severity congestion
   signal [RFC4774], [I-D.ietf-pcn-3-in-1-encoding], depending on the new decapsulation rules to be
   introduced:

   o  They could be specified
   transport in use.  Whether they mean the present standards track proposal
      (preferred) same or in an experimental extension;

   o  They could be specified not, at the ingress
   the outer should have started the same as the inner and only a new default for all Diffserv PHBs
      (preferred) broken
   or as an option compromised router could have changed the outer to be configured only for Diffserv
      PHBs requiring them (e.g.  PCN). ECT(0).

   The argument for making decapsulator can detect this change now, rather than in a separate
   experimental extension, is to avoid anomaly.  But the burden of an extra standard
   to be compliant with and to be backwards compatible with--so we don't
   add to question is,
   should it correct the already complex history of ECN tunnelling RFCs.  The
   argument for a separate experimental extension is that we may never
   need this change (if PCN is never successfully deployed and if no-one
   ever needs three ECN anomaly by ignoring the outer, or PCN encoding states rather than two).
   However, should it
   reveal the change does no harm anomaly to existing mechanisms and stops
   tunnels wasting of quarter of a bit (a 2-bit codepoint).

   The argument for making this new decapsulation behaviour the default
   for all PHBs is that end-to-end transport by forwarding the
   outer?

   On balance, it doesn't change any expected behaviour was decided that
   existing mechanisms rely on already.  Also, by ending the present
   waste of a codepoint, in decapsulator should correct the
   anomaly, but log the event and optionally raise an alarm.  This is
   the future a use of that codepoint could be
   proposed for all PHBs, even if PCN isn't successfully deployed.

   In practice, safe action if these new decapsulation rules are specified
   straightaway ECT(1) is being used as the normative default for all PHBs, a network
   operator deploying 3-state PCN would be able more severe marking than
   ECT(0), because it passes the more severe signal to request that tunnels
   comply with the latest specification.  Implementers of non-PCN
   tunnels would transport.
   However, it is not need a good idea to comply but, if they did, their code would
   be future proofed and no harm would hide anomalies, which is why an
   optional alarm is suggested.  It should be done to legacy operations.
   Therefore, rather than branching their code base, it would noted that this anomaly
   may be easiest
   for implementers the result of two changes to make all their new tunnel code comply with this
   specfication, whether the outer: a broken or not it was for PCN.  But they could leave
   old code untouched, unless it was for PCN.

   The alternatives are worse.  Implementers would otherwise have to
   provide configurable decapsulation options and operators would have
   to configure all IPsec and IP
   compromised router within the tunnel might be erasing congestion
   markings introduced earlier in IP the same tunnel endpoints for by a congested router.
   In this case, the
   exceptional behaviour of certain PHBs. anomaly would be losing congestion signals, which
   needs immediate attention.

   The rules original reason for tunnel
   endpoints to handle both the Diffserv field defining ECT(0) and ECT(1) as equivalent was
   so that the data source could use the ECN field should
   'just work' when handling packets with nonce [RFC3540] to detect
   if congestion signals were being erased.  However, in this case, the
   decapsulator does not need a nonce to detect any Diffserv codepoint.

Appendix E.  Why Resetting CE on Encapsulation Impedes PCN

   Regarding encapsulation, anomalies introduced
   within the tunnel, because it has the section inner as a record of the PCN architecture
   [I-D.ietf-pcn-architecture] on tunnelling says that header copying
   (RFC4301) allows PCN to work correctly.  Whereas resetting CE
   markings confuses PCN marking.

   The specific issue here concerns PCN excess rate marking
   [I-D.ietf-pcn-marking-behaviour], i.e.
   at the bulk marking of traffic ingress.  Therefore, it was decided that exceeds a configured threshold rate.  One of the goals of excess
   rate marking is best compromise
   would be to enable give precedence to solving the speedy removal of excess admission
   controlled traffic following re-routes caused by link failures or
   other disasters.  This maintains a share of safety issue over
   revealing the capacity for traffic
   in lower priority classes.  After failures, traffic re-routed onto
   remaining links can often stress multiple links along a path.
   Therefore, traffic can arrive anomaly, because the anomaly could at a link under stress with some
   proportion already marked for removal by a previous link.  By design,
   marked traffic will least be removed by detected
   and dealt with internally.

   Superficially, the overall system in subsequent
   round trips.  So when opposite case where the excess rate marking algorithm decides how
   much traffic inner and outer carry
   different ECT values, but with an ECT(1) outer and ECT(0) inner seems
   to mark for removal, it doesn't include traffic already
   marked for removal by another node upstream (the `Excess traffic
   meter function' of [I-D.ietf-pcn-marking-behaviour]). require a similar compromise.  However, if an RFC3168 tunnel ingress intervenes, because that case is
   reversed, no compromise is necessary; it resets the ECN
   field in all is best to forward the outer headers, hiding all
   whether the evidence of problems
   upstream.  Thus, although excess rate marking works fine with RFC4301
   IPsec tunnels, with RFC3168 tunnels transport expects the ECT(1) to mean a higher severity
   than ECT(0) or the same severity.  Forwarding the outer either
   preserves a higher value (if it typically removes large
   volumes of traffic that is higher) or it didn't need reveals an anomaly
   to remove at all. the transport (if the two ECT codepoints mean the same severity).

Author's Address

   Bob Briscoe
   BT
   B54/77, Adastral Park
   Martlesham Heath
   Ipswich  IP5 3RE
   UK

   Phone: +44 1473 645196
   Email:
   EMail: bob.briscoe@bt.com
   URI:   http://www.cs.ucl.ac.uk/staff/B.Briscoe/