Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim
draft-ietf-tsvwg-rfc6040update-shim-01

Transport Area Working Group                                  B. Briscoe
Internet-Draft                                Simula Research Laboratory
Updates: 6040, 2661, 2784, 3931 (if                         May 30, 2017
         approved)
Intended status: Standards Track
Expires: December 1, 2017

 Propagating Explicit Congestion Notification Across IP Tunnel Headers
                          Separated by a Shim
                 draft-ietf-tsvwg-rfc6040update-shim-01

Abstract

   RFC 6040 on "Tunnelling of Explicit Congestion Notification" made the
   rules for propagation of ECN consistent for all forms of IP in IP
   tunnel.  This specification extends the scope of RFC 6040 to include
   tunnels where two IP headers are separated by at least one shim
   header that is not sufficient on its own for packet forwarding.

Status of This Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on December 1, 2017.

Copyright Notice

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

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

Briscoe                 Expires December 1, 2017                [Page 1]
Internet-Draft               ECN Tunnelling                     May 2017

   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Scope of RFC 6040 . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  IP-in-IP Tunnels with Tightly Coupled Shim Headers  . . . . .   3
   4.  Specific Updates to Protocols under IETF Change Control . . .   4
     4.1.  L2TPv3  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.2.  GRE . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   7.  Comments Solicited  . . . . . . . . . . . . . . . . . . . . .   7
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Scope of RFC 6040

   RFC 6040 on "Tunnelling of Explicit Congestion Notification"
   [RFC6040] made the rules for propagation of Explicit Congestion
   Notification (ECN [RFC3168]) consistent for all forms of IP in IP
   tunnel.  The scope of RFC 6040 was stated as

      "...ECN field processing at encapsulation and decapsulation for
      any IP-in-IP tunnelling, whether IPsec or non-IPsec tunnels.  It
      applies irrespective of whether IPv4 or IPv6 is used for either
      the inner or outer headers. ..."

   A common pattern for many tunnelling protocols is to encapsulate an
   inner IP header with shim header(s) then an outer IP header.  To
   clear up confusion, this specification clarifies that the scope of
   RFC 6040 includes any IP-in-IP tunnel, including those with shim
   header(s) between the IP headers.

   Propagation of ECN between tunnelled IP headers is related to
   propagation of the Diffserv field over tunnels [RFC2983].  However,
   unlike Diffserv, no configuration knobs are required, because the
   network operator has no choices over propagation of the ECN field,
   which has end-to-end semantics.

Briscoe                 Expires December 1, 2017                [Page 2]
Internet-Draft               ECN Tunnelling                     May 2017

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119]
   when, and only when, they appear in all capitals, as shown here.

3.  IP-in-IP Tunnels with Tightly Coupled Shim Headers

   In many cases the shim header(s) and the outer IP header are always
   added (or removed) as part of the same process.  We call this a
   tightly coupled shim header.  Processing the shim and outer together
   is often necessary because the shim(s) are not sufficient for packet
   forwarding in their own right; not unless complemented by an outer
   header.

   For all such tightly coupled shim headers, the rules in [RFC6040] for
   propagating the ECN field MUST be applied between the inner and outer
   IP headers.  The above is written as a 'MUST' because RFC 6040 allows
   a compatibility mode for the encapsulator in cases where the
   decapsulator does not (or cannot) support ECN propagation.  In the
   compatibility mode, the outer ECN field is cleared to zero.

   There follows a list of encapsulations with tightly coupled shim
   header(s).  The list is not necessarily exhaustive, so the above
   requirement applies to all tightly coupled shim headers whether or
   not they are listed here.

   o  L2TPv2 [RFC2661], L2TPv3 [RFC3931]

   o  GRE [RFC2784], NVGRE [RFC7637]

   o  PPTP [RFC2637]

   o  GTPv1 [GTPv1], GTP v1 User Plane [GTPv1-U], GTP v2 Control Plane
      [GTPv2-C]

   o  VXLAN [RFC7348].

   Geneve [I-D.ietf-nvo3-geneve] and Generic UDP Encapsulation (GUE)
   [I-D.ietf-intarea-gue] are also tightly coupled shim headers, but
   their specifications already refer to RFC 6040 for ECN encapsulation.

   Some of the listed protocols enable encapsulation of a variety of
   network layer protocols as inner and/or outer.  This specification
   applies when the inner and outer are both IP (v4 or v6).  More
   generally, whatever form IP-in-IP tunnelling takes, the ECN field
   SHOULD be propagated according to the rules in RFC 6040 wherever

