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

Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim


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

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 ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

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

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.

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.

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

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

       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|

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

4.2. GRE

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

5. IANA Considerations

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

Attribute Type Description Reference

[TO BE REMOVED: This registration should take place at the following location: ]

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

[I-D.ietf-tsvwg-ecn-encap-guidelines] Briscoe, B., Kaippallimalil, J. and P. Thaler, "Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP", Internet-Draft draft-ietf-tsvwg-ecn-encap-guidelines-08, 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.
[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.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, DOI 10.17487/RFC2784, March 2000.
[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.
[RFC3931] Lau, J., Townsley, M. and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, DOI 10.17487/RFC3931, March 2005.
[RFC5129] Davie, B., Briscoe, B. and J. Tay, "Explicit Congestion Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January 2008.
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010.

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
[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", Internet-Draft draft-ietf-intarea-gue-04, May 2017.
[I-D.ietf-nvo3-geneve] Gross, J., Ganga, I. and T. Sridhar, "Geneve: Generic Network Virtualization Encapsulation", Internet-Draft draft-ietf-nvo3-geneve-04, March 2017.
[RFC1701] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, DOI 10.17487/RFC1701, October 1994.
[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.
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, DOI 10.17487/RFC2983, October 2000.
[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.
[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.
[RFC7637] Garg, P. and Y. Wang, "NVGRE: Network Virtualization Using Generic Routing Encapsulation", RFC 7637, DOI 10.17487/RFC7637, September 2015.

Author's Address

Bob Briscoe Simula Research Laboratory UK EMail: URI: