RFC 9601

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

📅 published August 2024, from ietf

RFC 9601 💖 Propagating Explicit Congestion Notification across IP Tunnel Headers Separated by a Shim

Internet Engineering Task Force (IETF) 🌸

Request for Comments: 9601 🎀 Authors: B. Briscoe (Independent) ✨ Date: August 2024 📅 Category: Standards Track 👑 Updates: 2661, 2784, 3931, 4380, 6040, 7450 🔥 ISSN: 2070-1721

okay bestie, this is RFC 9601 and it's all about making ECN (Explicit Congestion Notification) survive a trip through tunnels that have a "shim" header sitting between the two IP headers 🦋. It updates RFC 6040 and six older tunnelling specs so they're all on the same page. Let's go!! 💅

Abstract ✨

okay so RFC 6040 ("Tunnelling of Explicit Congestion Notification") made the ECN propagation rules consistent for every kind of IP-in-IP tunnel 🎀. This spec updates RFC 6040 to make it clear that its scope covers tunnels where the two IP headers are separated by at least one shim header, and that shim header can't forward packets over a wide-area network all by itself 🌈. It also looks at the widely used tunnelling protocols that rely on these shim headers, and it updates the specs of the ones that never mention ECN propagation. Those are RFC 2661 (L2TPv2), RFC 3931 (L2TPv3), RFC 2784 (GRE, Generic Routing Encapsulation), RFC 4380 (Teredo) and RFC 7450 (AMT, Automatic Multicast Tunneling) 💜. Finally, it updates RFC 6040 with configuration requirements that keep any legacy tunnel ingress safe 🫶.

Status of This Memo ✨

This is an Internet Standards Track document 👑.

This document is a product of the Internet Engineering Task Force (IETF). It reflects the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG) 🌸. You can find more about Internet Standards in Section 2 of RFC 7841 🍓.

Info about this document's current status, any errata, and how to send feedback lives at https://www.rfc-editor.org/info/rfc9601 🦋.

Copyright (c) 2024 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 (https://trustee.ietf.org/license-info) as they stand on the publication date. Please read those carefully, because they spell out your rights and restrictions for this document 📜. Any Code Components pulled out of this document must include the Revised BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Revised BSD License says 🔥.

This document might include material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008 🙈. The people who control the copyright on some of that older material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So unless you get a proper license from those copyright holders, this document can't be modified outside the IETF Standards Process, and derivative works can't be created outside it either. The one exceptions are formatting it for publication as an RFC or translating it into languages other than English 💖.

Table of Contents 🧚

1.  Introduction
2.  Terminology
3.  Scope of RFC 6040
  3.1.  Feasibility of ECN Propagation between Tunnel Headers
  3.2.  Desirability of ECN Propagation between Tunnel Headers
4.  Making a Non-ECN Tunnel Ingress Safe by Configuration
5.  ECN Propagation and Fragmentation/Reassembly
6.  IP-in-IP Tunnels with Tightly Coupled Shim Headers
  6.1.  Specific Updates to Protocols under IETF Change Control
    6.1.1.  L2TP (v2 and v3) ECN Extension
    6.1.2.  GRE
    6.1.3.  Teredo
    6.1.4.  AMT
7.  IANA Considerations
8.  Security Considerations
9.  References
  9.1.  Normative References
  9.2.  Informative References
Acknowledgements
Author's Address

1. Introduction ✨

okay so [RFC6040] ("Tunnelling of Explicit Congestion Notification") made the rules for propagating Explicit Congestion Notification (ECN) [RFC3168] consistent for every form of IP-in-IP tunnel 🎀.

tunnelling protocols tend to follow a pattern 🌈. They wrap an inner IP header (v4 or v6) in one or more shim headers, and then put an outer IP header (v4 or v6) on the very outside. Some shim headers are generic encapsulations, so they don't always wrap an IP header directly 💜. Instead, they can wrap things like link-layer (L2) protocols, and those usually wrap IP in turn. That's why the shorthand 'IP-shim-(L2)-IP' works for the tunnels that are in scope for this doc 🦋.

To clear up the confusion, this spec says that the scope of [RFC6040] includes any IP-in-IP tunnel, even ones with one or more shim headers and other encapsulations between the IP headers 💅. Where it's needed, it also updates the specs of the relevant encapsulation protocols so they comply with [RFC6040] 🫶.

This spec also updates [RFC6040] to explain how operators ought to configure a legacy tunnel ingress so they avoid unsafe system configurations 🔥.

2. Terminology ✨

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 💖.

This spec uses the terminology defined in [RFC6040] 🎀.

3. Scope of RFC 6040 👑

In Section 1.1 of [RFC6040], the scope is defined 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.

Okay, there are two problems with that scoping statement 😭.

Problem 1: It was meant to cover cases where one or more shim headers sit between the IP headers. Lots of tunnelling implementers have read the scope of [RFC6040] that way, which is what it was supposed to mean, but the wording is ambiguous 🙈. So this spec updates [RFC6040] by adding the following scoping text after the sentences quoted above:

It applies in cases where 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.

Problem 2: Like many IETF specifications, [RFC6040] is written as something implementations can choose to claim compliance with 🌸. That means it doesn't cover two important situations:

  1. Cases where it's infeasible for an implementation to access an inner IP header when adding or removing an outer IP header
  2. Cases where implementations choose not to propagate ECN between IP headers
The ECN field is a non-optional part of the IP header (v4 and v6), so any implementation that creates an outer IP header has to give the ECN field some value 🚨. If a tunnel ingress doesn't know whether the egress supports propagating the ECN field, its only safe choice is to clear the ECN field in any outer IP header to 0b00.

An RFC has no jurisdiction over implementations that choose not to comply or can't comply, including every implementation that existed before it 🙅. So it wouldn't have been reasonable to slap such a requirement onto [RFC6040]. Still, to make sure ECN propagates safely over tunnels, it's reasonable to put requirements on operators so they configure their tunnels safely (where that's possible) 🧁. Before solving 'Problem 2' by stating those configuration requirements (in Section 4), let's quickly look at the factors that decide whether ECN propagation is feasible or desirable 🔍.

3.1. Feasibility of ECN Propagation between Tunnel Headers 🦋

In lots of cases, one or more shim headers and an outer IP header always get added to (or removed from) an inner IP packet as part of the same procedure 💜. We call these tightly coupled shim headers. Processing a shim and outer header together is often necessary, because a shim alone isn't enough for packet forwarding. It needs an outer header to go with it 🫶. In these cases, it will often be feasible for an implementation to propagate the ECN field between the IP headers ✨.

Sometimes a tunnel adds an outer IP header and a tightly coupled shim header to an inner header that isn't an IP header, but that inner header in turn encapsulates an IP header (or might) 🌈. For example, an inner Ethernet (or other link-layer) header might carry an inner IP header as its payload. We call this a tightly coupled shim over an encapsulating header 🎀.

Digging down to arbitrary depths to find an inner IP header inside an encapsulation is a layering violation, so it can't be a required behaviour 🙅. Still, some tunnel endpoints already look inside a Layer 2 (L2) header for an IP header, for instance to map the Diffserv codepoint between an encapsulated IP header and an outer IP header [RFC2983] 💅. In those cases at least, it should be feasible to also (independently) propagate the ECN field between the same IP headers 💖. So getting at the ECN field inside an encapsulating header can be a useful and benign optimization 🌸. The guidelines in Section 5 of [RFC9599] give the conditions under which this layering violation is benign 📜.

3.2. Desirability of ECN Propagation between Tunnel Headers 🍓

Developers and network operators are encouraged to implement and deploy tunnel endpoints that comply with [RFC6040] (as updated by this spec) so they get the benefits of wider ECN deployment [RFC8087] 👑. Still, propagating ECN between IP headers, whether or not they're separated by shim headers, has to stay optional to implement and to use 🦋. Here's why:

  • legacy implementations of tunnels without any ECN support already exist 😭;
  • a network might be designed so there's usually no bottleneck within the tunnel 🌈; and
  • if the tunnel endpoints would have to search within an L2 header to find an encapsulated IP header, it might not be worth the potential performance hit 💀.

4. Making a Non-ECN Tunnel Ingress Safe by Configuration ✨

Okay so even if nobody has built ECN propagation into a tunnel ingress, the operator ought to be able to make it safe just by configuring it 🧚 The main worry is clearing the ECN bits to zero in the outer IP header at the ingress when the tunnel egress has no ECN logic to copy markings into packets forwarded past the tunnel. Otherwise the non-ECN egress could toss any ECN marking added inside the tunnel, and that would break every ECN-based control loop regulating traffic over the tunnel 💀 not it!!

Therefore, this specification updates Section 4.3 of [RFC6040] by inserting the following text at the end of the section:

Whether or not an ingress implementation claims compliance with [RFC6040], [RFC4301], or [RFC3168], when the outer tunnel header is IP (v4 or v6), if possible, the ingress MUST be configured to zero the outer ECN field in all of the following cases: - if it is known that the tunnel egress does not support any of the RFCs that define propagation of the ECN field ([RFC6040], [RFC4301], or the full functionality mode of [RFC3168]); - if the behaviour of the egress is not known or an egress with unknown behaviour might be dynamically paired with the ingress (one way for an operator of a tunnel ingress to determine the behaviour of an otherwise unknown egress is described in [decap-test]); - if an IP header might be encapsulated within a non-IP header that the tunnel ingress is encapsulating, but the ingress does not inspect within the encapsulation. For the avoidance of doubt, the above only concerns the outer IP header. The ingress MUST NOT alter the ECN field of the arriving IP header that will become the inner IP header. In order that the network operator can comply with the above safety rules, an implementation of a tunnel ingress: - MUST NOT treat the former Type of Service (ToS) octet (IPv4) or the former Traffic Class octet (IPv6) as a single 8-bit field. This is because the resulting linkage of ECN and Diffserv field propagation between inner and outer headers is not consistent with the definition of the 6-bit Diffserv field in [RFC2474] and [RFC3260]. - SHOULD be able to be configured to zero the ECN field of the outer header. These last two rules apply even if an implementation of a tunnel ingress does not claim to support [RFC6040], [RFC4301], or the full functionality mode of [RFC3168]

For instance, if a tunnel ingress with no ECN-specific logic had a configuration capability to refer to the last 2 bits of the old ToS Byte of the outer (e.g., with a 0x3 mask) and set them to zero, while also being able to allow the DSCP to be re-mapped independently, that would be sufficient to satisfy both implementation requirements above. 🎀

There might be concern that the above "MUST NOT" makes compliant implementations non-compliant at a stroke. However, by definition, it solely applies to equipment that provides Diffserv configuration. Any such Diffserv equipment that is configuring treatment of the former ToS octet (IPv4) or the former Traffic Class octet (IPv6) as a single 8-bit field must have always been non-compliant with the definition of the 6-bit Diffserv field in [RFC2474] and [RFC3260]. If a tunnel ingress does not have any ECN logic, copying the ECN field as a side effect of copying the DSCP is a seriously unsafe bug that risks breaking the feedback loops that regulate load on a tunnel, because it omits to check the ECN capability of the tunnel egress. 😭

Zeroing the outer ECN field of all packets in all circumstances would be safe, but it would not be sufficient to claim compliance with [RFC6040] because it would not meet the aim of introducing ECN support to tunnels (see Section 4.3 of [RFC6040]). 🙈

5. ECN Propagation and Fragmentation/Reassembly

The following requirements update [RFC6040], which omitted handling of the ECN field during fragmentation or reassembly. These changes might alter how many ECN-marked packets are propagated by a tunnel that fragments packets, but this would not raise any backward compatibility issues. 🦋

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.

