rfc9601.original   rfc9601.txt 
Transport Area Working Group B. Briscoe Internet Engineering Task Force (IETF) B. Briscoe
Internet-Draft Independent Request for Comments: 9601 Independent
Updates: 6040, 2661, 2784, 3931, 4380, 7450 (if 5 December 2023 Updates: 6040, 2661, 2784, 3931, 4380, 7450 August 2024
approved) Category: Standards Track
Intended status: Standards Track ISSN: 2070-1721
Expires: 7 June 2024
Propagating Explicit Congestion Notification Across IP Tunnel Headers Propagating Explicit Congestion Notification across IP Tunnel Headers
Separated by a Shim Separated by a Shim
draft-ietf-tsvwg-rfc6040update-shim-23
Abstract Abstract
RFC 6040 on "Tunnelling of Explicit Congestion Notification" made the RFC 6040 on "Tunnelling of Explicit Congestion Notification" made the
rules for propagation of ECN consistent for all forms of IP in IP rules for propagation of Explicit Congestion Notification (ECN)
tunnel. This specification updates RFC 6040 to clarify that its consistent for all forms of IP-in-IP tunnel. This specification
scope includes tunnels where two IP headers are separated by at least updates RFC 6040 to clarify that its scope includes tunnels where two
one shim header that is not sufficient on its own for wide area IP headers are separated by at least one shim header that is not
packet forwarding. It surveys widely deployed IP tunnelling sufficient on its own for wide-area packet forwarding. It surveys
protocols that use such shim header(s) and updates the specifications widely deployed IP tunnelling protocols that use such shim headers
of those that do not mention ECN propagation (that is RFC 2661, RFC and updates the specifications of those that do not mention ECN
3931, RFC 2784, RFC 4380 and RFC 7450, which respectively specify propagation (including RFCs 2661, 3931, 2784, 4380 and 7450, which
L2TPv2, L2TPv3, GRE, Teredo and AMT). This specification also specify L2TPv2, L2TPv3, Generic Routing Encapsulation (GRE), Teredo,
updates RFC 6040 with configuration requirements needed to make any and Automatic Multicast Tunneling (AMT), respectively). This
legacy tunnel ingress safe. specification also updates RFC 6040 with configuration requirements
needed to make any legacy tunnel ingress safe.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 7 June 2024. 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 Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. 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 This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology
3. Scope of RFC 6040 . . . . . . . . . . . . . . . . . . . . . . 3 3. Scope of RFC 6040
3.1. Feasibility of ECN Propagation between Tunnel Headers . . 5 3.1. Feasibility of ECN Propagation between Tunnel Headers
3.2. Desirability of ECN Propagation between Tunnel Headers . 5 3.2. Desirability of ECN Propagation between Tunnel Headers
4. Making a non-ECN Tunnel Ingress Safe by Configuration . . . . 6 4. Making a Non-ECN Tunnel Ingress Safe by Configuration
5. ECN Propagation and Fragmentation/Reassembly . . . . . . . . 7 5. ECN Propagation and Fragmentation/Reassembly
6. IP-in-IP Tunnels with Tightly Coupled Shim Headers . . . . . 8 6. IP-in-IP Tunnels with Tightly Coupled Shim Headers
6.1. Specific Updates to Protocols under IETF Change 6.1. Specific Updates to Protocols under IETF Change Control
Control . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1.1. L2TP (v2 and v3) ECN Extension
6.1.1. L2TP (v2 and v3) ECN Extension . . . . . . . . . . . 11 6.1.2. GRE
6.1.2. GRE . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1.3. Teredo
6.1.3. Teredo . . . . . . . . . . . . . . . . . . . . . . . 15 6.1.4. AMT
6.1.4. AMT . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9. References
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 9.1. Normative References
9.1. Normative References . . . . . . . . . . . . . . . . . . 18 9.2. Informative References
9.2. Informative References . . . . . . . . . . . . . . . . . 19 Acknowledgements
Comments Solicited . . . . . . . . . . . . . . . . . . . . . . . 23 Author's Address
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
RFC 6040 on "Tunnelling of Explicit Congestion Notification" [RFC6040] on "Tunnelling of Explicit Congestion Notification" made
[RFC6040] made the rules for propagation of Explicit Congestion the rules for propagation of Explicit Congestion Notification (ECN)
Notification (ECN [RFC3168]) consistent for all forms of IP in IP [RFC3168] consistent for all forms of IP-in-IP tunnel.
tunnel.
A common pattern for many tunnelling protocols is to encapsulate an A common pattern for many tunnelling protocols is to encapsulate an
inner IP header (v4 or v6) with shim header(s) then an outer IP inner IP header (v4 or v6) with one or more shim headers then an
header (v4 or v6). Some of these shim headers are designed as outer IP header (v4 or v6). Some of these shim headers are designed
generic encapsulations, so they do not necessarily directly as generic encapsulations, so they do not necessarily directly
encapsulate an inner IP header. Instead, they can encapsulate encapsulate an inner IP header. Instead, they can encapsulate
headers such as link-layer (L2) protocols that in turn often headers such as link-layer (L2) protocols that, in turn, often
encapsulate IP. 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 To clear up confusion, this specification clarifies that the scope of
RFC 6040 includes any IP-in-IP tunnel, including those with shim [RFC6040] includes any IP-in-IP tunnel, including those with one or
header(s) and other encapsulations between the IP headers. Where more shim headers and other encapsulations between the IP headers.
necessary, it updates the specifications of the relevant Where necessary, it updates the specifications of the relevant
encapsulation protocols with the specific text necessary to comply encapsulation protocols with the specific text necessary to comply
with RFC 6040. with [RFC6040].
This specification also updates RFC 6040 to state how operators ought This specification also updates [RFC6040] to state how operators
to configure a legacy tunnel ingress to avoid unsafe system ought to configure a legacy tunnel ingress to avoid unsafe system
configurations. configurations.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This specification uses the terminology defined in RFC 6040 This specification uses the terminology defined in [RFC6040].
[RFC6040].
3. Scope of RFC 6040 3. Scope of RFC 6040
In section 1.1 of RFC 6040, its scope is defined as: In Section 1.1 of [RFC6040], its scope is defined as:
"...ECN field processing at encapsulation and decapsulation for | ...ECN field processing at encapsulation and decapsulation for any
any IP-in-IP tunnelling, whether IPsec or non-IPsec tunnels. It | IP-in-IP tunnelling, whether IPsec or non-IPsec tunnels. It
applies irrespective of whether IPv4 or IPv6 is used for either | applies irrespective of whether IPv4 or IPv6 is used for either
the inner or outer headers. ..." | the inner or outer headers.
This was intended to include cases where shim header(s) sit between There are two problems with the above scoping statement:
the IP headers. Many tunnelling implementers have interpreted the
scope of RFC 6040 as it was intended, but it is ambiguous.
Therefore, this specification updates RFC 6040 by adding the
following scoping text after the sentences quoted above:
It applies in cases where an outer IP header encapsulates an inner Problem 1: It was intended to include cases where one or more shim
IP header either directly or indirectly by encapsulating other headers sit between the IP headers. Many tunnelling implementers
headers that in turn encapsulate (or might encapsulate) an inner have interpreted the scope of [RFC6040] as it was intended, but it is
IP header. ambiguous. Therefore, this specification updates [RFC6040] by adding
the following scoping text after the sentences quoted above:
There is another problem with the scope of RFC 6040. Like many IETF | It applies in cases where an outer IP header encapsulates an inner
specifications, RFC 6040 is written as a specification that | IP header either directly or indirectly by encapsulating other
implementations can choose to claim compliance with. This means it | headers that in turn encapsulate (or might encapsulate) an inner
does not cover two important cases: | IP header.
1. those cases where it is infeasible for an implementation to Problem 2: Like many IETF specifications, [RFC6040] is written as a
access an inner IP header when adding or removing an outer IP specification that implementations can choose to claim compliance
header; with. This means it does not cover two important situations:
2. those implementations that choose not to propagate ECN between IP 1. Cases where it is infeasible for an implementation to access an
headers. 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 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 and v6), so any implementation that creates an outer IP header has to
to give the ECN field some value. There is only one safe value a give the ECN field some value. There is only one safe value a tunnel
tunnel ingress can use if it does not know whether the egress ingress can use if it does not know whether the egress supports
supports propagation of the ECN field; it has to clear the ECN field propagation of the ECN field; it has to clear the ECN field in any
in any outer IP header to 0b00. outer IP header to 0b00.
However, an RFC has no jurisdiction over implementations that choose However, an RFC has no jurisdiction over implementations that choose
not to comply with it or cannot comply with it, including all those not to comply or cannot comply with the RFC, including all
implementations that predated the RFC. Therefore, it would have been implementations that predated it. Therefore, it would have been
unreasonable to add such a requirement to RFC 6040. Nonetheless, to unreasonable to add such a requirement to [RFC6040]. Nonetheless, to
ensure safe propagation of the ECN field over tunnels, it is ensure safe propagation of the ECN field over tunnels, it is
reasonable to add requirements on operators, to ensure they configure reasonable to add requirements on operators to ensure they configure
their tunnels safely (where possible). Before stating these their tunnels safely (where possible). Before resolving 'Problem 2'
configuration requirements in Section 4, the factors that determine by stating these configuration requirements (in Section 4), the
whether propagating ECN is feasible or desirable will be briefly factors that determine whether propagating ECN is feasible or
introduced. desirable will be briefly introduced.
3.1. Feasibility of ECN Propagation between Tunnel Headers 3.1. Feasibility of ECN Propagation between Tunnel Headers
In many cases shim header(s) and an outer IP header are always added In many cases, one or more shim headers and an outer IP header are
to (or removed from) an inner IP packet as part of the same always added to (or removed from) an inner IP packet as part of the
procedure. We call this a tightly coupled shim header. Processing same procedure. We call these tightly coupled shim headers.
the shim and outer together is often necessary because the shim(s) Processing a shim and outer header together is often necessary
are not sufficient for packet forwarding in their own right; not because a shim is not sufficient for packet forwarding in its own
unless complemented by an outer header. In these cases it will often right; not unless complemented by an outer header. In these cases,
be feasible for an implementation to propagate the ECN field between it will often be feasible for an implementation to propagate the ECN
the IP headers. field between the IP headers.
In some cases a tunnel adds an outer IP header and a tightly coupled 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 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). turn, encapsulates an IP header (or might encapsulate an IP header).
For instance an inner Ethernet (or other link layer) header might For instance, an inner Ethernet (or other link-layer) header might
encapsulate an inner IP header as its payload. We call this a encapsulate an inner IP header as its payload. We call this a
tightly coupled shim over an encapsulating header. tightly coupled shim over an encapsulating header.
Digging to arbitrary depths to find an inner IP header within an Digging to arbitrary depths to find an inner IP header within an
encapsulation is strictly a layering violation so it cannot be a encapsulation is strictly a layering violation, so it cannot be a
required behaviour. Nonetheless, some tunnel endpoints already look required behaviour. Nonetheless, some tunnel endpoints already look
within a L2 header for an IP header, for instance to map the Diffserv within a Layer 2 (L2) header for an IP header, for instance, to map
codepoint between an encapsulated IP header and an outer IP header the Diffserv codepoint between an encapsulated IP header and an outer
[RFC2983]. In such cases at least, it should be feasible to also IP header [RFC2983]. In such cases at least, it should be feasible
(independently) propagate the ECN field between the same IP headers. to also (independently) propagate the ECN field between the same IP
Thus, access to the ECN field within an encapsulating header can be a headers. Thus, access to the ECN field within an encapsulating
useful and benign optimization. The guidelines in section 5 of header can be a useful and benign optimization. The guidelines in
[I-D.ietf-tsvwg-ecn-encap-guidelines] give the conditions for this Section 5 of [RFC9599] give the conditions for this layering
layering violation to be benign. violation to be benign.
3.2. Desirability of ECN Propagation between Tunnel Headers 3.2. Desirability of ECN Propagation between Tunnel Headers
Developers and network operators are encouraged to implement and Developers and network operators are encouraged to implement and
deploy tunnel endpoints compliant with RFC 6040 (as updated by the deploy tunnel endpoints compliant with [RFC6040] (as updated by the
present specification) in order to provide the benefits of wider ECN present specification) in order to provide the benefits of wider ECN
deployment [RFC8087]. Nonetheless, propagation of ECN between IP deployment [RFC8087]. Nonetheless, propagation of ECN between IP
headers, whether separated by shim headers or not, has to be optional headers, whether separated by shim headers or not, has to be optional
to implement and to use, because: to implement and to use, because:
* Legacy implementations of tunnels without any ECN support already * legacy implementations of tunnels without any ECN support already
exist exist;
* A network might be designed so that there is usually no bottleneck * a network might be designed so that there is usually no bottleneck
within the tunnel within the tunnel; and
* If the tunnel endpoints would have to search within an L2 header * if the tunnel endpoints would have to search within an L2 header
to find an encapsulated IP header, it might not be worth the to find an encapsulated IP header, it might not be worth the
potential performance hit. potential performance hit.
4. Making a non-ECN Tunnel Ingress Safe by Configuration 4. Making a Non-ECN Tunnel Ingress Safe by Configuration
Even when no specific attempt has been made to implement propagation 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 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 operator to render a tunnel ingress safe by configuration. The main
safety concern is to disable (clear to zero) the ECN capability in 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 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 not implement ECN logic to propagate any ECN markings into the packet
forwarded beyond the tunnel. Otherwise, the non-ECN egress could forwarded beyond the tunnel. Otherwise, the non-ECN egress could
discard any ECN marking introduced within the tunnel, which would discard any ECN marking introduced within the tunnel, which would
break all the ECN-based control loops that regulate the traffic load break all the ECN-based control loops that regulate the traffic load
over the tunnel. over the tunnel.
Therefore this specification updates RFC 6040 by inserting the Therefore, this specification updates Section 4.3 of [RFC6040] by
following text at the end of section 4.3: inserting the following text at the end of the section:
"
Whether or not an ingress implementation claims compliance with
RFC 6040, RFC 4301 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 any 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 (RFC 6040,
RFC 4301 or the full functionality mode of RFC 3168);
- or 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]);
- or 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, even if an implementation of a tunnel ingress does
not claim to support RFC 6040, RFC 4301 or the full functionality
mode of RFC 3168:
- it MUST NOT treat the former ToS octet (IPv4) or the former
Traffic Class octet (IPv6) as a single 8-bit field, as the
resulting linkage of ECN and Diffserv field propagation between
inner and outer is not consistent with the definition of the
6-bit Diffserv field in [RFC2474] and [RFC3260];
- it SHOULD be able to be configured to zero the ECN field of the
outer header.
" | 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 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 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 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 also being able to allow the DSCP to be re-mapped independently, that
would be sufficient to satisfy both the above implementation would be sufficient to satisfy both implementation requirements
requirements. above.
There might be concern that the above "MUST NOT" makes compliant There might be concern that the above "MUST NOT" makes compliant
implementations non-compliant at a stroke. However, by definition it implementations non-compliant at a stroke. However, by definition,
solely applies to equipment that provides Diffserv configuration. it solely applies to equipment that provides Diffserv configuration.
Any such Diffserv equipment that is configuring treatment of the Any such Diffserv equipment that is configuring treatment of the
former ToS octet (IPv4) or the former Traffic Class octet (IPv6) as a 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 single 8-bit field must have always been non-compliant with the
definition of the 6-bit Diffserv field in [RFC2474] and [RFC3260]. definition of the 6-bit Diffserv field in [RFC2474] and [RFC3260].
If a tunnel ingress does not have any ECN logic, copying the ECN 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 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 that risks breaking the feedback loops that regulate load on a
tunnel. 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 Zeroing the outer ECN field of all packets in all circumstances would
be safe, but it would not be sufficient to claim compliance with RFC be safe, but it would not be sufficient to claim compliance with
6040 because it would not meet the aim of introducing ECN support to [RFC6040] because it would not meet the aim of introducing ECN
tunnels (see Section 4.3 of [RFC6040]). support to tunnels (see Section 4.3 of [RFC6040]).
5. ECN Propagation and Fragmentation/Reassembly 5. ECN Propagation and Fragmentation/Reassembly
The following requirements update RFC6040, which omitted handling of The following requirements update [RFC6040], which omitted handling
the ECN field during fragmentation or reassembly. These changes of the ECN field during fragmentation or reassembly. These changes
might alter how many ECN-marked packets are propagated by a tunnel might alter how many ECN-marked packets are propagated by a tunnel
that fragments packets, but this would not raise any backward that fragments packets, but this would not raise any backward
compatibility issues: compatibility issues.
If a tunnel ingress fragments a packet, it MUST set the outer ECN 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 field of all the fragments to the same value as it would have set if
it had not fragmented the packet. it had not fragmented the packet.
Section 5.3 of [RFC3168] specifies ECN requirements for reassembly of Section 5.3 of [RFC3168] specifies ECN requirements for reassembly of
sets of outer fragments into packets (in outer fragmentation, the sets of 'outer fragments' into packets (in 'outer fragmentation', the
fragmentation is visible in the outer header so that the tunnel fragmentation is visible in the outer header so that the tunnel
egress can reassemble the fragments [I-D.ietf-intarea-tunnels]). The egress can reassemble the fragments [INTAREA-TUNNELS]).
following two additional requirements apply at a tunnel egress: Additionally, the following requirements apply at a tunnel egress:
* During reassembly of outer fragments, if the ECN fields of the * During reassembly of outer fragments, the packet MUST be discarded
outer headers being reassembled into a single packet consist of a if the ECN fields of the outer headers being reassembled into a
mixture of Not-ECT and other ECN codepoints, the packet MUST be single packet consist of a mixture of Not ECN-Capable Transport
discarded. (Not-ECT) and other ECN codepoints.
* If there is mix of ECT(0) and ECT(1) outer fragments, then the * If there is mix of ECT(0) and ECT(1) outer fragments, then the
reassembled packet MUST be set to ECT(1). reassembled packet MUST be set to ECT(1).
Reasoning: Originally [RFC3168] defined ECT(0) and ECT(1) as Reasoning: [RFC3168] originally defined ECT(0) and ECT(1) as
equivalent, but RFC 3168 has been updated by [RFC8311] to make equivalent, but [RFC3168] has been updated by [RFC8311] to make
ECT(1) available for congestion marking differences. The rule is ECT(1) available for congestion marking differences. The rule is
independent of the current experimental use of ECT(1) for L4S independent of the current experimental use of ECT(1) for Low
[RFC9331]. The rule is compatible with PCN [RFC6660], which uses Latency, Low Loss, and Scalable throughput (L4S) [RFC9331]. The
2 levels of congestion severity, with the ranking of severity from rule is compatible with Pre-Congestion Notification (PCN)
highest to lowest being CE, ECT(1), ECT(0)). The decapsulation [RFC6660], which uses 2 levels of congestion severity, with the
rules in [RFC6040] take a similar approach. 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 6. IP-in-IP Tunnels with Tightly Coupled Shim Headers
There follows a list of specifications of encapsulations with tightly Below is a list of specifications of encapsulations with tightly
coupled shim header(s), in rough chronological order. The list is coupled shim header(s) in rough chronological order. This list is
confined to standards track or widely deployed protocols. The list confined to Standards Track or widely deployed protocols. So, for
is not necessarily exhaustive so, for the avoidance of doubt, the the avoidance of doubt, the updated scope of [RFC6040] is defined in
scope of RFC 6040 is defined in Section 3 and is not limited to this Section 3 and is not limited to this list.
list.
* PPTP (Point-to-Point Tunneling Protocol) [RFC2637]; * Point-to-Point Tunneling Protocol (PPTP) [RFC2637]
* L2TP (Layer 2 Tunnelling Protocol), specifically L2TPv2 [RFC2661] * Layer Two Tunneling Protocol (L2TP), specifically L2TPv2 [RFC2661]
and L2TPv3 [RFC3931], which not only includes all the L2-specific and L2TPv3 [RFC3931], which not only includes all the L2-specific
specializations of L2TP, but also derivatives such as the Keyed specializations of L2TP, but also derivatives such as the Keyed
IPv6 Tunnel [RFC8159]; IPv6 Tunnel [RFC8159]
* GRE (Generic Routing Encapsulation) [RFC2784] and NVGRE (Network * Generic Routing Encapsulation (GRE) [RFC2784] and Network
Virtualization using GRE) [RFC7637]; Virtualization using GRE (NVGRE) [RFC7637]
* GTP (GPRS Tunnelling Protocol), specifically GTPv1 [GTPv1], GTP v1 * GPRS Tunnelling Protocol (GTP), specifically GTPv1 [GTPv1], GTP v1
User Plane [GTPv1-U], GTP v2 Control Plane [GTPv2-C]; User Plane [GTPv1-U], and GTP v2 Control Plane [GTPv2-C]
* Teredo [RFC4380]; * Teredo [RFC4380]
* CAPWAP (Control And Provisioning of Wireless Access Points)
[RFC5415];
* LISP (Locator/Identifier Separation Protocol) [RFC9300]; * Control And Provisioning of Wireless Access Points (CAPWAP)
[RFC5415]
* AMT (Automatic Multicast Tunneling) [RFC7450]; * Locator/Identifier Separation Protocol (LISP) [RFC9300]
* VXLAN (Virtual eXtensible Local Area Network) [RFC7348] and VXLAN- * Automatic Multicast Tunneling (AMT) [RFC7450]
GPE [I-D.ietf-nvo3-vxlan-gpe];
* The Network Service Header (NSH [RFC8300]) for Service Function * Virtual eXtensible Local Area Network (VXLAN) [RFC7348] and
Chaining (SFC); Generic Protocol Extensions for VXLAN (VXLAN-GPE) [NVO3-VXLAN-GPE]
* Geneve [RFC8926]; * 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 * Direct tunnelling of an IP packet within a UDP/IP datagram (see
Section 3.1.11 of [RFC8085]); Section 3.1.11 of [RFC8085])
* TCP Encapsulation of IKE and IPsec Packets (see Section 9.5 of * TCP Encapsulation of Internet Key Exchange Protocol (IKE) and
[RFC9329]). IPsec Packets (see Section 9.5 of [RFC9329])
Some of the listed protocols enable encapsulation of a variety of Some of the listed protocols enable encapsulation of a variety of
network layer protocols as inner and/or outer. This specification network layer protocols as inner and/or outer. This specification
applies in the cases where there is an inner and outer IP header as applies to the cases where there is an inner and outer IP header as
described in Section 3. Otherwise described in Section 3. Otherwise, [RFC9599] gives guidance on how
[I-D.ietf-tsvwg-ecn-encap-guidelines] gives guidance on how to design to design propagation of ECN into other protocols that might
propagation of ECN into other protocols that might encapsulate IP. encapsulate IP.
Where protocols in the above list need to be updated to specify ECN Where protocols in the above list need to be updated to specify ECN
propagation and they are under IETF change control, update text is propagation and are under IETF change control, update text is given
given in the following subsections. For those not under IETF in the following subsections. For those not under IETF control, it
control, it is RECOMMENDED that implementations of encapsulation and is RECOMMENDED that implementations of encapsulation and
decapsulation comply with RFC 6040. It is also RECOMMENDED that decapsulation comply with [RFC6040]. It is also RECOMMENDED that
their specifications are updated to add a requirement to comply with their specifications are updated to add a requirement to comply with
RFC 6040 (as updated by the present document). [RFC6040] (as updated by the present document).
PPTP is not under the change control of the IETF, but it has been PPTP is not under the change control of the IETF, but it has been
documented in an informational RFC [RFC2637]. However, there is no documented in an Informational RFC [RFC2637]. However, there is no
need for the present specification to update PPTP because L2TP has need for the present specification to update PPTP because L2TP has
been developed as a standardized replacement. been developed as a standardized replacement.
NVGRE is not under the change control of the IETF, but it has been NVGRE is not under the change control of the IETF, but it has been
documented in an informational RFC [RFC7637]. NVGRE is a specific documented in an Informational RFC [RFC7637]. NVGRE is a specific
use-case of GRE (it re-purposes the key field from the initial use case of GRE (it re-purposes the key field from the initial
specification of GRE [RFC1701] as a Virtual Subnet ID). Therefore 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 the text that updates GRE in Section 6.1.2 below is also intended to
update NVGRE. update NVGRE.
Although the definition of the various GTP shim headers is under the Although the definition of the various GTP shim headers is under the
control of the 3rd Generation Partnership Project (3GPP), it is hard control of the Third Generation Partnership Project (3GPP), it is
to determine whether the 3GPP or the IETF controls standardization of hard to determine whether the 3GPP or the IETF controls
the _process_ of adding both a GTP and an IP header to an inner IP standardization of the _process_ of adding both a GTP and an IP
header. Nonetheless, the present specification is provided so that header to an inner IP header. Nonetheless, the present specification
the 3GPP can refer to it from any of its own specifications of GTP is provided so that the 3GPP can refer to it from any of its own
and IP header processing. specifications of GTP and IP header processing.
The specification of CAPWAP already specifies RFC 3168 ECN The specification of CAPWAP already specifies [RFC3168] ECN
propagation and ECN capability negotiation. Without modification the propagation and ECN capability negotiation. Without modification,
CAPWAP specification already interworks with the backward compatible the CAPWAP specification already interworks with the backward-
updates to RFC 3168 in RFC 6040. compatible updates to [RFC3168] in [RFC6040].
LISP made the ECN propagation procedures in RFC 3168 mandatory from LISP made the ECN propagation procedures in [RFC3168] mandatory from
the start. RFC 3168 has since been updated by RFC 6040, but the the start. [RFC3168] has since been updated by [RFC6040], but the
changes are backwards compatible so there is still no need for LISP changes are backwards compatible, so there is still no need for LISP
tunnel endpoints to negotiate their ECN capabilities. tunnel endpoints to negotiate their ECN capabilities.
VXLAN is not under the change control of the IETF but it has been VXLAN is not under the change control of the IETF, but it has been
documented in an informational RFC. In contrast, VXLAN-GPE (Generic documented in an Informational RFC. It is RECOMMENDED that VXLAN
Protocol Extension) is being documented under IETF change control. implementations comply with [RFC6040] when the VXLAN header is
It is RECOMMENDED that VXLAN and VXLAN-GPE implementations comply inserted between (or removed from between) IP headers. The authors
with RFC 6040 when the VXLAN header is inserted between (or removed of any future update of the VXLAN spec are also encouraged to add a
from between) IP headers. The authors of any future update to these requirement to comply with [RFC6040] as updated by the present
specifications are encouraged to add a requirement to comply with RFC specification. In contrast, VXLAN-GPE is being documented under IETF
6040 as updated by the present specification. change control and it does require compliance with [RFC6040].
The Network Service Header (NSH [RFC8300]) has been defined as a The Network Service Header (NSH) [RFC8300] has been defined as a
shim-based encapsulation to identify the Service Function Path (SFP) shim-based encapsulation to identify the Service Function Path (SFP)
in the Service Function Chaining (SFC) architecture [RFC7665]. A in the Service Function Chaining (SFC) architecture [RFC7665]. A
proposal has been made for the processing of ECN when handling proposal has been made for the processing of ECN when handling
transport encapsulation [I-D.ietf-sfc-nsh-ecn-support]. transport encapsulation [SFC-NSH-ECN].
The specification of Geneve already refers to RFC 6040 for ECN The specification of Geneve already refers to [RFC6040] for ECN
encapsulation. encapsulation.
Section 3.1.11 of RFC 8085 already explains that a tunnel that Section 3.1.11 of [RFC8085] already explains that a tunnel that
encapsulates an IP header within a UDP/IP datagram needs to follow encapsulates an IP header within a UDP/IP datagram needs to follow
RFC 6040 when propagating the ECN field between inner and outer IP [RFC6040] when propagating the ECN field between inner and outer IP
headers. Section 3 of the present specification updates RFC 6040 to headers. Section 3 of the present specification updates [RFC6040] to
clarify that its scope includes cases with a shim header between the clarify that its scope includes cases with a shim header between the
IP headers. So it indirectly updates the scope of RFC 8085 to 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 include cases with a shim header as well as a UDP header between the
IP headers. IP headers.
The requirements in Section 4 update RFC 6040, and hence indirectly The requirements in Section 4 update [RFC6040], and hence also
update the UDP usage guidelines in RFC 8085 to add the important but indirectly update the UDP usage guidelines in [RFC8085] to add the
previously unstated requirement that, if the UDP tunnel egress does important but previously unstated requirement that, if the UDP tunnel
not, or might not, support ECN propagation, a UDP tunnel ingress has egress does not, or might not, support ECN propagation, a UDP tunnel
to clear the outer IP ECN field to 0b00, e.g. by configuration. ingress has to clear the outer IP ECN field to 0b00, e.g., by
configuration.
Section 9.5 of TCP Encapsulation of IKE and IPsec Packets [RFC9329] Section 9.5 of [RFC9329] already recommends the compatibility mode of
already recommends the compatibility mode of RFC 6040 in this case, [RFC6040] in this case because there is not a one-to-one mapping
because there is not a one-to-one mapping between inner and outer between inner and outer packets when TCP encapsulates IKE or IPsec.
packets.
6.1. Specific Updates to Protocols under IETF Change Control 6.1. Specific Updates to Protocols under IETF Change Control
6.1.1. L2TP (v2 and v3) ECN Extension 6.1.1. L2TP (v2 and v3) ECN Extension
The L2TP terminology used here is defined in [RFC2661] and [RFC3931]. The L2TP terminology used here is defined in [RFC2661] and [RFC3931].
L2TPv3 [RFC3931] is used as a shim header between any packet-switched L2TPv3 [RFC3931] is used as a shim header between any packet-switched
network (PSN) header (e.g. IPv4, IPv6, MPLS) and many types of layer network (PSN) header (e.g., IPv4, IPv6, and MPLS) and many types of
2 (L2) header. The L2TPv3 shim header encapsulates an L2-specific L2 headers. The L2TPv3 shim header encapsulates an L2-specific sub-
sub-layer then an L2 header that is likely to contain an inner IP layer, then an L2 header that is likely to contain an inner IP header
header (v4 or v6). Then this whole stack of headers can be (v4 or v6). Then this whole stack of headers can be encapsulated
encapsulated optionally within an outer UDP header then an outer PSN within an optional outer UDP header and an outer PSN header that is
header that is typically IP (v4 or v6). typically IP (v4 or v6).
L2TPv2 is used as a shim header between any PSN header and a PPP 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. header, which is in turn likely to encapsulate an IP header.
Even though these shims are rather fat (particularly in the case of Even though these shims are rather fat (particularly in the case of
L2TPv3), they still fit the definition of a tightly coupled shim L2TPv3), they still fit the definition of a tightly coupled shim
header over an encapsulating header (Section 3.1), because all the header over an encapsulating header (Section 3.1) because all the
headers encapsulating the L2 header are added (or removed) together. headers encapsulating the L2 header are added (or removed) together.
L2TPv2 and L2TPv3 are therefore within the scope of RFC 6040, as L2TPv2 and L2TPv3 are therefore within the scope of [RFC6040], as
updated by Section 3 above. updated by Section 3.
Implementation of the ECN extension to L2TPv2 and L2TPv3 defined in Implementation of the ECN extension to L2TPv2 and L2TPv3 defined in
Section 6.1.1.2 below is RECOMMENDED, in order to provide the Section 6.1.1.2 is RECOMMENDED in order to provide the benefits of
benefits of ECN [RFC8087], whenever a node within an L2TP tunnel ECN [RFC8087] whenever a node within an L2TP tunnel becomes the
becomes the bottleneck for an end-to-end traffic flow. bottleneck for an end-to-end traffic flow.
6.1.1.1. Safe Configuration of a 'Non-ECN' Ingress LCCE 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 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 Section 4.5 of [RFC3931] as an update to the base L2TPv2 and L2TPv3
specifications: specifications:
The operator of an LCCE that does not support the ECN Extension in | The operator of an LCCE that does not support the ECN extension in
Section 6.1.1.2 of [this document] MUST follow the configuration | Section 6.1.1.2 of RFC 9601 MUST follow the configuration
requirements in Section 4 of [this document] to ensure it clears | requirements in Section 4 of RFC 9601 to ensure it clears the
the outer IP ECN field to 0b00 when the outer PSN header is IP (v4 | outer IP ECN field to 0b00 when the outer PSN header is IP (v4 or
or v6). | v6).
In particular, for an L2TP Control Connection Endpoint (LCCE) In particular, for an L2TP Control Connection Endpoint (LCCE)
implementation that does not support the ECN Extension, this means implementation that does not support the ECN extension, this means
that configuration of how it propagates the ECN field between inner that configuration of how it propagates the ECN field between inner
and outer IP headers MUST be independent of any configuration of the and outer IP headers MUST be independent of any configuration of the
Diffserv extension of L2TP [RFC3308]. Diffserv extension of L2TP [RFC3308].
6.1.1.2. ECN Extension for L2TP (v2 or v3) 6.1.1.2. ECN Extension for L2TP (v2 or v3)
When the outer PSN header and the payload inside the L2 header are When the outer PSN header and the payload inside the L2 header are
both IP (v4 or v6), to comply with RFC 6040, an LCCE will follow the both IP (v4 or v6), an LCCE will propagate the ECN field at ingress
rules for propagation of the ECN field at ingress and egress in and egress by following the rules in Section 4 of [RFC6040].
Section 4 of RFC 6040 [RFC6040].
Before encapsulating any data packets, RFC 6040 requires an ingress Before encapsulating any data packets, [RFC6040] requires an ingress
LCCE to check that the egress LCCE supports ECN propagation as LCCE to check that the egress LCCE supports ECN propagation as
defined in RFC 6040 or one of its compatible predecessors ([RFC4301] defined in [RFC6040] or one of its compatible predecessors ([RFC4301]
or the full functionality mode of [RFC3168]). If the egress supports or the full functionality mode of [RFC3168]). If the egress supports
ECN propagation, the ingress LCCE can use the normal mode of ECN propagation, the ingress LCCE can use the normal mode of
encapsulation (copying the ECN field from inner to outer). encapsulation (copying the ECN field from inner to outer).
Otherwise, the ingress LCCE has to use compatibility mode [RFC6040] Otherwise, the ingress LCCE has to use compatibility mode [RFC6040]
(clearing the outer IP ECN field to 0b00). (clearing the outer IP ECN field to 0b00).
An LCCE can determine the remote LCCE's support for ECN either An LCCE can determine the remote LCCE's support for ECN either
statically (by configuration) or by dynamic discovery during setup of statically (by configuration) or by dynamic discovery during setup of
each control connection between the LCCEs, using the ECN Capability each control connection between the LCCEs using the ECN Capability
AVP defined in Section 6.1.1.2.1 below. Attribute-Value Pair (AVP) defined in Section 6.1.1.2.1.
Where the outer PSN header is some protocol other than IP that Where the outer PSN header is some protocol other than IP that
supports ECN, the appropriate ECN propagation specification will need supports ECN, the appropriate ECN propagation specification will need
to be followed, e.g. "Explicit Congestion Marking in MPLS" [RFC5129]. to be followed, e.g., [RFC5129] for MPLS. Where no specification
Where no specification exists for ECN propagation by a particular exists for ECN propagation by a particular PSN, [RFC9599] gives
PSN, [I-D.ietf-tsvwg-ecn-encap-guidelines] gives general guidance on general guidance on how to design ECN propagation into a protocol
how to design ECN propagation into a protocol that encapsulates IP. that encapsulates IP.
6.1.1.2.1. ECN Capability AVP for Negotiation between LCCEs 6.1.1.2.1. ECN Capability AVP for Negotiation between LCCEs
The ECN Capability Attribute-Value Pair (AVP) defined here has The ECN Capability AVP defined here has Attribute Type 103. The AVP
Attribute Type TBD. The AVP has the following format: has the following format:
0 1 2 3 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 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 | |M|H|0|0|0|0| Length | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD | | 103 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ECN Capability Attribute Value Pair for L2TP (v2 or v3) Figure 1: ECN Capability AVP for L2TP (v2 or v3)
This AVP MAY be present in the following message types: SCCRQ and This AVP MAY be present in the Start-Control-Connection-Request
SCCRP (Start-Control-Connection-Request and Start-Control-Connection- (SCCRQ) and Start-Control-Connection-Reply (SCCRP) message types.
Reply). This AVP MAY be hidden (the H-bit set to 0 or 1) and is This AVP MAY be hidden (the H-bit is set to 0 or 1) and is optional
optional (M-bit not set). The length (before hiding) of this AVP is (the M-bit is not set). The length (before hiding) of this AVP is 6
6 octets. The Vendor ID is the IETF Vendor ID of 0. octets. The Vendor ID is the IETF Vendor ID of 0.
When an LCCE sends an ECN Capability AVP, it indicates that it When an LCCE sends an ECN Capability AVP, it indicates that it
supports ECN propagation. When no ECN Capability AVP is present, it supports ECN propagation. When no ECN Capability AVP is present, it
indicates that the sender does not support ECN propagation. indicates that the sender does not support ECN propagation.
If an LCCE initiating a control connection supports ECN propagation, If an LCCE initiating a control connection supports ECN propagation,
it will send a Start-Control-Connection-Request (SCCRQ) containing an it will send an SCCRQ containing an ECN Capability AVP. If the
ECN Capability AVP. If the tunnel terminator supports ECN, it will tunnel terminator supports ECN, it will return an SCCRP that also
return a Start-Control-Connection-Reply (SCCRP) that also includes an includes an ECN Capability AVP. Then, for any sessions created by
ECN Capability AVP. Then, for any sessions created by that control that control connection, both ends of the tunnel can use the normal
connection, both ends of the tunnel can use the normal mode of RFC mode of [RFC6040]; i.e., they can copy the IP ECN field from inner to
6040, i.e. they can copy the IP ECN field from inner to outer when outer when encapsulating data packets.
encapsulating data packets.
If, on the other hand, the tunnel terminator does not support ECN it 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 will ignore the ECN Capability AVP and send an SCCRP to the tunnel
initiator without an ECN Capability AVP. The tunnel initiator initiator without an ECN Capability AVP. The tunnel initiator
interprets the absence of the ECN Capability flag in the SCCRP as an interprets the absence of the ECN Capability flag in the SCCRP as an
indication that the tunnel terminator is incapable of supporting ECN. indication that the tunnel terminator is incapable of supporting ECN.
When encapsulating data packets for any sessions created by that When encapsulating data packets for any sessions created by that
control connection, the tunnel initiator will then use the control connection, the tunnel initiator will then use the
compatibility mode of RFC 6040 to clear the ECN field of the outer IP compatibility mode of [RFC6040] to clear the ECN field of the outer
header to 0b00. IP header to 0b00.
If the tunnel terminator does not support this ECN extension, the If the tunnel terminator does not support this ECN extension, the
network operator is still expected to configure it to comply with the network operator is still expected to configure it to comply with the
safety provisions set out in Section 6.1.1.1 above, when it acts as safety provisions set out in Section 6.1.1.1 when it acts as an
an ingress LCCE. 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 6.1.2. GRE
The GRE terminology used here is defined in [RFC2784]. GRE is often The GRE terminology used here is defined in [RFC2784]. GRE is often
used as a tightly coupled shim header between IP headers. Sometimes used as a tightly coupled shim header between IP headers. Sometimes,
the GRE shim header encapsulates an L2 header, which might in turn the GRE shim header encapsulates an L2 header, which might in turn
encapsulate an IP header. Therefore GRE is within the scope of RFC encapsulate an IP header. Therefore, GRE is within the scope of
6040 as updated by Section 3 above. [RFC6040] as updated by Section 3.
Implementation of support for [RFC6040] as updated by the present Implementation of support for [RFC6040] as updated by the present
specification is RECOMMENDED for GRE tunnel endpoints, in order to specification is RECOMMENDED for GRE tunnel endpoints in order to
provide the benefits of ECN [RFC8087] whenever a node within a GRE provide the benefits of ECN [RFC8087] whenever a node within a GRE
tunnel becomes the bottleneck for an end-to-end IP traffic flow tunnel becomes the bottleneck for an end-to-end IP traffic flow
tunnelled over GRE using IP as the delivery protocol (outer header). tunnelled over GRE using IP as the delivery protocol (outer header).
GRE itself does not support dynamic set-up and configuration of GRE itself does not support dynamic setup and configuration of
tunnels. However, control plane protocols such as Next Hop tunnels. However, control plane protocols, such as Next Hop
Resolution Protocol (NHRP) [RFC2332], Mobile IPv4 (MIP4) [RFC5944], Resolution Protocol (NHRP) [RFC2332], Mobile IPv4 (MIP4) [RFC5944],
Mobile IPv6 (MIP6) [RFC6275], Proxy Mobile IP (PMIP) [RFC5845] and Mobile IPv6 (MIP6) [RFC6275], Proxy Mobile IP (PMIP) [RFC5845], and
IKEv2 [RFC7296] are sometimes used to set up GRE tunnels dynamically. 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 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 likely that the resulting tunnels will propagate the ECN field as
defined in RFC 6040 or one of its compatible predecessors (RFC 4301 defined in [RFC6040] or one of its compatible predecessors ([RFC4301]
or the full functionality mode of RFC 3168). However, if they use a or the full functionality mode of [RFC3168]). However, if they use a
GRE encapsulation, this presumption is less sound. GRE encapsulation, this presumption is less sound.
Therefore, if the outer delivery protocol is IP (v4 or v6) the Therefore, if the outer delivery protocol is IP (v4 or v6), the
operator is obliged to follow the safe configuration requirements in operator is obliged to follow the safe configuration requirements in
Section 4 above. Section 6.1.2.1 below updates the base GRE Section 4. Section 6.1.2.1 updates the base GRE specification with
specification with this requirement, to emphasize its importance. this requirement to emphasize its importance.
Where the delivery protocol is some protocol other than IP that Where the delivery protocol is some protocol other than IP that
supports ECN, the appropriate ECN propagation specification will need supports ECN, the appropriate ECN propagation specification will need
to be followed, e.g. Explicit Congestion Marking in MPLS [RFC5129]. to be followed, e.g., [RFC5129] for MPLS. Where no specification
Where no specification exists for ECN propagation by a particular exists for ECN propagation by a particular PSN, [RFC9599] gives more
PSN, [I-D.ietf-tsvwg-ecn-encap-guidelines] gives more general general guidance on how to propagate ECN to and from protocols that
guidance on how to propagate ECN to and from protocols that
encapsulate IP. encapsulate IP.
6.1.2.1. Safe Configuration of a 'Non-ECN' GRE Ingress 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 The following text is appended to Section 3 of [RFC2784] as an update
to the base GRE specification: to the base GRE specification:
The operator of a GRE tunnel ingress MUST follow the configuration | The operator of a GRE tunnel ingress MUST follow the configuration
requirements in Section 4 of [this document] when the outer | requirements in Section 4 of RFC 9601 when the outer delivery
delivery protocol is IP (v4 or v6). | protocol is IP (v4 or v6).
6.1.3. Teredo 6.1.3. Teredo
Teredo [RFC4380] provides a way to tunnel IPv6 over an IPv4 network, Teredo [RFC4380] provides a way to tunnel IPv6 over an IPv4 network
with a UDP-based shim header between the two. with a UDP-based shim header between the two.
For Teredo tunnel endpoints to provide the benefits of ECN, the For Teredo tunnel endpoints to provide the benefits of ECN, the
Teredo specification would have to be updated to include negotiation Teredo specification would have to be updated to include negotiation
of the ECN capability between Teredo tunnel endpoints. Otherwise it of the ECN capability between Teredo tunnel endpoints. Otherwise, it
would be unsafe for a Teredo tunnel ingress to copy the ECN field to would be unsafe for a Teredo tunnel ingress to copy the ECN field to
the IPv6 outer. the IPv6 outer.
Those implementations known to the authors at the time of writing do Those implementations known to the authors at the time of writing do
not support propagation of ECN, but that they do safely zero the ECN not support propagation of ECN, but they do safely zero the ECN field
field in the outer IPv6 header. However, the specification does not in the outer IPv6 header. However, the specification does not
mention anything about this. mention anything about this.
To make existing Teredo deployments safe, it would be possible to add To make existing Teredo deployments safe, it would be possible to add
ECN capability negotiation to those that are subject to remote OS ECN capability negotiation to those that are subject to remote OS
update. However, for those implementations not 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 update, it will not be feasible to require them to be configured
correctly, because Teredo tunnel endpoints are generally deployed on correctly because Teredo tunnel endpoints are generally deployed on
hosts. hosts.
Therefore, until ECN support is added to the specification of Teredo, Therefore, until ECN support is added to the specification of Teredo,
the only feasible further safety precaution available here is to the only feasible further safety precaution available here is to
update the specification of Teredo implementations with the following update the specification of Teredo implementations with the following
text, as a new section 5.1.3: text as a new section:
"5.1.3 Safe 'Non-ECN' Teredo Encapsulation
A Teredo tunnel ingress implementation that does not support ECN | 5.1.3. Safe "Non-ECN" Teredo Encapsulation
propagation as defined in RFC 6040 or one of its compatible |
predecessors (RFC 4301 or the full functionality mode of RFC 3168) | A Teredo tunnel ingress implementation that does not support ECN
MUST zero the ECN field in the outer IPv6 header." | 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 6.1.4. AMT
Automatic Multicast Tunneling (AMT [RFC7450]) is a tightly coupled AMT [RFC7450] is a tightly coupled shim header that encapsulates an
shim header that encapsulates an IP packet and is itself encapsulated IP packet and is encapsulated within a UDP/IP datagram. Therefore,
within a UDP/IP datagram. Therefore AMT is within the scope of RFC AMT is within the scope of [RFC6040] as updated by Section 3.
6040 as updated by Section 3 above.
Implementation of support for [RFC6040] as updated by the present Implementation of support for [RFC6040] as updated by the present
specification is RECOMMENDED for AMT tunnel endpoints, in order to specification is RECOMMENDED for AMT tunnel endpoints in order to
provide the benefits of ECN [RFC8087] whenever a node within an AMT provide the benefits of ECN [RFC8087] whenever a node within an AMT
tunnel becomes the bottleneck for an IP traffic flow tunnelled over tunnel becomes the bottleneck for an IP traffic flow tunnelled over
AMT. AMT.
To comply with RFC 6040, an AMT relay and gateway will follow the To comply with [RFC6040], an AMT relay and gateway will follow the
rules for propagation of the ECN field at ingress and egress rules for propagation of the ECN field at ingress and egress,
respectively, as described in Section 4 of RFC 6040 [RFC6040]. respectively, as described in Section 4 of [RFC6040].
Before encapsulating any data packets, RFC 6040 requires an ingress Before encapsulating any data packets, [RFC6040] requires an ingress
AMT relay to check that the egress AMT gateway supports ECN AMT relay to check that the egress AMT gateway supports ECN
propagation as defined in RFC 6040 or one of its compatible propagation as defined in [RFC6040] or one of its compatible
predecessors (RFC 4301 or the full functionality mode of RFC 3168). predecessors ([RFC4301] or the full functionality mode of [RFC3168]).
If the egress gateway supports ECN, the ingress relay can use the If the egress gateway supports ECN, the ingress relay can use the
normal mode of encapsulation (copying the IP ECN field from inner to normal mode of encapsulation (copying the IP ECN field from inner to
outer). Otherwise, the ingress relay has to use compatibility mode, outer). Otherwise, the ingress relay has to use compatibility mode,
which means it has to clear the outer ECN field to zero [RFC6040]. which means it has to clear the outer ECN field to zero [RFC6040].
An AMT tunnel is created dynamically (not manually), so the relay An AMT tunnel is created dynamically (not manually), so the relay
will need to determine the remote gateway's support for ECN using the will need to determine the remote gateway's support for ECN using the
ECN capability declaration defined in Section 6.1.4.2 below. ECN capability declaration defined in Section 6.1.4.2.
6.1.4.1. Safe Configuration of a 'Non-ECN' Ingress AMT Relay 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 The following text is appended to Section 4.2.2 of [RFC7450] as an
update to the AMT specification: update to the AMT specification:
The operator of an AMT relay that does not support RFC 6040 or one | The operator of an AMT relay that does not support [RFC6040] or
of its compatible predecessors (RFC 4301 or the full functionality | one of its compatible predecessors ([RFC4301] or the full
mode of RFC 3168) MUST follow the configuration requirements in | functionality mode of [RFC3168]) MUST follow the configuration
Section 4 of [this document] to ensure it clears the outer IP ECN | requirements in Section 4 of RFC 9601 to ensure it clears the
field to zero. | outer IP ECN field to zero.
6.1.4.2. ECN Capability Declaration of an AMT Gateway 6.1.4.2. ECN Capability Declaration of an AMT Gateway
0 1 2 3 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 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 | | V=0 |Type=3 | Reserved |E|P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Nonce | | Request Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Updated AMT Request Message Format Figure 2: Updated AMT Request Message Format
Bit 14 of the AMT Request Message counting from 0 (or bit 7 of the 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 Reserved field counting from 1) is defined here as the AMT Gateway
ECN Capability flag (E), as shown in Figure 2. The definitions of ECN Capability flag (E) as shown in Figure 2. The definitions of all
all other fields in the AMT Request Message are unchanged from RFC other fields in the AMT Request Message are unchanged from [RFC7450].
7450.
When the E flag is set to 1, it indicates that the sender of the When the E flag is set to 1, it indicates that the sender of the
message supports RFC 6040 ECN propagation. When it is cleared to message supports [RFC6040] ECN propagation. When it is cleared to
zero, it indicates the sender of the message does not support RFC zero, it indicates the sender of the message does not support
6040 ECN propagation. An AMT gateway "that supports RFC 6040 ECN [RFC6040] ECN propagation. An AMT gateway "that supports [RFC6040]
propagation" means one that propagates the ECN field to the forwarded ECN propagation" means one that propagates the ECN field to the
data packet based on the combination of arriving inner and outer ECN forwarded data packet based on the combination of arriving inner and
fields, as defined in Section 4 of RFC 6040. outer ECN fields as defined in Section 4 of [RFC6040].
The other bits of the Reserved field remain reserved. They will The other bits of the Reserved field remain reserved. They will
continue to be cleared to zero when sent and ignored when either continue to be cleared to zero when sent and ignored when either
received or forwarded, as specified in Section 5.1.3.3. of RFC 7450. received or forwarded as specified in Section 5.1.3.3 of [RFC7450].
An AMT gateway that does not support RFC 6040 MUST NOT set the E flag An AMT gateway that does not support [RFC6040] MUST NOT set the E
of its Request Message to 1. flag of its Request Message to 1.
An AMT gateway that supports RFC 6040 ECN propagation MUST set the E An AMT gateway that supports [RFC6040] ECN propagation MUST set the E
flag of its Relay Discovery Message to 1. flag of its Relay Discovery Message to 1.
The action of the corresponding AMT relay that receives a Request 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 message with the E flag set to 1 depends on whether the relay itself
supports RFC 6040 ECN propagation: supports [RFC6040] ECN propagation:
* If the relay supports RFC 6040 ECN propagation, it will store the * If the relay supports [RFC6040] ECN propagation, it will store the
ECN capability of the gateway along with its address. Then ECN capability of the gateway along with its address. Then,
whenever it tunnels datagrams towards this gateway, it MUST use whenever it tunnels datagrams towards this gateway, it MUST use
the normal mode of RFC 6040 to propagate the ECN field when the normal mode of [RFC6040] to propagate the ECN field when
encapsulating datagrams (i.e. it copies the IP ECN field from encapsulating datagrams (i.e., it copies the IP ECN field from
inner to outer). inner to outer header).
* If the discovered AMT relay does not support RFC 6040 ECN * If the discovered AMT relay does not support [RFC6040] ECN
propagation, it will ignore the E flag in the Reserved field, as propagation, it will ignore the E flag in the Reserved field as
per section 5.1.3.3. of RFC 7450. per Section 5.1.3.3 of [RFC7450].
If the AMT relay does not support RFC 6040 ECN propagation, the If the AMT relay does not support [RFC6040] ECN propagation, the
network operator is still expected to configure it to comply with network operator is still expected to configure it to comply with
the safety provisions set out in Section 6.1.4.1 above. the safety provisions set out in Section 6.1.4.1.
7. IANA Considerations 7. IANA Considerations
IANA is requested to assign the following L2TP Control Message IANA has assigned the following AVP in the L2TP "Control Message
Attribute Value Pair: Attribute Value Pairs" registry:
+================+================+=================+ +================+================+===========+
| Attribute Type | Description | Reference | | Attribute Type | Description | Reference |
+================+================+=================+ +================+================+===========+
| TBD | ECN Capability | [this document] | | 103 | ECN Capability | RFC 9601 |
+----------------+----------------+-----------------+ +----------------+----------------+-----------+
Table 1 Table 1
[TO BE REMOVED: This registration should take place at the following
location: https://www.iana.org/assignments/l2tp-parameters/l2tp-
parameters.xhtml ]
8. Security Considerations 8. Security Considerations
The Security Considerations in [RFC6040] and The Security Considerations in [RFC6040] and [RFC9599] apply equally
[I-D.ietf-tsvwg-ecn-encap-guidelines] apply equally to the scope to the scope defined for the present specification.
defined for the present specification.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-tsvwg-ecn-encap-guidelines]
Briscoe, B. and J. Kaippallimalil, "Guidelines for Adding
Congestion Notification to Protocols that Encapsulate IP",
Work in Progress, Internet-Draft, draft-ietf-tsvwg-ecn-
encap-guidelines-21, 10 November 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-
ecn-encap-guidelines-21>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998, DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>. <https://www.rfc-editor.org/info/rfc2474>.
skipping to change at page 19, line 47 skipping to change at line 854
[RFC6660] Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three [RFC6660] Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three
Pre-Congestion Notification (PCN) States in the IP Header Pre-Congestion Notification (PCN) States in the IP Header
Using a Single Diffserv Codepoint (DSCP)", RFC 6660, Using a Single Diffserv Codepoint (DSCP)", RFC 6660,
DOI 10.17487/RFC6660, July 2012, DOI 10.17487/RFC6660, July 2012,
<https://www.rfc-editor.org/info/rfc6660>. <https://www.rfc-editor.org/info/rfc6660>.
[RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, [RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450,
DOI 10.17487/RFC7450, February 2015, DOI 10.17487/RFC7450, February 2015,
<https://www.rfc-editor.org/info/rfc7450>. <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 9.2. Informative References
[decap-test] [decap-test]
Briscoe, B., "A Test for IP-ECN Propagation over a Briscoe, B., "A Test for IP-ECN Propagation by a Remote
Tunnel", Technical Report, TR-BB-2023-003, Tunnel Endpoint", Technical Report, TR-BB-2023-003,
DOI 10.48550/arXiv.2311.16825, November 2023, DOI 10.48550/arXiv.2311.16825, November 2023,
<https://arxiv.org/abs/2311.16825>. <https://arxiv.org/abs/2311.16825>.
[GTPv1] 3GPP, "GPRS Tunnelling Protocol (GTP) across the Gn and Gp [GTPv1] 3GPP, "General Packet Radio Service (GPRS); GPRS
interface", Technical Specification TS 29.060. Tunnelling Protocol (GTP) across the Gn and Gp interface",
Technical Specification 29.060.
[GTPv1-U] 3GPP, "General Packet Radio System (GPRS) Tunnelling [GTPv1-U] 3GPP, "General Packet Radio System (GPRS) Tunnelling
Protocol User Plane (GTPv1-U)", Technical Specification TS Protocol User Plane (GTPv1-U)", Technical
29.281. Specification 29.281.
[GTPv2-C] 3GPP, "Evolved General Packet Radio Service (GPRS) [GTPv2-C] 3GPP, "3GPP Evolved Packet System (EPS); Evolved General
Tunnelling Protocol for Control plane (GTPv2-C)", Packet Radio Service (GPRS) Tunnelling Protocol for
Technical Specification TS 29.274. Control plane (GTPv2-C); Stage 3", Technical
Specification 29.274.
[I-D.ietf-intarea-tunnels] [INTAREA-TUNNELS]
Touch, J. D. and M. Townsley, "IP Tunnels in the Internet Touch, J. D. and M. Townsley, "IP Tunnels in the Internet
Architecture", Work in Progress, Internet-Draft, draft- Architecture", Work in Progress, Internet-Draft, draft-
ietf-intarea-tunnels-13, 26 March 2023, ietf-intarea-tunnels-13, 26 March 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-intarea- <https://datatracker.ietf.org/doc/html/draft-ietf-intarea-
tunnels-13>. tunnels-13>.
[I-D.ietf-nvo3-vxlan-gpe] [NVO3-VXLAN-GPE]
Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol
Extension for VXLAN (VXLAN-GPE)", Work in Progress, Extension for VXLAN (VXLAN-GPE)", Work in Progress,
Internet-Draft, draft-ietf-nvo3-vxlan-gpe-13, 4 November Internet-Draft, draft-ietf-nvo3-vxlan-gpe-13, 4 November
2023, <https://datatracker.ietf.org/doc/html/draft-ietf- 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
nvo3-vxlan-gpe-13>. nvo3-vxlan-gpe-13>.
[I-D.ietf-sfc-nsh-ecn-support]
Eastlake, D. E., Briscoe, B., Zhuang, S., Malis, A. G.,
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-12, 23 October 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-sfc-nsh-
ecn-support-12>.
[RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
Routing Encapsulation (GRE)", RFC 1701, Routing Encapsulation (GRE)", RFC 1701,
DOI 10.17487/RFC1701, October 1994, DOI 10.17487/RFC1701, October 1994,
<https://www.rfc-editor.org/info/rfc1701>. <https://www.rfc-editor.org/info/rfc1701>.
[RFC2332] Luciani, J., Katz, D., Piscitello, D., Cole, B., and N. [RFC2332] Luciani, J., Katz, D., Piscitello, D., Cole, B., and N.
Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)", Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)",
RFC 2332, DOI 10.17487/RFC2332, April 1998, RFC 2332, DOI 10.17487/RFC2332, April 1998,
<https://www.rfc-editor.org/info/rfc2332>. <https://www.rfc-editor.org/info/rfc2332>.
skipping to change at page 23, line 31 skipping to change at line 1017
Key Exchange Protocol (IKE) and IPsec Packets", RFC 9329, Key Exchange Protocol (IKE) and IPsec Packets", RFC 9329,
DOI 10.17487/RFC9329, November 2022, DOI 10.17487/RFC9329, November 2022,
<https://www.rfc-editor.org/info/rfc9329>. <https://www.rfc-editor.org/info/rfc9329>.
[RFC9331] De Schepper, K. and B. Briscoe, Ed., "The Explicit [RFC9331] De Schepper, K. and B. Briscoe, Ed., "The Explicit
Congestion Notification (ECN) Protocol for Low Latency, Congestion Notification (ECN) Protocol for Low Latency,
Low Loss, and Scalable Throughput (L4S)", RFC 9331, Low Loss, and Scalable Throughput (L4S)", RFC 9331,
DOI 10.17487/RFC9331, January 2023, DOI 10.17487/RFC9331, January 2023,
<https://www.rfc-editor.org/info/rfc9331>. <https://www.rfc-editor.org/info/rfc9331>.
Comments Solicited [SFC-NSH-ECN]
Eastlake 3rd, D., Briscoe, B., Zhuang, S., Malis, A., and
This section is to be removed before publishing as an RFC. X. Wei, "Explicit Congestion Notification (ECN) and
Congestion Feedback Using the Network Service Header (NSH)
Comments and questions are encouraged and very welcome. They can be and IPFIX", Work in Progress, Internet-Draft, draft-ietf-
addressed to the IETF Transport Area working group mailing list sfc-nsh-ecn-support-13, 15 April 2024,
<tsvwg@ietf.org>, and/or to the authors. <https://datatracker.ietf.org/doc/html/draft-ietf-sfc-nsh-
ecn-support-13>.
Acknowledgements Acknowledgements
Thanks to Ing-jyh (Inton) Tsang for initial discussions on the need Thanks to Ing-jyh (Inton) Tsang for initial discussions on the need
for ECN propagation in L2TP and its applicability. Thanks also to for ECN propagation in L2TP and its applicability. Thanks also to
Carlos Pignataro, Tom Herbert, Ignacio Goyret, Alia Atlas, Praveen Carlos Pignataro, Tom Herbert, Ignacio Goyret, Alia Atlas, Praveen
Balasubramanian, Joe Touch, Mohamed Boucadair, David Black, Jake Balasubramanian, Joe Touch, Mohamed Boucadair, David Black, Jake
Holland, Sri Gundavelli, Gorry Fairhurst and Martin Duke for helpful Holland, Sri Gundavelli, Gorry Fairhurst, and Martin Duke for helpful
advice and comments. "A Comparison of IPv6-over-IPv4 Tunnel advice and comments. [RFC7059] helped to identify a number of
Mechanisms" [RFC7059] helped to identify a number of tunnelling tunnelling protocols to include within the scope of this document.
protocols to include within the scope of this document.
Bob Briscoe was part-funded by the Research Council of Norway through Bob Briscoe was part-funded by the Research Council of Norway through
the TimeIn project for early drafts, and for final drafts (from -17) the TimeIn project for early drafts, and he was funded by Apple Inc.
he was funded by Apple Inc. The views expressed here are solely those for later draft versions (from -17). The views expressed here are
of the authors. solely those of the authors.
Author's Address Author's Address
Bob Briscoe Bob Briscoe
Independent Independent
United Kingdom United Kingdom
Email: ietf@bobbriscoe.net Email: ietf@bobbriscoe.net
URI: https://bobbriscoe.net/ URI: https://bobbriscoe.net/
 End of changes. 155 change blocks. 
482 lines changed or deleted 463 lines changed or added

This html diff was produced by rfcdiff 1.48.