Briscoe                 Expires December 1, 2017                [Page 3]
Internet-Draft               ECN Tunnelling                     May 2017

   possible.  Otherwise [I-D.ietf-tsvwg-ecn-encap-guidelines] gives more
   general guidance on how to propagate ECN to and from protocols that
   encapsulate IP.

   Specific update text for those protocols in the above list that are
   under IETF change control is given in Section 4.  For those not under
   IETF control, it is RECOMMENDED that implementations of encapsulation
   and decapsulation comply with RFC 6040.  It is also RECOMMENDED that
   their specifications are updated to add a requirement to comply with
   RFC 6040.

   Although the definition of the various GTP shim headers is under the
   control of the 3GPP, it is hard to determine whether the 3GPP or the
   IETF controls standardization of the _process_ of adding both a GTP
   and an IP header to an inner IP header.  Nonetheless, the present
   specification is provided so that the 3GPP can refer to it from any
   of its own specifications of GTP and IP header processing.

   PPTP is not under the change control of the IETF, but it has been
   documented in an informational RFC [RFC2637].  However, there is no
   need for this memo to update PPTP because L2TP has been developed as
   a standardized replacement.

   NVGRE is not under the change control of the IETF, but it has been
   documented in an informational RFC [RFC7637].  NVGRE is a specific
   use-case of GRE (it re-purposes the key field from the initial
   specification of GRE [RFC1701] as a Virtual Subnet ID).  Therefore
   the text that updates GRE below is also intended to update NVGRE.

   VXLAN is not under the change control of the IETF but it has been
   documented in an informational RFC.  It is RECOMMENDED that VXLAN
   implementations comply with RFC 6040 when the VXLAN header is
   inserted between (or removed from between) IP headers.  And the
   authors of any future update to these specifications are encouraged
   to add a requirement to comply with RFC 6040.

4.  Specific Updates to Protocols under IETF Change Control

4.1.  L2TPv3

   L2TPv3 [RFC3931] can be used as a shim header that encapsulates an
   L2-specific sub-layer then an L2 header containing an inner IP header
   (v4 or v6).  Then this whole stack of headers can be encapsulated
   optionally within an outer UDP header then an outer IP header (v4 or
   v6).  Even though this shim is rather fat, it still fits the
   definition of a tightly coupled shim header, because all the headers
   are added (or removed) together.

Briscoe                 Expires December 1, 2017                [Page 4]
Internet-Draft               ECN Tunnelling                     May 2017

   ECN propagation is defined here as an update to L2TPv3 itself,
   because the ECN field in IP has end-to-end semantics with no operator
   choice.  In contrast, Diffserv handling was defined as an extension
   to L2TP[RFC3308] because the operator of the tunnel determines
   whether and how Diffserv is handled.  This memo updates the
   specification of L2TPv3 [RFC3931] as follows:

   Append the following text to Section 4.5 of [RFC3931]:

      "When the payload inside the L2 header and the outer PSN header
      are both IP (v4 or v6), the ECN field MUST be propagated between
      these IP headers according to the rules in Section 4 of RFC 6040
      [RFC6040].  ECN propagation occurs both when the packet is
      encapsulated and when it is decapsulated.

      Before encapsulating any data packets, these rules require an LCCE
      to check that the remote LCCE supports ECN propagation.  If it
      does, the normal mode of encapsulation can be used, otherwise the
      compatibility mode is required [RFC6040].  An LCCE can determine
      the remote LCCE's support for ECN either statically (by
      configuration) or by dynamic discovery during setup of each
      control connection between the LCCEs, using the ECN AVP defined
      below.

      Where the outer PSN header is some protocol other than IP that
      supports ECN, the appropriate ECN propagation specification will
      need to be followed, e.g Explicit Congestion Marking in MPLS
      [RFC5129].  Where no specification exists for ECN propagation by
      particular PSN, [I-D.ietf-tsvwg-ecn-encap-guidelines] gives more
      general guidance on how to propagate ECN to and from protocols
      that encapsulate IP."

   Append the following text to the list of Control Connection AVPs
   (Attribute Value Pairs) in Section 5.4.3 of [RFC3931]:

      "ECN Capability (SCCRQ, SCCRP)

         The ECN Capability AVP, Attribute Type ZZ, declares that the
         sender of the AVP supports propagation of ECN.  An LCCE
         initiating a control connection will send a Start-Control-
         Connection-Request (SCCRQ) containing the ECN AVP.  If the
         tunnel terminator supports ECN, it will return a Start-Control-
         Connection-Reply (SCCRP) that also includes the ECN AVP.  Then
         both ends of the tunnel can use the normal mode of RFC 6040 to
         propagate the ECN field when encapsulating data packets for any
         sessions created by that control connection.