Section 5.3 of [RFC3168] specifies ECN requirements for reassembly of sets of 'outer fragments' into packets (in 'outer fragmentation', the fragmentation is visible in the outer header so that the tunnel egress can reassemble the fragments [INTAREA-TUNNELS]). Additionally, the following requirements apply at a tunnel egress:

  • During reassembly of outer fragments, the packet MUST be discarded if the ECN fields of the outer headers being reassembled into a single packet consist of a mixture of Not ECN-Capable Transport (Not-ECT) and other ECN codepoints.
  • If there is mix of ECT(0) and ECT(1) outer fragments, then the reassembled packet MUST be set to ECT(1).

Reasoning: [RFC3168] originally defined ECT(0) and ECT(1) as equivalent, but [RFC3168] has been updated by [RFC8311] to make ECT(1) available for congestion marking differences. The rule is independent of the current experimental use of ECT(1) for Low Latency, Low Loss, and Scalable throughput (L4S) [RFC9331]. The rule is compatible with Pre-Congestion Notification (PCN) [RFC6660], which uses 2 levels of congestion severity, with the ranking of severity from highest to lowest being Congestion Experienced (CE), ECT(1), ECT(0). The decapsulation rules in [RFC6040] take a similar approach. Ngl this part is so satisfying, the priority ladder just clicks 👑

6. IP-in-IP Tunnels with Tightly Coupled Shim Headers ✨

okay bestie, here's the list of encapsulations with tightly coupled shim header(s), roughly in chronological order 🦋 It's only Standards Track or widely deployed protocols, so just so we're clear, the updated scope of [RFC6040] is set in Section 3 and is not limited to this list 💅

  • Point-to-Point Tunneling Protocol (PPTP) [RFC2637]
  • Layer Two Tunneling Protocol (L2TP), specifically L2TPv2 [RFC2661] and L2TPv3 [RFC3931], which not only includes all the L2-specific specializations of L2TP, but also derivatives such as the Keyed IPv6 Tunnel [RFC8159]
  • Generic Routing Encapsulation (GRE) [RFC2784] and Network Virtualization using GRE (NVGRE) [RFC7637]
  • GPRS Tunnelling Protocol (GTP), specifically GTPv1 [GTPv1], GTP v1 User Plane [GTPv1-U], and GTP v2 Control Plane [GTPv2-C]
  • Teredo [RFC4380]
  • Control And Provisioning of Wireless Access Points (CAPWAP) [RFC5415]
  • Locator/Identifier Separation Protocol (LISP) [RFC9300]
  • Automatic Multicast Tunneling (AMT) [RFC7450]
  • Virtual eXtensible Local Area Network (VXLAN) [RFC7348] and Generic Protocol Extensions for VXLAN (VXLAN-GPE) [NVO3-VXLAN-GPE]
  • The Network Service Header (NSH) [RFC8300] for Service Function Chaining (SFC)
  • Geneve [RFC8926]
  • Direct tunnelling of an IP packet within a UDP/IP datagram (see Section 3.1.11 of [RFC8085])
  • TCP Encapsulation of Internet Key Exchange Protocol (IKE) and IPsec Packets (see Section 9.5 of [RFC9329])

Some of the listed protocols can wrap lots of different network layer protocols as inner and/or outer, which is very flexible of them 🌈 This specification applies to the cases where there is an inner and outer IP header, as described in Section 3. Otherwise, [RFC9599] gives guidance on how to design propagation of ECN into other protocols that might encapsulate IP ✨

Where protocols in the above list need to be updated to specify ECN propagation and are under IETF change control, the update text is given in the following subsections 🎀 For those not under IETF control, it is RECOMMENDED that implementations of encapsulation and decapsulation comply with [RFC6040]. It is also RECOMMENDED that their specifications are updated to add a requirement to comply with [RFC6040] (as updated by the present document) 🫶

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 the present specification 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 in Section 6.1.2 below is also intended to update NVGRE 🧚

