Transport Area Working Group                                  B. Briscoe
Internet-Draft                                                        BT
Intended status: Standards Track                            Oct 27, 2008                          March 24, 2009
Expires: April 30, September 25, 2009

            Layered Encapsulation

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

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she

   This Internet-Draft is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, submitted to IETF in accordance full conformance with Section 6 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 April 30, September 25, 2009.

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 outer IP header of a tunnel should be constructed.
   It constructed on entry to and
   exit from any IP in IP tunnel.  On encapsulation it brings all IP in
   IP tunnels (v4 or v6) into line with the way RFC4301 IPsec tunnels
   now construct the ECN field.  On decapsulation it redefines how the
   ECN field in the forwarded IP header should be calculated for two
   previously invalid combinations of incoming inner and outer headers,
   in order that these combinations may be usefully employed in future
   standards actions.  It includes a thorough analysis of the reasoning
   for this change these changes and the implications.  It
   also gives guidelines on the encapsulation of IP congestion
   notification by any outer header, whether encapsulated in an IP
   tunnel or in a lower layer header.  Following these guidelines should
   help interworking, if the IETF or other standards bodies specify any
   new encapsulation of congestion notification.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4  6
     1.1.  The Need for Rationalisation .  Scope  . . . . . . . . . . . . . .  5
     1.2.  Document Roadmap . . . . . . . . . . . .  8
     1.2.  Document Roadmap . . . . . . . . .  6
     1.3.  Scope . . . . . . . . . . . .  9
   2.  Requirements Language  . . . . . . . . . . . . . .  7
   2.  Requirements Language . . . . . .  9
   3.  Summary of Pre-Existing RFCs . . . . . . . . . . . . . .  8
   3.  Design Constraints . . . 10
     3.1.  Encapsulation at Tunnel Ingress  . . . . . . . . . . . . . 10
     3.2.  Decapsulation at Tunnel Egress . . . . . .  9
     3.1.  Security Constraints . . . . . . . . 12
   4.  New ECN Tunnelling Rules . . . . . . . . . . .  9
     3.2.  Control Constraints . . . . . . . . 13
     4.1.  Default Tunnel Ingress Behaviour . . . . . . . . . . . 11
     3.3.  Management Constraints . . 14
     4.2.  Default Tunnel Egress Behaviour  . . . . . . . . . . . . . 14
     4.3.  Design Principles for Future Non-Default Schemes . . . 12
   4.  Design Principles . . 16
   5.  Backward Compatibility . . . . . . . . . . . . . . . . . . . . 13
     4.1.  Design Guidelines for New Encapsulations of Congestion
           Notification 17
     5.1.  Non-Issues Upgrading Any Tunnel Decapsulation  . . . . . . 18
     5.2.  Non-Issues for RFC4301 IPsec Encapsulation . . . . . . . . 18
     5.3.  Upgrading Other IP in IP Tunnel Encapsulators  . . . . . . 19
   6.  Changes from Earlier RFCs  . . . 14
   5.  Default ECN Tunnelling Rules . . . . . . . . . . . . . . . 20
   7.  IANA Considerations  . . 16
   6.  Backward Compatibility . . . . . . . . . . . . . . . . . . . 21
   8.  Security Considerations  . 17
   7.  Changes from Earlier RFCs . . . . . . . . . . . . . . . . . . 19
   8.  IANA Considerations 21
   9.  Conclusions  . . . . . . . . . . . . . . . . . . . . . 20
   9.  Security Considerations . . . . 23
   10. Acknowledgements . . . . . . . . . . . . . . . . . 20
   10. Conclusions . . . . . . 24
   11. Comments Solicited . . . . . . . . . . . . . . . . . . . 22
   11. Acknowledgements . . . 25
   12. References . . . . . . . . . . . . . . . . . . . . . 23
   12. Comments Solicited . . . . . 25
     12.1. Normative References . . . . . . . . . . . . . . . . . 23
   13. . . 25
     12.2. Informative References . . . . . . . . . . . . . . . . . . 25
   Appendix A.  Design Constraints  . . . . . . . . 23
     13.1. Normative References . . . . . . . . . 28
     A.1.  Security Constraints . . . . . . . . . . 23
     13.2. Informative References . . . . . . . . . 28
     A.2.  Control Constraints  . . . . . . . . . . . . 24
   Editorial Comments . . . . . . . 30
     A.3.  Management Constraints . . . . . . . . . . . . . . . . . . 31
   Appendix A.  Why resetting CE on encapsulation harms PCN B.  Relative Placement of Tunnelling and In-Path Load
                Regulation  . . . . . . . . . . . . . . . . . . . . . 32
     B.1.  Identifiers and In-Path Load Regulators  . . . . . . . . . 32
     B.2.  Non-Dependence of Tunnelling on In-path Load Regulation  . 33
     B.3.  Dependence of In-Path Load Regulation on Tunnelling  . . 26 . 34
   Appendix B. C.  Contribution to Congestion across a Tunnel  . . . . . 27 37
   Appendix C.  Comprehensive D.  Why Not Propagating ECT(1) on Decapsulation Rules
                Impedes PCN . . . . . . . . . . 28
     C.1. . . . . . . . . . . . 38
     D.1.  Alternative Ways to Introduce the Comprehensive New Decapsulation
           Rules  . 31
   Appendix D.  Non-Dependence of Tunnelling on In-path Load
                Regulation  . . . . . . . . . . . . . . . . . . . . . 32
     D.1.  Dependence of In-Path Load Regulation on Tunnelling . . . 33
   Author's Address . . . . . . 39
   Appendix E.  Why Resetting CE on Encapsulation Impedes PCN . . . . 40
   Author's Address . . . . . . . . . . . . . . . 36
   Intellectual Property and Copyright Statements . . . . . . . . . . 37 40

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>

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

      *  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);

         +  Added Section 3 to summarise relevant existing RFCs;

         +  Structured Section 4 and Section 5 into subsections.

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

         +  Moved Section 4.3 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.

   From ietf-00 to ietf-01:

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

      *  Altered Comprehensive Decapsulation Rules (Appendix C) 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 C.1 D.1 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 B 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 C D

      *  Updated references.  Minor corrections & clarifications
         throughout.

   From -00 to -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 A; 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 (Section 4.1);
         Notification;

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

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

      *  Summarised the primary rationale much better in the
         conclusions;

      *  Added numerous extra acknowledgements;

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

      *  Re-wrote Appendix D, B.2, explaining how tunnel encapsulation no
         longer depends on in-path 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 congestion notification
   (ECN) field [RFC3168] of in the outer IP header of a tunnel should be
   constructed.  It brings constructed for all
   IP in IP tunnels (v4 or v6) into line
   with the way IPsec tunnels [RFC4301] now construct tunnelling.  Previously, tunnel endpoints blocked visibility
   of transitions of the ECN field,
   ensuring that the outer header reveals any congestion experienced so
   far on field except the whole path, not just since minimum necessary to allow
   the last tunnel ingress. basic ECN allows a congested resource mechanism to notify the onset of congestion
   without having 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 drop packets, by explicitly marking a proportion of
   packets with the congestion experienced (CE) codepoint.  Because
   congestion is exhaustion ECN field visible
   across tunnel end-points, so tunnels no longer restrict new uses of a physical resource, if
   the transport
   layer is to deal with congestion, congestion notification must
   propagate upwards; from ECN field that were not envisaged when ECN was first designed.

   The immediate motivation for opening up the physical layer to ECN behaviour of tunnels
   is because otherwise they impede the transport layer.
   The transport layer can directly detect loss introduction of a packet (or frame)
   by a lower layer.  But if a lower layer marks rather than drops a
   forward-travelling data packet (or frame) pre-congestion
   notification (PCN [I-D.ietf-pcn-marking-behaviour]) in order to notify
   incipient congestion, this marking has networks with
   tunnels (Appendix E explains why).  But these changes are not just
   intended to be explicitly copied up ease the
   layers at every header decapsulation.  So, at each decapsulation introduction of
   an outer (lower layer) header a congestion marking PCN; care has been taken to be arranged
   to propagate into the forwarded (upper layer) header.  It must
   continue upwards until it reaches the destination transport.  Then
   typically the destination feeds this congestion notification back to
   ensure the source transport.  Given encapsulation by lower layer headers resulting ECN tunnelling behaviour is
   functionally similar to tunnelling, it simple and generic
   for other potential future uses.

   Given this is necessary a change to arrange
   similar propagation behaviour at 'the neck of congestion notification up the layers.  For
   instance, ECN and its propagation up hourglass',
   an extensive analysis of the layers trade-offs between control, management
   and security constraints has recently been
   specified for MPLS [RFC5129].

   As packets pass up the layers, current specifications of
   decapsulation behaviours are largely all consistent conducted in order to minimise
   unexpected side-effects both now and correct.
   However, as packets pass down in the layers, specifications of
   encapsulation behaviours future.  Care has also
   been taken to ensure the changes are not consistent.  This document is
   primarily aimed at rationalising encapsulation.  (Nevertheless,
   Appendix C explains why fully backwards compatible with
   all previous tunnelling behaviours.

   The ECN protocol allows a forwarding element to notify the consistency onset of decapsulation solutions
   will not last for long and proposes a fix
   congestion of its resources without having to decapsulation rules as
   well.  The IETF drop packets.  Instead
   it can then discuss whether to rationalise decapsulation
   at the same time as encapsulation.)