Briscoe                 Expires December 1, 2017                [Page 5]
Internet-Draft               ECN Tunnelling                     May 2017

         If, on the other hand, the tunnel terminator does not support
         ECN it will ignore the ECN AVP and send an SCCRP to the tunnel
         initiator without the ECN AVP.  The tunnel initiator interprets
         the absence of the ECN AVP in the SCCRP as an indication that
         the tunnel terminator is incapable of supporting ECN.  When
         encapsulating data packets for any sessions created by that
         control connection, it will then use the compatibility mode of
         RFC 6040 to clear the ECN field of the outer IP header.

         If there is no ECN AVP in an arriving control connection
         request (SCCRQ), a tunnel terminator MUST NOT include the ECN
         APV in its reply (SCCRP).

         The Attribute Value field for this AVP is a bit-mask with the
         following format:

          0                   1
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |X X X X X X X X X X X X X X X E|
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         This AVP MAY be present in the following message types: SCCRQ
         and SCCRP.  This AVP MAY be hidden (the H-bit set to 0 or 1)
         and is optional (M-bit not set).  The length (before hiding) of
         this AVP MUST be 8 octets.  The Vendor ID is the IETF Vendor ID
         of 0.

         When bit 15 of this attribute value field is set to 1, it
         indicates that the sender supports ECN propagation.  All the
         other bits are reserved.  They MUST be cleared to zero when
         sent and ignored when received."

      "

4.2.  GRE

   This memo updates the specification of GRE [RFC2784] by appending the
   following text to Section 3:

      "When the payload and delivery protocols are either both IP (v4 or
      v6), the ECN field SHOULD be propagated between these IP headers
      according to the rules in Section 4 of RFC 6040 [RFC6040].  ECN
      propagation occurs both when the packet is encapsulated and when
      it is decapsulated.  In a case where the tunnel egress does not
      support ECN propagation, RFC 6040 requires the encapsulator to use
      compatibility mode.

Briscoe                 Expires December 1, 2017                [Page 6]
Internet-Draft               ECN Tunnelling                     May 2017

      Where the delivery protocol (outer header) is some protocol other
      than IP that supports ECN, the appropriate ECN propagation
      specification will need to be followed, e.g Explicit Congestion
      Marking in MPLS [RFC5129].  Where no specification exists for ECN
      propagation by particular PSN,
      [I-D.ietf-tsvwg-ecn-encap-guidelines] gives more general guidance
      on how to propagate ECN to and from protocols that encapsulate
      IP."

5.  IANA Considerations

   IANA is requested to assign the following L2TP Control Message
   Attribute Value Pair:

              +----------------+----------------+-----------+
              | Attribute Type | Description    | Reference |
              +----------------+----------------+-----------+
              | ZZ             | ECN Capability | RFCXXXX   |
              +----------------+----------------+-----------+

   [TO BE REMOVED: This registration should take place at the following
   location: https://www.iana.org/assignments/l2tp-parameters/l2tp-
   parameters.xhtml ]

6.  Security Considerations

   The Security Considerations in [RFC6040] and
   [I-D.ietf-tsvwg-ecn-encap-guidelines] apply equally to the scope
   defined for the present specification.

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

8.  Acknowledgements

   Thanks for Ing-jyh (Inton) Tsang for initial discussions on the need
   for ECN propagation in L2TP and its applicability.

9.  References

9.1.  Normative References