Although the definition of the various GTP shim headers is under the control of the Third Generation Partnership Project (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 💜

The specification of CAPWAP already specifies [RFC3168] ECN propagation and ECN capability negotiation. Without modification, the CAPWAP specification already interworks with the backward-compatible updates to [RFC3168] in [RFC6040] 🍓

LISP made the ECN propagation procedures in [RFC3168] mandatory from the start. [RFC3168] has since been updated by [RFC6040], but the changes are backwards compatible, so there is still no need for LISP tunnel endpoints to negotiate their ECN capabilities 🙈

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 [RFC6040] when the VXLAN header is inserted between (or removed from between) IP headers. The authors of any future update of the VXLAN spec are also encouraged to add a requirement to comply with [RFC6040] as updated by the present specification. In contrast, VXLAN-GPE is being documented under IETF change control, and it does require compliance with [RFC6040] 🦋

The Network Service Header (NSH) [RFC8300] has been defined as a shim-based encapsulation to identify the Service Function Path (SFP) in the Service Function Chaining (SFC) architecture [RFC7665]. A proposal has been made for the processing of ECN when handling transport encapsulation [SFC-NSH-ECN] 👑

The specification of Geneve already refers to [RFC6040] for ECN encapsulation ✨

Section 3.1.11 of [RFC8085] already explains that a tunnel that encapsulates an IP header within a UDP/IP datagram needs to follow [RFC6040] when propagating the ECN field between inner and outer IP headers. Section 3 of the present specification updates [RFC6040] to clarify that its scope includes cases with a shim header between the IP headers. So it indirectly updates the scope of [RFC8085] to include cases with a shim header as well as a UDP header between the IP headers 🌈

The requirements in Section 4 update [RFC6040], and hence also indirectly update the UDP usage guidelines in [RFC8085] to add the important but previously unstated requirement that, if the UDP tunnel egress does not, or might not, support ECN propagation, a UDP tunnel ingress has to clear the outer IP ECN field to 0b00, e.g., by configuration. This one is a big deal 😭

Section 9.5 of [RFC9329] already recommends the compatibility mode of [RFC6040] in this case, because there is not a one-to-one mapping between inner and outer packets when TCP encapsulates IKE or IPsec 🙈

6.1. Specific Updates to Protocols under IETF Change Control

6.1.1. L2TP (v2 and v3) ECN Extension

The L2TP terminology used here is defined in [RFC2661] and [RFC3931] 🎀

L2TPv3 [RFC3931] is used as a shim header between any packet-switched network (PSN) header (e.g., IPv4, IPv6, and MPLS) and many types of L2 headers. The L2TPv3 shim header encapsulates an L2-specific sub-layer, then an L2 header that is likely to contain an inner IP header (v4 or v6). Then this whole stack of headers can be encapsulated within an optional outer UDP header and an outer PSN header that is typically IP (v4 or v6) 🧚

L2TPv2 is used as a shim header between any PSN header and a PPP header, which is in turn likely to encapsulate an IP header 💖

Even though these shims are rather fat (particularly in the case of L2TPv3), they still fit the definition of a tightly coupled shim header over an encapsulating header (Section 3.1), because all the headers encapsulating the L2 header are added (or removed) together. L2TPv2 and L2TPv3 are therefore within the scope of [RFC6040], as updated by Section 3 ✨

Implementation of the ECN extension to L2TPv2 and L2TPv3 defined in Section 6.1.1.2 is RECOMMENDED in order to provide the benefits of ECN [RFC8087] whenever a node within an L2TP tunnel becomes the bottleneck for an end-to-end traffic flow 🦋

6.1.1.1. Safe Configuration of a "Non-ECN" Ingress LCCE

The following text is appended to both Section 5.3 of [RFC2661] and Section 4.5 of [RFC3931] as an update to the base L2TPv2 and L2TPv3 specifications 📝

The operator of an LCCE that does not support the ECN extension in Section 6.1.1.2 of RFC 9601 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).

In particular, for an L2TP Control Connection Endpoint (LCCE) implementation that does not support the ECN extension, this means that 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 [RFC3308]. Keep those configs separate, bestie, it's giving clean architecture 🧼

6.1.1.2. ECN Extension for L2TP (v2 or v3)

When the outer PSN header and the payload inside the L2 header are both IP (v4 or v6), an LCCE will propagate the ECN field at ingress and egress by following the rules in Section 4 of [RFC6040] 💅

