Transport Area Working Group                                  B. Briscoe
Internet-Draft                                Simula Research Laboratory
Updates: 2661, 1701, 2784, 2637, 7348                       July 8, 2016
         (if approved)
Intended status: Standards Track
Expires: January 9, 2017


 Propagating Explicit Congestion Notification Across IP Tunnel Headers
                          Separated by a Shim
                   draft-briscoe-tsvwg-rfc6040bis-00

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 a shim header that
   cannot stand alone.

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 January 9, 2017.

Copyright Notice

   Copyright (c) 2016 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 January 9, 2017                [Page 1]


Internet-Draft               ECN Tunnelling                    July 2016


   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 . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  IP-in-IP Tunnels with Tightly Coupled Shim Headers  . . . . .   2
   4.  IANA Considerations (to be removed by RFC Editor) . . . . . .   3
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   3
   6.  Comments Solicited  . . . . . . . . . . . . . . . . . . . . .   4
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   4
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

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.

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

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.




Briscoe                  Expires January 9, 2017                [Page 2]


Internet-Draft               ECN Tunnelling                    July 2016


   For all such tightly coupled shim headers, the rules in [RFC6040] for
   propagating the ECN field SHOULD be applied directly between the
   inner and outer IP headers.  This specification therefore updates the
   following specifications of tightly coupled shim headers by adding
   that RFC 6040 SHOULD apply when the shim header is used between IP
   headers:

   o  L2TP [RFC2661]

   o  GRE [RFC1701], [RFC2784]

   o  PPTP [RFC2637]

   o  GTP [GTPv1], [GTPv1-U], [GTPv2-C]

   o  VXLAN [RFC7348].

   The above is written as a 'SHOULD' not a 'MUST' to allow for the
   possibility that the structure of some pre-existing tunnel
   implementations might make it hard to predict what other headers will
   be added or removed subsequently.

   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.

   More generally, whatever form IP-in-IP tunnelling takes, the ECN
   field SHOULD be propagated according to the rules in RFC 6040
   wherever 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.

4.  IANA Considerations (to be removed by RFC Editor)

   This memo includes no request to IANA.

5.  Security Considerations

   The Security Considerations in RFC 6040 apply equally to the wider
   scope defined by the present specification.








Briscoe                  Expires January 9, 2017                [Page 3]


Internet-Draft               ECN Tunnelling                    July 2016


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

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

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

   [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-05 (work in progress), March 2016.

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

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

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

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







Briscoe                  Expires January 9, 2017                [Page 4]


Internet-Draft               ECN Tunnelling                    July 2016


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

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

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

Author's Address

   Bob Briscoe
   Simula Research Laboratory
   UK

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






















Briscoe                  Expires January 9, 2017                [Page 5]