doc: Add RFC documents

1 files changed, 1963 insertions, 0 deletions

diff --git a/doc/rfc/rfc6040.txt b/doc/rfc/rfc6040.txt
new file mode 100644
index 0000000..ba10878
--- /dev/null
+++ b/doc/rfc/rfc6040.txt
@@ -0,0 +1,1963 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        B. Briscoe
+Request for Comments: 6040                                            BT
+Updates: 3168, 4301, 4774                                  November 2010
+Category: Standards Track
+ISSN: 2070-1721
+
+
+             Tunnelling of Explicit Congestion Notification
+
+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 updates RFC 3168
+   to bring all IP-in-IP tunnels (v4 or v6) into line with RFC 4301
+   IPsec ECN processing.  On decapsulation, it updates both RFC 3168 and
+   RFC 4301 to add new behaviours for previously unused combinations of
+   inner and outer headers.  The new rules ensure the ECN field is
+   correctly propagated across a tunnel whether it is used to signal one
+   or two severity levels of congestion; whereas before, only one
+   severity level was supported.  Tunnel endpoints can be updated in any
+   order without affecting pre-existing uses of the ECN field, thus
+   ensuring backward compatibility.  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 is
+   included.  In the unlikely event that the new rules do not meet a
+   specific need, RFC 4774 gives guidance on designing alternate ECN
+   semantics, and this document extends that to include tunnelling
+   issues.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6040.
+
+
+
+
+
+
+
+Briscoe                      Standards Track                    [Page 1]
+
+RFC 6040                     ECN Tunnelling                November 2010
+
+
+Copyright Notice
+
+   Copyright (c) 2010 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
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Briscoe                      Standards Track                    [Page 2]
+
+RFC 6040                     ECN Tunnelling                November 2010
+
+
+Table of Contents
+
+   1. Introduction ....................................................4
+      1.1. Scope ......................................................5
+   2. Terminology .....................................................6
+   3. Summary of Pre-Existing RFCs ....................................7
+      3.1. Encapsulation at Tunnel Ingress ............................7
+      3.2. Decapsulation at Tunnel Egress .............................8
+   4. New ECN Tunnelling Rules ........................................9
+      4.1. Default Tunnel Ingress Behaviour ..........................10
+      4.2. Default Tunnel Egress Behaviour ...........................10
+      4.3. Encapsulation Modes .......................................12
+      4.4. Single Mode of Decapsulation ..............................14
+   5. Updates to Earlier RFCs ........................................15
+      5.1. Changes to RFC 4301 ECN Processing ........................15
+      5.2. Changes to RFC 3168 ECN Processing ........................16
+      5.3. Motivation for Changes ....................................17
+           5.3.1. Motivation for Changing Encapsulation ..............17
+           5.3.2. Motivation for Changing Decapsulation ..............18
+   6. Backward Compatibility .........................................21
+      6.1. Non-Issues Updating Decapsulation .........................21
+      6.2. Non-Update of RFC 4301 IPsec Encapsulation ................21
+      6.3. Update to RFC 3168 Encapsulation ..........................22
+   7. Design Principles for Alternate ECN Tunnelling Semantics .......22
+   8. Security Considerations ........................................24
+   9. Conclusions ....................................................26
+   10. Acknowledgements ..............................................26
+   11. References ....................................................27
+      11.1. Normative References .....................................27
+      11.2. Informative References ...................................27
+   Appendix A.  Early ECN Tunnelling RFCs ............................29
+   Appendix B.  Design Constraints ...................................29
+     B.1.  Security Constraints ......................................29
+     B.2.  Control Constraints .......................................31
+     B.3.  Management Constraints ....................................32
+   Appendix C.  Contribution to Congestion across a Tunnel ...........33
+   Appendix D.  Compromise on Decap with ECT(1) Inner and ECT(0)
+                Outer ................................................34
+   Appendix E.  Open Issues ..........................................35
+
+
+
+
+
+
+
+
+
+
+
+
+Briscoe                      Standards Track                    [Page 3]
+
+RFC 6040                     ECN Tunnelling                November 2010
+
+
+1.  Introduction
+
+   Explicit congestion notification (ECN [RFC3168]) allows a forwarding
+   element (e.g., a router) to notify the onset of congestion without
+   having to drop packets.  Instead, it can explicitly mark a proportion
+   of packets in the two-bit ECN field in the IP header (Table 1 recaps
+   the ECN codepoints).
+
+   The outer header of an IP packet can encapsulate one or more IP
+   headers for tunnelling.  A forwarding element using ECN to signify
+   congestion will only mark the immediately visible outer IP header.
+   When a tunnel decapsulator later removes this outer header, it
+   follows rules to propagate congestion markings by combining the ECN
+   fields of the inner and outer IP header into one outgoing IP header.
+
+   This document updates those rules for IPsec [RFC4301] and non-IPsec
+   [RFC3168] tunnels to add new behaviours for previously unused
+   combinations of inner and outer headers.  It also updates the ingress
+   behaviour of RFC 3168 tunnels to match that of RFC 4301 tunnels.
+   Tunnel endpoints complying with the updated rules will be backward
+   compatible when interworking with tunnel endpoints complying with RFC
+   4301, RFC 3168, or any earlier specification.
+
+   When ECN and its tunnelling was defined in RFC 3168, only the minimum
+   necessary changes to the ECN field were propagated through tunnel
+   endpoints -- just enough for the basic ECN mechanism to work.  This
+   was due to concerns that the ECN field might be toggled to
+   communicate between a secure site and someone on the public Internet
+   -- a covert channel.  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 Internet.
+
+   Nonetheless, the latest IPsec architecture [RFC4301] considered a
+   bandwidth limit of two bits per packet on a covert channel to be a
+   manageable risk.  Therefore, for simplicity, an RFC 4301 ingress
+   copied the whole ECN field to encapsulate a packet.  RFC 4301
+   dispensed with the two modes of RFC 3168, one which partially copied
+   the ECN field, and the other which blocked all propagation of ECN
+   changes.
+
+   Unfortunately, this entirely reasonable sequence of standards actions
+   resulted in a perverse outcome; non-IPsec tunnels (RFC 3168) blocked
+   the two-bit covert channel, while IPsec tunnels (RFC 4301) did not --
+   at least not at the ingress.  At the egress, both IPsec and non-IPsec
+   tunnels still partially restricted propagation of the full ECN field.
+
+
+
+
+
+
+Briscoe                      Standards Track                    [Page 4]
+
+RFC 6040                     ECN Tunnelling                November 2010
+
+
+   The trigger for the changes in this document was the introduction of
+   pre-congestion notification (PCN [RFC5670]) to the IETF Standards
+   Track.  PCN needs the ECN field to be copied at a tunnel ingress and
+   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 RFC 3168 and RFC 4301.  Operators of tunnels who
+   specifically want to support four states can require that all their
+   tunnels comply with this specification.  However, this is not a fork
+   in the RFC series.  It is an update that can be deployed first by
+   those that need it, and subsequently by all tunnel endpoint
+   implementations (RFC 4301, RFC 3168, RFC 2481, RFC 2401, RFC 2003),
+   which 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.
+
+   In fact, this document is the opposite of a fork.  At the same time
+   as supporting a fourth state, the opportunity has been taken to draw
+   together divergent ECN tunnelling specifications into a single
+   consistent behaviour, harmonising differences such as perverse covert
+   channel treatment.  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 ECN field processing at encapsulation
+   and decapsulation for any IP-in-IP tunnelling, whether IPsec or non-
+   IPsec tunnels.  It applies irrespective of whether IPv4 or IPv6 is
+   used for either the inner or outer headers.  It applies 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 (but Section 4
+   strongly deprecates such exceptions).  It is intended to be a good
+   trade off between somewhat conflicting security, control, and
+   management requirements.
+
+
+
+
+
+Briscoe                      Standards Track                    [Page 5]
+
+RFC 6040                     ECN Tunnelling                November 2010
+
+
+   [RFC2983] is a comprehensive primer on differentiated services and
+   tunnels.  Given ECN raises similar issues to differentiated services
+   when interacting with tunnels, useful concepts introduced in RFC 2983
+   are used throughout, with brief recaps of the explanations where
+   necessary.
+
+2.  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].
+
+   Table 1 recaps the names of the ECN 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 Codepoints of the ECN Field [RFC3168]
+                             in the IP Header
+
+   Further terminology used within this document:
+
+   Encapsulator:  The tunnel endpoint function that adds an outer IP
+      header to tunnel a packet (also termed the 'ingress tunnel
+      endpoint' or just the 'ingress' where the context is clear).
+
+   Decapsulator:  The tunnel endpoint function that removes an outer IP
+      header from a tunnelled packet (also termed the 'egress tunnel
+      endpoint' or just the 'egress' where the context is clear).
+
+   Incoming header:  The header 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 combines the fields in the outer and inner headers.
+
+   Copying ECN:  On encapsulation, setting the ECN field of the new
+      outer header to be a copy of the ECN field in the incoming header.
+
+
+
+Briscoe                      Standards Track                    [Page 6]
+
+RFC 6040                     ECN Tunnelling                November 2010
+
+
+   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.
+
+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 (RFC 2481, RFC 2401, and
+   RFC 2003) are briefly outlined in Appendix 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, RFC 3168 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 incoming 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 encapsulator must simply copy the ECN field from the
+   incoming header to the outer header.
+
+   RFC 3168 also provided a Limited Functionality mode that turns off
+   ECN processing over the scope of the tunnel 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 added to
+   the outer header.  Otherwise, such legacy decapsulators would throw
+   away congestion notifications before they reached the transport
+   layer.
+
+
+
+
+
+
+
+
+Briscoe                      Standards Track                    [Page 7]
+
+RFC 6040                     ECN Tunnelling                November 2010
+
+
+   Neither Limited Functionality mode nor Full Functionality mode are
+   used by an RFC 4301 IPsec encapsulator, which simply copies the
+   incoming ECN field into the outer header.  An earlier key-exchange
+   phase ensures an RFC 4301 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 |             Departing Outer Header            |
+    | (also equal to  +---------------+---------------+---------------+
+    | departing Inner |  RFC 3168 ECN |  RFC 3168 ECN | RFC 4301 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       |
+    +-----------------+---------------+---------------+---------------+
+
+
+    Figure 1: IP-in-IP Encapsulation: Recap of Pre-Existing Behaviours
+
+3.2.  Decapsulation at Tunnel Egress
+
+   RFC 3168 and RFC 4301 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 arriving inner
+   header (row) and arriving outer header (column).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Briscoe                      Standards Track                    [Page 8]
+
+RFC 6040                     ECN Tunnelling                November 2010
+
+
+            +---------+------------------------------------------------+
+            |Arriving |            Arriving Outer Header               |
+            |   Inner +---------+------------+------------+------------+
+            |  Header | Not-ECT | ECT(0)     | ECT(1)     |     CE     |
+            +---------+---------+------------+------------+------------+
+  RFC 3168->| Not-ECT | Not-ECT |Not-ECT     |Not-ECT     |  <drop>    |
+  RFC 4301->| Not-ECT | Not-ECT |Not-ECT     |Not-ECT     |Not-ECT     |
+            |  ECT(0) |  ECT(0) | ECT(0)     | ECT(0)     |     CE     |
+            |  ECT(1) |  ECT(1) | ECT(1)     | ECT(1)     |     CE     |
+            |    CE   |      CE |     CE     |     CE     |     CE     |
+            +---------+---------+------------+------------+------------+
+
+   In pre-existing RFCs, the ECN field in the outgoing header was set to
+   the codepoint at the intersection of the appropriate arriving inner
+   header (row) and arriving outer header (column), or the packet was
+   dropped where indicated.
+
+     Figure 2: IP in IP Decapsulation; Recap of Pre-Existing Behaviour
+
+   The behaviour in the table derives from the logic given in RFC 3168
+   and RFC 4301, briefly recapped as follows:
+
+   o  On decapsulation, if the inner ECN field is Not-ECT the outer is
+      ignored.  RFC 3168 (but not RFC 4301) also specified that the
+      decapsulator must drop a packet with a Not-ECT inner and CE in the
+      outer.
+
+   o  In all other cases, if the outer is CE, the outgoing ECN field is
+      set to CE; otherwise, the outer is ignored and the inner is used
+      for the outgoing ECN field.
+
+   Section 9.2.2 of RFC 3168 also made it an auditable event for an
+   IPsec tunnel "if the ECN Field is changed inappropriately within an
+   IPsec tunnel...".  Inappropriate changes were not specifically
+   enumerated.  RFC 4301 did not mention inappropriate ECN changes.
+
+4.  New ECN Tunnelling Rules
+
+   The standards actions below in Section 4.1 (ingress encapsulation)
+   and Section 4.2 (egress decapsulation) define new default ECN tunnel
+   processing rules for any IP packet (v4 or v6) with any Diffserv
+   codepoint.
+
+   If these defaults do not meet a particular requirement, an alternate
+   ECN tunnelling scheme can be introduced as part of the definition of
+   an alternate congestion marking scheme used by a specific Diffserv
+   PHB (see [RFC4774] and Section 5 of [RFC3168]).  When designing such
+   alternate ECN tunnelling schemes, the principles in Section 7 should
+
+
+
+Briscoe                      Standards Track                    [Page 9]
+
+RFC 6040                     ECN Tunnelling                November 2010
+
+
+   be followed.  However, alternate ECN tunnelling schemes SHOULD be
+   avoided whenever possible as the deployment burden of handling
+   exceptional PHBs in implementations of all affected tunnels should
+   not be underestimated.  There is no requirement for a PHB definition
+   to state anything about ECN tunnelling behaviour if the default
+   behaviour in the present specification is sufficient.
+
+4.1.  Default Tunnel Ingress Behaviour
+
+   Two modes of encapsulation are defined here; a REQUIRED 'normal mode'
+   and a 'compatibility mode', which is for backward compatibility with
+   tunnel decapsulators that do not understand ECN.  Note that these are
+   modes of the ingress tunnel endpoint only, not the whole tunnel.
+   Section 4.3 explains why two modes are necessary and specifies the
+   circumstances in which it is sufficient to solely implement normal
+   mode.
+
+   Whatever the mode, an encapsulator forwards the inner header without
+   changing the ECN field.
+
+   In normal mode, an encapsulator compliant with this specification
+   MUST construct the outer encapsulating IP header by copying the
+   two-bit ECN field of the incoming IP header.  In compatibility mode,
+   it clears the ECN field in the outer header to the Not-ECT codepoint
+   (the IPv4 header checksum also changes whenever the ECN field is
+   changed).  These rules are tabulated for convenience in Figure 3.
+
+            +-----------------+-------------------------------+
+            | Incoming Header |    Departing Outer Header     |
+            | (also equal to  +---------------+---------------+
+            | departing 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
+
+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 arriving inner header (row) and outer
+   header (column) in Figure 4 (the IPv4 header checksum also changes
+
+
+
+
+Briscoe                      Standards Track                   [Page 10]
+
+RFC 6040                     ECN Tunnelling                November 2010
+
+
+   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.
+
+            +---------+------------------------------------------------+
+            |Arriving |            Arriving Outer Header               |
+            |   Inner +---------+------------+------------+------------+
+            |  Header | Not-ECT | ECT(0)     | ECT(1)     |     CE     |
+            +---------+---------+------------+------------+------------+
+            | Not-ECT | Not-ECT |Not-ECT(!!!)|Not-ECT(!!!)| <drop>(!!!)|
+            |  ECT(0) |  ECT(0) | ECT(0)     | ECT(1)     |     CE     |
+            |  ECT(1) |  ECT(1) | ECT(1) (!) | ECT(1)     |     CE     |
+            |    CE   |      CE |     CE     |     CE(!!!)|     CE     |
+            +---------+---------+------------+------------+------------+
+
+    The ECN field in the outgoing header is set to the codepoint at the
+      intersection of the appropriate arriving inner header (row) and
+      arriving outer header (column), or the packet is dropped where
+   indicated.  Currently unused combinations are indicated by '(!!!)' or
+                                   '(!)'
+
+              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 onwards.  This is because the
+      inner Not-ECT marking is set by transports that rely on dropped
+      packets as an indication of congestion and would not understand or
+      respond to any other ECN codepoint [RFC4774].  Specifically:
+
+      *  If the inner ECN field is Not-ECT and the outer ECN field is
+         CE, the decapsulator MUST drop the packet.
+
+      *  If the inner ECN field is Not-ECT and the outer ECN field is
+         Not-ECT, ECT(0), or ECT(1), the decapsulator MUST forward the
+         outgoing packet with the ECN field cleared to Not-ECT.
+
+   o  In all other cases where the inner supports ECN, the decapsulator
+      MUST set the outgoing ECN field 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.  This in no way
+      precludes cases where ECT(1) and ECT(0) have the same severity;
+
+   o  Certain combinations of inner and outer ECN fields cannot result
+      from any transition in any current or previous ECN tunneling
+      specification.  These currently unused (CU) combinations are
+
+
+
+Briscoe                      Standards Track                   [Page 11]
+
+RFC 6040                     ECN Tunnelling                November 2010
+
+
+      indicated in Figure 4 by '(!!!)' or '(!)', where '(!!!)' means the
+      combination is CU and always potentially dangerous, while '(!)'
+      means it is CU and possibly dangerous.  In these cases,
+      particularly the more dangerous ones, the decapsulator SHOULD log
+      the event and MAY also raise an alarm.
+
+      Just because the highlighted combinations are currently unused,
+      does not mean that all the other combinations are always valid.
+      Some are only valid if they have arrived from a particular type of
+      legacy ingress, and dangerous otherwise.  Therefore, an
+      implementation MAY allow an operator to configure logging and
+      alarms for such additional header combinations known to be
+      dangerous or CU for the particular configuration of tunnel
+      endpoints deployed at run-time.
+
+      Alarms SHOULD be rate-limited so that the anomalous combinations
+      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.
+
+   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), in particular, enabling the simplest
+   possible encoding for PCN [PCN3in1] (see Section 5.3.2).  Treating
+   ECT(1) as either the same as ECT(0) or as a higher severity level is
+   explained in the discussion of the ECN nonce [RFC3540] in Section 8,
+   which in turn refers to Appendix D.
+
+4.3.  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 the ingress tunnel endpoint only, not the tunnel as a whole.
+
+   To comply with this specification, a tunnel ingress MUST at least
+   implement normal mode.  Unless it will never be used with legacy
+   tunnel egress nodes (RFC 2003, RFC 2401, or RFC 2481 or the limited
+   functionality mode of RFC 3168), an ingress MUST also implement
+   compatibility mode for backward compatibility with tunnel egresses
+   that do not propagate explicit congestion notifications [RFC4774].
+
+   We can categorise the way that an ingress tunnel endpoint is paired
+   with an egress as either static or dynamically discovered:
+
+
+
+
+Briscoe                      Standards Track                   [Page 12]
+
+RFC 6040                     ECN Tunnelling                November 2010
+
+
+   Static:  Tunnel endpoints paired together by prior configuration.
+
+      Some implementations of encapsulator might always be statically
+      deployed, and constrained to never be paired with a legacy
+      decapsulator (RFC 2003, RFC 2401 or RFC 2481 or the limited
+      functionality mode of RFC 3168).  In such a case, only normal mode
+      needs to be implemented.
+
+      For instance, IPsec tunnel endpoints compatible with RFC 4301
+      invariably use Internet Key Exchange Protocol version 2 (IKEv2)
+      [RFC5996] for key exchange, the original specification of which
+      was introduced alongside RFC 4301.  Therefore, both endpoints of
+      an RFC 4301 tunnel can be sure that the other end is compatible
+      with RFC 4301, because the tunnel is only formed after IKEv2 key
+      management has completed, at which point both ends will be
+      compliant with RFC 4301 by definition.  Therefore an IPsec tunnel
+      ingress does not need compatibility mode, as it will never
+      interact with legacy ECN tunnels.  To comply with the present
+      specification, it only needs to implement the required normal
+      mode, which is identical to the pre-existing RFC 4301 behaviour.
+
+   Dynamic Discovery:  Tunnel endpoints paired together by some form of
+      tunnel endpoint discovery, typically finding an egress on the path
+      taken by the first packet.
+
+      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 ensure safe interworking.
+
+      If dynamic tunnel endpoint discovery might pair an ingress with a
+      legacy egress (RFC 2003, RFC 2401, or RFC 2481 or the limited
+      functionality mode of RFC 3168), the ingress MUST implement both
+      normal and compatibility mode.  If the tunnel discovery process is
+      arranged to only ever find a tunnel egress that propagates ECN
+      (RFC 3168 full functionality mode, RFC 4301, or this present
+      specification), then a tunnel ingress can be compliant with the
+      present specification without implementing compatibility mode.
+
+      While a compliant tunnel ingress is discovering an egress, it MUST
+      send packets in compatibility mode in case the egress it discovers
+      is a legacy egress.  If, through the discovery protocol, the
+      egress indicates that it is compliant with the present
+      specification, with RFC 4301 or with RFC 3168 full functionality
+      mode, the ingress can switch itself into normal mode.  If the
+      egress denies compliance with any of these or returns an error
+
+
+
+
+Briscoe                      Standards Track                   [Page 13]
+
+RFC 6040                     ECN Tunnelling                November 2010
+
+
+      that implies it does not understand a request to work to any of
+      these ECN specifications, the tunnel ingress MUST remain in
+      compatibility mode.
+
+   If an ingress claims compliance with this specification, it MUST NOT
+   permanently disable ECN processing across the tunnel (i.e., only
+   using compatibility mode).  It is true that such a tunnel ingress is
+   at least safe with the ECN behaviour of any egress it may encounter,
+   but it does not meet the central aim of this specification:
+   introducing ECN support to tunnels.
+
+   Instead, if the ingress knows that the egress does support
+   propagation of ECN (full functionality mode of RFC 3168 or RFC 4301
+   or the present specification), it SHOULD use normal mode, in order to
+   support ECN where possible.  Note that this section started by saying
+   an ingress "MUST implement" normal mode, while it has just said an
+   ingress "SHOULD use" normal mode.  This distinction is deliberate, to
+   allow the mode to be turned off in exceptional circumstances but to
+   ensure all implementations make normal mode available.
+
+   Implementation note:  If a compliant node is the ingress for multiple
+      tunnels, a mode setting will need to be stored for each tunnel
+      ingress.  However, if a node is the egress for multiple tunnels,
+      none of the tunnels will need to store a mode setting, because a
+      compliant egress only needs one mode.
+
+4.4.  Single Mode of Decapsulation
+
+   A compliant decapsulator only needs one mode of operation.  However,
+   if a compliant egress is implemented to be dynamically discoverable,
+   it may need to respond to discovery requests from various types of
+   legacy tunnel 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 tunnel ingress compliant with the
+   present specification might ask if the egress is compliant with the
+   present specification, with RFC 4301 or with RFC 3168 full
+   functionality mode.  Or an RFC 3168 tunnel ingress might try to
+   negotiate to use limited functionality or full functionality mode
+   [RFC3168].  In all these cases, a decapsulating tunnel egress
+   compliant with this specification MUST agree to any of these
+   requests, since it will behave identically in all these cases.
+
+
+
+
+
+
+
+Briscoe                      Standards Track                   [Page 14]
+
+RFC 6040                     ECN Tunnelling                November 2010
+
+
+   If no ECN-related mode is requested, a compliant tunnel egress MUST
+   continue without raising any error or warning, because its egress
+   behaviour is compatible with all the legacy ingress behaviours that
+   do not negotiate capabilities.
+
+   A compliant tunnel egress SHOULD raise a warning alarm about any
+   requests to enter modes it does not recognise but, for 'forward
+   compatibility' with standards actions possibly defined after it was
+   implemented, it SHOULD continue operating.
+
+5.  Updates to Earlier RFCs
+
+5.1.  Changes to RFC 4301 ECN Processing
+
+   Ingress:  An RFC 4301 IPsec encapsulator is not changed at all by the
+      present specification.  It uses the normal mode of the present
+      specification, which defines packet encapsulation identically to
+      RFC 4301.
+
+   Egress:  An RFC 4301 egress will need to be updated to the new
+      decapsulation behaviour in Figure 4, in order to comply with the
+      present specification.  However, the changes are backward
+      compatible; combinations of inner and outer that result from any
+      protocol defined in the RFC series so far are unaffected.  Only
+      combinations that have never been used have been changed,
+      effectively adding new behaviours to RFC 4301 decapsulation
+      without altering existing behaviours.  The following specific
+      updates to Section 5.1.2 of RFC 4301 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 Not-ECT in the inner and an outer of 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:  RFC 4301 tunnel endpoints do not need modes and are not
+      updated by the modes in the present specification.  Effectively,
+      an RFC 4301 IPsec ingress solely uses the REQUIRED normal mode of
+      encapsulation, which is unchanged from RFC 4301 encapsulation.  It
+      will never need the OPTIONAL compatibility mode as explained in
+      Section 4.3.
+
+
+
+
+
+
+Briscoe                      Standards Track                   [Page 15]
+
+RFC 6040                     ECN Tunnelling                November 2010
+
+
+5.2.  Changes to RFC 3168 ECN Processing
+
+   Ingress:  On encapsulation, the new rule in Figure 3 that a normal
+      mode tunnel ingress copies any ECN field into the outer header
+      updates the full functionality behaviour of an RFC 3168 ingress
+      (Section 9.1.1 of [RFC3168]).  Nonetheless, the new compatibility
+      mode encapsulates packets identically to the limited functionality
+      mode of an RFC 3168 ingress.
+
+   Egress:  An RFC 3168 egress will need to be updated to the new
+      decapsulation behaviour in Figure 4, in order to comply with the
+      present specification.  However, the changes are backward
+      compatible; combinations of inner and outer that result from any
+      protocol defined in the RFC series so far are unaffected.  Only
+      combinations that have never been used have been changed,
+      effectively adding new behaviours to RFC 3168 decapsulation
+      without altering existing behaviours.  The following specific
+      updates to Section 9.1.1 of RFC 3168 have been made:
+
+      *  The outer, not the inner, is propagated when the outer is
+         ECT(1) and the inner is ECT(0);
+
+      *  Certain combinations of inner and outer ECN field have been
+         identified as currently unused.  These can trigger logging
+         and/or raise alarms.
+
+   Modes:  An RFC 3168 ingress will need to be updated if it is to
+      comply with the present specification, whether or not it
+      implemented the optional full functionality mode of Section 9.1.1
+      of RFC 3168.
+
+      Section 9.1 of RFC 3168 defined a (required) limited functionality
+      mode and an (optional) full functionality mode for a tunnel.  In
+      RFC 3168, modes applied to both ends of the tunnel, while in the
+      present specification, modes are only used at the ingress -- a
+      single egress behaviour covers all cases.
+
+      The normal mode of encapsulation is an update to the encapsulation
+      behaviour of the full functionality mode of an RFC 3168 ingress.
+      The compatibility mode of encapsulation is identical to the
+      encapsulation behaviour of the limited functionality mode of an
+      RFC 3168 ingress, except it is not always obligatory.
+
+      The constraints on how tunnel discovery protocols set modes in
+      Sections 4.3 and 4.4 are an update to RFC 3168, but they are
+      unlikely to require code changes as they document existing safe
+      practice.
+
+
+
+
+Briscoe                      Standards Track                   [Page 16]
+
+RFC 6040                     ECN Tunnelling                November 2010
+
+
+5.3.  Motivation for Changes
+
+   An overriding goal is to ensure the same ECN signals can mean the
+   same thing whatever tunnels happen to encapsulate an IP packet flow.
+   This removes gratuitous inconsistency, which otherwise constrains the
+   available design space and makes it harder to design networks and new
+   protocols that work predictably.
+
+5.3.1.  Motivation for Changing Encapsulation
+
+   The normal mode in Section 4 updates RFC 3168 to make all IP-in-IP
+   encapsulation of the ECN field consistent -- consistent with the way
+   both RFC 4301 IPsec [RFC4301] and IP-in-MPLS or MPLS-in-MPLS
+   encapsulation [RFC5129] construct the ECN field.
+
+   Compatibility mode has also been defined so that an ingress compliant
+   with a version of IPsec prior to RFC 4301 can still switch to using
+   drop across a tunnel for backward compatibility with legacy
+   decapsulators that do not propagate ECN.
+
+   The trigger that motivated this update to RFC 3168 encapsulation was
+   a Standards-Track proposal for pre-congestion notification (PCN
+   [RFC5670]).  PCN excess-traffic-marking only works correctly if the
+   ECN field is copied on encapsulation (as in RFC 4301 and RFC 5129);
+   it does not work if ECN is reset (as in RFC 3168).  This is because
+   PCN excess-traffic-marking depends on the outer header revealing any
+   congestion experienced so far on the whole path, not just since the
+   last tunnel ingress.
+
+   PCN allows a network operator to 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 of Diffserv, aiming to significantly reduce
+   costs.  The PCN architecture [RFC5559] states that RFC 3168 IP-in-IP
+   tunnelling of the ECN field cannot be used for any tunnel ingress in
+   a PCN domain.  Prior to the present specification, this left a stark
+   choice between not being able to use PCN for inelastic traffic
+   control or not being able to use the many tunnels already deployed
+   for Mobile IP, VPNs, and so forth.
+
+   The present specification provides a clean solution to this problem,
+   so that network operators who want to use both PCN and tunnels can
+   specify that every tunnel ingress in a PCN region must comply with
+   this latest specification.
+
+   Rather than allow tunnel specifications to fragment further into one
+   for PCN, one for IPsec, and one for other tunnels, the opportunity
+   has been taken to consolidate the diverging specifications back into
+
+
+
+Briscoe                      Standards Track                   [Page 17]
+
+RFC 6040                     ECN Tunnelling                November 2010
+
+
+   a single tunnelling behaviour.  Resetting ECN was originally
+   motivated by a covert channel concern that has been deliberately set
+   aside in RFC 4301 IPsec.  Therefore, the reset behaviour of RFC 3168
+   is an anomaly that we do not need to keep.  Copying ECN on
+   encapsulation is simpler than resetting.  So, as more tunnel
+   endpoints comply with this single consistent specification,
+   encapsulation will be simpler as well as more predictable.
+
+   Appendix B assesses whether copying rather than resetting CE on
+   ingress will cause any unintended side effects, from the three
+   perspectives of security, control, and management.  In summary, this
+   analysis finds that:
+
+   o  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
+      that is already on the Standards Track.
+
+   o  From the 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 information security perspective, resetting is
+      preferable, but the IETF Security Area now considers copying
+      acceptable given the bandwidth of a two-bit covert channel can be
+      managed.
+
+   Therefore, there are two points against resetting CE on ingress while
+   copying CE causes no significant harm.
+
+5.3.2.  Motivation for Changing Decapsulation
+
+   The specification for decapsulation in Section 4 fixes three problems
+   with the pre-existing behaviours found in both RFC 3168 and RFC 4301:
+
+   1.  The pre-existing rules prevented the introduction of alternate
+       ECN semantics to signal more than one severity level of
+       congestion [RFC4774], [RFC5559].  The four states of the two-bit
+       ECN field provide room for signalling two severity levels in
+       addition to not-congested and not-ECN-capable states.  But, the
+       pre-existing rules assumed that two of the states (ECT(0) and
+       ECT(1)) are always equivalent.  This unnecessarily restricts the
+       use of one of four codepoints (half a bit) in the IP (v4 and v6)
+       header.  The new rules are designed to work in either case;
+       whether ECT(1) is more severe than or equivalent to ECT(0).
+
+
+
+Briscoe                      Standards Track                   [Page 18]
+
+RFC 6040                     ECN Tunnelling                November 2010
+
+
+       As explained in Appendix B.1, the original reason for not
+       forwarding the outer ECT codepoints was to limit the covert
+       channel across a decapsulator to 1 bit per packet.  However, now
+       that the IETF Security Area has deemed that a two-bit covert
+       channel through an encapsulator is a manageable risk, the same
+       should be true for a decapsulator.
+
+       As well as being useful for general future-proofing, this problem
+       is immediately pressing for standardisation of pre-congestion
+       notification (PCN), which uses two severity levels of congestion.
+       If a congested queue used ECT(1) in the outer header to signal
+       more severe congestion than ECT(0), the pre-existing
+       decapsulation rules would have thrown away this congestion
+       signal, preventing tunnelled traffic from ever knowing that it
+       should reduce its load.
+
+       Before the present specification was written, the PCN working
+       group had to consider a number of wasteful or convoluted work-
+       rounds to this problem.  Without wishing to disparage the
+       ingenuity of these work-rounds, none were chosen for the
+       Standards Track because they were either somewhat wasteful,
+       imprecise, or complicated.  Instead, a baseline PCN encoding was
+       specified [RFC5696] that supported only one severity level of
+       congestion but allowed space for these work-rounds as
+       experimental extensions.
+
+       By far the simplest approach is that taken by the current
+       specification: just to remove the covert channel blockages from
+       tunnelling behaviour -- now deemed unnecessary anyway.  Then,
+       network operators that want to support two congestion severity
+       levels for PCN can specify that every tunnel egress in a PCN
+       region must comply with this latest specification.  Having taken
+       this step, the simplest possible encoding for PCN with two
+       severity levels of congestion [PCN3in1] can be used.
+
+       Not only does this make two congestion severity levels available
+       for PCN, but also for other potential uses of the extra ECN
+       codepoint (e.g., [VCP]).
+
+   2.  Cases are documented where a middlebox (e.g., a firewall) drops
+       packets with header values that were currently unused (CU) when
+       the box was deployed, often on the grounds that anything
+       unexpected might be 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
+       headers that are currently unused.  The aim is to give
+       implementers a recourse other than drop if they are concerned
+       about the security of CU values.  It recognises legitimate
+
+
+
+Briscoe                      Standards Track                   [Page 19]
+
+RFC 6040                     ECN Tunnelling                November 2010
+
+
+       security concerns about CU values, but still eases their future
+       use.  If the alarms are interpreted as an attack (e.g., by a
+       management system) the offending packets can be dropped.
+       However, alarms can be turned off if these combinations come into
+       regular use (e.g., through a future standards action).
+
+   3.  While reviewing currently unused combinations of inner and outer
+       headers, the opportunity was taken to define a single consistent
+       behaviour for the three cases with a Not-ECT inner header but a
+       different outer.  RFC 3168 and RFC 4301 had diverged in this
+       respect and even their common behaviours had never been
+       justified.
+
+       None of these combinations should result from Internet protocols
+       in the RFC series, but future standards actions might put any or
+       all of them to good use.  Therefore, it was decided that a
+       decapsulator must forward a Not-ECT inner header unchanged when
+       the arriving outer header is ECT(0) or ECT(1).  For safety, it
+       must drop a combination of Not-ECT inner and CE outer headers.
+       Then, if some unfortunate misconfiguration resulted in a
+       congested router marking CE on a packet that was originally
+       Not-ECT, drop would be the only appropriate signal for the egress
+       to propagate -- the only signal a non-ECN-capable transport
+       (Not-ECT) would understand.
+
+       It may seem contradictory that the same argument has not been
+       applied to the ECT(1) codepoint, given it is being proposed as an
+       intermediate level of congestion in a scheme progressing through
+       the IETF [PCN3in1].  Instead, a decapsulator must forward a
+       Not-ECT inner unchanged when its outer is ECT(1).  The rationale
+       for not dropping this CU combination is to ensure it will be
+       usable if needed in the future.  If any misconfiguration led to
+       ECT(1) congestion signals with a Not-ECT inner, it would not be
+       disastrous for the tunnel egress to suppress them, because the
+       congestion should then escalate to CE marking, which the egress
+       would drop, thus at least preventing congestion collapse.
+
+   Problems 2 and 3 alone would not warrant a change to decapsulation,
+   but it was decided they are worth fixing and making consistent at the
+   same time as decapsulation code is changed to fix problem 1 (two
+   congestion severity levels).
+
+
+
+
+
+
+
+
+
+
+Briscoe                      Standards Track                   [Page 20]
+
+RFC 6040                     ECN Tunnelling                November 2010
+
+
+6.  Backward Compatibility
+
+   A tunnel endpoint compliant with the present specification is
+   backward compatible when paired with any tunnel endpoint compliant
+   with any previous tunnelling RFC, whether RFC 4301, RFC 3168 (see
+   Section 3), or the earlier RFCs summarised in Appendix A (RFC 2481,
+   RFC 2401, and RFC 2003).  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 field (RFC 3168 and RFC 4301) 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 RFC 4301 IPsec egress
+   is updated to comply with the new rules, it will still interwork with
+   any ingress compliant with RFC 4301 and the packet outputs will be
+   identical to those it would have output before (fully backward
+   compatible).
+
+   And, all other things being equal, if an RFC 3168 egress is updated
+   to comply with the same new rules, it will still interwork with any
+   ingress complying with any previous specification (both modes of RFC
+   3168, both modes of RFC 2481, RFC 2401, and RFC 2003) and the packet
+   outputs will be identical to those it would have output before (fully
+   backward compatible).
+
+   A compliant tunnel egress merely needs to implement the one behaviour
+   in Section 4 with no additional mode or option configuration at the
+   ingress or egress nor any additional negotiation with the ingress.
+   The new decapsulation rules have been defined in such a way that
+   congestion control will still work safely if any of the earlier
+   versions of ECN processing are used unilaterally at the encapsulating
+   ingress of the tunnel (any of RFC 2003, RFC 2401, either mode of RFC
+   2481, either mode of RFC 3168, RFC 4301, and this present
+   specification).
+
+6.2.  Non-Update of RFC 4301 IPsec Encapsulation
+
+   An RFC 4301 IPsec ingress can comply with this new specification
+   without any update and it has no need for any new modes, options, or
+   configuration.  So, all other things being equal, it will continue to
+   interwork identically with any egress it worked with before (fully
+   backward compatible).
+
+
+
+
+
+
+Briscoe                      Standards Track                   [Page 21]
+
+RFC 6040                     ECN Tunnelling                November 2010
+
+
+6.3.  Update to RFC 3168 Encapsulation
+
+   The encapsulation behaviour of the new normal mode copies the ECN
+   field, whereas an RFC 3168 ingress in full functionality mode reset
+   it.  However, all other things being equal, if an RFC 3168 ingress is
+   updated to the present specification, the outgoing packets from any
+   tunnel egress will still be unchanged.  This is because all variants
+   of tunnelling at either end (RFC 4301, both modes of RFC 3168, both
+   modes of RFC 2481, RFC 2401, RFC 2003, and the present specification)
+   have always propagated an incoming CE marking through the inner
+   header and onward into the outgoing header; whether the outer header
+   is reset or copied.  Therefore, if the tunnel is considered a black
+   box, the packets output from any egress will be identical with or
+   without an update to the ingress.  Nonetheless, if packets are
+   observed within the black box (between the tunnel endpoints), CE
+   markings copied by the updated ingress will be visible within the
+   black box, whereas they would not have been before.  Therefore, the
+   update to encapsulation can be termed 'black-box backward compatible'
+   (i.e., identical unless you look inside the tunnel).
+
+   This specification introduces no new backward compatibility issues
+   when a compliant ingress talks with a legacy egress, but it has to
+   provide similar safeguards to those already defined in RFC 3168.  RFC
+   3168 laid down rules to ensure that an RFC 3168 ingress turns off ECN
+   (limited functionality mode) if it is paired with a legacy egress
+   (RFC 2481, RFC 2401, or RFC 2003), which would not propagate ECN
+   correctly.  The present specification carries forward those rules
+   (Section 4.3).  It uses compatibility mode whenever RFC 3168 would
+   have used limited functionality mode, and their per-packet behaviours
+   are identical.  Therefore, all other things being equal, an ingress
+   using the new rules will interwork with any legacy tunnel egress in
+   exactly the same way as an RFC 3168 ingress (still black-box backward
+   compatible).
+
+7.  Design Principles for Alternate ECN Tunnelling Semantics
+
+   This section is informative, not normative.
+
+   Section 5 of RFC 3168 permits the Diffserv codepoint (DSCP)[RFC2474]
+   to 'switch in' alternative behaviours for marking the ECN field, just
+   as it switches in different per-hop behaviours (PHBs) for scheduling.
+   [RFC4774] gives best current practice for designing such alternative
+   ECN semantics and very briefly mentions in Section 5.4 that
+   tunnelling needs to be considered.  The guidance below complements
+   and extends RFC 4774, giving additional guidance on designing any
+   alternate ECN semantics that would also require alternate tunnelling
+   semantics.
+
+
+
+
+Briscoe                      Standards Track                   [Page 22]
+
+RFC 6040                     ECN Tunnelling                November 2010
+
+
+   The overriding guidance is: "Avoid designing alternate ECN tunnelling
+   semantics, if at all possible".  If a scheme requires tunnels to
+   implement special processing of the ECN field for certain DSCPs, it
+   will be hard to guarantee that every implementer of every tunnel will
+   have added the required exception or that operators will have
+   ubiquitously deployed the required updates.  It is unlikely a single
+   authority is even aware of all the tunnels in a network, which may
+   include tunnels set up by applications between endpoints, or
+   dynamically created in the network.  Therefore, it is highly likely
+   that some tunnels within a network or on hosts connected to it will
+   not implement the required special case.
+
+   That said, if a non-default scheme for tunnelling the ECN field is
+   really required, the following guidelines might prove useful in its
+   design:
+
+   On encapsulation in any alternate scheme:
+
+      1.  The ECN field of the outer header ought to 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 the outer header.
+
+      2.  If it has established that ECN will be correctly propagated,
+          an encapsulator also ought to 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 monitoring
+          explains).
+
+          In some circumstances (e.g., PCN [RFC5559] and perhaps some
+          pseudowires [RFC5659]), the whole path is divided into
+          segments, each with its own congestion notification and
+          feedback loop.  In these cases, the function that regulates
+          load at the start of each segment will need to reset
+          congestion notification for its segment.  Often, the point
+          where congestion notification is reset will also be located at
+          the start of a tunnel.  However, the resetting function can 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 the load
+          regulator module can reset congestion, without any code in
+          either module being conditional on whether the other is there.
+
+
+
+
+
+
+Briscoe                      Standards Track                   [Page 23]
+
+RFC 6040                     ECN Tunnelling                November 2010
+
+
+   On decapsulation in any alternate scheme:
+
+      1.  If the arriving inner header is Not-ECT, the transport will
+          not understand other ECN codepoints.  If the outer header
+          carries an explicit congestion marking, the alternate scheme
+          would be expected to drop the packet -- the only indication of
+          congestion the transport will understand.  If the alternate
+          scheme recommends forwarding rather than dropping such a
+          packet, it will need to clearly justify this decision.  If the
+          inner is Not-ECT and the outer carries any other ECN codepoint
+          that does not indicate congestion, the alternate scheme can
+          forward the packet, but probably only as Not-ECT.
+
+      2.  If the arriving inner header is one other than Not-ECT, the
+          ECN field that the alternate decapsulation scheme forwards
+          ought to reflect the more severe congestion marking of the
+          arriving inner and outer headers.
+
+      3.  Any alternate scheme will need to define a behaviour for all
+          combinations of inner and outer headers, even those that would
+          not be expected to result from standards known at the time and
+          even those that would not be expected from the tunnel ingress
+          paired with the egress at run-time.  Consideration should be
+          given to logging such unexpected combinations and raising an
+          alarm, particularly if there is a danger that the invalid
+          combination implies congestion signals are not being
+          propagated correctly.  The presence of currently unused
+          combinations may represent an attack, but the new scheme
+          should try to define a way to forward such packets, at least
+          if a safe outgoing codepoint can be defined.
+
+          Raising an alarm allows a management system to decide whether
+          the anomaly is indeed an attack, in which case it can decide
+          to drop such packets.  This is a preferable approach to hard-
+          coded discard of packets that seem anomalous today, but may be
+          needed tomorrow in future standards actions.
+
+8.  Security Considerations
+
+   Appendix 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 traffic
+   security (congestion monitoring and control).  Ensuring congestion
+   markings are not lost is itself an aspect of security, because if we
+   allowed congestion notification to be lost, any attempt to enforce a
+   response to congestion would be much harder.
+
+
+
+
+
+Briscoe                      Standards Track                   [Page 24]
+
+RFC 6040                     ECN Tunnelling                November 2010
+
+
+   Security issues in unlikely, but possible, scenarios:
+
+   Tunnels intersecting Diffserv regions with alternate ECN semantics:
+      If alternate congestion notification semantics are defined for a
+      certain Diffserv PHB, the scope of the alternate semantics might
+      typically be bounded by the limits of a Diffserv region or
+      regions, as envisaged in [RFC4774] (e.g., the pre-congestion
+      notification architecture [RFC5559]).  The inner headers in
+      tunnels crossing the boundary of such a Diffserv region but ending
+      within the region can potentially leak the 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 be applied at these tunnel
+      endpoints as if they are at the edge of the Diffserv region.
+      Similar concerns apply to any processing or propagation of the ECN
+      field at the endpoints of tunnels with one end inside and the
+      other outside the domain.  [RFC5559] 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.
+
+   ECN nonce tunnel coverage:  The new decapsulation rules improve the
+      coverage of the ECN nonce [RFC3540] relative to the previous rules
+      in RFC 3168 and RFC 4301.  However, nonce coverage is still not
+      perfect, as this would have led to a safety problem in another
+      case.  Both are corner-cases, so discussion of the compromise
+      between them is deferred to Appendix D.
+
+   Covert channel not turned off:  A legacy (RFC 3168) tunnel ingress
+      could ask an RFC 3168 egress to turn off ECN 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 ingress always sending Not-ECT in the outer
+      header.  If the egress receives other ECN codepoints in the outer
+      it will process them as normal, so it will actually still copy
+      congestion markings from the outer to the outgoing header.
+      Referring, for example, to Figure 5 (Appendix B.1), although the
+      tunnel ingress 'I' will set all ECN fields in outer headers to
+      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 says it has
+      negotiated.  We could have specified that 'E' should have a
+      limited functionality mode and check for such behaviour.  However,
+      we decided not to add the extra complexity of two modes on a
+      compliant tunnel egress merely to cater for an historic security
+      concern that is now considered manageable.
+
+
+
+
+
+Briscoe                      Standards Track                   [Page 25]
+
+RFC 6040                     ECN Tunnelling                November 2010
+
+
+9.  Conclusions
+
+   This document allows tunnels to propagate an extra level of
+   congestion severity.  It uses previously unused combinations of inner
+   and outer headers to augment the rules for calculating the ECN field
+   when decapsulating IP packets at the egress of IPsec (RFC 4301) and
+   non-IPsec (RFC 3168) tunnels.
+
+   This document also updates the ingress tunnelling encapsulation of
+   RFC 3168 ECN to bring all IP-in-IP tunnels into line with the new
+   behaviour in the IPsec architecture of RFC 4301, which copies rather
+   than resets the ECN field when creating outer headers.
+
+   The need for both these updated behaviours was triggered by the
+   introduction of pre-congestion notification (PCN) onto the IETF
+   Standards Track.  Operators wanting to support PCN or other alternate
+   ECN schemes that use an extra severity level can require that their
+   tunnels comply with the present specification.  This is not a fork in
+   the RFC series, it is an update that can be deployed first by those
+   that need it, and subsequently by all tunnel endpoint implementations
+   during general code maintenance.  It is backward compatible with all
+   previous tunnelling behaviours, so existing single severity level
+   schemes will continue to work as before, but support for two severity
+   levels will gradually be added to the Internet.
+
+   The new rules propagate changes to the ECN field across tunnel
+   endpoints that previously blocked them to restrict the bandwidth of a
+   potential covert channel.  Limiting the channel's bandwidth to two
+   bits per packet is now considered sufficient.
+
+   At the same time as removing these legacy 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.  This new certainty could enable new uses of the ECN field
+   that would otherwise be confounded by ambiguity.
+
+10.  Acknowledgements
+
+   Thanks to David Black for his insightful reviews and patient
+   explanations of better ways to think about function placement and
+   alarms.  Thanks to David and to Anil Agarwal for pointing out cases
+   where it is safe to forward CU combinations of headers.  Also, thanks
+   to Arnaud Jacquet for the idea for Appendix C.  Thanks to Gorry
+   Fairhurst, Teco Boot, Michael Menth, Bruce Davie, Toby Moncaster,
+
+
+
+Briscoe                      Standards Track                   [Page 26]
+
+RFC 6040                     ECN Tunnelling                November 2010
+
+
+   Sally Floyd, Alfred Hoenes, Gabriele Corliano, Ingemar Johansson,
+   Philip Eardley, and David Harrington for their thoughts and careful
+   review comments, and to Stephen Hanna, Ben Campbell, and members of
+   the IESG for respectively conducting the Security Directorate,
+   General Area, and IESG reviews.
+
+   Bob Briscoe is partly funded by Trilogy, a research project (ICT-
+   216372) supported by the European Community under its Seventh
+   Framework Programme.
+
+11.  References
+
+11.1.  Normative References
+
+   [RFC2003]  Perkins, C., "IP Encapsulation within IP", RFC 2003,
+              October 1996.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
+              of Explicit Congestion Notification (ECN) to IP",
+              RFC 3168, September 2001.
+
+   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
+              Internet Protocol", RFC 4301, December 2005.
+
+11.2.  Informative References
+
+   [PCN3in1]  Briscoe, B., Moncaster, T., and M. Menth, "Encoding 3 PCN-
+              States in the IP header using a single DSCP", Work
+              in Progress, July 2010.
+
+   [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 Differentiated Services Field (DS
+              Field) in the IPv4 and IPv6 Headers", RFC 2474,
+              December 1998.
+
+   [RFC2481]  Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit
+              Congestion Notification (ECN) to IP", RFC 2481,
+              January 1999.
+
+   [RFC2983]  Black, D., "Differentiated Services and Tunnels",
+              RFC 2983, October 2000.
+
+
+
+
+Briscoe                      Standards Track                   [Page 27]
+
+RFC 6040                     ECN Tunnelling                November 2010
+
+
+   [RFC3540]  Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
+              Congestion Notification (ECN) Signaling with Nonces",
+              RFC 3540, June 2003.
+
+   [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 in MPLS", RFC 5129, January 2008.
+
+   [RFC5559]  Eardley, P., "Pre-Congestion Notification (PCN)
+              Architecture", RFC 5559, June 2009.
+
+   [RFC5659]  Bocci, M. and S. Bryant, "An Architecture for Multi-
+              Segment Pseudowire Emulation Edge-to-Edge", RFC 5659,
+              October 2009.
+
+   [RFC5670]  Eardley, P., "Metering and Marking Behaviour of PCN-
+              Nodes", RFC 5670, November 2009.
+
+   [RFC5696]  Moncaster, T., Briscoe, B., and M. Menth, "Baseline
+              Encoding and Transport of Pre-Congestion Information",
+              RFC 5696, November 2009.
+
+   [RFC5996]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
+              "Internet Key Exchange Protocol Version 2 (IKEv2)",
+              RFC 5996, September 2010.
+
+   [VCP]      Xia, Y., Subramanian, L., Stoica, I., and S. Kalyanaraman,
+              "One more bit is enough", Proc. SIGCOMM'05, ACM
+              CCR 35(4)37--48, 2005,
+              <http://doi.acm.org/10.1145/1080091.1080098>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Briscoe                      Standards Track                   [Page 28]
+
+RFC 6040                     ECN Tunnelling                November 2010
+
+
+Appendix A.  Early ECN Tunnelling RFCs
+
+   IP-in-IP tunnelling was originally defined in [RFC2003].  On
+   encapsulation, the incoming header was copied to the outer and on
+   decapsulation, the outer was simply discarded.  Initially, IPsec
+   tunnelling [RFC2401] followed the same behaviour.
+
+   When ECN was introduced experimentally in [RFC2481], legacy (RFC 2003
+   or RFC 2401) tunnels would have discarded any congestion markings
+   added to the outer header, so RFC 2481 introduced rules for
+   calculating the outgoing header from a combination of the inner and
+   outer on decapsulation.  RFC 2481 also introduced a second mode for
+   IPsec tunnels, which turned off ECN processing (Not-ECT) in the outer
+   header on encapsulation because an RFC 2401 decapsulator would
+   discard the outer on decapsulation.  For RFC 2401 IPsec, this had the
+   side effect of completely blocking the covert channel.
+
+   In RFC 2481, the ECN field was defined as two separate bits.  But
+   when ECN moved from Experimental to Standards Track [RFC3168], the
+   ECN field was redefined as four codepoints.  This required a
+   different calculation of the ECN field from that used in RFC 2481 on
+   decapsulation.  RFC 3168 also had two modes; a 'full functionality
+   mode' that restricted the covert channel as much as possible but
+   still allowed ECN to be used with IPsec, and another that completely
+   turned off ECN processing across the tunnel.  This 'limited
+   functionality mode' both offered a way for operators to completely
+   block the covert channel and allowed an RFC 3168 ingress to interwork
+   with a legacy tunnel egress (RFC 2481, RFC 2401, or RFC 2003).
+
+   The present specification includes a similar compatibility mode to
+   interwork safely with tunnels compliant with any of these three
+   earlier RFCs.  However, unlike RFC 3168, it is only a mode of the
+   ingress, as decapsulation behaviour is the same in either case.
+
+Appendix B.  Design Constraints
+
+   Tunnel processing of a congestion notification field has to meet
+   congestion control and management needs without creating new
+   information security vulnerabilities (if information security is
+   required).  This appendix documents the analysis of the trade-offs
+   between these factors that led to the new encapsulation rules in
+   Section 4.1.
+
+B.1.  Security Constraints
+
+   Information security can be assured by using various end-to-end
+   security solutions (including IPsec in transport mode [RFC4301]), but
+   a commonly used scenario involves the need to communicate between two
+
+
+
+Briscoe                      Standards Track                   [Page 29]
+
+RFC 6040                     ECN Tunnelling                November 2010
+
+
+   physically protected domains across the public Internet.  In this
+   case, there are certain management advantages to using IPsec in
+   tunnel mode solely across the publicly accessible part of the path.
+   The path followed by a packet then crosses security 'domains'; the
+   ones protected by physical or other means before and after the tunnel
+   and the one protected by an IPsec tunnel across the otherwise
+   unprotected domain.  The scenario in Figure 5 will be used where
+   endpoints 'A' and 'B' communicate through a tunnel.  The tunnel
+   ingress 'I' and egress 'E' are within physically protected edge
+   domains, while the tunnel spans an unprotected internetwork where
+   there may be 'men in 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' to 'B'.  IPsec authentication is used to prevent 'M'
+   masquerading as the sender of messages from 'A' to 'B' or altering
+   their contents.  'I' can use IPsec tunnel mode to allow 'A' to
+   communicate with 'B', but 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 ECN field (as well as the Time
+   to Live (TTL) / Hop Limit and DS fields) cannot be included in the
+   cryptographic calculations of IPsec.  Therefore, if 'I' copies these
+   mutable fields into the outer header that is exposed across the
+   tunnel it will have allowed a covert channel from 'A' to 'M' that
+   bypasses its encryption of the inner header.  And if 'E' copies these
+   fields from the outer header to the outgoing, even if it validates
+   authentication from 'I', it will have allowed a covert channel from
+   'M' to 'B'.
+
+   ECN at the IP layer is designed to carry information about congestion
+   from a congested resource towards downstream nodes.  Typically, a
+   downstream transport might feed the information back somehow to the
+   point upstream of the congestion that can regulate the load on the
+   congested resource, but other actions are possible [RFC3168], Section
+   6.  In terms of the above unicast scenario, ECN effectively intends
+
+
+
+Briscoe                      Standards Track                   [Page 30]
+
+RFC 6040                     ECN Tunnelling                November 2010
+
+
+   to create an information channel (for congestion signalling) from 'M'
+   to 'B' (for 'B' to feed back to 'A').  Therefore, the goals of IPsec
+   and ECN are mutually incompatible, requiring some compromise.
+
+   With respect to using the DS or ECN fields as covert channels,
+   Section 5.1.2 of RFC 4301 says, "controls are provided to manage the
+   bandwidth of this channel".  Using the ECN processing rules of RFC
+   4301, the channel bandwidth is two bits per datagram from 'A' to 'M'
+   and one bit per datagram from 'M' to 'B' (because 'E' limits the
+   combinations of the 2-bit ECN field that it will copy).  In both
+   cases, the covert channel bandwidth is further reduced by noise from
+   any real congestion marking.  RFC 4301 implies that these covert
+   channels are sufficiently limited to be considered a manageable
+   threat.  However, with respect to the larger (six-bit) DS field, the
+   same section of RFC 4301 says not copying is the default, but a
+   configuration option can allow copying "to allow a local
+   administrator to decide whether the covert channel provided by
+   copying these bits outweighs the benefits of copying".  Of course, an
+   administrator who plans to copy the DS field has to take into account
+   that it could be concatenated with the ECN field, creating a covert
+   channel with eight bits per datagram.
+
+   For tunnelling the six-bit Diffserv field, two conceptual models have
+   had to be defined so that administrators can trade off security
+   against the needs of traffic conditioning [RFC2983]:
+
+   The uniform model:  where the Diffserv field is preserved end-to-end
+      by copying into the outer header on encapsulation 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 the Diffserv field of the inner header
+      from any interaction with nodes along the tunnel.
+
+   However, for ECN, the new IPsec security architecture in RFC 4301
+   only standardised one tunnelling model equivalent to the uniform
+   model.  It deemed that simplicity was more important than allowing
+   administrators the option of a tiny increment in security, especially
+   given not 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 able to traverse a feedback loop
+   back to a function capable of controlling the load on that resource.
+   To be precise, rather than calling this function the data source, it
+   will be called the 'Load Regulator'.  This allows for exceptional
+
+
+
+Briscoe                      Standards Track                   [Page 31]
+
+RFC 6040                     ECN Tunnelling                November 2010
+
+
+   cases where load is 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 to (e.g., an application
+   without congestion control that uses UDP).
+
+                 A--->R--->I=========>M=========>E-------->B
+
+                     Figure 6: Simple Tunnel Scenario
+
+   A similar tunnelling scenario to the IPsec one just described will
+   now be considered, but without the different security domains,
+   because the focus now shifts to whether the control loop and
+   management monitoring work (Figure 6).  If resources in the tunnel
+   are to be able to explicitly notify congestion and the feedback path
+   is from 'B' to 'A', it will certainly be necessary for 'E' to copy
+   any CE marking from the outer header to the outgoing header for
+   onward transmission to 'B'; otherwise, congestion notification from
+   resources like 'M' cannot be fed back to the Load Regulator ('A').
+   But it does not seem necessary for 'I' to copy CE markings from the
+   incoming to the outer header.  For instance, if resource 'R' is
+   congested, it can send congestion information to 'B' using the
+   congestion field in the inner header without 'I' copying the
+   congestion field into the outer header and 'E' copying it back to the
+   outgoing header.  'E' can still write any additional congestion
+   marking introduced across the tunnel into the congestion field of the
+   outgoing header.
+
+   All this shows that 'E' can preserve the control loop irrespective of
+   whether 'I' copies congestion notification into the outer 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, resetting CE marking on
+   encapsulation breaks the Standards-Track PCN congestion marking
+   scheme [RFC5670].  It ends up removing excessive amounts of traffic
+   unnecessarily (Section 5.3.1).  Whereas copying CE markings at
+   ingress leads to the correct control behaviour.
+
+B.3.  Management Constraints
+
+   As well as control, there are also management constraints.
+   Specifically, a 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 the borders of
+
+
+
+
+
+Briscoe                      Standards Track                   [Page 32]
+
+RFC 6040                     ECN Tunnelling                November 2010
+
+
+   autonomous systems may need to measure how much congestion has
+   accumulated so far along the path, perhaps to determine between them
+   how much of the congestion is contributed by each domain.
+
+   In this document, the baseline of congestion marking (or the
+   Congestion Baseline) is defined as the 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 or not packets were tunnelled.
+   Given some tunnels cross domain borders (e.g., consider 'M' in
+   Figure 6 is monitoring a border), it would therefore be desirable for
+   'I' to copy congestion accumulated so far into the outer headers, so
+   that it is exposed across the tunnel.
+
+   For management purposes, it might be useful for the tunnel egress to
+   be able to monitor whether congestion occurred across a tunnel or
+   upstream of it.  Superficially, it appears that copying congestion
+   markings at the ingress would make this difficult, whereas it was
+   straightforward when an RFC 3168 ingress reset them.  However,
+   Appendix C gives a simple and precise method for a tunnel egress to
+   infer the congestion level introduced across a tunnel.  It works
+   irrespective of whether the ingress copies or resets congestion
+   markings.
+
+Appendix C.  Contribution to Congestion across a Tunnel
+
+   This specification mandates that a tunnel ingress determines the ECN
+   field of each new outer tunnel header by copying the arriving header.
+   Concern has been expressed that this will make it difficult for the
+   tunnel egress to monitor congestion introduced only along a tunnel,
+   which is easy if the outer ECN field is reset at a tunnel ingress
+   (RFC 3168 full functionality mode).  However, in fact copying CE
+   marks at ingress will still make it easy for the egress to measure
+   congestion introduced across 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 had already experienced 30% congestion.  However, it
+   does not mean there was 12% congestion across the tunnel.  The
+   correct calculation of congestion across the tunnel is p_t = 12/
+   (100-30) = 12/70 = 17%.  This is easy for the egress to measure.  It
+   is simply the proportion of packets not marked in the inner header
+   (70) that have a CE marking in the outer header (12).  This technique
+   works whether the ingress copies or resets CE markings, so it can be
+   used by an egress that is not sure with which RFC the ingress
+   complies.
+
+
+
+
+Briscoe                      Standards Track                   [Page 33]
+
+RFC 6040                     ECN Tunnelling                November 2010
+
+
+   Figure 7 illustrates this 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 the
+   side represents marking introduced across the tunnel.
+
+        ^ outer header marking
+        |
+   100% +-----+---------+       The 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 Packets Already Marked at Ingress
+
+Appendix D.  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, RFC 3168 and
+   RFC 4301 both say the outer should be ignored when decapsulating such
+   a packet.  This appendix explains why it was decided not to change
+   this advice.
+
+   In summary, ECT(0) always means 'not congested' and ECT(1) may imply
+   the same [RFC3168] or it may imply a higher severity congestion
+   signal [RFC4774], [PCN3in1], depending on the transport in use.
+   Whether or not they mean the same, at the ingress the outer should
+   have started the same as the inner, and only a broken or compromised
+   router could have changed the outer to ECT(0).
+
+   The decapsulator can detect this anomaly.  But the question is,
+   should it correct the anomaly by ignoring the outer, or should it
+   reveal the anomaly to the end-to-end transport by forwarding the
+   outer?
+
+   On balance, it was decided that the decapsulator should correct the
+   anomaly, but log the event and optionally raise an alarm.  This is
+   the safe action if ECT(1) is being used as a more severe marking than
+   ECT(0), because it passes the more severe signal to the transport.
+   However, it is not a good idea to hide anomalies, which is why an
+   optional alarm is suggested.  It should be noted that this anomaly
+   may be the result of two changes to the outer: a broken or
+   compromised router within the tunnel might be erasing congestion
+   markings introduced earlier in the same tunnel by a congested router.
+
+
+
+
+Briscoe                      Standards Track                   [Page 34]
+
+RFC 6040                     ECN Tunnelling                November 2010
+
+
+   In this case, the anomaly would be losing congestion signals, which
+   needs immediate attention.
+
+   The original reason for defining ECT(0) and ECT(1) as equivalent was
+   so that the data source could use the ECN nonce [RFC3540] to detect
+   if congestion signals were being erased.  However, in this case, the
+   decapsulator does not need a nonce to detect any anomalies introduced
+   within the tunnel, because it has the inner as a record of the header
+   at the ingress.  Therefore, it was decided that the best compromise
+   would be to give precedence to solving the safety issue over
+   revealing the anomaly, because the anomaly could at least be detected
+   and dealt with internally.
+
+   Superficially, the opposite case where the inner and outer carry
+   different ECT values, but with an ECT(1) outer and ECT(0) inner,
+   seems to require a similar compromise.  However, because that case is
+   reversed, no compromise is necessary; it is best to forward the outer
+   whether the 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 is higher) or it reveals an anomaly
+   to the transport (if the two ECT codepoints mean the same severity).
+
+Appendix E.  Open Issues
+
+   The new decapsulation behaviour defined in Section 4.2 adds support
+   for propagation of two severity levels of congestion.  However,
+   transports have no way to discover whether there are any legacy
+   tunnels on their path that will not propagate two severity levels.
+   It would have been nice to add a feature for transports to check path
+   support, but this remains an open issue that will have to be
+   addressed in any future standards action to define an end-to-end
+   scheme that requires two severity levels of congestion.  PCN avoids
+   this problem because it is only for a controlled region, so all
+   legacy tunnels can be upgraded by the same operator that deploys PCN.
+
+Author's Address
+
+   Bob Briscoe
+   BT
+   B54/77, Adastral Park
+   Martlesham Heath
+   Ipswich  IP5 3RE
+   UK
+
+   Phone: +44 1473 645196
+   EMail: bob.briscoe@bt.com
+   URI:   http://bobbriscoe.net/
+
+
+
+
+Briscoe                      Standards Track                   [Page 35]
+