Before encapsulating any data packets, [RFC6040] requires an ingress LCCE to check that the egress LCCE supports ECN propagation as defined in [RFC6040] or one of its compatible predecessors ([RFC4301] or the full functionality mode of [RFC3168]). If the egress supports ECN propagation, the ingress LCCE can use the normal mode of encapsulation (copying the ECN field from inner to outer). Otherwise, the ingress LCCE has to use compatibility mode [RFC6040] (clearing the outer IP ECN field to 0b00). The handshake check is giving responsible adult energy 🫶

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 Capability Attribute-Value Pair (AVP) defined in Section 6.1.1.2.1 🌸

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., [RFC5129] for MPLS. Where no specification exists for ECN propagation by a particular PSN, [RFC9599] gives general guidance on how to design ECN propagation into a protocol that encapsulates IP 🌈

6.1.1.2.1. ECN Capability AVP for Negotiation between LCCEs ✨

okay so the ECN Capability AVP here has Attribute Type 103 🎀 and it's built like this:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|H|0|0|0|0|      Length       |          Vendor ID            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             103               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: ECN Capability AVP for L2TP (v2 or v3)

this AVP MAY be present in the Start-Control-Connection-Request (SCCRQ) and Start-Control-Connection-Reply (SCCRP) message types 💅. It MAY be hidden (the H-bit is set to 0 or 1) and it's optional (the M-bit is not set) 🫶. The length before hiding is 6 octets, and the Vendor ID is the IETF Vendor ID of 0 🔥.

when an LCCE sends an ECN Capability AVP, that's its way of saying it supports ECN propagation 🦋. when no ECN Capability AVP shows up, it means the sender does NOT support ECN propagation 💀.

so if an LCCE that's starting a control connection supports ECN propagation, it sends an SCCRQ with an ECN Capability AVP ✨. if the tunnel terminator supports ECN too, it sends back an SCCRP that also has an ECN Capability AVP 👑. then, for any sessions made by that control connection, both ends can use the normal mode of [RFC6040] 🌈. that means they can copy the IP ECN field from inner to outer when encapsulating data packets 💖.

on the flip side, if the tunnel terminator doesn't support ECN, it just ignores the ECN Capability AVP and sends an SCCRP to the tunnel initiator without one 🙈. the tunnel initiator reads the missing ECN Capability flag in the SCCRP as a sign that the terminator can't do ECN 😭. so when it encapsulates data packets for any sessions from that control connection, it switches to the compatibility mode of [RFC6040] and clears the ECN field of the outer IP header to 0b00 🍓.

if the tunnel terminator doesn't support this ECN extension, the network operator is still expected to configure it to follow the safety provisions in Section 6.1.1.1 when it acts as an ingress LCCE 🛡️.

and if ECN support by the ingress and egress LCCEs is configured statically (which Section 6.1.1.2 allows), they both ignore whether an ECN capability AVP is present or absent 🧚.

6.1.2. GRE ✨

the GRE terminology used here comes from [RFC2784] 🎀. GRE is often used as a tightly coupled shim header between IP headers 🌸. sometimes the GRE shim header wraps an L2 header, and that L2 header might wrap an IP header in turn 💅. so GRE is within the scope of [RFC6040] as updated by Section 3 ✨.

implementing support for [RFC6040] as updated by this specification is RECOMMENDED for GRE tunnel endpoints 🔥. the payoff is the benefits of ECN [RFC8087], especially whenever a node inside a GRE tunnel becomes the bottleneck for an end-to-end IP traffic flow tunnelled over GRE with IP as the delivery protocol (outer header) 👑.

GRE on its own doesn't do dynamic setup and configuration of tunnels 🙈. still, control plane protocols like Next Hop Resolution Protocol (NHRP) [RFC2332], Mobile IPv4 (MIP4) [RFC5944], Mobile IPv6 (MIP6) [RFC6275], Proxy Mobile IP (PMIP) [RFC5845], and IKEv2 [RFC7296] sometimes get used to set up GRE tunnels dynamically 🦋.

