diff options
Diffstat (limited to 'doc/rfc/rfc9601.txt')
| -rw-r--r-- | doc/rfc/rfc9601.txt | 1051 |
1 files changed, 1051 insertions, 0 deletions
diff --git a/doc/rfc/rfc9601.txt b/doc/rfc/rfc9601.txt new file mode 100644 index 0000000..8e4e827 --- /dev/null +++ b/doc/rfc/rfc9601.txt @@ -0,0 +1,1051 @@ + + + + +Internet Engineering Task Force (IETF) B. Briscoe +Request for Comments: 9601 Independent +Updates: 2661, 2784, 3931, 4380, 6040, 7450 August 2024 +Category: Standards Track +ISSN: 2070-1721 + + + Propagating Explicit Congestion Notification across IP Tunnel Headers + Separated by a Shim + +Abstract + + 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. This specification + updates RFC 6040 to clarify that its scope includes tunnels where two + IP headers are separated by at least one shim header that is not + sufficient on its own for wide-area packet forwarding. It surveys + widely deployed IP tunnelling protocols that use such shim headers + and updates the specifications of those that do not mention ECN + propagation (including RFCs 2661, 3931, 2784, 4380 and 7450, which + specify L2TPv2, L2TPv3, Generic Routing Encapsulation (GRE), Teredo, + and Automatic Multicast Tunneling (AMT), respectively). This + specification also updates RFC 6040 with configuration requirements + needed to make 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 represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9601. + +Copyright Notice + + 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) 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 Revised BSD License text as described in Section 4.e of the + Trust Legal Provisions and are provided without warranty as described + in the Revised BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate 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 + + [RFC6040] on "Tunnelling of Explicit Congestion Notification" made + the rules for propagation of Explicit Congestion Notification (ECN) + [RFC3168] consistent for all forms of IP-in-IP tunnel. + + A common pattern for many tunnelling protocols is to encapsulate an + inner IP header (v4 or v6) with one or more shim headers then an + outer IP header (v4 or v6). Some of these shim headers are designed + as generic encapsulations, so they do not necessarily directly + encapsulate an inner IP header. Instead, they can encapsulate + headers such as link-layer (L2) protocols that, in turn, often + encapsulate IP. Thus, the abbreviation 'IP-shim-(L2)-IP' can be used + for tunnels that are in scope of this document. + + To clear up confusion, this specification clarifies that the scope of + [RFC6040] includes any IP-in-IP tunnel, including those with one or + more shim headers and other encapsulations between the IP headers. + Where necessary, it updates the specifications of the relevant + encapsulation protocols with the specific text necessary to comply + with [RFC6040]. + + This specification also updates [RFC6040] to state how operators + ought to configure a legacy tunnel ingress to 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 specification uses the terminology defined in [RFC6040]. + +3. Scope of RFC 6040 + + In Section 1.1 of [RFC6040], its 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. + + There are two problems with the above scoping statement: + + Problem 1: It was intended to include cases where one or more shim + headers sit between the IP headers. Many tunnelling implementers + have interpreted the scope of [RFC6040] as it was intended, but it is + ambiguous. Therefore, this specification 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 a + specification that implementations can choose to claim compliance + with. This means it does not cover two important situations: + + 1. Cases where it is 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 + + However, 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. There is only one safe value a tunnel + ingress can use if it does not know whether the egress supports + propagation of the ECN field; it has to clear the ECN field in any + outer IP header to 0b00. + + However, an RFC has no jurisdiction over implementations that choose + not to comply or cannot comply with the RFC, including all + implementations that predated it. Therefore, it would have been + unreasonable to add such a requirement to [RFC6040]. Nonetheless, to + ensure safe propagation of the ECN field over tunnels, it is + reasonable to add requirements on operators to ensure they configure + their tunnels safely (where possible). Before resolving 'Problem 2' + by stating these configuration requirements (in Section 4), the + factors that determine whether propagating ECN is feasible or + desirable will be briefly introduced. + +3.1. Feasibility of ECN Propagation between Tunnel Headers + + In many cases, one or more shim headers and an outer IP header are + always 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 is not sufficient for packet forwarding in its own + right; not unless complemented by an outer header. In these cases, + it will often be feasible for an implementation to propagate the ECN + field between the IP headers. + + In some cases, a tunnel adds an outer IP header and a tightly coupled + shim header to an inner header that is not an IP header, but that, in + turn, encapsulates an IP header (or might encapsulate an IP header). + For instance, an inner Ethernet (or other link-layer) header might + encapsulate an inner IP header as its payload. We call this a + tightly coupled shim over an encapsulating header. + + Digging to arbitrary depths to find an inner IP header within an + encapsulation is strictly a layering violation, so it cannot be a + required behaviour. Nonetheless, some tunnel endpoints already look + within 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 such cases at least, it should be feasible + to also (independently) propagate the ECN field between the same IP + headers. Thus, access to the ECN field within an encapsulating + header can be a useful and benign optimization. The guidelines in + Section 5 of [RFC9599] give the conditions for this layering + violation to be benign. + +3.2. Desirability of ECN Propagation between Tunnel Headers + + Developers and network operators are encouraged to implement and + deploy tunnel endpoints compliant with [RFC6040] (as updated by the + present specification) in order to provide the benefits of wider ECN + deployment [RFC8087]. Nonetheless, propagation of ECN between IP + headers, whether separated by shim headers or not, has to be optional + to implement and to use, because: + + * legacy implementations of tunnels without any ECN support already + exist; + + * a network might be designed so that there is 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 + + Even when no specific attempt has been made to implement propagation + of the ECN field at a tunnel ingress, it ought to be possible for the + operator to render a tunnel ingress safe by configuration. The main + safety concern is to disable (clear to zero) the ECN capability in + the outer IP header at the ingress if the egress of the tunnel does + not implement ECN logic to propagate any ECN markings into the packet + forwarded beyond the tunnel. Otherwise, the non-ECN egress could + discard any ECN marking introduced within the tunnel, which would + break all the ECN-based control loops that regulate the traffic load + over the tunnel. + + 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. + +6. IP-in-IP Tunnels with Tightly Coupled Shim Headers + + Below is a list of specifications of encapsulations with tightly + coupled shim header(s) in rough chronological order. This list is + confined to Standards Track or widely deployed protocols. So, for + the avoidance of doubt, the updated scope of [RFC6040] is defined 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 enable encapsulation of a variety of + network layer protocols as inner and/or outer. 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, 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. + + 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]. + +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). + + 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 + + The ECN Capability AVP defined here has Attribute Type 103. The AVP + has the following format: + + 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. + This AVP MAY be hidden (the H-bit is set to 0 or 1) and is optional + (the M-bit is not set). The length (before hiding) of this AVP is 6 + octets. The Vendor ID is the IETF Vendor ID of 0. + + When an LCCE sends an ECN Capability AVP, it indicates that it + supports ECN propagation. When no ECN Capability AVP is present, it + indicates that the sender does not support ECN propagation. + + If an LCCE initiating a control connection supports ECN propagation, + it will send an SCCRQ containing an ECN Capability AVP. If the + tunnel terminator supports ECN, it will return an SCCRP that also + includes an ECN Capability AVP. Then, for any sessions created by + that control connection, both ends of the tunnel can use the normal + mode of [RFC6040]; i.e., they can copy the IP ECN field from inner to + outer when encapsulating data packets. + + On the other hand, if the tunnel terminator does not support ECN, it + will ignore the ECN Capability AVP and send an SCCRP to the tunnel + initiator without an ECN Capability AVP. The tunnel initiator + interprets the absence of the ECN Capability flag 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, the tunnel initiator will then use the + compatibility mode of [RFC6040] to clear the ECN field of the outer + IP header to 0b00. + + If the tunnel terminator does not support this ECN extension, the + network operator is still expected to configure it to comply with the + safety provisions set out in Section 6.1.1.1 when it acts as an + ingress LCCE. + + If ECN support by the ingress and egress LCCEs is configured + statically, as allowed in Section 6.1.1.2, they both ignore the + presence or absence of any ECN capability AVP. + +6.1.2. GRE + + The GRE terminology used here is defined in [RFC2784]. GRE is often + used as a tightly coupled shim header between IP headers. Sometimes, + the GRE shim header encapsulates an L2 header, which might in turn + encapsulate an IP header. Therefore, GRE is within the scope of + [RFC6040] as updated by Section 3. + + Implementation of support for [RFC6040] as updated by the present + specification is RECOMMENDED for GRE tunnel endpoints in order to + provide the benefits of ECN [RFC8087] whenever a node within a GRE + tunnel becomes the bottleneck for an end-to-end IP traffic flow + tunnelled over GRE using IP as the delivery protocol (outer header). + + GRE itself does not support dynamic setup and configuration of + tunnels. However, control plane protocols, such as Next Hop + Resolution Protocol (NHRP) [RFC2332], Mobile IPv4 (MIP4) [RFC5944], + Mobile IPv6 (MIP6) [RFC6275], Proxy Mobile IP (PMIP) [RFC5845], and + IKEv2 [RFC7296], are sometimes used to set up GRE tunnels + dynamically. + + When these control protocols set up IP-in-IP or IPsec tunnels, it is + likely that the resulting tunnels will propagate the ECN field as + defined in [RFC6040] or one of its compatible predecessors ([RFC4301] + or the full functionality mode of [RFC3168]). However, if they use a + GRE encapsulation, this presumption is less sound. + + Therefore, 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 emphasize its importance. + + Where the delivery protocol 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 more + general guidance on how to propagate ECN to and from protocols that + encapsulate IP. + +6.1.2.1. Safe Configuration of a "Non-ECN" GRE Ingress + + The following text is 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] provides a way to tunnel IPv6 over an IPv4 network + with a UDP-based shim header between the two. + + For Teredo tunnel endpoints to provide the benefits of ECN, the + Teredo specification would have to be updated to include negotiation + of the ECN capability between Teredo tunnel endpoints. Otherwise, it + would be unsafe for a Teredo tunnel ingress to copy the ECN field to + the IPv6 outer. + + Those implementations known to the authors at the time of writing do + not support propagation of ECN, but they do safely zero the ECN field + in the outer IPv6 header. However, the specification does not + mention anything about this. + + To make existing Teredo deployments safe, it would be possible to add + ECN capability negotiation to those that are subject to remote OS + update. However, for those implementations not subject to remote OS + update, it will not be feasible to require them to be configured + correctly because Teredo tunnel endpoints are generally deployed on + hosts. + + Therefore, until ECN support is added to the specification of Teredo, + the only feasible further safety precaution available here is to + update the specification of Teredo implementations 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 encapsulated within a UDP/IP datagram. Therefore, + AMT is within the scope of [RFC6040] as updated by Section 3. + + Implementation of support for [RFC6040] as updated by the present + specification is RECOMMENDED for AMT tunnel endpoints in order to + provide the benefits of ECN [RFC8087] whenever a node within an AMT + tunnel becomes the bottleneck for an IP traffic flow tunnelled over + AMT. + + To comply with [RFC6040], an AMT relay and gateway will follow the + rules for propagation of 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 it has to clear the outer ECN field to zero [RFC6040]. + + An AMT tunnel is created dynamically (not manually), so the relay + will need to determine the remote gateway's support for ECN 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 is 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. The definitions of all + other fields in the AMT Request Message are unchanged from [RFC7450]. + + When the E flag is set to 1, it indicates that the sender of the + message supports [RFC6040] ECN propagation. When it is cleared to + zero, it indicates the sender of the message does not support + [RFC6040] ECN propagation. An AMT gateway "that supports [RFC6040] + ECN propagation" means 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 remain reserved. They will + continue to be cleared to zero when sent and ignored when either + 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. + + The action of the corresponding AMT relay that receives 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 will store 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 (i.e., it copies the IP ECN field from + inner to outer header). + + * If the discovered AMT relay does not support [RFC6040] ECN + propagation, it will ignore 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 comply with + the safety provisions set out 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 + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, + "Definition of the Differentiated Services Field (DS + Field) in the IPv4 and IPv6 Headers", RFC 2474, + DOI 10.17487/RFC2474, December 1998, + <https://www.rfc-editor.org/info/rfc2474>. + + [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, + <https://www.rfc-editor.org/info/rfc2661>. + + [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. + Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, + DOI 10.17487/RFC2784, March 2000, + <https://www.rfc-editor.org/info/rfc2784>. + + [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, + <https://www.rfc-editor.org/info/rfc3168>. + + [RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., + "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", + RFC 3931, DOI 10.17487/RFC3931, March 2005, + <https://www.rfc-editor.org/info/rfc3931>. + + [RFC4301] Kent, S. and K. Seo, "Security Architecture for the + Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, + December 2005, <https://www.rfc-editor.org/info/rfc4301>. + + [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through + Network Address Translations (NATs)", RFC 4380, + DOI 10.17487/RFC4380, February 2006, + <https://www.rfc-editor.org/info/rfc4380>. + + [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion + Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January + 2008, <https://www.rfc-editor.org/info/rfc5129>. + + [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion + Notification", RFC 6040, DOI 10.17487/RFC6040, November + 2010, <https://www.rfc-editor.org/info/rfc6040>. + + [RFC6660] Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three + Pre-Congestion Notification (PCN) States in the IP Header + Using a Single Diffserv Codepoint (DSCP)", RFC 6660, + DOI 10.17487/RFC6660, July 2012, + <https://www.rfc-editor.org/info/rfc6660>. + + [RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, + DOI 10.17487/RFC7450, February 2015, + <https://www.rfc-editor.org/info/rfc7450>. + + [RFC9599] Briscoe, B. and J. Kaippallimalil, "Guidelines for Adding + Congestion Notification to Protocols that Encapsulate IP", + RFC 9599, DOI 10.17487/RFC9599, August 2024, + <https://www.rfc-editor.org/info/rfc9599>. + +9.2. Informative References + + [decap-test] + Briscoe, B., "A Test for IP-ECN Propagation by a Remote + Tunnel Endpoint", Technical Report, TR-BB-2023-003, + DOI 10.48550/arXiv.2311.16825, November 2023, + <https://arxiv.org/abs/2311.16825>. + + [GTPv1] 3GPP, "General Packet Radio Service (GPRS); GPRS + Tunnelling Protocol (GTP) across the Gn and Gp interface", + Technical Specification 29.060. + + [GTPv1-U] 3GPP, "General Packet Radio System (GPRS) Tunnelling + Protocol User Plane (GTPv1-U)", Technical + Specification 29.281. + + [GTPv2-C] 3GPP, "3GPP Evolved Packet System (EPS); Evolved General + Packet Radio Service (GPRS) Tunnelling Protocol for + Control plane (GTPv2-C); Stage 3", Technical + Specification 29.274. + + [INTAREA-TUNNELS] + Touch, J. D. and M. Townsley, "IP Tunnels in the Internet + Architecture", Work in Progress, Internet-Draft, draft- + ietf-intarea-tunnels-13, 26 March 2023, + <https://datatracker.ietf.org/doc/html/draft-ietf-intarea- + tunnels-13>. + + [NVO3-VXLAN-GPE] + Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol + Extension for VXLAN (VXLAN-GPE)", Work in Progress, + Internet-Draft, draft-ietf-nvo3-vxlan-gpe-13, 4 November + 2023, <https://datatracker.ietf.org/doc/html/draft-ietf- + nvo3-vxlan-gpe-13>. + + [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic + Routing Encapsulation (GRE)", RFC 1701, + DOI 10.17487/RFC1701, October 1994, + <https://www.rfc-editor.org/info/rfc1701>. + + [RFC2332] Luciani, J., Katz, D., Piscitello, D., Cole, B., and N. + Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)", + RFC 2332, DOI 10.17487/RFC2332, April 1998, + <https://www.rfc-editor.org/info/rfc2332>. + + [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, + <https://www.rfc-editor.org/info/rfc2637>. + + [RFC2983] Black, D., "Differentiated Services and Tunnels", + RFC 2983, DOI 10.17487/RFC2983, October 2000, + <https://www.rfc-editor.org/info/rfc2983>. + + [RFC3260] Grossman, D., "New Terminology and Clarifications for + Diffserv", RFC 3260, DOI 10.17487/RFC3260, April 2002, + <https://www.rfc-editor.org/info/rfc3260>. + + [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, + <https://www.rfc-editor.org/info/rfc3308>. + + [RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, + Ed., "Control And Provisioning of Wireless Access Points + (CAPWAP) Protocol Specification", RFC 5415, + DOI 10.17487/RFC5415, March 2009, + <https://www.rfc-editor.org/info/rfc5415>. + + [RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, + "Generic Routing Encapsulation (GRE) Key Option for Proxy + Mobile IPv6", RFC 5845, DOI 10.17487/RFC5845, June 2010, + <https://www.rfc-editor.org/info/rfc5845>. + + [RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", + RFC 5944, DOI 10.17487/RFC5944, November 2010, + <https://www.rfc-editor.org/info/rfc5944>. + + [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility + Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July + 2011, <https://www.rfc-editor.org/info/rfc6275>. + + [RFC7059] Steffann, S., van Beijnum, I., and R. van Rein, "A + Comparison of IPv6-over-IPv4 Tunnel Mechanisms", RFC 7059, + DOI 10.17487/RFC7059, November 2013, + <https://www.rfc-editor.org/info/rfc7059>. + + [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. + Kivinen, "Internet Key Exchange Protocol Version 2 + (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October + 2014, <https://www.rfc-editor.org/info/rfc7296>. + + [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, + <https://www.rfc-editor.org/info/rfc7348>. + + [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network + Virtualization Using Generic Routing Encapsulation", + RFC 7637, DOI 10.17487/RFC7637, September 2015, + <https://www.rfc-editor.org/info/rfc7637>. + + [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function + Chaining (SFC) Architecture", RFC 7665, + DOI 10.17487/RFC7665, October 2015, + <https://www.rfc-editor.org/info/rfc7665>. + + [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage + Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, + March 2017, <https://www.rfc-editor.org/info/rfc8085>. + + [RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using + Explicit Congestion Notification (ECN)", RFC 8087, + DOI 10.17487/RFC8087, March 2017, + <https://www.rfc-editor.org/info/rfc8087>. + + [RFC8159] Konstantynowicz, M., Ed., Heron, G., Ed., Schatzmayr, R., + and W. Henderickx, "Keyed IPv6 Tunnel", RFC 8159, + DOI 10.17487/RFC8159, May 2017, + <https://www.rfc-editor.org/info/rfc8159>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., + "Network Service Header (NSH)", RFC 8300, + DOI 10.17487/RFC8300, January 2018, + <https://www.rfc-editor.org/info/rfc8300>. + + [RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion + Notification (ECN) Experimentation", RFC 8311, + DOI 10.17487/RFC8311, January 2018, + <https://www.rfc-editor.org/info/rfc8311>. + + [RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed., + "Geneve: Generic Network Virtualization Encapsulation", + RFC 8926, DOI 10.17487/RFC8926, November 2020, + <https://www.rfc-editor.org/info/rfc8926>. + + [RFC9300] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. + Cabellos, Ed., "The Locator/ID Separation Protocol + (LISP)", RFC 9300, DOI 10.17487/RFC9300, October 2022, + <https://www.rfc-editor.org/info/rfc9300>. + + [RFC9329] Pauly, T. and V. Smyslov, "TCP Encapsulation of Internet + Key Exchange Protocol (IKE) and IPsec Packets", RFC 9329, + DOI 10.17487/RFC9329, November 2022, + <https://www.rfc-editor.org/info/rfc9329>. + + [RFC9331] De Schepper, K. and B. Briscoe, Ed., "The Explicit + Congestion Notification (ECN) Protocol for Low Latency, + Low Loss, and Scalable Throughput (L4S)", RFC 9331, + DOI 10.17487/RFC9331, January 2023, + <https://www.rfc-editor.org/info/rfc9331>. + + [SFC-NSH-ECN] + Eastlake 3rd, D., Briscoe, B., Zhuang, S., Malis, A., and + X. Wei, "Explicit Congestion Notification (ECN) and + Congestion Feedback Using the Network Service Header (NSH) + and IPFIX", Work in Progress, Internet-Draft, draft-ietf- + sfc-nsh-ecn-support-13, 15 April 2024, + <https://datatracker.ietf.org/doc/html/draft-ietf-sfc-nsh- + ecn-support-13>. + +Acknowledgements + + Thanks to Ing-jyh (Inton) Tsang for initial discussions on the need + for ECN propagation in L2TP and its applicability. Thanks also to + 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 for helpful + advice and comments. [RFC7059] helped to identify a number of + tunnelling protocols to include within the scope of this document. + + Bob Briscoe was part-funded by the Research Council of Norway through + the TimeIn project for early drafts, and he was funded by Apple Inc. + for 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/ |