Simula Research Laboratory

UK ietf@bobbriscoe.net http://bobbriscoe.net/

Transport Transport Area Working Group Congestion Control and Management Congestion Notification Information Security Tunnelling Encapsulation & Decapsulation Protocol ECN Layering 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.

RFC 6040 on "Tunnelling of Explicit Congestion Notification" made the rules for propagation of Explicit Congestion Notification (ECN ) 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.

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 .

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 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: L2TPv2 , L2TPv3 GRE , , PPTP GTP , , VXLAN . Geneve and Generic UDP Encapsulation (GUE) are also tightly coupled shim headers, but their specifications already refer to RFC 6040 for ECN encapsulation. 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. Similarly, VXLAN and NVGRE are not under the control of the IETF, but the present specification is provided so that the authors of any future update to these specifications can refer to it. 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 gives more general guidance on how to propagate ECN to and from protocols that encapsulate IP.pdat

L2TPv2 , L2TPv3 GRE , GRE PPTP {ToDo: Provide text for each of the above bullets}

This memo includes no request to IANA.

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

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.

3GPP 3GPP 3GPP