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 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. Terminology
• 3. IP-in-IP Tunnels with Tightly Coupled Shim Headers
• 4. Specific Updates to Protocols under IETF Change Control
• 4.1. L2TPv3
• 4.2. GRE
• 5. IANA Considerations
• 6. Security Considerations
• 7. Comments Solicited
• 8. Acknowledgements
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Author's Address

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.

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.

• L2TPv2 [RFC2661], L2TPv3 [RFC3931]
• GRE [RFC2784], NVGRE [RFC7637]
• PPTP [RFC2637]
• GTPv1 [GTPv1], GTP v1 User Plane [GTPv1-U], GTP v2 Control Plane [GTPv2-C]
• 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 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]:

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

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

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

[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

9.2. Informative References

Author's Address