1.1.  The Need for Rationalisation

   IPsec tunnel mode is explicitly mark a specific form proportion of tunnelling that can hide packets by setting the
   inner headers.  Because
   congestion experienced (CE) codepoint in the 2-bit ECN field has to be mutable, it cannot be
   covered by IPsec encryption or authentication calculations.
   Therefore concern has been raised in the past that
   IP header (see Table 1 for a recap of the ECN field
   could be used as a low bandwidth covert channel to communicate with
   someone on 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 unprotected public Internet even if ECN Field [RFC3168] in the IP
                                  Header

   The outer header of an end-host IP packet can encapsulate one (or more)
   additional IP headers tunnelled within it.  A forwarding element that
   is
   restricted using ECN to signify congestion will only communicate with the public Internet through an
   IPsec gateway.  However, mark the updated version of IPsec [RFC4301] chose
   not outer IP header
   that is immediately visible to block it.  When a tunnel decapsulator later
   removes this covert channel, deciding that the threat could be
   managed given outer header, it must follow rules to ensure the channel bandwidth marking
   is so limited (ECN propagated into the IP header being forwarded onwards, otherwise
   congestion notifications will disappear into a black hole leading to
   potential congestion collapse.

   The rules for constructing the ECN field to be forwarded after tunnel
   decapsulation ensure this happens, but they are not wholly
   straightforward, and neither are the rules for encapsulating one IP
   header in another on entry to a tunnel.  The factor that has
   introduced most complication at both ends of a tunnel has been the
   possibility that 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 2-bit
   field).

   An secure tunnel between two
   secure sites across the public Internet.  A field like ECN 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 to the
   design of ECN (with consequent backward compatibility complications).
   However the latest IPsec architecture [RFC4301] takes the view that
   simplicity is more important than closing off the covert channel
   threat, which it deems manageable given its bandwidth is limited to
   two bits per packet.

   As a result, an unfortunate sequence of standards actions leading up to this
   latest change in IPsec has left us
   with nearly the worst of all possible combinations of outcomes,
   despite the best endeavours of everyone concerned.  The controversy has been over whether to reveal
   information about congestion experienced on new IPsec
   architecture [RFC4301] only updates the path upstream earlier specification of ECN
   tunnelling behaviour [RFC3168] for the
   tunnel ingress.  Even though this has various uses if it is revealed
   in case of IPsec tunnels.  For
   the outer header case of a tunnel, when ECN was standardised [RFC3168]
   it was decided that all IP in IP non-IPsec tunnels should hide this upstream
   congestion simply to avoid the extra complexity of two different
   mechanisms for earlier RFC3168 specification still
   applies.  At the time RFC3168 was standardised, covert channels
   through the ECN field were restricted, whether or not IPsec and non-IPsec tunnels.  However, was being
   used.  The perverse position now is that
   [RFC4301] non-IPsec tunnels restrict
   covert channels, while IPsec tunnels deliberately no longer hide don't.

   Actually, this information,
   we are left in the perverse position where non-IPsec statement needs some qualification.  IPsec tunnels still
   hide congestion information unnecessarily.  This document is designed
   to correct that anomaly.

   Specifically, RFC3168 says that, if a tunnel fully supports ECN
   (termed a 'full-functionality' ECN tunnel in [RFC3168]), the tunnel
   ingress must not copy a CE marking from
   only don't restrict the inner header into ECN covert channel at the
   outer header that it creates.  Instead ingress.  At the
   tunnel ingress has to set
   the ECN field of egress, the outer header to ECT(0) (i.e. codepoint 10).  We
   term this 'resetting' a CE codepoint.  However, RFC4301 reverses
   this, stating presumption that the tunnel ingress must simply copy the ECN field 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
   the inner to the outer header.  The main purpose introduction of PCN, this
   document specification is designed to carry remove
   them and at the new behaviour of IPsec over to all IP in IP
   tunnels, so all tunnel ingress nodes consistently copy same time streamline the whole ECN field.

   Why does it matter if we have different ECN encapsulation behaviours behaviour for IPsec and non-IPsec tunnels?  The general argument is that
   gratuitous inconsistency constrains the available design space
   future.

1.1.  Scope

   This document only concerns wire protocol processing at tunnel
   endpoints and makes it harder to design networks and new protocols that work
   predictably.

   Already complicated constraints have had to be added to a standards
   track no changes or recommendations concerning
   algorithms for congestion marking proposal.  The section of the pre-congestion
   notification (PCN) architecture [I-D.ietf-pcn-architecture] on
   tunnelling says PCN works correctly in the presence of RFC4301 IPsec or congestion response.

   This document specifies common, default ECN field processing at
   encapsulation (and RFC5129 MPLS encapsulation).  However it doesn't
   work with RFC3168 and decapsulation for any IP in IP encapsulation (Appendix A explains why).

   To ensure we do not cause any unintended side-effects, Section 3
   assesses whether copying or resetting CE would harm any security,
   control or management functions. tunnelling.  It finds that resetting CE makes
   life difficult in a number
   applies irrespective of directions, while copying CE harms
   nothing (other than opening a low bit-rate covert channel
   vulnerability which the IETF Security Area deems whether IPv4 or IPv6 is manageable).

1.2.  Document Roadmap

   Most used for either of
   the document gives a thorough analysis of inner and outer headers.  It applies to all Diffserv per-hop
   behaviours (PHBs), unless stated otherwise in the knock-on
   effects specification of the apparently minor change to tunnel encapsulation.  The
   reader may jump a
   PHB.  It is intended to Section 5 be a good trade off between somewhat
   conflicting security, control and management requirements.

   Nonetheless, if only interested in standards actions
   impacting implementation.  The whole document is organised necessary, an alternate congestion encapsulation
   behaviour can be introduced as
   follows:

   o  S.5 part of RFC3168 permits the Diffserv codepoint (DSCP)[RFC2474] to
      'switch in' different behaviours for definition of an alternate
   congestion marking scheme used by a specific Diffserv PHB (see S.5 of
   [RFC3168] and [RFC4774]).  When designing such new encapsulation
   schemes, the ECN field, just
      as it switches in different per-hop behaviours (PHBs) for
      scheduling.  Therefore we cannot only discuss the ECN protocol
      that RFC3168 gives as a default.  Instead, Section 3 lays out the
      design constraints when tunnelling congestion notification without
      assuming a particular congestion marking scheme.

   o  Then principles in Section 4 we resolve the tensions between these
      constraints to give general design principles and guidelines on
      how a tunnel 4.3 should process congestion notification; principles
      that could apply be followed as closely
   as possible.  There is no requirement for a PHB to any marking state anything
   about ECN tunnelling behaviour for any PHB, not just if the new default behaviour is
   sufficient.

   [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 RFC3168.  In particular, we examine RFC2983
   are used throughout, with brief recaps of the underlying
      principles behind whether CE should be reset or copied into explanations where
   necessary.

1.2.  Document Roadmap

   The body of the
      outer header at document focuses solely on standards actions
   impacting implementation.  Appendices record the ingress 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 a tunnel--or indeed Appendix D and Appendix E in
      order to explain in detail why current tunnelling behaviours
      impede PCN deployment, at the egress and ingress
      of any layered encapsulation of headers with congestion
      notification fields.  We end this section with a bulleted list of
      design guidelines for new encapsulations of congestion
      notification. respectively.

   o  Section 5 then 4 uses precise standards terminology to confirm the
      rules for specify the default new
      ECN tunnelling behaviour based on behaviours.  It refers to Appendix A for analysis
      of the above trade-offs between security, control and management design principles.
      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 6 5 and detailed changes from earlier RFCs are
      brought together in Section 7. 6.

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

1.3.  Scope

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

   This document specifies a common, default congestion encapsulation
   for any IP

   o  Additional specialist issues are deferred to appendices in IP tunnelling, based on that now specified for IPsec.
   It applies irrespective of whether IPv4 or IPv6 is used for either of
   the inner and outer headers.  It applies
      addition to all PHBs, unless stated
   otherwise those already referred to above, in the specification of a PHB.  It particular
      Appendix B discusses specialist tunnelling issues that could arise
      when ECN is intended fed back 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 load regulation function on a specific Diffserv PHB (see S.5 middlebox,
      rather than at the source of
   [RFC3168] and [RFC4774]).  When designing such new encapsulation
   schemes, the principles path.

2.  Requirements Language

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

3.  Summary of Pre-Existing RFCs

   This section is no requirement for a PHB informative not normative.  It merely recaps pre-
   existing RFCs to help motivate changing these behaviours.  Earlier
   relevant RFCs that were either experimental or incomplete with
   respect to state anything about ECN tunnelling behaviour if the default behaviour is sufficient.

   Often lower layer resources (e.g. a point-to-point Ethernet link) (RFC2481, RFC2401 and RFC2003) are
   arranged to be protected by higher layer buffers, so instead of
   congestion occurring at the lower layer, it merely causes not
   discussed, although the queue
   from backwards compatibility considerations in
   Section 5 take them into account.  The question of whether tunnel
   implementations used in the higher layer to overflow.  Such non-blocking link and
   physical layer technologies do Internet comply with any of these RFCs is
   also not have discussed.

3.1.  Encapsulation at Tunnel Ingress

   The controversy at tunnel ingress has been over whether to implement propagate
   information about congestion
   notification, which can be introduced solely in experienced on the active queue
   management (AQM) from path upstream of the IP layer.  However,
   tunnel ingress 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 tunnel
   ingress must not all link layer
   technologies are always protected from congestion by buffers at
   higher layers (e.g. copy a subnetwork of Ethernet links and switches can
   congest internally).  In these cases, when adding congestion
   notification to lower layers, we have to arrange for CE marking from the inner header into the
   outer header that it creates.  Instead the tunnel ingress must set
   the outer header to be
   explicitly copied up ECT(0) (i.e. codepoint 10) if the layers, just as when IP ECN field is tunnelled
   marked CE (codepoint 11) in IP.

   As well as guiding alternate the arriving IP header.  We term this
   'resetting' a CE codepoint.

   However, the new IPsec architecture in IP tunnelling schemes, [RFC4301] reverses this rule,
   stating that the design
   guidelines of Section 4 are intended tunnel ingress must simply copy the ECN field from
   the arriving to be followed when IP packets
   are encapsulated by any connectionless datagram/packet/frame where the outer header header.  The main purpose of the present
   specification is designed to support a congestion notification
   capability.  [RFC5129] already deals with handling ECN for IP in MPLS
   and MPLS in MPLS, and S.9.3 carry the new behaviour of [RFC3168] lists IPsec over to all IP encapsulated in
   L2TP [RFC2661], GRE [RFC1701] or PPTP [RFC2637] as possible examples
   where ECN may be added
   in future.

   Of course, the IETF does not have standards authority over every link
   or tunnel protocol, IP tunnels, so this document merely aims to guide all tunnel ingress nodes consistently copy the
   interface between IP ECN and lower layer congestion notification.
   Then the IETF or the relevant standards body can be free to define
   the specifics of each lower layer scheme, but
   field.

   RFC3168 also provided a common interface
   should ensure interworking across all technologies.

   Note Limited Functionality mode that just because there turns off ECN
   processing over the scope of the tunnel.  This is forward congestion notification in a
   lower layer protocol, necessary if the lower layer has its own feedback and
   load regulation, there is no need to propagate it up
   ingress does not know whether the layers.  For
   instance, FECN (forward ECN) has been present in Frame Relay and EFCI
   (explicit forward congestion indication) in ATM [ITU-T.I.371] for a
   long time.  But so far they have been used for internal management
   rather than being propagated to endpoint transports for them to
   control end-to-end congestion.

   [RFC2983] is a comprehensive primer on differentiated services and
   tunnels.  Given tunnel egress supports propagation
   of ECN raises similar issues to differentiated services
   when interacting with tunnels, useful concepts introduced in RFC2983 markings.  Neither Limited Functionality mode nor Full
   Functionality mode are used throughout, with brief recaps of the explanations where
   necessary.

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document RFC4301 IPsec.

   These pre-existing behaviours are to be interpreted as described summarised in RFC 2119 [RFC2119].

3.  Design Constraints

   Tunnel processing of a congestion notification field has to meet
   congestion control needs without creating new information security
   vulnerabilities (if information security is required).

3.1.  Security Constraints

   Information security can be assured by using various end Figure 1.

    +-----------------+-----------------------------------------------+
    | Incoming Header |             Outgoing Outer Header             |
    | (also equal to end
   security solutions (including  +---------------+---------------+---------------+
    | 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 transport mode [RFC4301]), but
   a commonly used scenario involves IP Encapsulation: Recap of Pre-existing Behaviours

   For encapsulation, the need to communicate between two
   physically protected domains across specification in Section 4 below brings all IP
   in IP tunnels (v4 or v6) into line with the public Internet.  In this
   case there are certain management advantages to using way IPsec in tunnels
   [RFC4301] now construct the ECN field, except where a legacy tunnel
   egress might not understand ECN at all.  This removes the now
   redundant full functionality mode solely across in the publicly accessible part middle column of Figure 1.
   Wherever possible it ensures that the path.  The
   path followed by a packet then crosses security 'domains'; outer header reveals any
   congestion experienced so far on the ones
   protected by physical or other means before and after whole path, not just since the
   last tunnel and
   the one protected by an ingress.

   Why does it matter if we have different ECN encapsulation behaviours
   for IPsec tunnel across the otherwise unprotected
   domain.  We will use and non-IPsec tunnels?  A general answer is that gratuitous
   inconsistency constrains the scenario in Figure 1 where endpoints 'A' available design space and
   'B' communicate through a tunnel.  The tunnel ingress 'I' makes it
   harder to design networks and egress
   'E' are within physically protected edge domains, while the tunnel
   spans an unprotected internetwork where new protocols that work predictably.

   But 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 1: IPsec Tunnel Scenario

   IPsec encryption is typically used to prevent 'M' seeing messages
   from 'A' to 'B'.  IPsec authentication is used also a specific need not to prevent 'M'
   masquerading as reset the sender 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 messages from 'A' to 'B' or altering
   their contents.  But 'I' can also use RFC4301 IPsec tunnel mode to allow 'A'
   to communicate with 'B', encapsulation or [RFC5129] MPLS
   encapsulation, but impose encryption to prevent 'A' leaking
   information to 'M'.  Or 'E' can insist not with RFC3168 IP in IP encapsulation
   (Appendix E explains why).  The PCN architecture
   [I-D.ietf-pcn-architecture] states that 'I' uses tunnel mode
   authentication to prevent 'M' communicating information to 'B'.
   Mutable the regular RFC3168 rules for
   IP header fields such as in IP tunnelling of the ECN field (as well as the TTL/
   Hop Limit and DS fields) cannot should not be included in the cryptographic
   calculations of IPsec.  Therefore, used for PCN.  But
   if 'I' copies these mutable fields
   into the outer header non-IPsec tunnels are already present within a network to which
   PCN is being added, that is exposed across the tunnel it will have
   allowed not particularly helpful advice.

   The present specification provides a covert channel from 'A' clean solution to M this problem,
   so that bypasses its encryption
   of the inner header.  And if 'E' copies these fields from the outer
   header network operators who want to the inner, even if it validates authentication from 'I', 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 have allowed 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 from 'M' to 'B'.

   ECN at
   vulnerability which the IP layer IETF Security Area now deems 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 manageable).

3.2.  Decapsulation at Tunnel Egress

   Both RFC3168 and RFC4301 specify the
   point upstream of decapsulation behaviour
   summarised in Figure 2.  The ECN field in the congestion that can regulate outgoing header is set
   to the load on codepoint at the
   congested resource, but other actions are possible (see [RFC3168]
   S.6).  In terms intersection of the above unicast scenario, ECN is typically
   intended to create an information channel appropriate incoming
   inner header (row) and incoming outer header (column).
    +------------------+----------------------------------------------+
    |  Incoming Inner  |             Incoming Outer Header            |
    |      Header      +---------+------------+------------+----------+
    |                  | Not-ECT |   ECT(0)   |   ECT(1)   |    CE    |
    +------------------+---------+------------+------------+----------+
    |     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 'M' to 'B' (for 'B' to
   feed back to 'A').  Therefore the goals of IPsec and logic given in RFC3168,
   briefly recapped as follows:

   o  On decapsulation, if the inner ECN are mutually
   incompatible.

   With respect field is Not-ECT but the outer
      ECN field is anything except Not-ECT the decapsulator must drop
      the packet.  Drop is mandated because known legal protocol
      transitions should not be able to lead to these cases (indicated
      in the DS or table by '(!!!)'), therefore the decapsulator may also
      raise an alarm;

   o  In all other cases, the outgoing ECN fields, S.5.1.2 of RFC4301 says,
   "controls are provided field is set to manage the bandwidth more
      severe marking of this [covert]
   channel".  Using the outer and inner ECN processing rules of RFC4301, fields, where the channel
   bandwidth is two bits per datagram
      ranking of severity from 'A' highest to 'M' lowest is CE, ECT, Not-ECT;

   o  ECT(0) and one bit per
   datagram from 'M' to 'A' (because 'E' limits the combinations ECT(1) are considered of equal severity (indicated by
      just 'ECT' in the
   2-bit rank order above).  Where the inner and outer
      ECN field that it will copy).  In fields are both cases ECT but they differ, the covert channel
   bandwidth packet 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, forwarded
      with respect to the larger (6b) DS field, the same section of RFC4301
   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 considering copying codepoint of the DS
   field has to take into account that it could be concatenated with the inner ECN field giving an 8b per datagram field, which prevents ECT
      codepoints being used for a covert channel.

   Thus,

   The specification for tunnelling the 6b Diffserv field decapsulation in Section 4 fixes two conceptual models have
   had to be defined so that administrators can trade off security
   against problems
   with this pre-existing behaviour:

   o  Firstly, forwarding the needs codepoint of traffic conditioning [RFC2983]:

   The uniform model:  where the DIffserv field is preserved end-to-end
      by copying into the outer inner header on encapsulation and copying from in the outer header on decapsulation.

   The pipe model: cases
      where the both inner and outer header is independent are different values of ECT effectively
      implies that any distinction between ECT(0) and ECT(1) cannot be
      introduced in the
      inner header so it hides future wherever a tunnel might be deployed.
      Therefore, the Diffserv field currently specified tunnel decapsulation behaviour
      unnecessarily wastes one of four codepoints (effectively wasting
      half a bit) in the inner header
      from any interaction with nodes along IP (v4 & v6) header.  As explained in
      Appendix A.1, the tunnel.

   However, original reason for ECN, not using the new IPsec security architecture in RFC4301 only
   standardised one tunnelling model equivalent outer ECT
      codepoints for onward forwarding was to limit the uniform model.

   It deemed covert channel
      across a decapsulator to 1 bit per packet.  However, now 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.

3.2.  Control Constraints

   Congestion control requires
      IETF Security Area has deemed that any congestion notification marked
   into packets by a resource will 2-bit covert channel through
      an encapsulator is a manageable risk, the same should be able to traverse true for
      a feedback loop
   back to decapsulator.

      As well as being a function capable general future-proofing issue, this problem is
      immediately pressing for standardisation of controlling 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 the load on that resource.
   To ECN field
      gives sufficient codepoints for these three states, they cannot
      all be precise, rather than calling this function the data source, we
   will call it used for PCN because a change between ECT(0) and ECT(1) in
      any tunnelled packet would be lost when the Load Regulator.  This will allow us outer header was
      decapsulated, dangerously discarding congestion signalling.  A
      number of wasteful or convoluted work-rounds to deal with
   exceptional cases where load is not regulated this problem are
      being considered for standardisation by the data source, PCN working group (see
      Appendix D), but
   usually the two terms will be synonymous.  Note by far the term "a function
   _capable of_ controlling simplest approach is just to remove
      the load" deliberately includes a source
   application covert channel blockages from tunnelling behaviour, that doesn't actually control the load are
      now deemed unnecessary anyway.  Not only will this streamline PCN
      standardisation, but ought to (e.g.
   an application without congestion control that it could also streamline other future uses UDP).

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

                     Figure 2: Simple Tunnel Scenario

   We now consider of
      these codepoints.

   o  Secondly, mandating drop is not always a similar tunnelling scenario to the IPsec one just
   described, but without the different security domains so we can good idea just
   focus on ensuring because a
      combination of headers seems invalid.  There are many cases where
      it has become nearly impossible to deploy new standards because
      legacy middleboxes drop packets carrying header values they don't
      expect.  Where possible, the control loop and management monitoring can work
   (Figure 2).  If we want resources new decapsulation behaviour specified
      in the tunnel to be able Section 4 below is more liberal in its response to
   explicitly notify congestion unexpected
      combinations of headers.

4.  New ECN Tunnelling Rules

   The ECN tunnel processing rules below in Section 4.1 (ingress
   encapsulation) and Section 4.2 (egress decapsulation) are the feedback path is from 'B' to
   'A', it will certainly be necessary default
   for 'E' to copy a packet with any CE marking
   from the outer header to the inner header for onward transmission to
   'B', otherwise congestion notification from resources like 'M' cannot DSCP.  If required, different ECN encapsulation
   rules MAY be fed back to the Load Regulator ('A').  But it doesn't seem
   necessary for 'I' to copy CE markings from the inner to defined as part of the outer
   header.  For instance, if resource 'R' is congested, it can send
   congestion information to 'B' definition of an appropriate
   Diffserv PHB using the congestion field guidelines that follow in Section 4.3.
   However, the inner
   header without 'I' copying the congestion field into the outer header deployment burden of handling exceptional PHBs in
   implementations of all affected tunnels and 'E' copying it back to the inner header.  'E' can still write any
   additional congestion marking introduced across the lower layer link
   protocols should not be underestimated.

4.1.  Default Tunnel Ingress Behaviour

   A tunnel into the
   congestion field of the inner header. ingress compliant with this specification MUST implement a
   `normal mode'.  It might be useful for the tunnel egress to be able also need to tell whether
   congestion occurred across implement a `compatibility
   mode' for backward compatibility with legacy tunnel or upstream egresses that do
   not understand ECN (see Section 5 for when compatibility mode is
   required).  Note that these are modes of it.  If outer
   header congestion marking was reset by the tunnel ingress ('I'), at tunnel endpoint
   only, not the end of a tunnel ('E') as a whole.

   Whatever the outer headers would indicate congestion
   experienced across mode, the tunnel ('I' to 'E'), while ingress forwards the inner header
   would indicate congestion upstream of 'I'.  But similar information
   can be gleaned even if
   without changing the ECN field.  In normal mode a tunnel ingress copies the inner to
   compliant with this specification MUST construct the outer headers.  At
   encapsulating IP header by copying the end 2-bit ECN field of the tunnel ('E'), any packet with an
   _extra_ mark
   arriving IP header.  In compatibility mode it clears the ECN field in
   the outer header relative to the inner header
   indicates congestion across the tunnel ('I' to 'E'), while the inner
   header would still indicate congestion upstream of ('I').  Appendix B
   gives a simple and precise method Not-ECT codepoint.  These rules are tabulated
   for a tunnel egress to infer the
   congestion level introduced across a tunnel.

   All this shows that 'E' can preserve convenience in 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 mode is the control loop irrespective of
   whether 'I' copies congestion notification into same per packet behaviour as the outer header or
   resets it.

   That ingress
   end of RFC3168's limited functionality mode.  Normal mode 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 A describes
   how resetting CE marking at a tunnel ingress confuses a proposed
   congestion marking scheme on same
   per packet behaviour as the standards track.  It ends up
   removing excessive amounts of traffic unnecessarily.  Whereas copying
   CE markings at ingress leads to end of RFC4301 IPsec.

4.2.  Default Tunnel Egress Behaviour

   To decapsulate the correct control behaviour.

3.3.  Management Constraints

   As well as control, there are also management constraints.
   Specifically, a management system may monitor congestion markings in
   passing packets, perhaps inner header at the border between networks as part of tunnel egress, a
   service level agreement.  For instance, monitors at compliant
   tunnel egress MUST set the borders of
   autonomous systems may need outgoing ECN field to measure how much congestion has
   accumulated since the original source, perhaps to determine between
   them how much codepoint at the
   intersection of the congestion is contributed by each domain.

   Therefore, when monitoring appropriate incoming inner header (row) and outer
   header (column) in Figure 4.

    +------------------+----------------------------------------------+
    |  Incoming Inner  |             Incoming Outer Header            |
    |      Header      +---------+------------+------------+----------+
    |                  | Not-ECT |   ECT(0)   |   ECT(1)   |    CE    |
    +------------------+---------+------------+------------+----------+
    |     Not-ECT      | Not-ECT |Not-ECT(!!!)|   drop(!!!)| drop(!!!)|
    |      ECT(0)      |  ECT(0) | ECT(0)     | ECT(1)     |   CE     |
    |      ECT(1)      |  ECT(1) | ECT(1)(!!!)| ECT(1)     |   CE     |
    |        CE        |      CE |     CE     |     CE(!!!)|   CE     |
    +------------------+---------+------------+------------+----------+
                       |                Outgoing Header               |
                       +----------------------------------------------+

              Figure 4: New IP in IP Decapsulation Behaviour

   This table for decapsulation behaviour is derived from the middle of a path, it should be
   possible to establish how far back following
   logic:

   o  If the inner ECN field is Not-ECT the decapsulator MUST NOT
      propagate any other ECN codepoint in the path congestion markings
   have accumulated from.  In this document we term this outer header onwards.
      This is because the baseline of
   congestion inner Not-ECT marking (or is set by transports
      that would not understand the Congestion Baseline), i.e. ECN protocol.  Instead:

      *  If the source 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 the layer tunnel, or
         that last reset (or created) the congestion notification
   field.  Given some tunnels cross domain borders (e.g. consider M in
   Figure 2 locally defined mechanism is monitoring a border), it would therefore being used within the
         tunnel that might be desirable for
   'I' to copy congestion accumulated so far into signalling congestion.  In either case,
         the outer headers
   exposed across only appropriate signal to the tunnel.

   Appendix D discusses various scenarios where the Load Regulator lies
   in-path, not at the source host as we would typically expect.  It
   concludes that a Congestion Baseline transport is determined by where a packet drop.
         It would have been nice to allow packets with ECT(1) in the Load
   Regulator function is, which should
         outer to be identified forwarded, but drop has had to be mandated in the transport
   layer, not by addresses case
         future multi-level ECN schemes are defined.  Then ECT(1) and CE
         can be used in network layer headers.  This applies
   whether the Load Regulator future to signify two levels of congestion
         severity.

      *  If the inner ECN field is at Not-ECT and the source host outer ECN field is
         ECT(0) or within Not-ECT the path.
   The appendix also discusses where a Load Regulator function should be
   located relative decapsulator MUST forward the packet with
         the ECN field cleared to a local tunnel encapsulation function.

4.  Design Principles

   The constraints from Not-ECT.
         Reasoning: Although no known legal protocol transition would
         lead to ECT(0) in the three perspectives of security, control outer and
   management in Section 3 are somewhat Not-ECT in tension the inner, no known
         or proposed protocol uses ECT(0) as to whether a
   tunnel ingress should copy congestion markings into signal either.
         Therefore in this case the outer header
   it creates or reset them.  From packet can be forwarded rather than
         dropped, which will allow future standards actions to use this
         combination.

   o  In all other cases, the outgoing ECN field is set to the control perspective either
   copying or resetting works for existing arrangements, but copying has more potential for simplifying control.  From
      severe marking of the management
   perspective copying is preferable.  From outer and inner ECN fields, where the security perspective
   resetting is preferable but copying
      ranking of severity from highest to lowest is now considered acceptable
   given the bandwidth CE, ECT(1), ECT(0),
      Not-ECT;

   o  There are cases where no currently legal transition in any current
      or previous ECN tunneling specification would result in certain
      combinations of a 2-bit covert channel can be managed.

   Therefore an inner and outer encapsulating header capable of carrying
   congestion markings SHOULD reflect accumulated congestion since ECN fields.  These cases are
      indicated in Figure 4 by '(!!!)').  In these cases, the
   last interface designed to regulate load (the Load Regulator).  This
   implies congestion notification
      decapsulator SHOULD be copied into log the outer
   header of each new encapsulating header that supports it.

   We have said that a tunnel ingress SHOULD (as opposed to MUST) copy
   incoming congestion notification into event and MAY also raise an outer encapsulating header alarm, but
      not so often that supports it.  In the case illegal combinations would amplify into a
      flood of 2-bit ECN, the IETF security area
   has deemed the benefit always outweighs the risk.  Therefore alarm messages.

   The above logic allows for
   2-bit ECN we can ECT(0) and we will say 'MUST' (Section 5). ECT(1) to both represent the
   same severity of congestion marking (e.g. "not congestion marked").
   But in this
   section where we are setting down general design principles, we leave it as a 'SHOULD'.  This also allows for future multi-bit congestion
   notification fields 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 risk from the covert channel created by
   copying congestion notification might outweigh the congestion control
   benefit discussion of copying.

   The Load Regulator the ECN nonce [RFC3540] in
   Section 8.

4.3.  Design Principles for Future Non-Default Schemes

   This section is informative not normative.

   S.5 of RFC3168 permits the node Diffserv codepoint (DSCP)[RFC2474] to which congestion feedback should be
   returned by the next downstream node with a transport layer feedback
   function (typically but not always the data receiver).  The Load
   Regulator is not always (or even typically)
   'switch in' different behaviours for marking the same thing ECN field, just as the
   node identified by the source address of the outermost exposed
   header.
   it switches in different per-hop behaviours (PHBs) for scheduling.
   Therefore here we give guidance for designing possibly different
   marking schemes.

   In general one word the addressing guidance is "Don't".  If a scheme requires tunnels to
   implement special processing of the outermost encapsulation
   header says nothing about the identifiers ECN field for certain DSCPs, it
   is highly unlikely that every implementer of either the upstream or
   the downstream transport layer functions.  As long as every tunnel will want
   to add the transport
   functions know each other's addresses, they don't have required exception and that operators will want to be
   identified in deploy
   the network layer or in any link layer.  It was only a
   convenience required configuration options.  Therefore it is highly likely
   that some tunnels within a TCP receiver assumed that the address of network will not implement this special
   case.  Therefore, designers should avoid non-default tunnelling
   schemes if at all possible.

   That said, if a non-default scheme for processing the
   source transport ECN field is
   really required, the same as the network layer source address of
   an IP packet it receives.

   More generally, the return transport address for feedback could be
   identified solely following guidelines may prove useful in the transport layer protocol. its
   design:

   o  For instance, a
   signalling protocol like RSVP [RFC2205] breaks up any new scheme, a path into
   transport layer hops and informs each hop of the address tunnel ingress should not set the ECN field
      of its
   transport layer neighbour without any need to identify these hops in the network layer.  RSVP can be arranged so outer header if it cannot guarantee that these transport
   layer hops are bigger than the underlying network layer hops.  The
   host identity protocol (HIP) architecture [RFC4423] also supports the
   same principled separation (for mobility amongst other things), where
   the transport layer sender identifies its transport address for
   feedback any corresponding
      tunnel egress will understand how to be sent to, using handle such an identifier provided by a shim below
   the transport layer.

   Keeping to this layering principle deliberately doesn't require a
   network layer packet ECN field.

   o  On encapsulation in any new scheme, an outer header to reveal the origin address from where capable of
      carrying congestion notification accumulates (its Congestion Baseline).  It is
   not necessary for markings should reflect accumulated congestion
      since the network and lower layers last interface designed to know regulate load (see
      Appendix A.2 for the address definition of
   the a Load Regulator.  Only Regulator, which is
      usually but not always the destination transport needs to know
   that.  With forward data source).  This implies that new
      schemes for tunnelling congestion notification, notification should copy
      congestion notification into the network outer header of each new
      encapsulating header that supports it.

      Reasoning: The constraints from the three perspectives of
      security, control and link
   layers only notify congestion forwards; they aren't involved management in
   feeding it backwards.  If they Appendix A are (e.g. backward congestion
   notification (BCN) in Ethernet [IEEE802.1au] or EFCI somewhat in ATM
   [ITU-T.I.371]), that should be considered
      tension as a transport function
   added 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 whether a tunnel ingress should copy congestion
      markings into the outer header it is complex
   (particularly in creates or reset them.  From the case of IPsec tunnels) to return
      control perspective either copying or resetting works for existing
      arrangements, but copying has more potential for simplifying
      control.  From the ICMP
   messages beyond management perspective copying is preferable.
      From the tunnel ingress back to security perspective resetting is preferable but copying
      is now considered acceptable given the Load Regulator.

   Similarly, if bandwidth of a management system 2-bit covert
      channel can be managed.  Therefore, on balance, copying is monitoring congestion simpler
      and needs
   to know more useful than resetting and does minimal harm.

   o  For any new scheme, a tunnel egress should not forward any ECN
      codepoint if the Congestion Baseline, arriving inner header implies the management system has transport will
      not understand how to find
   this out from the transport; process it.

   o  On decapsulation in general it cannot tell solely by
   looking at the network or link layer headers.

4.1.  Design Guidelines for New Encapsulations of Congestion
      Notification

   The following guidelines are for specifications of any new schemes for
   encapsulating congestion notification (e.g. for specialised Diffserv
   PHBs in IP, or for lower layer technologies):

   1.  Congestion notification in scheme, if a combination of inner and
      outer headers SHOULD is encountered that should not have been possible,
      this event should be relative to logged and an alarm raised.  But the packet
      should still be forwarded with a
       Congestion Baseline safe codepoint setting if at all
      possible.  This increases the node expected to regulate the load on
       the link chances of 'forward compatibility'
      with possible future protocol extensions.

   o  On decapsulation in question (the Load Regulator).  This implies incoming
       congestion notifications from any new scheme, the higher layer SHOULD be copied
       into encapsulating headers.  This guideline is particularly
       important where outer headers might cross trust boundaries, but
       less important otherwise.

   2.  Congestion notification MUST NOT simply be copied from outer
       headers to ECN field that the forwarded header on decapsulation.  The forwarded tunnel
      egress forwards should reflect the more severe congestion notification field SHOULD be calculated from marking
      of the arriving inner and outer headers, taking account of the following, headers.

5.  Backward Compatibility

   Note: in the order
       given:

       1.  If the inner header does not support congestion notification, RFC3168, a whole tunnel was considered in one of two modes:
   limited functionality or indicates that the transport does not support congestion
           notification, any explicit congestion notifications full functionality.  The new modes defined
   in this specification are only modes of the
           outer header will not be understood if propagated further, so
           if the tunnel ingress.  The new
   tunnel egress behaviour has only way to indicate congestion to onward nodes is one mode and doesn't need to
           drop the packet, it MUST be dropped.

       2.  If the outer header does not support explicit congestion
           notification, but the inner header does, know
   what mode the inner header
           SHOULD be forwarded unchanged.

       3.  Congestion indications may be ranked by strength.  For
           instance no congestion would be ingress is in.

5.1.  Non-Issues Upgrading Any Tunnel Decapsulation

   This specification only changes the weakest indication, with
           possibly increasing levels egress per-packet calculation of congestion given increasingly
           stronger indications.

       4.  Where
   the ECN field for combinations of inner and outer headers carry indications of
           congestion of different strengths, the stronger indication
           SHOULD be forwarded in preference to the weaker.  Obviously,
           if the strengths that have
   so far not been used in both inner and outer are the same, the
           same strength should be forwarded.

       5.  If the outer header carries any IETF protocols.  Therefore, a weaker indication tunnel
   egress complying with any previous specification (RFC4301, both modes
   of congestion
           than the inner, it MAY RFC3168, both modes of RFC2481, RFC2401 and RFC2003) can be appropriate
   upgraded to raise a warning, as comply with this would be in illegal combination if Guideline Paragraph 1
           had been followed.

   3.  Where framing boundaries are different between the two layers,
       congestion indications SHOULD be propagated on the basis that a
       congestion indication in a packet new decapsulation specification without
   any backwards compatibility issues.

   The proposed tunnel egress behaviour also requires no additional mode
   or frame applies to all option configuration at the
       octets in ingress or egress nor any additional
   negotiation with the frame/packet.  On average, a ingress.  A compliant tunnel endpoint SHOULD
       approximately preserve egress merely needs
   to implement the number of marked octets arriving and
       leaving.  An algorithm for spreading congestion indications over
       multiple smaller `fragments' SHOULD propagate congestion
       indications as soon as they arrive, and SHOULD NOT hold them back
       for later frames. one behaviour in Section 4.  Assumptions on incremental deployment MUST be stated.

   Regarding incremental deployment, the Per-Domain ECT Checking
   of[RFC5129] is a good example  The reduction to follow.  In this example, header
   space in one
   mode at the lower layer protocol (MPLS) was extremely limited, so egress has no
   ECN-capable transport codepoint was added to backwards compatibility issues, because
   previously the MPLS header.
   Interior nodes in a domain were allowed to set explicit congestion
   indications without checking whether egress produced the frame same output whichever mode the
   tunnel was destined for in.

   These new decapsulation rules have been defined in such a
   transport that would understand them.  This was made safe by
   emphasising repeatedly way that all
   congestion control will still work safely if any of the decapsulating edges earlier
   versions of a whole
   domain had to be upgraded ECN processing are used unilaterally at once, so there would always be a check
   that the higher layer transport was ECN-capable on decapsulation.  If
   the decapsulator discovered that the higher layer showed the
   transport would not understand ECN, it dropped the packet on behalf encapsulating
   ingress of the earlier congestion node (see Guideline Paragraph 2.1).

   Note that such a deployment strategy that assumes a savvy operator
   was only appropriate because MPLS is targeted solely at professional
   operators.  This strategy would not be appropriate for other link
   technologies (e.g.  Ethernet) targeted at deployment by the general
   public.

5.  Default ECN Tunnelling Rules

   The following ECN tunnel processing rules are the default for a
   packet with any DSCP.  If required, different ECN encapsulation rules
   MAY be defined as part of the definition (any of an appropriate Diffserv
   PHB using the guidelines in Section 4.  However, the burden RFC2003, RFC2401, either mode of
   handling exceptional PHBs in implementations
   RFC2481, either mode of all affected tunnels RFC3168, RFC4301 and lower layer link protocols should not be underestimated.

   A this present
   specification).  If a tunnel ingress tries to negotiate to use
   limited functionality mode or full functionality mode [RFC3168], a
   decapsulating tunnel egress compliant with this specification MUST copy the
   2-bit ECN field of the arriving IP header into the outer
   encapsulating IP header, for all types of IP in IP tunnel.  This
   encapsulation
   agree to either request, as its behaviour MUST only will be used if the tunnel ingress is in
   `normal state'.  A `compatibility state' with a different
   encapsulation behaviour is also specified same in Section 6 for backward
   compatibility with legacy tunnel egresses that do not understand ECN.

   To decapsulate the inner header at the tunnel egress, both
   cases.

   For 'forward compatibility', a compliant tunnel egress MUST set the outgoing ECN field 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 continue without raising any error or
   warning as its egress behaviour is compatible with all the codepoint at the
   intersection legacy
   ingress behaviours that don't negotiate capabilities.

5.2.  Non-Issues for RFC4301 IPsec Encapsulation

   The new normal mode of the appropriate incoming inner header (row) and outer
   header (column) in Figure 3.

                       +----------------------------------------------+
                       |             Incoming Outer Header            |
    +------------------+---------+------------+------------+----------+
    |  Incoming Inner  | Not-ECT |   ECT(0)   |   ECT(1)   |    CE    |
    |      Header      |         |            |            |          |
    +------------------+---------+------------+------------+----------+
    |     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 3: ingress behaviour defined above (Section 4.1)
   brings all IP in IP Decapsulation

   The exclamation marks '(!!!)' in Figure 3 indicate that this
   combination tunnels into line with [RFC4301].  If one end of inner and outer headers should not
   an IPsec tunnel is compliant with [RFC4301], the other end is
   guaranteed to also be possible if only
   legal transitions have taken place.  So, RFC4301-compliant (there could be corner cases
   where manual keying is used, but they will be set aside here).
   Therefore the decapsulator should drop new normal ingress behaviour introduces no backward
   compatibility isses with IKEv2 [RFC4306] IPsec [RFC4301] tunnels, and
   no need for any new modes, options or mark configuration.

5.3.  Upgrading Other IP in IP Tunnel Encapsulators

   At the ECN field as tunnel ingress, this specification effectively extends the table
   scope of RFC4301's ingress behaviour to any IP in Figure 3 specifies, but it MAY
   also raise an appropriate alarm.  It MUST NOT raise an alarm so often
   that the illegal combinations would amplify into a flood of alarm
   messages.

6.  Backward Compatibility

   Note: in RFC3168, a tunnel was in one of two modes: limited
   functionality or full functionality.  Rather than working with modes
   of the tunnel as a whole, this specification uses the term `state' to
   refer separately to the state of each tunnel end point, which is how
   implementations have to work. IP tunnel.  If one end of an IPsec any
   other IP in IP tunnel ingress (i.e. not RFC4301 IPsec) is compliant with [RFC4301], the other
   end can be guaranteed upgraded to also
   be [RFC4301] compliant (there could be
   corner cases where manual keying is used, but they will be ignored
   here).  So there is no backward compatibility problem with IKEv2
   RFC4301 IPsec tunnels.  But once we extend our scope to any IP in IP
   tunnel, we have this specification, it has to cater for the
   possibility that it is talking to a legacy tunnel egress that may not
   know how to process an the ECN field, so if field.  If ECN capable outer headers were
   sent towards a legacy (e.g.  [RFC2003]) egress, it would most likely
   simply disregard the outer headers, dangerously discarding
   information about congestion experienced within the tunnel.  ECN-capable  ECN-
   capable traffic sources would not see any congestion feedback and
   instead continually ratchet up their share of the bandwidth without
   realising that cross-flows from other ECN sources were continually
   having to ratchet down.

   To be

   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, to comply with this specification specification, a tunnel ingress that
   does not always know the ECN capability of its tunnel egress MUST
   implement a 'normal' state mode and a 'compatibility' state, mode, and for safety
   it MUST initiate each negotiated tunnel in the compatibility state. mode.

   However, a tunnel ingress can be compliant even if it only implements
   the 'normal state' mode' of encapsulation behaviour, but only as long as it
   is designed or configured so that all possible tunnel egress nodes it
   will ever talk to will have at least full ECN functionality (RFC3168
   (complying with either RFC3168 full functionality mode, RFC4301 and or
   this present specification).  The
   `normal state' is that defined in Section 5 (i.e. header copying).
   Note that a [RFC4301] tunnel ingress that has used IKEv2 key
   management [RFC4306] can guarantee that its tunnel egress is also
   RFC4301-compliant and therefore need not further negotiate ECN
   capabilities.

   Before switching to normal state, mode, a compliant tunnel ingress that does
   not know the egress ECN capability MUST negotiate with the tunnel
   egress.  If the egress says it is in compliant with this specification
   or with RFC3168 full functionality state
   (or mode), mode, the ingress puts itself into
   normal state.  In normal
   state the ingress follows the encapsulation rule in Section 5 (i.e.
   header copying). mode.  If the egress says it is not in full-functionality
   state/mode denies compliance with all of these or
   doesn't understand the question, the tunnel ingress MUST remain in
   compatibility state.

   A tunnel ingress in mode.

   The encapsulation rules for normal mode and compatibility state MUST set all outer headers to
   Not-ECT.  This is the same per packet behaviour as the mode are
   defined in Section 4 (i.e. header copying or zeroing respectively).

   An ingress end of
   RFC3168's limited functionality mode.

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

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

   A mode'.

   Implementation note: if a compliant tunnel egress on node is the other hand merely needs ingress for multiple
   tunnels, a mode setting will need to implement
   the one behaviour in Section 5, which we term 'full-functionality'
   state, as it be stored for each tunnel
   ingress.  However, if a node is the same as the egress end for multiple tunnels, none
   of the full-functionality tunnels will need to store a mode setting, because a compliant
   egress can only be in one mode.

6.  Changes from Earlier RFCs

   On encapsulation, the rule that a normal mode tunnel ingress MUST
   copy any ECN field into the outer header is a change to the ingress
   behaviour of [RFC3168].  It RFC3168, but it is also the same as the [RFC4301] egress
   behaviour.

   The decapsulation rules for IPsec
   tunnels in RFC4301.

   On decapsulation, the egress of rules for calculating the outgoing ECN field at
   a tunnel in Section 5
   have been defined in such a way that congestion control will still
   work safely if any of egress are similar to the earlier versions full functionality mode of ECN processing are used
   unilaterally at in
   RFC3168 and to RFC4301, with the encapsulating ingress of following exceptions:

   o  The outer, not the tunnel (any of
   RFC2003, RFC2401, either mode of RFC2481, either mode of RFC3168,
   RFC4301 inner, is propagated when the outer is ECT(1)
      and this present specification).  If the inner is ECT(0);

   o  A packet with Not-ECT in the inner may be forwarded as Not-ECT
      rather than dropped, if 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 for how a tunnel ingress tries
   to negotiate to use limited functionality mode or establishes whether the egress has full
   functionality
   mode [RFC3168], a decapsulating tunnel egress compliant with this
   specification MUST agree ECN capabilities are an update to either request, as its behaviour will be RFC3168.  For all the same
   typical cases, RFC4301 is not updated by the ECN capability check in both cases.

   For 'forward compatibility',
   this specification, because a compliant typical RFC4301 tunnel egress SHOULD raise a
   warning about any requests to enter states or modes it doesn't
   recognise, but ingress will
   have already established that it can continue operating.  If no ECN-related state or
   mode is requested, a compliant talking to an RFC4301 tunnel
   egress need not raise an error
   or warning as its egress behaviour is compatible with all the legacy
   ingress behaviours that don't negotiate capabilities.

   Implementation note: if a compliant node is the ingress for multiple
   tunnels, a state 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 state setting, because a
   compliant egress can only be in one state.

7.  Changes from Earlier RFCs

   The rule that a normal state tunnel ingress MUST copy any ECN field
   into the outer header is a change to the ingress behaviour of
   RFC3168, but it is the same as the rules for IPsec tunnels in
   RFC4301.

   The rules for calculating the outgoing ECN field on decapsulation at
   a tunnel egress are in line with the full functionality mode of ECN
   in RFC3168 and with RFC4301, except that neither identified the
   following illegal combinations: outer ECT(1) with inner ECT(0) or
   with CE; outer ECT(0) with inner ECT(1).

   The rules for how a tunnel establishes whether the egress has full
   functionality ECN capabilities are an update to RFC3168.  For all the
   typical cases, RFC4301 is not updated by the ECN capability check in
   this specification, because a typical RFC4301 tunnel ingress will
   have already established that it is talking 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 (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, for
   such corner cases, the requirement to use compatibility mode in this
   specification updates RFC4301. RFC4301, but this is unlikely to be necessary
   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 and an
   (optional) full functionality mode for a tunnel, but RFC4301 doesn't
   need modes.  In this specification only the ingress might need two
   states:
   modes: a normal state mode (required) and a compatibility state mode (required in
   some scenarios, optional in others).  The egress needs only full-
   functionality state one mode
   which correctly handles any ingress ECN the same as either mode of
   RFC3168 or RFC4301. behaviour.

Additional changes to the RFC Index (to be removed by the RFC Editor):

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

   This specification updates RFC3168.  It also suggests a minor
   optional warning RFC3168 and a corner-case change to RFC4301, but these don't
   really count as an update.

8. RFC4301.

7.  IANA Considerations

   This memo includes no request to IANA.

9.

8.  Security Considerations

   Section 3.1

   Appendix A.1 discusses the security constraints imposed on ECN tunnel
   processing.  The Design Principles of Section 4 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 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 for a
   certain PHB (e.g. the pre-congestion notification architecture
   [I-D.ietf-pcn-architecture]), the scope of the alternate semantics
   might typically be bounded by the limits of a Diffserv region or
   regions, as envisaged in [RFC4774].  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 edges of a Diffserv
   region with alternate ECN semantics.  Such edge processing must also
   be applied at the endpoints of tunnels with ends both 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
   their
   each case.

   With the decapsulation rules as they stand stood in RFC3168 and RFC4301, a
   small part of the protection of the ECN nonce [RFC3540] is was
   compromised.  One reason
   two ECT codepoints were defined  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 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 ECT(1) values into a stream of
   packets, which is termed an ECN nonce.  By the decapsulation rules in
   RFC3168 and RFC4301, if the inner and outer headers carry
   contradictory ECT values only the inner header is preserved for
   onward forwarding.  So if a CE marking added to the outer ECN field
   in a tunnel has been illegally (or accidentally) suppressed by 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.  To  We chose not to close this minor loophole, we could have specified that an outer header value of
   ECT should overwrite a contradictory ECT value in the inner header.
   But currently we choose to keep the 'broken' behaviour defined in
   RFC3168 & RFC4301
   loophole for all the following reasons:

   1.  We wanted to avoid any changes to IPsec tunnelling behaviour;

   2.  Allowing ECT values in the outer header to override the inner
       header would have increased the bandwidth of the covert channel
       through the egress gateway from 1 to 1.5 bit per datagram,
       potentially threatening to upset the consensus established in the
       security area that says that the bandwidth of this covert channel
       can now be safely managed;

   3.  This loophole is only applicable in the corner case where the
       attacker is controls a network node downstream of a congested node
       in the same tunnel;

   4.

   2.  In tunnelling scenarios, the ECN nonce is already vulnerable to
       suppression by nodes downstream of a congested node in the same
       tunnel, if they can copy the ECT value in the inner header to the
       outer header (any node in the tunnel can do this if the inner
       header is not encrypted, and an IPsec tunnel egress can do it
       whether or not the tunnel is encrypted);

   5.

   3.  Although the 'broken' new decapsulation behaviour removes evidence of
       congestion suppression from the onward feedback loop, the
       decapsulator itself can at least detect that congestion within
       the tunnel has been suppressed;

   6.

   4.  The ECN nonce [RFC3540] currently has experimental status and
       there has been no evidence that anyone has implemented it beyond
       the author's prototype.

   If a legacy security policy configures a legacy tunnel ingress to
   negotiate to turn off ECN processing, a compliant tunnel egress will
   agree to a request to turn off ECN processing but it will actually
   still copy CE markings from

   We could have fixed this loophole by specifying that the outer to the forwarded header. header
   should always be propagated onwards if inner and outer are both ECT.
   Although this would close the minor loophole in the nonce, it would
   raise a minor safety issue if multilevel ECN or PCN were used.  A
   less severe marking in the inner header would override a more severe
   one in the outer.  Both are corner cases so it is difficult to decide
   which is more important:

   1.  The loophole in the nonce is only for a minor case of one tunnel
       node attacking another in the same tunnel;

   2.  The severity inversion for multilevel congestion notification
       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, a compliant tunnel egress will
   agree to a request to turn off ECN processing but it will actually
   still copy CE markings from the outer to the forwarded header.
   Although the tunnel ingress 'I' in Figure 1 5 (Appendix A.1) will set
   all ECN fields in outer headers to Not-ECT, 'M' could still toggle CE
   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.  But we
   decided not to add the extra complexity of two modes on a compliant
   tunnel egress merely to cater for a legacy security concern that is
   now considered manageable.

10.

9.  Conclusions

   This document updates the ingress tunnelling encapsulation of RFC3168
   ECN for all IP in IP tunnels to bring it into line with the new
   behaviour in the IPsec architecture of RFC4301.

   At  It copies rather
   than resets a tunnel egress, header decapsulation for the default ECN congestion experienced (CE) marking
   behaviour is broadly unchanged except when creating outer
   headers.

   It also specifies new rules that one exceptional case has
   been catered for.  At the ingress, update both RFC3168 and RFC4301 for all forms of IP in IP tunnel,
   encapsulation has been brought into line with
   calculating the outgoing ECN field on tunnel decapsulation.  The new IPsec
   rules in
   RFC4301 which copy rather than reset CE markings when creating update egress behaviour for two specific combinations of inner
   and outer
   headers.

   This change to encapsulation has been motivated header that have no current legal usage, but will now be
   possible to use in future standards actions, rather than being wasted
   by analysis current tunnelling behaviour.

   The new rules propagate changes to 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 the ECN field opens up is a manageable threat, so these
   new rules bring all IP in IP tunnelling into line with this new more
   permissive attitude.  The result 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 the ECN field that would
   otherwise be confounded by ambiguity.

   The immediate motivation for making these changes is to allow the
   introduction of multi-level pre-congestion notification (PCN).  But
   great care has been taken to ensure the resulting ECN tunnelling
   behaviour is simple and generic for other potential future uses.

   The change to encapsulation has been analysed from the three
   perspectives of security, control and management.  They are somewhat
   in tension as to whether a tunnel ingress should copy congestion
   markings into the outer header it creates or 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 the management and monitoring perspective copying 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 a 2-bit covert
   channel can be managed.  Therefore there are no points against
   copying and a number against resetting CE on ingress.

   The change ensures ECN processing in all IP in IP tunnels reflects
   this slightly more permissive attitude only downside of the changes to revealing congestion
   information in decapsulation is that the new IPsec architecture.  Once all tunnelling of
   ECN works same
   2-bit covert channel is opened up as at the same, ECN markings will have ingress, but this is now
   deemed to be a defined meaning when
   measured manageable threat.  The changes at decapsulation have
   been found to be free of any point in backwards compatibility issues.

10.  Acknowledgements

   Thanks to Anil Agawaal for pointing out a case where it's safe for a network.  This new certainty will enable
   new uses of the ECN field that would otherwise be confounded by
   ambiguity.

   Also, this document defines more generic principles to guide the
   design of alternate forms of
   tunnel processing decapsulator to forward a combination of congestion
   notification, if required for specific Diffserv PHBs or for other
   lower layer encapsulating protocols that might support congestion
   notification in the future.

11.  Acknowledgements headers 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
   to think about multilayer transports and networks, having read
   [Patterns_Arch].  Also thanks to Arnaud Jacquet for the idea for
   Appendix B. C.  Thanks 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 is partly funded by Trilogy, a research project (ICT-
   216372) supported by the European Community under its Seventh
   Framework Programme.  The views expressed here are those of the
   author only.

12.

11.  Comments Solicited

   Comments and questions are encouraged and very welcome.  They can be
   addressed to the IETF Transport Area working group mailing list
   <tsvwg@ietf.org>, and/or to the authors.

13.

12.  References

13.1.

12.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.

   [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.

   [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.

13.2.

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 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 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-08 draft-ietf-pcn-architecture-10 (work in
              progress), October 2008. March 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-01
              draft-ietf-pcn-baseline-encoding-02 (work in progress),
              October 2008.
              February 2009.

   [I-D.ietf-pcn-marking-behaviour]
              Eardley, P., "Marking behaviour of PCN-nodes",
              draft-ietf-pcn-marking-behaviour-01
              draft-ietf-pcn-marking-behaviour-02 (work in progress),
              October 2008.
              March 2009.

   [I-D.ietf-pwe3-congestion-frmwk]
              Bryant, S., Davie, B., Martini, L., 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., and B. Briscoe,
              "PCN Encoding 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., and M. Menth, "A three state
              extended PCN encoding scheme",
              draft-moncaster-pcn-3-state-encoding-00
              draft-moncaster-pcn-3-state-encoding-01 (work in
              progress), June 2008. 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 in progress),
              March 2009.

   [IEEE802.1au]
              IEEE, "IEEE Standard for Local 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 and Congestion Control in B-ISDN",
              ITU-T Rec. I.371 (03/04), March 2004.

   [PCNcharter]
              IETF, "Congestion 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 to
              Fundamentals", Pub: Prentice Hall ISBN-13: 9780132252423,
              Jan 2008.

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

   [RFC1701]  Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
              Routing Encapsulation (GRE)", RFC 1701, October 1994.

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

   [RFC2637]  Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little,
              W., and G. Zorn, "Point-to-Point Tunneling Protocol",
              RFC 2637, July 1999.

   [RFC2661]  Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
              G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
              RFC 2661, August 1999.

   [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 in MPLS", RFC 5129, January 2008.

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

              (Expired)

Editorial Comments

   [Note_Nonce_Compr]  Note

Appendix A.  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 tradeoffs
   between these factors that led to the new encapsulation rules in
   Section 4.1.

A.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
   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.  We will use the scenario in Figure 5 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.  But 'I' can also 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 even 'I' uses tunnel mode
   authentication to prevent 'M' communicating information to 'B'.
   Mutable IP header fields such as the tentatively proposed
                       Comprehensive Decapsulation Rules in Appendix C
                       do not fix ECN field (as well as the minor compromise to TTL/
   Hop Limit and DS fields) cannot be included in the protection cryptographic
   calculations of IPsec.  Therefore, if 'I' copies these mutable fields
   into the ECN nonce outer header that RFC3168 and RFC4301 both
                       suffer from (described under Security
                       Considerations above). An attacker with control
                       over a tunnel interior node can revert a packet
                       previously marked CE within is exposed across the same tunnel it will have
   allowed a covert channel from 'A' to M that bypasses its original marking. It can do this by changing
                       CE markings to ECT(0) because the decapsulator
                       rules give precedence to encryption
   of the inner header header.  And if 'E' copies these fields from the outer is ECT(0). To fix this, we could have
                       specified that the outgoing
   header should be
                       ECT(0) when to the incoming outer is ECT(0) but inner, even if it validates authentication from 'I', it
   will have allowed a covert channel from 'M' to 'B'.

   ECN at the
                       inner IP layer is ECT(1). Although this would close designed to carry information about congestion
   from a congested resource towards downstream nodes.  Typically a
   downstream transport might feed the
                       minor loophole in information back somehow to the nonce, it would raise a
                       minor safety issue if multilevel
   point upstream of the congestion that can regulate the load on the
   congested resource, but other actions are possible (see [RFC3168]
   S.6).  In terms of the above unicast scenario, ECN or PCN were
                       used. A less severe marking in is typically
   intended to create an information channel from 'M' to 'B' (for 'B' to
   feed back to 'A').  Therefore the inner header
                       would override a more severe one in goals of IPsec and ECN are mutually
   incompatible.

   With respect to the outer.
                       Both DS or ECN fields, S.5.1.2 of RFC4301 says,
   "controls are corner cases so it is difficult provided to
                       decide which is more important: i) manage the loophole
                       in bandwidth of this [covert]
   channel".  Using the nonce is only for a minor case ECN processing rules of one
                       tunnel node attacking another in RFC4301, the same tunnel; channel
   bandwidth is two bits per datagram from 'A' to 'M' and ii) the severity inversion would not result one bit per
   datagram from any legal codepoint transition. If 'M' to 'A' (because 'E' limits the
                       Comprehensive Decapsulation Rules combinations of Appendix C
                       are taken up, we currently believe i) safety
                       against misconfiguration the
   2-bit ECN field that it will copy).  In both cases the covert channel
   bandwidth is slightly more
                       important than ii) securing against an attack further reduced by noise from any real congestion
   marking.  RFC4301 therefore implies that has little, if any, clear motivation.