Briscoe                 Expires December 1, 2017                [Page 7]
Internet-Draft               ECN Tunnelling                     May 2017

   [I-D.ietf-tsvwg-ecn-encap-guidelines]
              Briscoe, B., Kaippallimalil, J., and P. Thaler,
              "Guidelines for Adding Congestion Notification to
              Protocols that Encapsulate IP", draft-ietf-tsvwg-ecn-
              encap-guidelines-08 (work in progress), March 2017.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC2661]  Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
              G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
              RFC 2661, DOI 10.17487/RFC2661, August 1999,
              <http://www.rfc-editor.org/info/rfc2661>.

   [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
              Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
              DOI 10.17487/RFC2784, March 2000,
              <http://www.rfc-editor.org/info/rfc2784>.

   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
              of Explicit Congestion Notification (ECN) to IP",
              RFC 3168, DOI 10.17487/RFC3168, September 2001,
              <http://www.rfc-editor.org/info/rfc3168>.

   [RFC3931]  Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed.,
              "Layer Two Tunneling Protocol - Version 3 (L2TPv3)",
              RFC 3931, DOI 10.17487/RFC3931, March 2005,
              <http://www.rfc-editor.org/info/rfc3931>.

   [RFC5129]  Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion
              Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January
              2008, <http://www.rfc-editor.org/info/rfc5129>.

   [RFC6040]  Briscoe, B., "Tunnelling of Explicit Congestion
              Notification", RFC 6040, DOI 10.17487/RFC6040, November
              2010, <http://www.rfc-editor.org/info/rfc6040>.

9.2.  Informative References

   [GTPv1]    3GPP, "GPRS Tunnelling Protocol (GTP) across the Gn and Gp
              interface", Technical Specification TS 29.060.

   [GTPv1-U]  3GPP, "General Packet Radio System (GPRS) Tunnelling
              Protocol User Plane (GTPv1-U)", Technical Specification TS
              29.281.

Briscoe                 Expires December 1, 2017                [Page 8]
Internet-Draft               ECN Tunnelling                     May 2017

   [GTPv2-C]  3GPP, "Evolved General Packet Radio Service (GPRS)
              Tunnelling Protocol for Control plane (GTPv2-C)",
              Technical Specification TS 29.274.

   [I-D.ietf-intarea-gue]
              Herbert, T., Yong, L., and O. Zia, "Generic UDP
              Encapsulation", draft-ietf-intarea-gue-04 (work in
              progress), May 2017.

   [I-D.ietf-nvo3-geneve]
              Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic
              Network Virtualization Encapsulation", draft-ietf-
              nvo3-geneve-04 (work in progress), March 2017.

   [RFC1701]  Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
              Routing Encapsulation (GRE)", RFC 1701,
              DOI 10.17487/RFC1701, October 1994,
              <http://www.rfc-editor.org/info/rfc1701>.

   [RFC2637]  Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little,
              W., and G. Zorn, "Point-to-Point Tunneling Protocol
              (PPTP)", RFC 2637, DOI 10.17487/RFC2637, July 1999,
              <http://www.rfc-editor.org/info/rfc2637>.

   [RFC2983]  Black, D., "Differentiated Services and Tunnels",
              RFC 2983, DOI 10.17487/RFC2983, October 2000,
              <http://www.rfc-editor.org/info/rfc2983>.

   [RFC3308]  Calhoun, P., Luo, W., McPherson, D., and K. Peirce, "Layer
              Two Tunneling Protocol (L2TP) Differentiated Services
              Extension", RFC 3308, DOI 10.17487/RFC3308, November 2002,
              <http://www.rfc-editor.org/info/rfc3308>.

   [RFC7348]  Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
              L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
              eXtensible Local Area Network (VXLAN): A Framework for
              Overlaying Virtualized Layer 2 Networks over Layer 3
              Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
              <http://www.rfc-editor.org/info/rfc7348>.

   [RFC7637]  Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network
              Virtualization Using Generic Routing Encapsulation",
              RFC 7637, DOI 10.17487/RFC7637, September 2015,
              <http://www.rfc-editor.org/info/rfc7637>.

Briscoe                 Expires December 1, 2017                [Page 9]
Internet-Draft               ECN Tunnelling                     May 2017

Author's Address

   Bob Briscoe
   Simula Research Laboratory
   UK

   EMail: ietf@bobbriscoe.net
   URI:   http://bobbriscoe.net/

Briscoe                 Expires December 1, 2017               [Page 10]