Propagating Explicit Congestion Notification across IP Tunnel Headers Separated by a Shim
updates
- rfc-2661 — Layer Two Tunneling Protocol "L2TP"
- rfc-2784 — Generic Routing Encapsulation (GRE)
- rfc-3931 — Layer Two Tunneling Protocol - Version 3 (L2TPv3)
- rfc-4380 — Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)
- rfc-6040 — Tunnelling of Explicit Congestion Notification
- rfc-7450 — Automatic Multicast Tunneling
Extracted elements (25)
ECN propagation between IP tunnel headers must remain optional to implement because legacy tunnel implementations without any ECN support already exist, a network might have no bottleneck within the tunnel, and searching within an L2 header to find an encapsulated IP header may impose unacceptable performance overhead.
RFC 6040 was intended to cover IP-in-IP tunnels with intervening shim headers, but its scope statement was ambiguous. This specification clarifies that RFC 6040 applies when an outer IP header encapsulates an inner IP header 'either directly or indirectly by encapsulating other headers that in turn encapsulate (or might encapsulate) an inner IP header,' covering the IP-shim-(L2)-IP pattern.
The rule that ECT(1) takes precedence over ECT(0) in fragment reassembly is independent of L4S experimental use of ECT(1) and is compatible with Pre-Congestion Notification (PCN, RFC 6660), which uses a severity ranking of CE > ECT(1) > ECT(0). RFC 8311 updated RFC 3168 to make ECT(1) available for congestion marking differences, motivating this ordering.
CAPWAP (RFC 5415) already specifies RFC 3168 ECN propagation and ECN capability negotiation and interworks with RFC 6040 without modification. LISP (RFC 9300) made RFC 3168 ECN procedures mandatory from the start and is backwards compatible with RFC 6040 updates. Geneve (RFC 8926) already refers to RFC 6040 for ECN encapsulation.
NVGRE (RFC 7637) is a specific use case of GRE that re-purposes the GRE key field as a Virtual Subnet ID. Because it is not under IETF change control but is documented as Informational, the GRE update text in Section 6.1.2 is also intended to apply to NVGRE implementations.
A Teredo tunnel ingress implementation that does not support ECN propagation as defined in RFC 6040 or its compatible predecessors MUST zero the ECN field in the outer IPv6 header. This is added as a new section 5.1.3 to the Teredo specification (RFC 4380).
A tunnel ingress implementation SHOULD be able to be configured to zero the ECN field of the outer IP header, independently of any Diffserv configuration, even if the implementation does not claim compliance with RFC 6040, RFC 4301, or RFC 3168 full functionality mode.
An AMT gateway that does not support RFC 6040 MUST NOT set the E flag of its Request Message to 1. An AMT gateway that supports RFC 6040 ECN propagation MUST set the E flag of its Relay Discovery Message to 1.
An implementation of a tunnel ingress MUST NOT treat the former Type of Service (ToS) octet (IPv4) or Traffic Class octet (IPv6) as a single 8-bit field, because doing so incorrectly links ECN and Diffserv field propagation in a way inconsistent with RFC 2474 and RFC 3260.
During reassembly of outer IP fragments at a tunnel egress, the packet MUST be discarded if the ECN fields of the outer headers being reassembled consist of a mixture of Not-ECT and other ECN codepoints.
For an L2TP LCCE that does not support the ECN extension, configuration of how it propagates the ECN field between inner and outer IP headers MUST be independent of any configuration of the Diffserv extension of L2TP (RFC 3308).
If a tunnel ingress fragments a packet, it MUST set the outer ECN field of all the fragments to the same value as it would have set if it had not fragmented the packet.
If an AMT relay that supports RFC 6040 ECN propagation receives a Request message with E=1, it MUST use the normal mode of RFC 6040 (copying the IP ECN field from inner to outer header) when tunneling datagrams toward that gateway.
If there is a mix of ECT(0) and ECT(1) outer fragments during reassembly at a tunnel egress, the reassembled packet MUST be set to ECT(1).
The operator of a GRE tunnel ingress MUST follow the configuration requirements in Section 4 of RFC 9601 when the outer delivery protocol is IP (v4 or v6). This update is appended to Section 3 of RFC 2784.
The operator of an AMT relay that does not support RFC 6040 or compatible predecessors MUST follow the configuration requirements in Section 4 of RFC 9601 to ensure it clears the outer IP ECN field to zero.
The operator of an L2TP LCCE that does not support the ECN extension MUST follow the configuration requirements in Section 4 of RFC 9601 to ensure it clears the outer IP ECN field to 0b00 when the outer PSN header is IP (v4 or v6).
The tunnel ingress MUST NOT alter the ECN field of the arriving IP header that will become the inner IP header; only the outer IP header's ECN field is subject to zeroing requirements.
When the outer tunnel header is IP (v4 or v6), if possible, the tunnel ingress MUST be configured to zero the outer ECN field when: (1) the egress is known not to support ECN propagation per RFC 6040, RFC 4301, or RFC 3168 full functionality mode; (2) the egress behavior is unknown or a dynamically-paired egress with unknown behavior might be used; or (3) the ingress is encapsulating a non-IP header that might encapsulate IP but the ingress does not inspect within it.
A 'tightly coupled shim header' is one where the shim and outer IP header are always added or removed together as part of the same procedure. Because a shim is not sufficient for packet forwarding on its own, it is generally feasible for implementations handling tightly coupled shims to also propagate the ECN field between inner and outer IP headers.
An L2TP LCCE may determine remote LCCE ECN support either statically by configuration or dynamically during control connection setup using the ECN Capability AVP (Attribute Type 103). If the responder sends an SCCRP without the ECN Capability AVP, the initiator treats this as absence of ECN support and MUST use RFC 6040 compatibility mode (clearing the outer IP ECN field to 0b00).
IANA has assigned Attribute Type 103 ('ECN Capability') in the L2TP 'Control Message Attribute Value Pairs' registry, with reference to RFC 9601.
The security considerations of RFC 6040 and RFC 9599 apply equally to the extended scope defined in this specification. No additional security considerations beyond those documents are identified; the primary safety concern addressed is preventing non-ECN tunnel egresses from silently discarding ECN markings and thus breaking ECN-based congestion control feedback loops.
Bit 14 (counting from 0) of the AMT Request Message is defined as the AMT Gateway ECN Capability flag (E). When set to 1 it indicates the sender supports RFC 6040 ECN propagation; when cleared to 0 it indicates no support. All other bits of the Reserved field remain cleared to zero.
The L2TP ECN Capability AVP has Attribute Type 103, is 6 octets in length (before hiding), carries IETF Vendor ID of 0, and is optional (M-bit not set). It may be present in SCCRQ and SCCRP messages. Its presence signals ECN propagation support; its absence signals lack of support.