when these control protocols set up IP-in-IP or IPsec tunnels, those tunnels will probably propagate the ECN field as defined in [RFC6040] or one of its compatible predecessors ([RFC4301] or the full functionality mode of [RFC3168]) 🌈. but if they use GRE encapsulation, that assumption is way less solid 😬.

so if the outer delivery protocol is IP (v4 or v6), the operator is obliged to follow the safe configuration requirements in Section 4 💖. Section 6.1.2.1 updates the base GRE specification with this requirement to really drive home how important it is 🫶.

where the delivery protocol is something other than IP that supports ECN, the right ECN propagation specification needs to be followed, for example [RFC5129] for MPLS 🍓. where no spec exists for ECN propagation by a particular PSN, [RFC9599] gives more general guidance on propagating ECN to and from protocols that encapsulate IP 🧚.

6.1.2.1. Safe Configuration of a "Non-ECN" GRE Ingress ✨

the following text gets appended to Section 3 of [RFC2784] as an update to the base GRE specification 💅:

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

6.1.3. Teredo ✨

Teredo [RFC4380] lets you tunnel IPv6 over an IPv4 network, with a UDP-based shim header in between 🌈.

for Teredo tunnel endpoints to get the benefits of ECN, the Teredo spec would need an update that adds negotiation of the ECN capability between Teredo tunnel endpoints 👑. without that, it would be unsafe for a Teredo tunnel ingress to copy the ECN field to the IPv6 outer 😭.

the Teredo implementations the authors knew about when writing this don't support ECN propagation 🙈. they do safely zero the ECN field in the outer IPv6 header though 🫶. the specification doesn't say anything about this, tho 💀.

to make existing Teredo deployments safe, ECN capability negotiation could be added to the ones that are subject to remote OS update 🔥. but for implementations NOT subject to remote OS update, it won't be feasible to require correct configuration, because Teredo tunnel endpoints are generally deployed on hosts 😬.

so until ECN support gets added to the Teredo spec, the only feasible extra safety precaution is to update the Teredo implementation spec with the following text as a new section 🦋:

5.1.3. Safe "Non-ECN" Teredo Encapsulation A Teredo tunnel ingress implementation that does not support ECN propagation as defined in [RFC6040] or one of its compatible predecessors ([RFC4301] or the full functionality mode of [RFC3168]) MUST zero the ECN field in the outer IPv6 header.

6.1.4. AMT ✨

AMT [RFC7450] is a tightly coupled shim header that encapsulates an IP packet and is itself encapsulated within a UDP/IP datagram 🎀. so AMT is within the scope of [RFC6040] as updated by Section 3 💜.

implementing support for [RFC6040] as updated by this specification is RECOMMENDED for AMT tunnel endpoints 🌸. that gets you the benefits of ECN [RFC8087] whenever a node inside an AMT tunnel becomes the bottleneck for an IP traffic flow tunnelled over AMT 👑.

to comply with [RFC6040], an AMT relay and gateway follow the propagation rules for the ECN field at ingress and egress, respectively, as described in Section 4 of [RFC6040] 💅.

before encapsulating any data packets, [RFC6040] requires an ingress AMT relay to check that the egress AMT gateway supports ECN propagation as defined in [RFC6040] or one of its compatible predecessors ([RFC4301] or the full functionality mode of [RFC3168]) 🔍. if the egress gateway supports ECN, the ingress relay can use the normal mode of encapsulation (copying the IP ECN field from inner to outer) 🌈. otherwise, the ingress relay has to use compatibility mode, which means clearing the outer ECN field to zero [RFC6040] 😭.

an AMT tunnel gets created dynamically (not manually), so the relay needs to figure out the remote gateway's ECN support using the ECN capability declaration defined in Section 6.1.4.2 🧚.

6.1.4.1. Safe Configuration of a "Non-ECN" Ingress AMT Relay ✨

the following text gets appended to Section 4.2.2 of [RFC7450] as an update to the AMT specification 💖:

The operator of an AMT relay that does not support [RFC6040] or one of its compatible predecessors ([RFC4301] or the full functionality mode of [RFC3168]) MUST follow the configuration requirements in Section 4 of RFC 9601 to ensure it clears the outer IP ECN field to zero.