Appendix A.  Why resetting CE on encapsulation harms PCN

   Regarding encapsulation, these covert channels are
   sufficiently limited to be considered a manageable threat.  However,
   with respect to the larger (6b) DS field, the same section of the PCN architecture
   [I-D.ietf-pcn-architecture] on tunnelling RFC4301
   says that header not 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. is the default, but a configuration option can allow
   copying "to allow a local administrator to decide whether the bulk marking covert
   channel provided by copying these bits outweighs the benefits of traffic
   that exceeds a configured threshold rate.  One
   copying".  Of course, an administrator considering copying of the goals of excess
   rate marking is DS
   field has to enable take into account that it could be concatenated with the speedy removal
   ECN field giving an 8b per datagram covert channel.

   Thus, for tunnelling the 6b Diffserv field two conceptual models have
   had to be defined so that administrators can trade off security
   against the needs of excess admission
   controlled traffic following re-routes caused conditioning [RFC2983]:

   The uniform model:  where the DIffserv field is preserved end-to-end
      by link failures or
   other disasters.  This maintains a share of copying into the capacity for
   competing admission controlled traffic outer header on encapsulation and 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 at a link under stress with some proportion
   already marked for removal by a previous link.  By design, marked
   traffic will be removed by copying from
      the overall system outer header on decapsulation.

   The pipe model:  where the outer header is independent of that in subsequent round
   trips.  So when the excess rate marking algorithm decides how much
   traffic to mark for removal,
      inner header so it doesn't include traffic already
   marked for removal by another node upstream (the `Excess traffic
   meter function' hides the Diffserv field of [I-D.ietf-pcn-marking-behaviour]). the inner header
      from any interaction with nodes along the tunnel.

   However, if an RFC3168 tunnel ingress intervenes, it resets for ECN, the ECN
   field new IPsec security architecture in all RFC4301 only
   standardised one tunnelling model equivalent to the outer headers, hiding all uniform model.
   It deemed that simplicity was more important than allowing
   administrators the evidence of problems
   upstream.  Thus, although excess rate marking works fine with RFC4301
   IPsec tunnels, with RFC3168 tunnels it typically removes large
   volumes option of traffic a tiny increment in security, especially
   given not copying congestion indications could seriously harm
   everyone's network service.

A.2.  Control Constraints

   Congestion control requires that it didn't need to remove at all.

Appendix B.  Contribution any congestion notification marked
   into packets by a resource will be able to Congestion across traverse a Tunnel

   This specification mandates that feedback loop
   back to a tunnel ingress determines the ECN
   field function capable of each new outer tunnel header by copying controlling the arriving header.
   Concern has been expressed load on that resource.
   To be precise, rather than calling this function the data source, we
   will make call it difficult for the
   tunnel egress Load Regulator.  This will allow us to monitor congestion introduced along a tunnel, which deal with
   exceptional cases where load is easy if not regulated by the outer ECN field is reset at a tunnel ingress (RFC3168
   full functionality mode).  However, in fact copying CE marks at
   ingress data source, but
   usually the two terms will still make it easy for be synonymous.  Note the egress to measure congestion
   introduced across term "a function
   _capable of_ controlling the load" deliberately includes a tunnel, as illustrated below.

   Consider 100 packets measured at source
   application that doesn't actually control the egress.  It measures load but ought to (e.g.
   an application without congestion control that 30 are
   CE marked in the inner and outer headers and 12 have additional CE
   marks in uses UDP).

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

                     Figure 6: Simple Tunnel Scenario

   We now consider a similar tunnelling scenario to the outer IPsec one just
   described, but not without the inner.  This means packets arriving at different security domains so we can just
   focus on ensuring the ingress had already experienced 30% congestion.  However, it does
   not mean there was 12% congestion across control loop and management monitoring can work
   (Figure 6).  If we want resources in the tunnel.  The correct
   calculation of tunnel to be able to
   explicitly notify congestion across and the tunnel is p_t = 12/(100-30) =
   12/70 = 17%.  This feedback path is easy for the egress from 'B' to
   'A', it will certainly be necessary for 'E' to measure.  It is the
   packets with additional copy any CE marking in
   from the outer header (12) as a
   proportion of packets not marked in the inner header (70).

   Figure 4 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 along to the tunnel.

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

       Figure 4: Tunnel Marking of Packets Already Marked at Ingress

Appendix C.  Comprehensive Decapsulation Rules

   This appendix is not currently normative.  Compliance with this
   appendix is NOT REQUIRED for compliance with the present
   specification.

   Given this specification requests a standards action onward transmission to
   'B', otherwise congestion notification from resources like 'M' cannot
   be fed back to update the
   RFC3168 encapsulation behaviour, this appendix explores a further
   change Load Regulator ('A').  But it doesn't seem
   necessary for 'I' to decapsulation that we ought copy CE markings from the inner to specify at the same time.
   If instead this further change outer
   header.  For instance, if resource 'R' is added later, congested, it will add another
   optional mode can send
   congestion information to 'B' using the already complicated change history of ECN
   tunnelling.

   Multi-level congestion notification is currently on the IETF's
   standards track agenda field in the Congestion and Pre-Congestion
   Notification (PCN) working group.  The PCN working group eventually
   requires three inner
   header without 'I' copying the congestion states (not marked field into the outer header
   and two increasingly
   severe levels of 'E' copying it back to the inner header.  'E' can still write any
   additional congestion marking) [I-D.ietf-pcn-architecture].
   The aim is for marking introduced across the less severe level tunnel into the
   congestion field of marking to stop admitting new
   traffic and the more severe level inner header.

   It might be useful for the tunnel egress to terminate sufficient existing
   flows be able to bring tell whether
   congestion occurred across a network back to its operating point after tunnel or upstream of it.  If outer
   header congestion marking was reset by the tunnel ingress ('I'), at
   the end of a serious
   failure.

   Although tunnel ('E') the outer headers would indicate congestion
   experienced across the tunnel ('I' to 'E'), while the inner header
   would indicate congestion upstream of 'I'.  But similar information
   can be gleaned even if the tunnel ingress copies the inner to the
   outer headers.  At the ECN field gives sufficient codepoints for these three
   states, current ECN tunnelling RFCs prevent end of the PCN working group
   from using them in case tunnel ('E'), any packet with an
   _extra_ mark in the outer header relative to the inner header
   indicates congestion across the tunnel decapsulations occur within a PCN
   region (see Appendix A ('I' to 'E'), while the inner
   header would still indicate congestion upstream of [I-D.ietf-pcn-baseline-encoding]).  If ('I').  Appendix C
   gives a
   node in simple and precise method for a tunnel sets the ECN field egress to ECT(0) or ECT(1), this change
   will be discarded by infer the
   congestion level introduced across a tunnel egress compliant with RFC4301 or
   RFC3168.  This tunnel.

   All this shows that 'E' can be seen in Figure 3, where preserve the ECT values in control loop irrespective of
   whether 'I' copies congestion notification into the outer header are ignored unless the inner header or
   resets it.

   That is the same.
   Effectively 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 describes
   how resetting CE marking at a tunnel ingress confuses a proposed
   congestion marking scheme on the ECT(0) and ECT(1) codepoints have standards track.  It ends up
   removing excessive amounts of traffic unnecessarily.  Whereas copying
   CE markings at ingress leads to be treated the correct control behaviour.

A.3.  Management Constraints

   As well as
   just one codepoint when they could otherwise have been used for their
   intended purpose 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 congestion notification.

   As a consequence,
   service level agreement.  For instance, monitors at the PCN w-g has initially confined itself borders of
   autonomous systems may need to two
   encoding states as a baseline encoding
   [I-D.ietf-pcn-baseline-encoding].  And it measure how much congestion has had to propose an
   experimental extension using extra Diffserv codepoint(s)
   accumulated since the original source, perhaps to encode determine between
   them how much of the extra states [I-D.moncaster-pcn-3-state-encoding], using up congestion is contributed by each domain.

   Therefore, when monitoring the
   rapidly exhausting DSCP space while leaving ECN codepoints unused.
   Another PCN encoding has been proposed that would survive tunnelling
   without an extra DSCP [I-D.menth-pcn-psdm-encoding], but middle of a path, it requires
   the PCN edge gateways should be
   possible to somehow share state so establish how far back in the egress can
   determine which marking a packet started with at path congestion markings
   have accumulated from.  In this document we term this the ingress.  Also a
   PCN ingress node can game baseline of
   congestion marking (or the system by initiating packets with
   inappropriate markings.

   Although this issue is currently most pressing for Congestion Baseline), i.e. the PCN working
   group, it is more general.  The currently standardised tunnel
   decapsulation behaviour unnecessarily wastes a quarter source of two bits
   (i.e. half a bit) in
   the IP (v4 & v6) header.  As explained in
   Section 3.1, layer that last reset (or created) the original reason for not copying down outer ECT
   codepoints congestion notification
   field.  Given some tunnels cross domain borders (e.g. consider M in
   Figure 6 is monitoring a border), it would therefore be desirable for onward forwarding was
   'I' to limit copy congestion accumulated so far into the covert channel outer headers
   exposed across a decapsulator to 1 bit per packet.  However, now that the
   IETF Security Area has deemed tunnel.

   Appendix B.2 discusses various scenarios where the Load Regulator
   lies in-path, not at the source host as we would typically expect.
   It concludes that a 2-bit covert channel through an
   encapsulator Congestion Baseline is a manageable risk, determined by where the same
   Load Regulator function is, which should be true for a
   decapsulator.

   Figure 5 proposes a more comprehensive layered decapsulation
   behaviour that would properly support a simpler experimental 3-state
   ECN encodings such as
   [I-D.briscoe-pcn-3-in-1-encoding].[Note_Nonce_Compr] Note that identified in the
   proposal tabulated
   transport layer, not by addresses in Figure 5 network layer headers.  This
   applies whether the Load Regulator is only at the source host or within
   the path.  The appendix also discusses where a Load Regulator
   function should be located relative to support discussion.  It is
   not currently proposed for standards action. a local tunnel encapsulation
   function.

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

B.1.  Identifiers and In-Path Load Regulators

   The only difference
   from Figure 3 (which _is_ proposed for standards action) Load Regulator is the
   change node to which congestion feedback should be
   returned by the cell highlighted as *ECT(1)*.

                      +----------------------------------------------+
                      |             Incoming Outer Header            |
   +------------------+---------+------------+------------+----------+
   |  Incoming Inner  | Not-ECT |   ECT(0)   |   ECT(1)   |    CE    |
   |      Header      |         |            |            |          |
   +------------------+---------+------------+------------+----------+
   |     Not-ECT      | Not-ECT |   drop(!!!)|   drop(!!!)| drop(!!!)|
   |      ECT(0)      |  ECT(0) | ECT(0)     |*ECT(1)*    |   CE     |
   |      ECT(1)      |  ECT(1) | ECT(1)(!!!)| ECT(1)     |   CE     |
   |        CE        |      CE |     CE     |     CE(!!!)|   CE     |
   +------------------+---------+------------+------------+----------+
                      |                Outgoing Header               |
                      +----------------------------------------------+

         Figure 5: Comprehensive IP in IP Decapsulation (currently
                        informative, next downstream node with a transport layer feedback
   function (typically but not normative)

   The table is derived from the following logic:

   o  On decapsulation, if always the inner ECN field data receiver).  The Load
   Regulator is Not-ECT often, but not always the outer
      ECN field data source.  It is anything but Not-ECT not always
   (or even typically) the decapsulator must drop same thing as the
      packet.  This is because node identified by the Not-ECT marking on
   source address of the inner outermost exposed header.  In general the
   addressing of the outermost encapsulation header says nothing about
   the identifiers of either the upstream or the downstream transport
   layer functions.  As long as the transport functions know each
   other's addresses, they don't have to be identified in the network
   layer or in any link layer.  It was only a convenience that a TCP
   receiver assumed that the address of the source transport is set the same
   as the network layer source address of an IP packet it receives.

   More generally, the return transport address for feedback could be
   identified solely in the transport layer protocol.  For instance, a
   signalling protocol like RSVP [RFC2205] breaks up a path into
   transport layer hops and informs each hop of the address of its
   transport layer neighbour without any need to identify these hops in
   the network layer.  RSVP can be arranged so that these transport
   layer hops are bigger than the underlying network layer hops.  The
   host identity protocol (HIP) architecture [RFC4423] also supports the
   same principled separation (for mobility amongst other things), where
   the transport layer sender identifies its transport address for
   feedback to be sent to, using an identifier provided by transports that do not know how a shim below
   the transport layer.

   Keeping to respond this layering principle deliberately doesn't require a
   network layer packet header to an
      explicit congestion marking;

   o  In all other cases, reveal the outgoing ECN field origin address from where
   congestion notification accumulates (its Congestion Baseline).  It is set
   not necessary for the network and lower layers to know the more
      severe marking address of
   the outer and inner ECN fields, where Load Regulator.  Only the
      ranking of severity from highest destination transport needs to lowest is CE, ECT(1), ECT(0),
      Not-ECT;

   o  There know
   that.  With forward congestion notification, the network and link
   layers only notify congestion forwards; they aren't involved in
   feeding it backwards.  If they are cases where no legal transition (e.g. backward congestion
   notification (BCN) in any current Ethernet [IEEE802.1au] or
      previous ECN tunneling specification would result EFCI in certain
      combinations of inner and outer ECN fields.  In these cases
      (indicated ATM
   [ITU-T.I.371]), that should be considered as a transport function
   added 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 table by '(!!!)'), case of IPsec tunnels) to return the decapsulator may also
      raise an alarm, but not so often that ICMP
   messages beyond the illegal combinations
      would amplify into tunnel ingress back to the Load Regulator.

   Similarly, if a flood of alarm messages.

   If this more comprehensive decapsulation proposal were taken up, management system is monitoring congestion and needs
   to know the Congestion Baseline, the management system has to find
   this out from the transport; in general it
   would be backwards compatible with all previous encapsulations of ECN cannot tell solely by
   looking at the ingress (RFC4301, both modes of RFC3168, both modes of RFC2481
   and RFC2003).  The outgoing header is different for one combination network or link layer headers.

B.2.  Non-Dependence of inner & outer headers, but Tunnelling on In-path Load Regulation

   We have said that combination was previously illegal
   anyway, so no known mechanisms at any point in a network, the Internet rely on Congestion Baseline
   (where congestion notification starts from zero) should be the
   previous
   behaviour.  The proposed tunnel egress requires no additional option
   configuration at upstream Load Regulator.  We have also said that the ingress or egress nor any additional negotiation
   with the ingress.

C.1.  Ways
   of an IP in IP tunnel must copy congestion indications to Introduce the Comprehensive Decapsulation Rules

   There would be
   encapsulating outer headers it creates.  If the Load Regulator is in-
   path rather than at the source, and also a number of ways for this more comprehensive
   decapsulation proposal tunnel ingress, these two
   requirements seem to be introduced:

   o  It could contradictory.  A tunnel ingress must not
   reset incoming congestion, but a Load Regulator must be specified in the present standards track proposal
      (preferred) or in an experimental extension;

   o
   Congestion Baseline, implying it could be specified as a new default for all Diffserv PHBs
      (preferred) or as an option needs to be configured only for Diffserv
      PHBs requiring it.

   The argument for making this change now, rather than reset incoming congestion.

   In fact, the two requirements are not contradictory, because a Load
   Regulator and a tunnel ingress are not the names of machines, but the
   names of functions within a machine that typically occur in sequence
   on a separate
   experimental extension, stream of packets, not at the same point.  Figure 7 is borrowed
   from [RFC2983] (which was making a similar point about the location
   of Diffserv traffic conditioning relative to avoid the burden encapsulation
   function of an extra standard 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 not ever need to be compliant integrated
   with and to the [Encapsulate] function (but it can be backwards compatible with--so for efficiency).
   Therefore we don't
   add to can still mandate that the already complex history [Encapsulate] function always
   copies CE into the outer header.

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

     Figure 7: Placement of ECN tunnelling RFCs.  The
   argument In-Path Load Regulator Relative to Tunnel
                                  Ingress

   Then separately, if there is a Load Regulator at location [2 -
   Outer], it might reset CE to ECT(0), say.  Then the Congestion
   Baseline for the lower layer (outer) will be [2 - Outer], while the
   Congestion Baseline of the inner layer will be unchanged.  But how
   encapsulation works has nothing to do with whether a separate experimental extension is that we may never
   need this change (if PCN Load Regulator
   is never successfully deployed and if no-one
   ever needs three ECN present or PCN encoding states rather than two).
   However, where it is.

   If on the change does no harm to existing mechanisms and stops
   tunnels wasting of quarter other hand a Load Regulator resets CE at [1 - Before], the
   Congestion Baseline of a bit (a 2-bit codepoint).

   The argument for making this new decapsulation behaviour both the default
   for all PHBs inner and outer headers will be [1 -
   Before].  But again, encapsulation is that it independent of load regulation.

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

   Although encapsulation doesn't change any expected behaviour that
   existing mechanisms rely need to depend on already.  Also, by ending in-path load
   regulation, the present
   waste reverse is not true.  The placement of a codepoint, an in-path
   Load Regulator must be carefully considered relative to
   encapsulation.  Some examples are given in the future a use of that codepoint could be
   proposed following for all PHBs, even if PCN isn't successfully deployed.
   guidance.

   In practice, if this comprehensive decapsulation was specified
   straightaway the traditional Internet architecture one tends to think of the
   source host as the normative default Load Regulator for all PHBs, a network
   operator deploying 3-state PCN would be able path.  It is generally not
   desirable or practical for a node part way along the path to request that tunnels
   comply with regulate
   the latest specification.  Implementers of non-PCN
   tunnels would not need load.  However, various reasonable proposals for in-path load
   regulation have been made from time to comply but, if they did, their code would
   be future proofed and no harm would be done time (e.g. fair queuing,
   traffic engineering, flow admission control).  The IETF has recently
   chartered a working group to legacy operations.
   Therefore, rather than branching their code base, standardise admission control across a
   part of a path using pre-congestion notification (PCN) [PCNcharter].
   This is of particular relevance here because it involves congestion
   notification with an in-path Load Regulator, it would be easiest
   for implementers can involve
   tunnelling and it certainly involves encapsulation more generally.

   We will use the more complex scenario in Figure 8 to make tease out all their new tunnel code comply
   the issues that arise when combining congestion notification and
   tunnelling with various possible in-path load regulation schemes.  In
   this
   specfication, whether or not it was for PCN.  But they could leave
   old code untouched, unless it was case 'I1' and 'E2' break up the path into three separate
   congestion control loops.  The feedback for PCN. these loops is shown
   going right to left across the top of the figure.  The alternatives 'V's are worse.  Implementers would otherwise have arrow
   heads representing the direction of feedback, not letters.  But there
   are also two tunnels within the middle control loop: 'I1' to
   provide configurable decapsulation options 'E1' and operators would have
   'I2' to configure all IPsec and IP in IP 'E2'.  The two tunnels might be VPNs, perhaps over two MPLS
   core networks.  M is a congestion monitoring point, perhaps between
   two border routers where the same tunnel endpoints for continues unbroken across
   the
   exceptional behaviour of certain PHBs. border.
        ______     _______________________________________      _____
       /      \   /                                        \   /     \
      V        \ V                                M         \ V       \
      A--->R--->I1===========>E1----->I2=========>==========>E2------->B

                     Figure 8: Complex Tunnel Scenario

   The rules for question is, should the congestion markings in the outer exposed
   headers of a tunnel
   endpoints to handle both represent congestion only since the Diffserv field and tunnel
   ingress or over the ECN field should
   'just work' when handling packets with any Diffserv codepoint.

Appendix D.  Non-Dependence whole upstream path from the source of Tunnelling on In-path Load Regulation

   We have said the inner
   header (whatever that at any point may mean)?  Or put another way, should 'I1' and
   'I2' copy or reset CE markings?
   Based on the design principles in a network, Section 4.3, the answer is that the
   Congestion Baseline
   (where congestion notification starts from zero) should be the
   previous nearest upstream interface designed
   to regulate traffic load--the Load Regulator.  In Figure 8 'A', 'I1'
   or 'E2' are all Load Regulators.  We have also said that shown the ingress
   of an IP in IP tunnel must copy congestion indications feedback loops
   returning to each of these nodes so that they can regulate the
   encapsulating outer headers it creates.  If load
   causing the congestion notification.  So the Congestion Baseline
   exposed to M should be 'I1' (the Load Regulator Regulator), not 'I2'.
   Therefore I1 should reset any arriving CE markings.  In this case,
   'I1' knows the tunnel to 'E1' is in-
   path rather than at unrelated to its load regulation
   function.  So the source, and also a load regulation function within 'I1' should be
   placed at [1 - Before] tunnel ingress, these two
   requirements seem encapsulation within 'I1' (using the
   terminology of Figure 7).  Then the Congestion Baseline all across
   the networks from 'I1' to 'E2' in both inner and outer headers will
   be contradictory.  A 'I1'.

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

   o  We argued in Appendix E that resetting CE on encapsulation could
      harm PCN excess rate marking, which marks excess traffic for
      removal in subsequent round trips.  This marking relies on not
      marking packets if another node upstream has already marked them
      for removal.  If there were a tunnel ingress must not
   reset incoming congestion, but a Load Regulator must be between the
   Congestion Baseline, implying it needs to two which
      reset incoming congestion.

   In fact, CE markings, it would confuse the two requirements are not contradictory, because a Load
   Regulator and downstream node into
      marking far too much traffic for removal.  So why do we say that
      'I1' should reset CE, while a tunnel ingress are functions within a node shouldn't?  The
      answer is that
   typically occur in sequence on a stream of packets, not at the same
   point.  Figure 6 it is borrowed from [RFC2983] (which was making a
   similar point about the location of Diffserv traffic conditioning
   relative to the encapsulation function of a tunnel).  An in-path Load Regulator can act on packets either at [1 - Before] encapsulation or function at [2 - Outer] after encapsulation.  Load Regulation does 'I1' that is
      resetting CE, not ever
   need the tunnel encapsulator.  The Load Regulator
      needs to be integrated with set itself as the [Encapsulate] function (but Congestion Baseline, so the feedback it can
      gets will only be
   for efficiency).  Therefore we about congestion on links it can still mandate that relieve itself
      (by regulating the
   [Encapsulate] function always copies CE load into them).  When it resets CE markings,
      it knows that something else upstream will have dealt with the outer header.

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

     Figure 6: Placement of In-Path Load Regulator Relative to Tunnel
                                  Ingress

   Then separately, if there
      congestion notifications it removes, given it is a part of an end-
      to-end admission control signalling loop.  It therefore knows that
      previous hops will be covered by other Load Regulator Regulators.
      Meanwhile, the tunnel ingresses at location [2 -
   Outer], it might reset CE to ECT(0), say.  Then both 'I1' and 'I2' should
      follow the Congestion
   Baseline new rule for any tunnel ingress and copy congestion
      marking into the lower layer (outer) outer tunnel header.  The ingress at 'I1' will be [2 - Outer], while the
   Congestion Baseline
      happen to copy headers that have already been reset just
      beforehand.  But it doesn't need to know that.

   o  [Shayman] suggested feedback of ECN accumulated across an MPLS
      domain could cause the inner layer will be unchanged.  But how
   encapsulation works has nothing ingress to do trigger re-routing to mitigate
      congestion.  This case is more like the simple scenario of
      Figure 6, with whether a Load Regulator
   is present or where it is.

   If on feedback loop across the other hand MPLS domain ('E' back to
      'I').  I is a Load Regulator resets CE at [1 - Before], because re-routing around congestion
      is a load regulation function.  But in this case 'I' should only
      reset itself as the Congestion Baseline of both the inner and in outer headers will be [1 -
   Before].  But again, encapsulation headers, as it is independent of load regulation.

D.1.  Dependence of In-Path Load Regulation on Tunnelling

   Although encapsulation doesn't need
      not handling congestion outside its domain, so it must preserve
      the end-to-end congestion feedback loop for something else to depend on in-path load
   regulation,
      handle (probably the data source).  Therefore the reverse is not true.  The placement of an in-path Load Regulator must
      within 'I' should be carefully considered relative placed at [2 - Outer] to
   encapsulation.  Some examples are given in reset CE markings
      just after the tunnel ingress has copied them from arriving
      headers.  Again, the following for
   guidance.

   In tunnel encapsulation function at 'I' simply
      copies incoming headers, unaware that the traditional Internet architecture one tends to think load regulator will
      subsequently reset its outer headers.

   o  The PWE3 working group of the
   source host as the Load Regulator for a path.  It IETF is generally not
   desirable or practical for a node part way along considering the path problem of
      how and whether an aggregate edge-to-edge pseudo-wire emulation
      should respond to regulate congestion [I-D.ietf-pwe3-congestion-frmwk].
      Although the load.  However, various reasonable study is still at the requirements stage, some
      (controversial) solution proposals for include in-path load regulation have been made from time
      at the ingress to time (e.g. fair queuing,
   traffic engineering, flow admission control).  The IETF has recently
   chartered a working group the tunnel that could lead to standardise admission control across a
   part tunnel
      arrangements with similar complexity to that of Figure 8.

   These are not contrived scenarios--they could be a path using pre-congestion notification (PCN) [PCNcharter].
   This lot worse.  For
   instance, a host may create a tunnel for IPsec which is placed inside
   a tunnel for Mobile IP over a remote part of particular relevance here because it involves congestion
   notification with an in-path Load Regulator, it can involve
   tunnelling its path.  And around
   this all we may have MPLS labels being pushed and popped as packets
   pass across different core networks.  Similarly, it certainly involves encapsulation more generally.

   We will use the more complex scenario is possible that
   subnets could be built from link technology (e.g. future Ethernet
   switches) so that link headers being added and removed could involve
   congestion notification in Figure 7 to tease out future Ethernet link headers with all the
   same issues that arise when combining congestion notification and
   tunnelling as with various possible IP in IP tunnels.

   One reason we introduced the concept of a Load Regulator was to allow
   for in-path load regulation schemes. regulation.  In
   this case 'I1' and 'E2' break up the path into three separate
   congestion control loops.  The feedback for these loops is shown
   going right traditional Internet
   architecture one tends to left across the top of the figure.  The 'V's are arrow
   heads representing the direction think of feedback, not letters.  But there
   are also two tunnels within the middle control loop: 'I1' to 'E1' a host and
   'I2' to 'E2'.  The two tunnels might be VPNs, perhaps over two MPLS
   core networks.  M is a congestion monitoring point, perhaps between
   two border routers where the same tunnel continues unbroken across
   the border.
        ______     _______________________________________      _____
       /      \   /                                        \   /     \
      V        \ V                                M         \ V       \
      A--->R--->I1===========>E1----->I2=========>==========>E2------->B

                     Figure 7: complex Tunnel Scenario

   The question is, should the congestion markings in Load Regulator as
   synonymous, but when considering tunnelling, even the outer exposed
   headers definition of a tunnel represent congestion only since the tunnel
   ingress or over
   host is too fuzzy, whereas a Load Regulator is a clearly defined
   function.  Similarly, the whole upstream path from concept of innermost header is too fuzzy to
   be able to (wrongly) say that the source address of the inner innermost
   header (whatever that may mean)?  Or put another way, should 'I1' and
   'I2' copy or reset CE markings?
   Based on the design principles in Section 4, be the answer Congestion Baseline.  Which is that the
   Congestion Baseline should innermost
   header when multiple encapsulations may be in use?  Where do we stop?
   If we say the nearest upstream interface designed
   to regulate traffic load--the Load Regulator.  In Figure 7 'A', 'I1'
   or 'E2' are all Load Regulators. original source in the above IPsec-Mobile IP case is
   the host, how do we know it isn't tunnelling an encrypted packet
   stream on behalf of another host in a p2p network?

   We have shown the feedback loops
   returning become used to each of these nodes so thinking that they can only hosts regulate load.  The
   end to end design principle advises that this is a good idea
   [RFC3426], but it also advises that it is solely a guiding principle
   intended to make the designer think very carefully before breaking
   it.  We do have proposals where load
   causing the regulation functions sit within
   a network path 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 to re-route around
   congestion notification.  So the Congestion Baseline
   exposed [Shayman].  Whether or not we want in-path load
   regulation, we have to M should be 'I1' (the Load Regulator), work round the fact that it will not 'I2'.
   Therefore I1 should reset any go away.

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 CE markings.  In header.
   Concern has been expressed that this case,
   'I1' knows will make it difficult for the
   tunnel egress to 'E1' monitor congestion introduced only along a tunnel,
   which is unrelated to its load regulation
   function.  So easy if the load regulation function within 'I1' should be
   placed outer ECN field is reset at [1 - Before] a tunnel encapsulation within 'I1' (using the
   terminology of Figure 6).  Then ingress
   (RFC3168 full functionality mode).  However, in fact copying CE marks
   at ingress will still make it easy for the Congestion Baseline all egress to measure
   congestion introduced across a tunnel, as illustrated below.

   Consider 100 packets measured at the networks from 'I1' to 'E2' egress.  It measures that 30 are
   CE marked in both the inner and outer headers will
   be 'I1'.

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

   o  We argued in Appendix A that resetting and 12 have additional CE on encapsulation could
      harm PCN excess rate marking, which
   marks excess traffic for
      removal in subsequent round trips.  This marking relies on the outer but not
      marking the inner.  This means packets if another node upstream has arriving at
   the ingress had already marked them
      for removal.  If experienced 30% congestion.  However, it does
   not mean there were a tunnel ingress between was 12% congestion across the two which
      reset CE markings, it would confuse tunnel.  The correct
   calculation of congestion across the downstream node into
      marking far too 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 p_t = 12/(100-30) =
   12/70 = 17%.  This is easy for the Load Regulator function at 'I1' that egress to to measure.  It is
      resetting CE, the
   packets with additional CE marking in the outer header (12) as a
   proportion of packets not marked in the tunnel encapsulator. inner header (70).

   Figure 9 illustrates this in a combinatorial probability diagram.
   The Load Regulator
      needs to set itself as square represents 100 packets.  The 30% division along the Congestion Baseline, so bottom
   represents marking before the feedback it
      gets will only be about ingress, and the p_t division up the
   side represents marking along 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

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

   Multi-level congestion notification is currently on links it can relieve itself
      (by regulating the load into them).  When it resets CE markings,
      it knows that something else upstream will have dealt with IETF's
   standards track agenda in the Congestion and Pre-Congestion
   Notification (PCN) working group.  The PCN working group eventually
   requires three congestion notifications it removes, given it states (not marked and two increasingly
   severe levels of congestion marking) [I-D.ietf-pcn-architecture].
   The aim is part for the less severe level of an end-
      to-end admission control signalling loop.  It therefore knows that
      previous hops marking 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 a serious
   failure.

   Although the ECN field gives sufficient codepoints for these three
   states, current ECN tunnelling RFCs prevent the PCN working group
   from using three ECN states in case any tunnel decapsulations occur
   within a PCN region (see Appendix A of
   [I-D.ietf-pcn-baseline-encoding]).  If a node in a tunnel sets the
   ECN field to ECT(0) or ECT(1), this change will be covered discarded by other Load Regulators.
      Meanwhile, the tunnel ingresses at both 'I1' and 'I2' should
      follow the new rule for any a
   tunnel ingress and copy congestion
      marking into egress compliant with RFC4301 or RFC3168.  This can be seen in
   Figure 2 (Section 3.2), where ECT values in the outer tunnel header.  The ingress at 'I1' will
      happen header are
   ignored unless the inner header is the same.  Effectively one ECT
   codepoint is wasted; the ECT(0) and ECT(1) codepoints have to copy headers that be
   treated as just one codepoint when they could otherwise have already been reset just
      beforehand.  But
   used for their intended purpose of congestion notification.

   As a consequence, the PCN w-g has initially confined itself to two
   encoding states as a baseline encoding
   [I-D.ietf-pcn-baseline-encoding].  And it doesn't need has had to know that.

   o  [Shayman] suggested feedback of propose an
   experimental extension using extra Diffserv codepoint(s) to encode
   the extra states [I-D.moncaster-pcn-3-state-encoding], using up the
   rapidly exhausting DSCP space while leaving ECN accumulated across codepoints unused.
   Another PCN encoding has been proposed that would survive tunnelling
   without an MPLS
      domain could cause extra DSCP [I-D.menth-pcn-psdm-encoding], but it requires
   the ingress to trigger re-routing PCN edge gateways to mitigate
      congestion.  This case is more like somehow share state so the simple scenario of
      Figure 2, egress can
   determine which marking a packet started with at the ingress.  Also a
   PCN ingress node can game the system by initiating packets with
   inappropriate markings.  Yet another work-round to the ECN tunnelling
   problem proposes a feedback loop across more involved marking algorithm in the MPLS domain ('E' back forwarding
   plane to
      'I').  I is a Load Regulator because re-routing around encode the three congestion
      is a load regulation function.  But in this case 'I' should notification states using only
      reset itself as
   two ECN codepoints [I-D.satoh-pcn-st-marking].  Still another
   proposal compromises the Congestion Baseline in outer headers, as it is
      not handling congestion outside its domain, so it must preserve precision of the end-to-end congestion feedback loop for something else admission control
   mechanism, but manages to
      handle (probably work with just two encoding states and a
   single marking algorithm [I-D.charny-pcn-single-marking].

   Rather than require the data source).  Therefore IETF to bless any of these work-rounds, this
   specification fixes the Load Regulator root cause of the problem so that operators
   deploying PCN can simply ask that tunnel end-points within 'I' a PCN
   region should be placed at [2 - Outer] comply with this new ECN tunnelling specification.

   Then PCN can use the trivially simple experimental 3-state ECN
   encoding defined in [I-D.briscoe-pcn-3-in-1-encoding].

D.1.  Alternative Ways to reset CE markings
      just after Introduce the tunnel ingress has copied them from arriving
      headers.  Again, New Decapsulation Rules

   There are a number of ways for the tunnel encapsulation function at 'I' simply
      copies incoming headers, unaware that new decapsulation rules to be
   introduced:

   o  They could be specified in the load regulator will
      subsequently reset its outer headers. present standards track proposal
      (preferred) or in an experimental extension;

   o  They could be specified as a new default for all Diffserv PHBs
      (preferred) or as an option to be configured only for Diffserv
      PHBs requiring them (e.g.  PCN).

   The PWE3 working group of the IETF argument for making this change now, rather than in a separate
   experimental extension, is considering to avoid the problem burden of
      how and whether an aggregate edge-to-edge pseudo-wire emulation
      should respond extra standard
   to be compliant with and to be backwards compatible with--so we don't
   add to congestion [I-D.ietf-pwe3-congestion-frmwk].
      Although the study already complex history of ECN tunnelling RFCs.  The
   argument for a separate experimental extension is still at the requirements stage, some
      (controversial) solution proposals include in-path load regulation
      at that we may never
   need this change (if PCN is never successfully deployed and if no-one
   ever needs three ECN or PCN encoding states rather than two).
   However, the ingress change does no harm 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 tunnel default
   for all PHBs is that it doesn't change any expected behaviour that
   existing mechanisms rely on already.  Also, by ending the present
   waste of a codepoint, in the future a use of that codepoint could lead to tunnel
      arrangements with similar complexity be
   proposed for all PHBs, even if PCN isn't successfully deployed.

   In practice, if these new decapsulation rules are specified
   straightaway as the normative default for all PHBs, a network
   operator deploying 3-state PCN would be able to request that tunnels
   comply with the latest specification.  Implementers of Figure 7.

   These are non-PCN
   tunnels would not contrived scenarios--they could need to comply but, if they did, their code would
   be a lot worse.  For
   instance, a host may create a tunnel future proofed and no harm would be done to legacy operations.
   Therefore, rather than branching their code base, it would be easiest
   for IPsec which is placed inside
   a implementers to make all their new tunnel for Mobile IP over a remote part of its path.  And around code comply with this all we may have MPLS labels being pushed and popped as packets
   pass across different core networks.  Similarly,
   specfication, whether or not it is possible that
   subnets was for PCN.  But they could be built from link technology (e.g. future Ethernet
   switches) so that link headers being added leave
   old code untouched, unless it was for PCN.

   The alternatives are worse.  Implementers would otherwise have to
   provide configurable decapsulation options and removed could involve
   congestion notification in future Ethernet link headers with operators would have
   to configure all the
   same issues as with IPsec and IP in IP tunnels.

   One reason we introduced tunnel endpoints for the concept
   exceptional behaviour of a Load Regulator was to allow certain PHBs.  The rules for in-path load regulation.  In the traditional Internet
   architecture one tends tunnel
   endpoints to think of a host handle both the Diffserv field and a Load Regulator as
   synonymous, but the ECN field should
   'just work' when considering tunnelling, even handling packets with any Diffserv codepoint.

Appendix E.  Why Resetting CE on Encapsulation Impedes PCN

   Regarding encapsulation, the definition section 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. the bulk marking of traffic
   that exceeds a
   host is too fuzzy, whereas a Load Regulator is a clearly defined
   function.  Similarly, configured threshold rate.  One of the concept goals of innermost header excess
   rate marking is too fuzzy to
   be able to (wrongly) say that enable the source address speedy removal of excess admission
   controlled traffic following re-routes caused by link failures or
   other disasters.  This maintains a share of the innermost
   header should be the Congestion Baseline.  Which is the innermost
   header when capacity for traffic
   in lower priority classes.  After failures, traffic re-routed onto
   remaining links can often stress multiple encapsulations may links along a path.
   Therefore, traffic can arrive at a link under stress with some
   proportion already marked for removal by a previous link.  By design,
   marked traffic will be in use?  Where do we stop?
   If we say removed by the original source overall system in subsequent
   round trips.  So when the above IPsec-Mobile IP case is
   the host, excess rate marking algorithm decides how do we know it isn't tunnelling an encrypted packet
   stream on behalf 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 a good idea
   [RFC3426], but it also advises that it is solely a guiding principle
   intended
   much traffic to make the designer think very carefully before breaking
   it.  We do have proposals where load regulation functions sit within
   a network path mark for good, if sometimes controversial, reasons, e.g.
   PCN edge admission control gateways [I-D.ietf-pcn-architecture] or removal, it doesn't include traffic engineering functions at domain borders to re-route around
   congestion [Shayman].  Whether or not we want in-path load
   regulation, we have to work round already
   marked for removal by another node upstream (the `Excess traffic
   meter function' of [I-D.ietf-pcn-marking-behaviour]).

   However, if an RFC3168 tunnel ingress intervenes, it resets the fact ECN
   field in all the outer headers, hiding all the evidence of problems
   upstream.  Thus, although excess rate marking works fine with RFC4301
   IPsec tunnels, with RFC3168 tunnels it typically removes large
   volumes of traffic that it will not go away. didn't need to remove at all.

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://www.cs.ucl.ac.uk/staff/B.Briscoe/

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgment

   This document was produced using xml2rfc v1.33 (of
   http://xml.resource.org/) from a source in RFC-2629 XML format.