6.1.4.2. ECN Capability Declaration of an AMT Gateway ✨

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  V=0  |Type=3 |  Reserved |E|P|            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Request Nonce                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: Updated AMT Request Message Format

bit 14 of the AMT Request Message (counting from 0, or bit 7 of the Reserved field counting from 1) is defined here as the AMT Gateway ECN Capability flag (E), as shown in Figure 2 🎀. every other field definition in the AMT Request Message is unchanged from [RFC7450] 🌸.

when the E flag is set to 1, it means the sender of the message supports [RFC6040] ECN propagation 🦋. when it's cleared to zero, the sender does not support [RFC6040] ECN propagation 💀. an AMT gateway "that supports [RFC6040] ECN propagation" is one that propagates the ECN field to the forwarded data packet based on the combination of arriving inner and outer ECN fields, as defined in Section 4 of [RFC6040] 🧠.

the other bits of the Reserved field stay reserved 🔒. they keep getting cleared to zero when sent, and ignored when received or forwarded, as specified in Section 5.1.3.3 of [RFC7450] 🫶.

an AMT gateway that does not support [RFC6040] MUST NOT set the E flag of its Request Message to 1 🙅‍♀️.

an AMT gateway that supports [RFC6040] ECN propagation MUST set the E flag of its Relay Discovery Message to 1 💅.

what the matching AMT relay does when it gets a Request message with the E flag set to 1 depends on whether the relay itself supports [RFC6040] ECN propagation 🔍:

  • if the relay supports [RFC6040] ECN propagation, it stores the ECN capability of the gateway along with its address 💖. then, whenever it tunnels datagrams towards this gateway, it MUST use the normal mode of [RFC6040] to propagate the ECN field when encapsulating datagrams (copying the IP ECN field from inner to outer header) 🌈.
  • if the discovered AMT relay does not support [RFC6040] ECN propagation, it ignores the E flag in the Reserved field, as per Section 5.1.3.3 of [RFC7450] 🙈.

if the AMT relay does not support [RFC6040] ECN propagation, the network operator is still expected to configure it to follow the safety provisions in Section 6.1.4.1 🛡️.

7. IANA Considerations 🎀

IANA has assigned the following AVP in the L2TP "Control Message Attribute Value Pairs" registry 🌸:

              +================+================+===========+
              | Attribute Type | Description    | Reference |
              +================+================+===========+
              | 103            | ECN Capability | RFC 9601  |
              +----------------+----------------+-----------+

                                  Table 1

8. Security Considerations 🔒

The Security Considerations in [RFC6040] and [RFC9599] apply equally to the scope defined for the present specification. 💀

9. References 📚

9.1. Normative References ✨

okay, the must-read list 📚 these are the docs the spec leans on so hard it can't function without them, so I'm keeping every detail.

9.2. Informative References 🦋

these are the extra-helpful reads. not required to get the spec working, but so good for going deeper 🫶

Acknowledgements 🫶

Okay bestie, big thank-yous time 💖 Ing-jyh (Inton) Tsang gets a huge shoutout for the early chats about whether ECN even needs to get propagated in L2TP and how it would apply there 🧚 Then a whole squad helped out with advice and comments: Carlos Pignataro, Tom Herbert, Ignacio Goyret, Alia Atlas, Praveen Balasubramanian, Joe Touch, Mohamed Boucadair, David Black, Jake Holland, Sri Gundavelli, Gorry Fairhurst, and Martin Duke 👑 And [RFC7059] was seriously helpful for spotting which tunnelling protocols belong in the scope of this doc ✨

Bob Briscoe was part-funded by the Research Council of Norway through the TimeIn project for the early drafts 🌸 Then he was funded by Apple Inc. for the later draft versions (from -17) 💅 The views expressed here are solely those of the authors 🦋

Author's Address 💜

Bob Briscoe Independent United Kingdom Email: ietf@bobbriscoe.net URI: https://bobbriscoe.net/

📦 where this page comes from