rfc9601.original.xml   rfc9601.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type='text/xsl' href='https://xml.resource.org/authoring/rfc262
9.xslt' ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
<!-- Alterations to I-D/RFC boilerplate --> std" consensus="true" docName="draft-ietf-tsvwg-rfc6040update-shim-23" number="9
<?rfc private="" ?> 601" ipr="pre5378Trust200902" updates="6040, 2661, 2784, 3931, 4380, 7450" obsol
<!-- Default private="" Produce an internal memo 2.5pp shorter than an I-D or RF etes="" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="
C --> 3">
<?rfc rfcprocack="yes" ?>
<!-- Default rfcprocack="no" add a short sentence acknowledging xml2rfc -->
<?rfc strict="no" ?>
<!-- Default strict="no" Don't check I-D nits -->
<?rfc rfcedstyle="yes" ?>
<!-- Default rfcedstyle="yes" attempt to closely follow finer details from the l
atest observable RFC-Editor style -->
<!-- IETF process -->
<?rfc iprnotified="no" ?>
<!-- Default iprnotified="no" I haven't disclosed existence of IPR to IETF -->
<!-- ToC format -->
<?rfc toc="yes" ?>
<!-- Default toc="no" No Table of Contents -->
<!-- Cross referencing, footnotes, comments -->
<?rfc symrefs="yes"?>
<!-- Default symrefs="no" Don't use anchors, but use numbers for refs -->
<?rfc sortrefs="yes"?>
<!-- Default sortrefs="no" Don't sort references into order -->
<?rfc comments="yes" ?>
<!-- Default comments="no" Don't render comments -->
<?rfc inline="no" ?>
<!-- Default inline="no" if comments is "yes", then render comments inline; othe
rwise render them in an `Editorial Comments' section -->
<!-- Pagination control -->
<?rfc compact="yes"?>
<!-- Default compact="no" Start sections on new pages -->
<?rfc subcompact="no"?>
<!-- Default subcompact="(as compact setting)" yes/no is not quite as compact as
yes/yes -->
<!-- HTML formatting control -->
<?rfc emoticonic="yes" ?>
<!-- Default emoticonic="no" Doesn't prettify HTML format -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" consensus="true"
docName="draft-ietf-tsvwg-rfc6040update-shim-23" ipr="pre5378Trust200902" update
s="6040, 2661, 2784, 3931, 4380, 7450" obsoletes="" submissionType="IETF" xml:la
ng="en" tocInclude="true" symRefs="true" sortRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.18.2 -->
<front> <front>
<title abbrev="ECN over IP-shim-(L2)-IP Tunnels">Propagating Explicit <title abbrev="ECN over IP-shim-(L2)-IP Tunnels">Propagating Explicit
Congestion Notification Across IP Tunnel Headers Separated by a Congestion Notification across IP Tunnel Headers Separated by a
Shim</title> Shim</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-tsvwg-rfc6040update-shim -23"/> <seriesInfo name="RFC" value="9601"/>
<author fullname="Bob Briscoe" initials="B." surname="Briscoe"> <author fullname="Bob Briscoe" initials="B." surname="Briscoe">
<organization>Independent</organization> <organization>Independent</organization>
<address> <address>
<postal> <postal>
<street/> <country>United Kingdom</country>
<country>UK</country>
</postal> </postal>
<email>ietf@bobbriscoe.net</email> <email>ietf@bobbriscoe.net</email>
<uri>https://bobbriscoe.net/</uri> <uri>https://bobbriscoe.net/</uri>
</address> </address>
</author> </author>
<date year=""/> <date year="2024" month="August"/>
<area>Transport</area> <area>tsv</area>
<workgroup>Transport Area Working Group</workgroup> <workgroup>tsvwg</workgroup>
<keyword>Congestion Control and Management</keyword> <keyword>Congestion Control and Management</keyword>
<keyword>Congestion Notification</keyword> <keyword>Congestion Notification</keyword>
<keyword>Information Security</keyword> <keyword>Information Security</keyword>
<keyword>Tunnelling</keyword> <keyword>Tunnelling</keyword>
<keyword>Encapsulation &amp; Decapsulation</keyword> <keyword>Encapsulation &amp; Decapsulation</keyword>
<keyword>Protocol</keyword> <keyword>Protocol</keyword>
<keyword>ECN</keyword> <keyword>ECN</keyword>
<keyword>Layering</keyword> <keyword>Layering</keyword>
<abstract> <abstract>
<t>RFC 6040 on "Tunnelling of Explicit Congestion Notification" made the <t>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) consistent for all forms of IP-in-IP
tunnel. This specification updates RFC 6040 to clarify that its scope tunnel. This specification updates RFC 6040 to clarify that its scope
includes tunnels where two IP headers are separated by at least one shim 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 header that is not sufficient on its own for wide-area packet
forwarding. It surveys widely deployed IP tunnelling protocols that use forwarding. It surveys widely deployed IP tunnelling protocols that use
such shim header(s) and updates the specifications of those that do not such shim headers and updates the specifications of those that do not
mention ECN propagation (that is RFC 2661, RFC 3931, RFC 2784, RFC 4380 mention ECN propagation (including RFCs 2661, 3931, 2784, 4380
and RFC 7450, which respectively specify L2TPv2, L2TPv3, GRE, Teredo and and 7450, which specify L2TPv2, L2TPv3, Generic Routing Encapsulation (GRE
AMT). This specification also updates RFC 6040 with configuration ), Teredo, and
Automatic Multicast Tunneling (AMT), respectively). This specification als
o updates RFC 6040 with configuration
requirements needed to make any legacy tunnel ingress safe.</t> requirements needed to make any legacy tunnel ingress safe.</t>
</abstract> </abstract>
</front> </front>
<!-- ================================================================ -->
<middle> <middle>
<!-- ================================================================ -->
<section anchor="rfc6040up_Introduction" numbered="true" toc="default"> <section anchor="rfc6040up_Introduction" numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t>RFC 6040 on "Tunnelling of Explicit Congestion Notification" <xref targ <t><xref target="RFC6040"/> on "Tunnelling of Explicit Congestion Notifica
et="RFC6040" format="default"/> made the rules for propagation of Explicit Conge tion" made the rules for propagation of Explicit Congestion
stion Notification (ECN) <xref target="RFC3168" format="default"/> consistent fo
Notification (ECN <xref target="RFC3168" format="default"/>) consistent fo r all forms of
r all forms of IP-in-IP tunnel.</t>
IP in IP tunnel.</t>
<t>A common pattern for many tunnelling protocols is to encapsulate an <t>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 header 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 (v4 or v6). Some of these shim headers are designed as generic
encapsulations, so they do not necessarily directly encapsulate an inner encapsulations, so they do not necessarily directly encapsulate an inner
IP header. Instead, they can encapsulate headers such as link-layer (L2) IP header. Instead, they can encapsulate headers such as link-layer (L2) p
protocols that in turn often encapsulate IP.</t> rotocols 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.</t>
<t>To clear up confusion, this specification clarifies that the scope of <t>To clear up confusion, this specification clarifies that the scope of
RFC 6040 includes any IP-in-IP tunnel, including those with shim <xref target="RFC6040"/> includes any IP-in-IP tunnel, including those wit
header(s) and other encapsulations between the IP headers. Where h one or more shim
headers and other encapsulations between the IP headers. Where
necessary, it updates the specifications of the relevant encapsulation necessary, it updates the specifications of the relevant encapsulation
protocols with the specific text necessary to comply with RFC 6040.</t> protocols with the specific text necessary to comply with <xref target="RF
<t>This specification also updates RFC 6040 to state how operators ought C6040"/>.</t>
<t>This specification also updates <xref target="RFC6040"/> to state how o
perators ought
to configure a legacy tunnel ingress to avoid unsafe system to configure a legacy tunnel ingress to avoid unsafe system
configurations.</t> configurations.</t>
</section> </section>
<!-- ================================================================ -->
<section anchor="rfc6040up_Reqs_Language" numbered="true" toc="default"> <section anchor="rfc6040up_Reqs_Language" numbered="true" toc="default">
<name>Terminology</name> <name>Terminology</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and >REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
"OPTIONAL" in this document are to be interpreted as described in "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED<
/bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and
"<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as descri
bed in
BCP&nbsp;14 <xref target="RFC2119" format="default"/> <xref target="RFC817 4" format="default"/> when, and BCP&nbsp;14 <xref target="RFC2119" format="default"/> <xref target="RFC817 4" format="default"/> when, and
only when, they appear in all capitals, as shown here.</t> only when, they appear in all capitals, as shown here.</t>
<t>This specification uses the terminology defined in RFC 6040 <xref targe t="RFC6040" format="default"/>.</t> <t>This specification uses the terminology defined in <xref target="RFC604 0" format="default"/>.</t>
</section> </section>
<section anchor="rfc6040up_scope" numbered="true" toc="default"> <section anchor="rfc6040up_scope" numbered="true" toc="default">
<name>Scope of RFC 6040</name> <name>Scope of RFC 6040</name>
<t>In section 1.1 of RFC 6040, its scope is defined as: </t> <t>In <xref target="RFC6040" section="1.1" sectionFormat="of"/>, its scope
<ul empty="true" spacing="normal"> is defined as: </t>
<li>
<t>"...ECN field processing at encapsulation and decapsulation for <blockquote>
...ECN field processing at encapsulation and decapsulation for
any IP-in-IP tunnelling, whether IPsec or non-IPsec tunnels. It any IP-in-IP tunnelling, whether IPsec or non-IPsec tunnels. It
applies irrespective of whether IPv4 or IPv6 is used for either the applies irrespective of whether IPv4 or IPv6 is used for either the
inner or outer headers. ..."</t> inner or outer headers.
</li> </blockquote>
</ul>
<t>This was intended to include cases where shim header(s) sit between <t>There are two problems with the above scoping statement:</t>
<t>Problem 1: It was intended to include cases where one or more shim head
ers sit between
the IP headers. Many tunnelling implementers have interpreted the scope the IP headers. Many tunnelling implementers have interpreted the scope
of RFC 6040 as it was intended, but it is ambiguous. Therefore, this of <xref target="RFC6040"/> as it was intended, but it is ambiguous. There
specification updates RFC 6040 by adding the following scoping text fore, this
specification updates <xref target="RFC6040"/> by adding the following sco
ping text
after the sentences quoted above:</t> after the sentences quoted above:</t>
<ul empty="true" spacing="normal">
<li> <blockquote>
<t>It applies in cases where an outer IP header encapsulates an It applies in cases where an outer IP header encapsulates an
inner IP header either directly or indirectly by encapsulating other inner IP header either directly or indirectly by encapsulating other
headers that in turn encapsulate (or might encapsulate) an inner IP headers that in turn encapsulate (or might encapsulate) an inner IP
header.</t> header.
</li> </blockquote>
</ul>
<t>There is another problem with the scope of RFC 6040. Like many IETF <t>Problem 2: Like many IETF
specifications, RFC 6040 is written as a specification that specifications, <xref target="RFC6040"/> is written as a specification tha
t
implementations can choose to claim compliance with. This means it does implementations can choose to claim compliance with. This means it does
not cover two important cases:</t> not cover two important situations:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>those cases where it is infeasible for an implementation to <t>Cases where it is infeasible for an implementation to
access an inner IP header when adding or removing an outer IP access an inner IP header when adding or removing an outer IP
header;</t> header</t>
</li> </li>
<li> <li>
<t>those implementations that choose not to propagate ECN between IP <t>Cases where implementations choose not to propagate ECN between IP
headers.</t> headers</t>
</li> </li>
</ol> </ol>
<t>However, the ECN field is a non-optional part of the IP header (v4 <t>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 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 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 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 propagation of the ECN field; it has to clear the ECN field in any outer
IP header to 0b00.</t> IP header to 0b00.</t>
<t>However, an RFC has no jurisdiction over implementations that choose <t>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 <xref target="RFC6040"/>. Noneth
eless, to
ensure safe propagation of the ECN field over tunnels, it is reasonable ensure safe propagation of the ECN field over tunnels, it is reasonable
to add requirements on operators, to ensure they configure their tunnels to add requirements on operators to ensure they configure their tunnels
safely (where possible). Before stating these configuration requirements safely (where possible). Before resolving 'Problem 2' by stating these con
in <xref target="rfc6040up_sec_safe" format="default"/>, the factors that figuration requirements
determine (in <xref target="rfc6040up_sec_safe" format="default"/>), the factors tha
t determine
whether propagating ECN is feasible or desirable will be briefly whether propagating ECN is feasible or desirable will be briefly
introduced.</t> introduced.</t>
<section anchor="rfc6040up_feasibility" numbered="true" toc="default"> <section anchor="rfc6040up_feasibility" numbered="true" toc="default">
<name>Feasibility of ECN Propagation between Tunnel Headers</name> <name>Feasibility of ECN Propagation between Tunnel Headers</name>
<t>In many cases shim header(s) and an outer IP header are always <t>In many cases, one or more shim headers and an outer IP header are
added 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 the same procedure. We call these tightly coupled shim headers.
shim and outer together is often necessary because the shim(s) are not Processing a shim and outer header together is often necessary because
sufficient for packet forwarding in their own right; not unless a shim is not sufficient for packet forwarding in its own right; not
complemented by an outer header. In these cases it will often be unless complemented by an outer header. In these cases, it will often
feasible for an implementation to propagate the ECN field between the be feasible for an implementation to propagate the ECN field between
IP headers.</t> the IP headers.</t>
<t>In some cases a tunnel adds an outer IP header and a tightly <t>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 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 that, in turn, encapsulates an IP header (or might encapsulate an IP
header). For instance an inner Ethernet (or other link layer) header header). For instance, an inner Ethernet (or other link-layer) header
might encapsulate an inner IP header as its payload. We call this a might encapsulate an inner IP header as its payload. We call this a
tightly coupled shim over an encapsulating header.</t> tightly coupled shim over an encapsulating header.</t>
<t>Digging to arbitrary depths to find an inner IP header within an <t>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.
within a L2 header for an IP header, for instance to map the Diffserv
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 codepoint between an encapsulated IP header and an outer IP header
<xref target="RFC2983" format="default"/>. In such cases at least, it sh ould be <xref target="RFC2983" format="default"/>. In such cases at least, it sh ould be
feasible to also (independently) propagate the ECN field between the feasible to also (independently) propagate the ECN field between the
same IP headers. Thus, access to the ECN field within an encapsulating same IP headers. Thus, access to the ECN field within an encapsulating
header can be a useful and benign optimization. The guidelines in header can be a useful and benign optimization. The guidelines in
section 5 of <xref target="I-D.ietf-tsvwg-ecn-encap-guidelines" format=" default"/> give <xref target="RFC9599" section="5" sectionFormat="of"/> give
the conditions for this layering violation to be benign.</t> the conditions for this layering violation to be benign.</t>
</section> </section>
<section anchor="rfc6040up_desirability" numbered="true" toc="default"> <section anchor="rfc6040up_desirability" numbered="true" toc="default">
<name>Desirability of ECN Propagation between Tunnel Headers</name> <name>Desirability of ECN Propagation between Tunnel Headers</name>
<t>Developers and network operators are encouraged to implement and <t>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 <xref target="RFC6040"/> (as upda ted 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 <xref target="RFC8087" format="default"/>. Nonetheless, propa gation of ECN deployment <xref target="RFC8087" format="default"/>. Nonetheless, propa gation of ECN
between IP headers, whether separated by shim headers or not, has to between IP headers, whether separated by shim headers or not, has to
be optional to implement and to use, because:</t> be optional to implement and to use, because:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Legacy implementations of tunnels without any ECN support <t>legacy implementations of tunnels without any ECN support
already exist</t> already exist;</t>
</li> </li>
<li> <li>
<t>A network might be designed so that there is usually no <t>a network might be designed so that there is usually no
bottleneck within the tunnel</t> bottleneck within the tunnel; and</t>
</li> </li>
<li> <li>
<t>If the tunnel endpoints would have to search within an L2 <t>if the tunnel endpoints would have to search within an L2
header to find an encapsulated IP header, it might not be worth header to find an encapsulated IP header, it might not be worth
the potential performance hit.</t> the potential performance hit.</t>
</li> </li>
</ul> </ul>
</section> </section>
</section> </section>
<section anchor="rfc6040up_sec_safe" numbered="true" toc="default"> <section anchor="rfc6040up_sec_safe" numbered="true" toc="default">
<name>Making a non-ECN Tunnel Ingress Safe by Configuration</name> <name>Making a Non-ECN Tunnel Ingress Safe by Configuration</name>
<t>Even when no specific attempt has been made to implement propagation <t>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 the 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 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 implement ECN logic to propagate any ECN markings into the packet
forwarded beyond the tunnel. Otherwise, the non-ECN egress could discard forwarded beyond the tunnel. Otherwise, the non-ECN egress could discard
any ECN marking introduced within the tunnel, which would break all the any ECN marking introduced within the tunnel, which would break all the
ECN-based control loops that regulate the traffic load over the ECN-based control loops that regulate the traffic load over the
tunnel.</t> tunnel.</t>
<t>Therefore this specification updates RFC 6040 by inserting the <t>Therefore, this specification updates <xref target="RFC6040" section="4
following text at the end of section 4.3:</t> .3"/> by inserting the
<ul empty="true" spacing="normal"> following text at the end of the section:</t>
<li>
<t>"</t> <blockquote>
<t>Whether or not an ingress implementation
claims compliance with RFC 6040, RFC 4301 or RFC3168, when the outer <t>Whether or not an ingress implementation
tunnel header is IP (v4 or v6), if possible, the ingress MUST be claims compliance with <xref target="RFC6040"/>, <xref target="RFC4301
configured to zero the outer ECN field in any of the following "/>, or <xref target="RFC3168"/>, when the outer
tunnel header is IP (v4 or v6), if possible, the ingress <bcp14>MUST</
bcp14> be
configured to zero the outer ECN field in all of the following
cases:</t> cases:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>if it is known that the tunnel egress does not support any of <t>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 the RFCs that define propagation of the ECN field (<xref target="R
4301 or the full functionality mode of RFC 3168);</t> FC6040"/>, <xref target="RFC4301"/>, or the full functionality mode of <xref tar
get="RFC3168"/>);</t>
</li> </li>
<!--...from the outer to any forwarded IP header (which might be the
forwarded header itself, or it might be encapsulated within a forwarded non-IP
header).-->
<li> <li>
<t>or if the behaviour of the egress is not known or an egress <t>if the behaviour of the egress is not known or an egress
with unknown behaviour might be dynamically paired with the with unknown behaviour might be dynamically paired with the
ingress (one way for an operator of a tunnel ingress to ingress (one way for an operator of a tunnel ingress to
determine the behaviour of an otherwise unknown egress is determine the behaviour of an otherwise unknown egress is
described in <xref target="decap-test" format="default"/>);</t> described in <xref target="decap-test" format="default"/>);</t>
</li> </li>
<li> <li>
<t>or if an IP header might be encapsulated within a non-IP <t>if an IP header might be encapsulated within a non-IP
header that the tunnel ingress is encapsulating, but the ingress header that the tunnel ingress is encapsulating, but the ingress
does not inspect within the encapsulation.</t> does not inspect within the encapsulation.</t>
</li> </li>
<!--Not sure this last bullet is needed. The above commented additio n to the first bullet would be better.-->
</ul> </ul>
<t>For the avoidance of doubt, the above only concerns the <t>For the avoidance of doubt, the above only concerns the
outer IP header. The ingress MUST NOT alter the ECN field of the outer IP header. The ingress <bcp14>MUST NOT</bcp14> alter the ECN fie
ld of the
arriving IP header that will become the inner IP header.</t> arriving IP header that will become the inner IP header.</t>
</li> <t>In order that the network operator can comply with the above
<li> safety rules, an implementation of a tunnel ingress:</t>
<t>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:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>it MUST NOT treat the former ToS octet (IPv4) or the former <t><bcp14>MUST NOT</bcp14> treat the former Type of Service (ToS)
Traffic Class octet (IPv6) as a single 8-bit field, as the octet (IPv4) or the former
Traffic Class octet (IPv6) as a single 8-bit field. This is becaus
e the
resulting linkage of ECN and Diffserv field propagation between resulting linkage of ECN and Diffserv field propagation between
inner and outer is not consistent with the definition of the inner and outer headers is not consistent with the definition of t
6-bit Diffserv field in <xref target="RFC2474" format="default"/> he
and <xref target="RFC3260" format="default"/>;</t> 6-bit Diffserv field in <xref target="RFC2474" format="default"/>
and <xref target="RFC3260" format="default"/>.</t>
</li> </li>
<li> <li>
<t>it SHOULD be able to be configured to zero the ECN field of <t><bcp14>SHOULD</bcp14> be able to be configured to zero the ECN field of
the outer header.</t> the outer header.</t>
</li> </li>
</ul> </ul>
<t>"</t> <t>These last two rules apply even if an implementation of a tunnel in
</li> gress does not
</ul> claim to support <xref target="RFC6040"/>, <xref target="RFC4301"/>, o
<t>For instance, if a tunnel ingress with no ECN-specific logic had a r the full functionality mode
of <xref target="RFC3168"/></t>
</blockquote>
<t>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 configuration capability to refer to the last 2 bits of the old ToS Byte
of the outer (e.g.&nbsp;with a 0x3 mask) and set them to zero, while 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.</t> requirements above.</t>
<t>There might be concern that the above "MUST NOT" makes compliant <t>There might be concern that the above "<bcp14>MUST NOT</bcp14>" makes c
implementations non-compliant at a stroke. However, by definition it ompliant
implementations non-compliant at a stroke. However, by definition, it
solely applies to equipment that provides Diffserv configuration. Any solely applies to equipment that provides Diffserv configuration. Any
such Diffserv equipment that is configuring treatment of the former ToS 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 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 field must have always been non-compliant with the definition of the
6-bit Diffserv field in <xref target="RFC2474" format="default"/> and <xre f target="RFC3260" format="default"/>. If a tunnel ingress does not have any ECN logic, 6-bit Diffserv field in <xref target="RFC2474" format="default"/> and <xre f target="RFC3260" format="default"/>. If a tunnel ingress does not have any ECN logic,
copying the ECN field as a side effect of copying the DSCP is a copying the ECN field as a side effect of copying the DSCP is a
seriously unsafe bug that risks breaking the feedback loops that seriously unsafe bug that risks breaking the feedback loops that
regulate load on a tunnel.</t> regulate load on a tunnel, because it omits to check the ECN capability of the tunnel egress.</t>
<t>Zeroing the outer ECN field of all packets in all circumstances would <t>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 <xref tar
6040 because it would not meet the aim of introducing ECN support to get="RFC6040"/> because it would not meet the aim of introducing ECN support to
tunnels (see Section 4.3 of <xref target="RFC6040" format="default"/>).</t tunnels (see <xref target="RFC6040" section="4.3" sectionFormat="of"/>).</
> t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>ECN Propagation and Fragmentation/Reassembly</name> <name>ECN Propagation and Fragmentation/Reassembly</name>
<t>The following requirements update RFC6040, which omitted handling of <t>The following requirements update <xref target="RFC6040"/>, which omitt ed handling of
the ECN field during fragmentation or reassembly. These changes might the ECN field during fragmentation or reassembly. These changes might
alter how many ECN-marked packets are propagated by a tunnel that alter how many ECN-marked packets are propagated by a tunnel that
fragments packets, but this would not raise any backward compatibility fragments packets, but this would not raise any backward compatibility
issues:</t> issues.</t>
<t>If a tunnel ingress fragments a packet, it MUST set the outer ECN <t>If a tunnel ingress fragments a packet, it <bcp14>MUST</bcp14> set the
outer ECN
field of all the fragments to the same value as it would have set if it field of all the fragments to the same value as it would have set if it
had not fragmented the packet.</t> had not fragmented the packet.</t>
<t>Section 5.3 of <xref target="RFC3168" format="default"/> specifies ECN <t><xref target="RFC3168" section="5.3" sectionFormat="of"/> specifies ECN
requirements requirements
for reassembly of sets of outer fragments into packets (in outer for reassembly of sets of 'outer fragments' into packets (in 'outer
fragmentation, the fragmentation is visible in the outer header so that fragmentation', the fragmentation is visible in the outer header so that
the tunnel egress can reassemble the fragments <xref target="I-D.ietf-inta the tunnel egress can reassemble the fragments <xref target="I-D.ietf-inta
rea-tunnels" format="default"/>). The following two additional rea-tunnels" format="default"/>). Additionally, the following
requirements apply at a tunnel egress:</t> requirements apply at a tunnel egress:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>During reassembly of outer fragments, if the ECN fields of the During reassembly of outer fragments, the packet <bcp14>MUST</bcp14> b e discarded if the ECN fields of the
outer headers being reassembled into a single packet consist of a outer headers being reassembled into a single packet consist of a
mixture of Not-ECT and other ECN codepoints, the packet MUST be mixture of Not ECN-Capable Transport (Not-ECT) and other ECN codepoint
discarded.</t> s.
</li> </li>
<li> <li>
<t>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).</t> reassembled packet <bcp14>MUST</bcp14> be set to ECT(1).</li>
<t>Reasoning: Originally <xref target="RFC3168" format="default"/> </ul>
defined ECT(0) and ECT(1) as equivalent, but RFC 3168 has been <t indent="3">Reasoning: <xref target="RFC3168" format="default"/>
originally defined ECT(0) and ECT(1) as equivalent, but <xref target="
RFC3168"/> has been
updated by <xref target="RFC8311" format="default"/> to make ECT(1) av ailable for updated by <xref target="RFC8311" format="default"/> to make ECT(1) av ailable for
congestion marking differences. The rule is independent of the congestion marking differences. The rule is independent of the
current experimental use of ECT(1) for L4S <xref target="RFC9331" form current experimental use of ECT(1) for Low Latency, Low Loss, and Scal
at="default"/>. able throughput (L4S) <xref target="RFC9331" format="default"/>.
The rule is compatible with PCN <xref target="RFC6660" format="default The rule is compatible with Pre-Congestion Notification (PCN) <xref ta
"/>, which uses rget="RFC6660" format="default"/>, which uses
2 levels of congestion severity, with the ranking of severity from 2 levels of congestion severity, with the ranking of severity from
highest to lowest being CE, ECT(1), ECT(0)). The decapsulation rules highest to lowest being Congestion Experienced (CE), ECT(1), ECT(0). T he decapsulation rules
in <xref target="RFC6040" format="default"/> take a similar approach.< /t> in <xref target="RFC6040" format="default"/> take a similar approach.< /t>
</li>
</ul>
</section> </section>
<section anchor="rfc6040up_IP-IP_Coupled_Shim_Tunnels" numbered="true" toc=" default"> <section anchor="rfc6040up_IP-IP_Coupled_Shim_Tunnels" numbered="true" toc=" default">
<name>IP-in-IP Tunnels with Tightly Coupled Shim Headers</name> <name>IP-in-IP Tunnels with Tightly Coupled Shim Headers</name>
<t>There follows a list of specifications of encapsulations with tightly <t>Below is a list of specifications of encapsulations with tightly coupled
coupled shim header(s), in rough chronological order. The list is shim header(s) in rough chronological order. This list is confined to
confined to standards track or widely deployed protocols. The list is Standards Track or widely deployed protocols. So, for the avoidance of doubt,
not necessarily exhaustive so, for the avoidance of doubt, the scope of the updated scope of <xref target="RFC6040"/> is defined in <xref target="rfc604
RFC 6040 is defined in <xref target="rfc6040up_scope" format="default"/> a 0up_scope"
nd is not format="default"/> and is not limited to this list.</t>
limited to this list. </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>PPTP (Point-to-Point Tunneling Protocol) <xref target="RFC2637" for mat="default"/>;</t> <t>Point-to-Point Tunneling Protocol (PPTP) <xref target="RFC2637" for mat="default"/>;</t>
</li> </li>
<li> <li>
<t>L2TP (Layer 2 Tunnelling Protocol), specifically L2TPv2 <xref targe t="RFC2661" format="default"/> and L2TPv3 <xref target="RFC3931" format="default "/>, which not <t>Layer Two Tunneling Protocol (L2TP), specifically L2TPv2 <xref targ et="RFC2661" format="default"/> and L2TPv3 <xref target="RFC3931" format="defaul t"/>, which not
only includes all the L2-specific specializations of L2TP, but also only includes all the L2-specific specializations of L2TP, but also
derivatives such as the Keyed IPv6 Tunnel <xref target="RFC8159" forma t="default"/>;</t> derivatives such as the Keyed IPv6 Tunnel <xref target="RFC8159" forma t="default"/></t>
</li> </li>
<li> <li>
<t>GRE (Generic Routing Encapsulation) <xref target="RFC2784" format=" <t>Generic Routing Encapsulation (GRE) <xref target="RFC2784" format="
default"/> and default"/> and Network Virtualization using GRE (NVGRE) <xref target="RFC7637" f
NVGRE (Network Virtualization using GRE) <xref target="RFC7637" format ormat="default"/></t>
="default"/>;</t>
</li> </li>
<li> <li>
<t>GTP (GPRS Tunnelling Protocol), specifically GTPv1 <xref target="GT <t>GPRS Tunnelling Protocol (GTP), specifically GTPv1 <xref target="GT
Pv1" format="default"/>, GTP v1 User Plane <xref target="GTPv1-U" format="defaul Pv1" format="default"/>, GTP v1 User Plane <xref target="GTPv1-U" format="defaul
t"/>, GTP v2 t"/>, and GTP v2
Control Plane <xref target="GTPv2-C" format="default"/>;</t> Control Plane <xref target="GTPv2-C" format="default"/></t>
</li> </li>
<li> <li>
<t>Teredo <xref target="RFC4380" format="default"/>;</t> <t>Teredo <xref target="RFC4380" format="default"/></t>
</li> </li>
<li> <li>
<t>CAPWAP (Control And Provisioning of Wireless Access Points) <xref t arget="RFC5415" format="default"/>;</t> <t>Control And Provisioning of Wireless Access Points (CAPWAP) <xref t arget="RFC5415" format="default"/>;</t>
</li> </li>
<li> <li>
<t>LISP (Locator/Identifier Separation Protocol) <xref target="RFC9300 " format="default"/>;</t> <t>Locator/Identifier Separation Protocol (LISP) <xref target="RFC9300 " format="default"/>;</t>
</li> </li>
<li> <li>
<t>AMT (Automatic Multicast Tunneling) <xref target="RFC7450" format=" default"/>;</t> <t>Automatic Multicast Tunneling (AMT) <xref target="RFC7450" format=" default"/>;</t>
</li> </li>
<li> <li>
<t>VXLAN (Virtual eXtensible Local Area Network) <xref target="RFC7348 " format="default"/> and VXLAN-GPE <xref target="I-D.ietf-nvo3-vxlan-gpe" format ="default"/>;</t> <t>Virtual eXtensible Local Area Network (VXLAN) <xref target="RFC7348 " format="default"/> and Generic Protocol Extensions for VXLAN (VXLAN-GPE) <xref target="I-D.ietf-nvo3-vxlan-gpe" format="default"/>;</t>
</li> </li>
<li> <li>
<t>The Network Service Header (NSH <xref target="RFC8300" format="defa <t>The Network Service Header (NSH) <xref target="RFC8300" format="def
ult"/>) for ault"/> for
Service Function Chaining (SFC);</t> Service Function Chaining (SFC)</t>
</li> </li>
<li> <li>
<t>Geneve <xref target="RFC8926" format="default"/>;</t> <t>Geneve <xref target="RFC8926" format="default"/></t>
</li> </li>
<li> <li>
<t>Direct tunnelling of an IP packet within a UDP/IP datagram (see <t>Direct tunnelling of an IP packet within a UDP/IP datagram (see <xr
Section 3.1.11 of <xref target="RFC8085" format="default"/>);</t> ef target="RFC8085" section="3.1.11" sectionFormat="of"/>)</t>
</li> </li>
<li> <li>
<t>TCP Encapsulation of IKE and IPsec Packets (see Section 9.5 of <t>TCP Encapsulation of Internet Key Exchange Protocol (IKE) and IPsec
<xref target="RFC9329" format="default"/>).</t> Packets (see <xref target="RFC9329" section="9.5" sectionFormat="of"/>)</t>
</li> </li>
</ul> </ul>
<t>Some of the listed protocols enable encapsulation of a variety of <t>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 <xref target="rfc6040up_scope" format="default"/>. Otherwise described in <xref target="rfc6040up_scope" format="default"/>. Otherwise,
<xref target="I-D.ietf-tsvwg-ecn-encap-guidelines" format="default"/> gives guid <xref target="RFC9599" format="default"/> gives guidance on how to
ance on how to
design propagation of ECN into other protocols that might encapsulate design propagation of ECN into other protocols that might encapsulate
IP.</t> IP.</t>
<t>Where protocols in the above list need to be updated to specify ECN <t>Where protocols in the above list need to be updated to specify ECN
propagation and they are under IETF change control, update text is given propagation and are under IETF change control, update text is given
in the following subsections. For those not under IETF control, it is in the following subsections. For those not under IETF control, it is
RECOMMENDED that implementations of encapsulation and decapsulation <bcp14>RECOMMENDED</bcp14> that implementations of encapsulation and decap
comply with RFC 6040. It is also RECOMMENDED that their specifications sulation
are updated to add a requirement to comply with RFC 6040 (as updated by comply with <xref target="RFC6040"/>. It is also <bcp14>RECOMMENDED</bcp14
> that their specifications
are updated to add a requirement to comply with <xref target="RFC6040"/> (
as updated by
the present document).</t> the present document).</t>
<t>PPTP is not under the change control of the IETF, but it has been <t>PPTP is not under the change control of the IETF, but it has been
documented in an informational RFC <xref target="RFC2637" format="default" />. However, documented in an Informational RFC <xref target="RFC2637" format="default" />. However,
there is no need for the present specification to update PPTP because there is no need for the present specification to update PPTP because
L2TP has been developed as a standardized replacement.</t> L2TP has been developed as a standardized replacement.</t>
<t>NVGRE is not under the change control of the IETF, but it has been <t>NVGRE is not under the change control of the IETF, but it has been
documented in an informational RFC <xref target="RFC7637" format="default" documented in an Informational RFC <xref target="RFC7637" format="default"
/>. NVGRE is a />. NVGRE is a
specific use-case of GRE (it re-purposes the key field from the initial specific use case of GRE (it re-purposes the key field from the initial
specification of GRE <xref target="RFC1701" format="default"/> as a Virtua l Subnet ID). specification of GRE <xref target="RFC1701" format="default"/> as a Virtua l Subnet ID).
Therefore the text that updates GRE in <xref target="rfc6040up_GRE" format ="default"/> Therefore, the text that updates GRE in <xref target="rfc6040up_GRE" forma t="default"/>
below is also intended to update NVGRE.</t> below is also intended to update NVGRE.</t>
<t>Although the definition of the various GTP shim headers is under the <t>Although the definition of the various GTP shim headers is under the
control of the 3rd Generation Partnership Project (3GPP), it is hard to control of the Third Generation Partnership Project (3GPP), it is hard to
determine whether the 3GPP or the IETF controls standardization of the determine whether the 3GPP or the IETF controls standardization of the
<em>process</em> of adding both a GTP and an IP <em>process</em> of adding both a GTP and an IP
header to an inner IP header. Nonetheless, the present specification is 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 provided so that the 3GPP can refer to it from any of its own
specifications of GTP and IP header processing.</t> specifications of GTP and IP header processing.</t>
<t>The specification of CAPWAP already specifies RFC 3168 ECN <t>The specification of CAPWAP already specifies <xref target="RFC3168"/>
propagation and ECN capability negotiation. Without modification the ECN
CAPWAP specification already interworks with the backward compatible propagation and ECN capability negotiation. Without modification, the
updates to RFC 3168 in RFC 6040.</t> CAPWAP specification already interworks with the backward-compatible
<t>LISP made the ECN propagation procedures in RFC 3168 mandatory from updates to <xref target="RFC3168"/> in <xref target="RFC6040"/>.</t>
the start. RFC 3168 has since been updated by RFC 6040, but the changes <t>LISP made the ECN propagation procedures in <xref target="RFC3168"/> ma
are backwards compatible so there is still no need for LISP tunnel ndatory from
the start. <xref target="RFC3168"/> has since been updated by <xref target
="RFC6040"/>, but the changes
are backwards compatible, so there is still no need for LISP tunnel
endpoints to negotiate their ECN capabilities.</t> endpoints to negotiate their ECN capabilities.</t>
<t>VXLAN is not under the change control of the IETF but it has been <t>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
Protocol Extension) is being documented under IETF change control. It is <bcp14>RECOMMENDED</bcp14> that VXLAN implementations comply with <xref ta
RECOMMENDED that VXLAN and VXLAN-GPE implementations comply with RFC rget="RFC6040"/>
6040 when the VXLAN header is inserted between (or removed from between) when the VXLAN header is inserted between (or removed from between)
IP headers. The authors of any future update to these specifications are IP headers. The authors of any future update of the VXLAN spec are also
encouraged to add a requirement to comply with RFC 6040 as updated by encouraged to add a requirement to comply with <xref target="RFC6040"/> as
the present specification.<!--{ToDo: Update this text if the VXLAN-GPE dra updated by
ft gets updated before the present draft reaches the RFC Editor.}--> the present specification. In contrast,
VXLAN-GPE is being documented under IETF change control and it does
require compliance with <xref target="RFC6040"/>.
</t> </t>
<t>The Network Service Header (NSH <xref target="RFC8300" format="default" />) has been <t>The Network Service Header (NSH) <xref target="RFC8300" format="default "/> has been
defined as a shim-based encapsulation to identify the Service Function defined as a shim-based encapsulation to identify the Service Function
Path (SFP) in the Service Function Chaining (SFC) architecture <xref targe t="RFC7665" format="default"/>. A proposal has been made for the processing of E CN Path (SFP) in the Service Function Chaining (SFC) architecture <xref targe t="RFC7665" format="default"/>. A proposal has been made for the processing of E CN
when handling transport encapsulation <xref target="I-D.ietf-sfc-nsh-ecn-s upport" format="default"/>.</t> when handling transport encapsulation <xref target="I-D.ietf-sfc-nsh-ecn-s upport" format="default"/>.</t>
<t>The specification of Geneve already refers to RFC 6040 for ECN <t>The specification of Geneve already refers to <xref target="RFC6040"/> for ECN
encapsulation.</t> encapsulation.</t>
<t>Section 3.1.11 of RFC 8085 already explains that a tunnel that <t><xref target="RFC8085" section="3.1.11" sectionFormat="of"/> already ex
encapsulates an IP header within a UDP/IP datagram needs to follow RFC plains that a tunnel that
6040 when propagating the ECN field between inner and outer IP headers. encapsulates an IP header within a UDP/IP datagram needs to follow <xref t
arget="RFC6040"/> when propagating the ECN field between inner and outer IP head
ers.
<xref target="rfc6040up_scope" format="default"/> of the present specifica tion updates <xref target="rfc6040up_scope" format="default"/> of the present specifica tion updates
RFC 6040 to clarify that its scope includes cases with a shim header <xref target="RFC6040"/> to clarify that its scope includes cases with a s
between the IP headers. So it indirectly updates the scope of RFC 8085 him header
between the IP headers. So it indirectly updates the scope of <xref target
="RFC8085"/>
to include cases with a shim header as well as a UDP header between the to include cases with a shim header as well as a UDP header between the
IP headers.</t> IP headers.</t>
<t>The requirements in <xref target="rfc6040up_sec_safe" format="default"/
> update RFC <t>The requirements in <xref target="rfc6040up_sec_safe" format="default"/
6040, and hence indirectly update the UDP usage guidelines in RFC 8085 > update <xref target="RFC6040"/>, and hence also indirectly update the UDP usag
e guidelines in <xref target="RFC8085"/>
to add the important but previously unstated requirement that, if the to add the important but previously unstated requirement that, if the
UDP tunnel egress does not, or might not, support ECN propagation, a UDP 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.&nbsp;by tunnel ingress has to clear the outer IP ECN field to 0b00, e.g., by
configuration.</t> configuration.</t>
<t>Section 9.5 of TCP Encapsulation of IKE and IPsec Packets <xref target= <t><xref target="RFC9329" sectionFormat="of" section="9.5"/> already recom
"RFC9329" format="default"/> already recommends the compatibility mode of RFC 60 mends the compatibility mode of <xref target="RFC6040"/>
40 in this case because there is not a one-to-one mapping between inner
in this case, because there is not a one-to-one mapping between inner and outer packets when TCP encapsulates IKE or IPsec.</t>
and outer packets.</t>
<section anchor="rfc6040up_rfc-updates" numbered="true" toc="default"> <section anchor="rfc6040up_rfc-updates" numbered="true" toc="default">
<name>Specific Updates to Protocols under IETF Change Control</name> <name>Specific Updates to Protocols under IETF Change Control</name>
<section anchor="rfc6040up_L2TPv3" numbered="true" toc="default"> <section anchor="rfc6040up_L2TPv3" numbered="true" toc="default">
<name>L2TP (v2 and v3) ECN Extension</name> <name>L2TP (v2 and v3) ECN Extension</name>
<t>The L2TP terminology used here is defined in <xref target="RFC2661" format="default"/> and <xref target="RFC3931" format="default"/>.</t> <t>The L2TP terminology used here is defined in <xref target="RFC2661" format="default"/> and <xref target="RFC3931" format="default"/>.</t>
<t>L2TPv3 <xref target="RFC3931" format="default"/> is used as a shim <t>L2TPv3 <xref target="RFC3931" format="default"/> is used as a
header between shim header between any packet-switched network (PSN) header (e.g.,
any packet-switched network (PSN) header (e.g.&nbsp;IPv4, IPv6, IPv4, IPv6, and MPLS) and many types of L2 headers. The L2TPv3 shim
MPLS) and many types of layer 2 (L2) header. The L2TPv3 shim header header encapsulates an L2-specific sub-layer, then an L2 header that
encapsulates an L2-specific sub-layer then an L2 header that is is likely to contain an inner IP header (v4 or v6).
likely to contain an inner IP header (v4 or v6). Then this whole Then this whole stack of headers can be encapsulated within an optional
stack of headers can be encapsulated optionally within an outer UDP outer UDP header and an outer PSN header that is typically IP (v4 or v6).
header then an outer PSN header that is typically IP (v4 or v6).</t> </t>
<t>L2TPv2 is used as a shim header between any PSN header and a PPP <t>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.</t> header, which is in turn likely to encapsulate an IP header.</t>
<t>Even though these shims are rather fat (particularly in the case <t>Even though these shims are rather fat (particularly in the case
of L2TPv3), they still fit the definition of a tightly coupled shim of L2TPv3), they still fit the definition of a tightly coupled shim
header over an encapsulating header (<xref target="rfc6040up_feasibili ty" format="default"/>), because all the headers header over an encapsulating header (<xref target="rfc6040up_feasibili ty" format="default"/>) because all the headers
encapsulating the L2 header are added (or removed) together. L2TPv2 encapsulating the L2 header are added (or removed) together. L2TPv2
and L2TPv3 are therefore within the scope of RFC 6040, as updated by and L2TPv3 are therefore within the scope of <xref target="RFC6040"/>,
<xref target="rfc6040up_scope" format="default"/> above.</t> as updated by
<xref target="rfc6040up_scope" format="default"/>.</t>
<t>Implementation of the ECN extension to L2TPv2 and L2TPv3 defined <t>Implementation of the ECN extension to L2TPv2 and L2TPv3 defined
in <xref target="rfc6040up_L2TP_ECN" format="default"/> below is RECOM in <xref target="rfc6040up_L2TP_ECN" format="default"/> is <bcp14>RECO
MENDED, in MMENDED</bcp14> in
order to provide the benefits of ECN <xref target="RFC8087" format="de order to provide the benefits of ECN <xref target="RFC8087" format="de
fault"/>, fault"/>
whenever a node within an L2TP tunnel becomes the bottleneck for an whenever a node within an L2TP tunnel becomes the bottleneck for an
end-to-end traffic flow.</t> end-to-end traffic flow.</t>
<section anchor="rfc6040up_L2TP_Safe" numbered="true" toc="default"> <section anchor="rfc6040up_L2TP_Safe" numbered="true" toc="default">
<name>Safe Configuration of a 'Non-ECN' Ingress LCCE</name> <name>Safe Configuration of a "Non-ECN" Ingress LCCE</name>
<t>The following text is appended to both Section 5.3 of <xref targe <t>The following text is appended to both <xref target="RFC2661" sec
t="RFC2661" format="default"/> and Section 4.5 of <xref target="RFC3931" format= tion="5.3" sectionFormat="of"/> and <xref target="RFC3931" section="4.5" section
"default"/> as Format="of"/> as
an update to the base L2TPv2 and L2TPv3 specifications:</t> an update to the base L2TPv2 and L2TPv3 specifications:</t>
<ul empty="true" spacing="normal"> <blockquote>The operator of an LCCE that does not support the ECN extension in
<li> <xref target="rfc6040up_L2TP_ECN" format="default"/> of RFC 9601
<t>The operator of an LCCE that does not support the ECN <bcp14>MUST</bcp14> follow the configuration requirements in <xref
Extension in <xref target="rfc6040up_L2TP_ECN" format="default"/ target="rfc6040up_sec_safe" format="default"/> of RFC 9601 to ensure it
> of [this clears the outer IP ECN field to 0b00 when the outer PSN header is IP (v4 or
document] MUST follow the configuration requirements in <xref ta v6).
rget="rfc6040up_sec_safe" format="default"/> of [this document] to ensure it </blockquote>
clears the outer IP ECN field to 0b00 when the outer PSN
header is IP (v4 or v6).</t>
</li>
</ul>
<t>In particular, for an L2TP Control Connection Endpoint (LCCE) <t>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 that configuration of how it propagates the ECN field between
inner and outer IP headers MUST be independent of any inner and outer IP headers <bcp14>MUST</bcp14> be independent of any
configuration of the Diffserv extension of L2TP <xref target="RFC330 8" format="default"/>.</t> configuration of the Diffserv extension of L2TP <xref target="RFC330 8" format="default"/>.</t>
</section> </section>
<section anchor="rfc6040up_L2TP_ECN" numbered="true" toc="default"> <section anchor="rfc6040up_L2TP_ECN" numbered="true" toc="default">
<name>ECN Extension for L2TP (v2 or v3)</name> <name>ECN Extension for L2TP (v2 or v3)</name>
<t>When the outer PSN header and the payload inside the L2 header <t>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 are both IP (v4 or v6), an LCCE will propagate
follow the rules for propagation of the ECN field at ingress and the ECN field at ingress and egress by following the rules in
egress in Section 4 of RFC 6040 <xref target="RFC6040" format="defau <xref target="RFC6040" section="4" sectionFormat="of"/>.</t>
lt"/>.</t> <t>Before encapsulating any data packets, <xref target="RFC6040"/>
<t>Before encapsulating any data packets, RFC 6040 requires an requires an ingress LCCE to check that the egress LCCE supports
ingress LCCE to check that the egress LCCE supports ECN ECN propagation as defined in <xref target="RFC6040"/> or one of
propagation as defined in RFC 6040 or one of its compatible its compatible predecessors (<xref target="RFC4301"
predecessors (<xref target="RFC4301" format="default"/> or the full format="default"/> or the full functionality mode of <xref
functionality target="RFC3168" format="default"/>).
mode of <xref target="RFC3168" format="default"/>). If the egress su If the egress supports ECN
pports ECN
propagation, the ingress LCCE can use the normal mode of 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 <xref targ Otherwise, the ingress LCCE has to use compatibility mode <xref
et="RFC6040" format="default"/> (clearing the outer IP ECN field to 0b00).</t> target="RFC6040" format="default"/> (clearing the outer IP ECN
field to 0b00).</t>
<t>An LCCE can determine the remote LCCE's support for ECN either <t>An LCCE can determine the remote LCCE's support for ECN either
statically (by configuration) or by dynamic discovery during setup statically (by configuration) or by dynamic discovery during setup
of each control connection between the LCCEs, using the ECN of each control connection between the LCCEs using the ECN
Capability AVP defined in <xref target="rfc6040up_L2TP_ECN_Capabilit Capability Attribute-Value Pair (AVP) defined in <xref target="rfc60
y_AVP" format="default"/> below.</t> 40up_L2TP_ECN_Capability_AVP" format="default"/>.</t>
<t>Where the outer PSN header is some protocol other than IP that <t>Where the outer PSN header is some protocol other than IP that
supports ECN, the appropriate ECN propagation specification will supports ECN, the appropriate ECN propagation specification will
need to be followed, e.g.&nbsp;"Explicit Congestion Marking in need to be followed, e.g., <xref target="RFC5129" format="default"/>
MPLS" <xref target="RFC5129" format="default"/>. Where no specificat for MPLS. Where no specification exists for
ion exists for ECN propagation by a particular PSN, <xref target="RFC9599" format="
ECN propagation by a particular PSN, <xref target="I-D.ietf-tsvwg-ec default"/> gives general
n-encap-guidelines" format="default"/> gives general
guidance on how to design ECN propagation into a protocol that guidance on how to design ECN propagation into a protocol that
encapsulates IP.</t> encapsulates IP.</t>
<section anchor="rfc6040up_L2TP_ECN_Capability_AVP" numbered="true" toc="default"> <section anchor="rfc6040up_L2TP_ECN_Capability_AVP" numbered="true" toc="default">
<name>ECN Capability AVP for Negotiation between LCCEs</name> <name>ECN Capability AVP for Negotiation between LCCEs</name>
<t>The ECN Capability Attribute-Value Pair (AVP) defined here <t>The ECN Capability AVP defined here
has Attribute Type TBD. The AVP has the following format:</t> has Attribute Type 103. The AVP has the following format:</t>
<figure anchor="Fig_rfc6040up_LCCE_ECN_Capabiliy_AVP"> <figure anchor="Fig_rfc6040up_LCCE_ECN_Capabiliy_AVP">
<name>ECN Capability Attribute Value Pair for L2TP (v2 or v3)</n <name>ECN Capability AVP for L2TP (v2 or v3)</name>
ame> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork name="" type="" align="left" alt=""><![CDATA[ 0 0 1 2 3
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 103 |
| TBD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure> </figure>
<t>This AVP MAY be present in the following message types: SCCRQ <t>This AVP <bcp14>MAY</bcp14> be present in the Start-Control-Con
and SCCRP (Start-Control-Connection-Request and nection-Request (SCCRQ) and Start-Control-Connection-Reply (SCCRP) message types
Start-Control-Connection-Reply). This AVP MAY be hidden (the . This AVP <bcp14>MAY</bcp14> be hidden (the
H-bit set to 0 or 1) and is optional (M-bit not set). The length H-bit is set to 0 or 1) and is optional (the M-bit is not set). Th
e length
(before hiding) of this AVP is 6 octets. The Vendor ID is the (before hiding) of this AVP is 6 octets. The Vendor ID is the
IETF Vendor ID of 0.</t> IETF Vendor ID of 0.</t>
<t>When an LCCE sends an ECN Capability AVP, it indicates that <t>When an LCCE sends an ECN Capability AVP, it indicates that
it supports ECN propagation. When no ECN Capability AVP is it supports ECN propagation. When no ECN Capability AVP is
present, it indicates that the sender does not support ECN present, it indicates that the sender does not support ECN
propagation.</t> propagation.</t>
<t>If an LCCE initiating a control connection supports ECN <t>If an LCCE initiating a control connection supports ECN
propagation, it will send a Start-Control-Connection-Request propagation, it will send an SCCRQ containing an ECN Capability AV
(SCCRQ) containing an ECN Capability AVP. If the tunnel P. If the tunnel
terminator supports ECN, it will return a terminator supports ECN, it will return an
Start-Control-Connection-Reply (SCCRP) that also includes an ECN SCCRP that also includes an ECN
Capability AVP. Then, for any sessions created by that control Capability AVP.
Then, for any sessions created by that control
connection, both ends of the tunnel can use the normal mode of connection, both ends of the tunnel can use the normal mode of
RFC 6040, i.e.&nbsp;they can copy the IP ECN field from inner to <xref target="RFC6040"/>; i.e., they can copy the IP ECN field fro m inner to
outer when encapsulating data packets.</t> outer when encapsulating data packets.</t>
<t>If, on the other hand, the tunnel terminator does not support <t>On the other hand, if the tunnel terminator does not support
ECN it will ignore the ECN Capability AVP and send an SCCRP to ECN, it will ignore the ECN Capability AVP and send an SCCRP to
the tunnel initiator without an ECN Capability AVP. The tunnel the tunnel initiator without an ECN Capability AVP. The tunnel
initiator interprets the absence of the ECN Capability flag in initiator interprets the absence of the ECN Capability flag in
the SCCRP as an indication that the tunnel terminator is the SCCRP as an indication that the tunnel terminator is
incapable of supporting ECN. When encapsulating data packets for incapable of supporting ECN. When encapsulating data packets for
any sessions created by that control connection, the tunnel any sessions created by that control connection, the tunnel
initiator will then use the compatibility mode of RFC 6040 to initiator will then use the compatibility mode of <xref target="RF C6040"/> to
clear the ECN field of the outer IP header to 0b00.</t> clear the ECN field of the outer IP header to 0b00.</t>
<t>If the tunnel terminator does not support this ECN extension, <t>If the tunnel terminator does not support this ECN extension,
the network operator is still expected to configure it to comply the network operator is still expected to configure it to comply
with the safety provisions set out in <xref target="rfc6040up_L2TP _Safe" format="default"/> above, when it acts as an ingress with the safety provisions set out in <xref target="rfc6040up_L2TP _Safe" format="default"/> when it acts as an ingress
LCCE.</t> LCCE.</t>
<t>If ECN support by the ingress and egress LCCEs is configured
statically, as allowed in <xref target="rfc6040up_L2TP_ECN" format
="default"/>,
they both ignore the presence or absence of any ECN capability AVP
.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="rfc6040up_GRE" numbered="true" toc="default"> <section anchor="rfc6040up_GRE" numbered="true" toc="default">
<name>GRE</name> <name>GRE</name>
<t>The GRE terminology used here is defined in <xref target="RFC2784" format="default"/>. GRE is often used as a tightly coupled shim <t>The GRE terminology used here is defined in <xref target="RFC2784" format="default"/>. GRE is often used as a tightly coupled shim
header between IP headers. Sometimes the GRE shim header header between IP headers. Sometimes, the GRE shim header
encapsulates an L2 header, which might in turn encapsulate an IP encapsulates an L2 header, which might in turn encapsulate an IP
header. Therefore GRE is within the scope of RFC 6040 as updated by header. Therefore, GRE is within the scope of <xref target="RFC6040"/>
<xref target="rfc6040up_scope" format="default"/> above.</t> as updated by
<xref target="rfc6040up_scope" format="default"/>.</t>
<t>Implementation of support for <xref target="RFC6040" format="defaul t"/> as updated <t>Implementation of support for <xref target="RFC6040" format="defaul t"/> as updated
by the present specification is RECOMMENDED for GRE tunnel by the present specification is <bcp14>RECOMMENDED</bcp14> for GRE tun
endpoints, in order to provide the benefits of ECN <xref target="RFC80 nel
87" format="default"/> whenever a node within a GRE tunnel becomes the endpoints in order to provide the benefits of ECN <xref target="RFC808
7" format="default"/> whenever a node within a GRE tunnel becomes the
bottleneck for an end-to-end IP traffic flow tunnelled over GRE bottleneck for an end-to-end IP traffic flow tunnelled over GRE
using IP as the delivery protocol (outer header).</t> using IP as the delivery protocol (outer header).</t>
<t>GRE itself does not support dynamic set-up and configuration of <t>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) <xref target="RFC2332" format="default"/>, Mobile IPv4 Resolution Protocol (NHRP) <xref target="RFC2332" format="default"/>, Mobile IPv4
(MIP4) <xref target="RFC5944" format="default"/>, Mobile IPv6 (MIP6) < (MIP4) <xref target="RFC5944" format="default"/>, Mobile IPv6 (MIP6) <
xref target="RFC6275" format="default"/>, Proxy Mobile IP (PMIP) <xref target="R xref target="RFC6275" format="default"/>, Proxy Mobile IP (PMIP) <xref target="R
FC5845" format="default"/> FC5845" format="default"/>,
and IKEv2 <xref target="RFC7296" format="default"/> are sometimes used and IKEv2 <xref target="RFC7296" format="default"/>, are sometimes use
to set up GRE d to set up GRE
tunnels dynamically.</t> tunnels dynamically.</t>
<t>When these control protocols set up IP-in-IP or IPSec tunnels, it <t>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 is 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 <xref target="RFC6040"/> or one of its compatible predecess
or the full functionality mode of RFC 3168). However, if they use a ors (<xref target="RFC4301"/>
or the full functionality mode of <xref target="RFC3168"/>). However,
if they use a
GRE encapsulation, this presumption is less sound.</t> GRE encapsulation, this presumption is less sound.</t>
<t>Therefore, if the outer delivery protocol is IP (v4 or v6) the <t>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
<xref target="rfc6040up_sec_safe" format="default"/> above. <xref targ <xref target="rfc6040up_sec_safe" format="default"/>. <xref target="rf
et="rfc6040up_GRE_Safe" format="default"/> below updates the base GRE c6040up_GRE_Safe" format="default"/> updates the base GRE
specification with this requirement, to emphasize its specification with this requirement to emphasize its
importance.</t> importance.</t>
<t>Where the delivery protocol is some protocol other than IP that <t>Where the delivery protocol is some protocol other than IP that
supports ECN, the appropriate ECN propagation specification will supports ECN, the appropriate ECN propagation specification will
need to be followed, e.g.&nbsp;Explicit Congestion Marking in MPLS need to be followed, e.g., <xref target="RFC5129" format="default"/> f
<xref target="RFC5129" format="default"/>. Where no specification exis or MPLS. Where no specification exists for ECN
ts for ECN propagation by a particular PSN, <xref target="RFC9599" format="defaul
propagation by a particular PSN, <xref target="I-D.ietf-tsvwg-ecn-enca t"/> gives more general
p-guidelines" format="default"/> gives more 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.</t> encapsulate IP.</t>
<section anchor="rfc6040up_GRE_Safe" numbered="true" toc="default"> <section anchor="rfc6040up_GRE_Safe" numbered="true" toc="default">
<name>Safe Configuration of a 'Non-ECN' GRE Ingress</name> <name>Safe Configuration of a "Non-ECN" GRE Ingress</name>
<t>The following text is appended to Section 3 of <xref target="RFC2 <t>The following text is appended to <xref target="RFC2784" section=
784" format="default"/> as an update to the base GRE "3" sectionFormat="of"/> as an update to the base GRE
specification:</t> specification:</t>
<ul empty="true" spacing="normal"> <blockquote>
<li> The operator of a GRE tunnel ingress <bcp14>MUST</bcp14> follow the configuratio
<t>The operator of a GRE tunnel ingress MUST follow the n requirements in <xref target="rfc6040up_sec_safe" format="default"/> of RFC 96
configuration requirements in <xref target="rfc6040up_sec_safe" 01 when the outer delivery protocol is IP (v4 or v6).
format="default"/> of [this document] when the </blockquote>
outer delivery protocol is IP (v4 or v6).</t>
</li>
</ul>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Teredo</name> <name>Teredo</name>
<t>Teredo <xref target="RFC4380" format="default"/> provides a way to tunnel IPv6 <t>Teredo <xref target="RFC4380" format="default"/> provides a way to tunnel IPv6
over an IPv4 network, with a UDP-based shim header between the over an IPv4 network with a UDP-based shim header between the
two.</t> two.</t>
<t>For Teredo tunnel endpoints to provide the benefits of ECN, the <t>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.</t> the IPv6 outer.</t>
<t>Those implementations known to the authors at the time of writing <t>Those implementations known to the authors at the time of writing
do not support propagation of ECN, but that they do safely zero the do not support propagation of ECN, but they do safely zero the
ECN field in the outer IPv6 header. However, the specification does ECN field in the outer IPv6 header. However, the specification does
not mention anything about this.</t> not mention anything about this.</t>
<t>To make existing Teredo deployments safe, it would be possible to <t>To make existing Teredo deployments safe, it would be possible to
add ECN capability negotiation to those that are subject to remote add 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 OS 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.</t> hosts.</t>
<t>Therefore, until ECN support is added to the specification of <t>Therefore, until ECN support is added to the specification of
Teredo, the only feasible further safety precaution available here Teredo, the only feasible further safety precaution available here
is to update the specification of Teredo implementations with the is to update the specification of Teredo implementations with the
following text, as a new section 5.1.3:</t> following text as a new section:</t>
<ul empty="true" spacing="normal"> <blockquote>
<li> <t>5.1.3. Safe "Non-ECN" Teredo Encapsulation</t>
<t>"5.1.3 Safe 'Non-ECN' Teredo Encapsulation</t>
<t>A Teredo tunnel ingress implementation that does <t>A Teredo tunnel ingress implementation that does
not support ECN propagation as defined in RFC 6040 or one of its not support ECN propagation as defined in <xref target="RFC6040"/>
compatible predecessors (RFC 4301 or the full functionality mode or one of its
of RFC 3168) MUST zero the ECN field in the outer IPv6 compatible predecessors (<xref target="RFC4301"/> or the full func
header."</t> tionality mode
</li> of <xref target="RFC3168"/>) <bcp14>MUST</bcp14> zero the ECN fiel
</ul> d in the outer IPv6
header.</t>
</blockquote>
</section> </section>
<section anchor="rfc6040up_AMT" numbered="true" toc="default"> <section anchor="rfc6040up_AMT" numbered="true" toc="default">
<name>AMT</name> <name>AMT</name>
<t>Automatic Multicast Tunneling (AMT <xref target="RFC7450" format="d efault"/>) is a <t>AMT <xref target="RFC7450" format="default"/> is a
tightly coupled shim header that encapsulates an IP packet and is tightly coupled shim header that encapsulates an IP packet and is
itself encapsulated within a UDP/IP datagram. Therefore AMT is encapsulated within a UDP/IP datagram. Therefore, AMT is
within the scope of RFC 6040 as updated by <xref target="rfc6040up_sco within the scope of <xref target="RFC6040"/> as updated by <xref targe
pe" format="default"/> above.</t> t="rfc6040up_scope" format="default"/>.</t>
<t>Implementation of support for <xref target="RFC6040" format="defaul t"/> as updated <t>Implementation of support for <xref target="RFC6040" format="defaul t"/> as updated
by the present specification is RECOMMENDED for AMT tunnel by the present specification is <bcp14>RECOMMENDED</bcp14> for AMT tun
endpoints, in order to provide the benefits of ECN <xref target="RFC80 nel
87" format="default"/> whenever a node within an AMT tunnel becomes the endpoints in order to provide the benefits of ECN <xref target="RFC808
7" format="default"/> whenever a node within an AMT tunnel becomes the
bottleneck for an IP traffic flow tunnelled over AMT.</t> bottleneck for an IP traffic flow tunnelled over AMT.</t>
<t>To comply with RFC 6040, an AMT relay and gateway will follow the <t>To comply with <xref target="RFC6040"/>, an AMT relay and gateway w
rules for propagation of the ECN field at ingress and egress ill follow the
respectively, as described in Section 4 of RFC 6040 <xref target="RFC6 rules for propagation of the ECN field at ingress and egress,
040" format="default"/>.</t> respectively, as described in <xref target="RFC6040" section="4" secti
<t>Before encapsulating any data packets, RFC 6040 requires an onFormat="of"/>.</t>
<t>Before encapsulating any data packets, <xref target="RFC6040"/> req
uires an
ingress AMT relay to check that the egress AMT gateway supports ECN ingress 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 <xref target="RFC6040"/> or one of its compa
predecessors (RFC 4301 or the full functionality mode of RFC 3168). tible
predecessors (<xref target="RFC4301"/> or the full functionality mode
of <xref target="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 <xref target=" RFC6040" format="default"/>.</t> which means it has to clear the outer ECN field to zero <xref target=" RFC6040" format="default"/>.</t>
<t>An AMT tunnel is created dynamically (not manually), so the relay <t>An AMT tunnel is created dynamically (not manually), so the relay
will need to determine the remote gateway's support for ECN using will need to determine the remote gateway's support for ECN using
the ECN capability declaration defined in <xref target="rfc6040up_AMT_ ECN_Capability" format="default"/> below.</t> the ECN capability declaration defined in <xref target="rfc6040up_AMT_ ECN_Capability" format="default"/>.</t>
<section anchor="rfc6040up_AMT_Safe" numbered="true" toc="default"> <section anchor="rfc6040up_AMT_Safe" numbered="true" toc="default">
<name>Safe Configuration of a 'Non-ECN' Ingress AMT Relay</name> <name>Safe Configuration of a "Non-ECN" Ingress AMT Relay</name>
<t>The following text is appended to Section 4.2.2 of <xref target=" <t>The following text is appended to <xref target="RFC7450" section=
RFC7450" format="default"/> as an update to the AMT specification:</t> "4.2.2" sectionFormat="of"/> as an update to the AMT specification:</t>
<ul empty="true" spacing="normal"> <blockquote>
<li> The operator of an AMT relay that does not support <xref target=
<t>The operator of an AMT relay that does not support RFC 6040 "RFC6040"/>
or one of its compatible predecessors (RFC 4301 or the full or one of its compatible predecessors (<xref target="RFC4301"/>
functionality mode of RFC 3168) MUST follow the configuration or the full
requirements in <xref target="rfc6040up_sec_safe" format="defaul functionality mode of <xref target="RFC3168"/>) <bcp14>MUST</bcp
t"/> of [this 14> follow the configuration
document] to ensure it clears the outer IP ECN field to requirements in <xref target="rfc6040up_sec_safe" format="defaul
zero.</t> t"/> of RFC 9601 to ensure it clears the outer IP ECN field to
</li> zero.
</ul> </blockquote>
</section> </section>
<section anchor="rfc6040up_AMT_ECN_Capability" numbered="true" toc="de fault"> <section anchor="rfc6040up_AMT_ECN_Capability" numbered="true" toc="de fault">
<name>ECN Capability Declaration of an AMT Gateway</name> <name>ECN Capability Declaration of an AMT Gateway</name>
<figure anchor="Fig_rfc6040up_AMT_ECN_Capability_Declaration"> <figure anchor="Fig_rfc6040up_AMT_ECN_Capability_Declaration">
<name>Updated AMT Request Message Format</name> <name>Updated AMT Request Message Format</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure> </figure>
<t>Bit 14 of the AMT Request Message counting from 0 (or bit 7 of <t>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 the Reserved field counting from 1) is defined here as the AMT
Gateway ECN Capability flag (E), as shown in <xref target="Fig_rfc60 40up_AMT_ECN_Capability_Declaration" format="default"/>. The Gateway ECN Capability flag (E) as shown in <xref target="Fig_rfc604 0up_AMT_ECN_Capability_Declaration" format="default"/>. The
definitions of all other fields in the AMT Request Message are definitions of all other fields in the AMT Request Message are
unchanged from RFC 7450.</t> unchanged from <xref target="RFC7450"/>.</t>
<t>When the E flag is set to 1, it indicates that the sender of <t>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 the message supports <xref target="RFC6040"/> ECN propagation. When it is cleared
to zero, it indicates the sender of the message does not support to zero, it indicates the sender of the message does not support
RFC 6040 ECN propagation. An AMT gateway "that supports RFC 6040 <xref target="RFC6040"/> ECN propagation. An AMT gateway "that suppo rts <xref target="RFC6040"/>
ECN propagation" means one that propagates the ECN field to the ECN propagation" means one that propagates the ECN field to the
forwarded data packet based on the combination of arriving inner forwarded data packet based on the combination of arriving inner
and outer ECN fields, as defined in Section 4 of RFC 6040.</t> and outer ECN fields as defined in <xref target="RFC6040" section="4 " sectionFormat="of"/>.</t>
<t>The other bits of the Reserved field remain reserved. They will <t>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 received or forwarded as specified in <xref target="RFC7450" section
7450.</t> ="5.1.3.3" sectionFormat="of"/>.</t>
<t>An AMT gateway that does not support RFC 6040 MUST NOT set the <t>An AMT gateway that does not support <xref target="RFC6040"/> <bc
p14>MUST NOT</bcp14> set the
E flag of its Request Message to 1.</t> E flag of its Request Message to 1.</t>
<t>An AMT gateway that supports RFC 6040 ECN propagation MUST set <t>An AMT gateway that supports <xref target="RFC6040"/> ECN propaga tion <bcp14>MUST</bcp14> set
the E flag of its Relay Discovery Message to 1.</t> the E flag of its Relay Discovery Message to 1.</t>
<t>The action of the corresponding AMT relay that receives a <t>The action of the corresponding AMT relay that receives a
Request message with the E flag set to 1 depends on whether the Request message with the E flag set to 1 depends on whether the
relay itself supports RFC 6040 ECN propagation:</t> relay itself supports <xref target="RFC6040"/> ECN propagation:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>If the relay supports RFC 6040 ECN propagation, it will <t>If the relay supports <xref target="RFC6040"/> ECN propagatio n, it will
store the ECN capability of the gateway along with its store the ECN capability of the gateway along with its
address. Then whenever it tunnels datagrams towards this address. Then, whenever it tunnels datagrams towards this
gateway, it MUST use the normal mode of RFC 6040 to propagate gateway, it <bcp14>MUST</bcp14> use the normal mode of <xref tar
the ECN field when encapsulating datagrams (i.e.&nbsp;it get="RFC6040"/> to propagate
copies the IP ECN field from inner to outer).</t> the ECN field when encapsulating datagrams (i.e., it
copies the IP ECN field from inner to outer header).</t>
</li> </li>
<li> <li>
<t>If the discovered AMT relay does not support RFC 6040 ECN <t>If the discovered AMT relay does not support <xref target="RF
propagation, it will ignore the E flag in the Reserved field, C6040"/> ECN
as per section 5.1.3.3. of RFC 7450. </t> propagation, it will ignore the E flag in the Reserved field
<t>If the AMT relay does not support RFC 6040 ECN as per <xref target="RFC7450" section="5.1.3.3" sectionFormat="o
f"/>. </t>
<t>If the AMT relay does not support <xref target="RFC6040"/> EC
N
propagation, the network operator is still expected to propagation, the network operator is still expected to
configure it to comply with the safety provisions set out in configure it to comply with the safety provisions set out in
<xref target="rfc6040up_AMT_Safe" format="default"/> above.</t> <xref target="rfc6040up_AMT_Safe" format="default"/>.</t>
</li> </li>
</ul> </ul>
</section> </section>
</section> </section>
</section> </section>
</section> </section>
<!-- ================================================================ -->
<section anchor="rfc6040up_IANA_Considerations" numbered="true" toc="default "> <section anchor="rfc6040up_IANA_Considerations" numbered="true" toc="default ">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>IANA is requested to assign the following L2TP Control Message <t>IANA has assigned the following AVP in the L2TP "Control Message Attrib
Attribute Value Pair:</t> ute Value Pairs" registry:</t>
<table align="center"> <table align="center">
<thead> <thead>
<tr> <tr>
<th align="left">Attribute Type</th> <th align="left">Attribute Type</th>
<th align="left">Description</th> <th align="left">Description</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">TBD</td> <td align="left">103</td>
<td align="left">ECN Capability</td> <td align="left">ECN Capability</td>
<td align="left">[this document]</td> <td align="left">RFC 9601</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>[TO BE REMOVED: This registration should take place at the following
location:
https://www.iana.org/assignments/l2tp-parameters/l2tp-parameters.xhtml
]</t>
</section> </section>
<!-- ================================================================ -->
<section anchor="rfc6040up_Security_Considerations" numbered="true" toc="def ault"> <section anchor="rfc6040up_Security_Considerations" numbered="true" toc="def ault">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>The Security Considerations in <xref target="RFC6040" format="default"/ > and <xref target="I-D.ietf-tsvwg-ecn-encap-guidelines" format="default"/> appl y equally to the <t>The Security Considerations in <xref target="RFC6040" format="default"/ > and <xref target="RFC9599" format="default"/> apply equally to the
scope defined for the present specification.</t> scope defined for the present specification.</t>
</section> </section>
</middle> </middle>
<back> <back>
<!-- ================================================================ -->
<displayreference target="I-D.ietf-nvo3-vxlan-gpe" to="NVO3-VXLAN-GPE"/>
<displayreference target="I-D.ietf-intarea-tunnels" to="INTAREA-TUNNELS"/>
<displayreference target="I-D.ietf-sfc-nsh-ecn-support" to="SFC-NSH-ECN"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"
<front> />
<title>Key words for use in RFCs to Indicate Requirement Levels</tit <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2474.xml"
le> />
<author fullname="S. Bradner" initials="S." surname="Bradner"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2661.xml"
<date month="March" year="1997"/> />
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2784.xml"
<t>In many standards track documents several words are used to sig />
nify the requirements in the specification. These words are often capitalized. T <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3168.xml"
his document defines these words as they should be interpreted in IETF documents />
. This document specifies an Internet Best Current Practices for the Internet Co <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3931.xml"
mmunity, and requests discussion and suggestions for improvements.</t> />
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4301.xml"
</front> />
<seriesInfo name="BCP" value="14"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4380.xml"
<seriesInfo name="RFC" value="2119"/> />
<seriesInfo name="DOI" value="10.17487/RFC2119"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5129.xml"
</reference> />
<reference anchor="RFC2474" target="https://www.rfc-editor.org/info/rfc2 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6040.xml"
474" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2474.xml"> />
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6660.xml"
<title>Definition of the Differentiated Services Field (DS Field) in />
the IPv4 and IPv6 Headers</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7450.xml"
<author fullname="K. Nichols" initials="K." surname="Nichols"/> />
<author fullname="S. Blake" initials="S." surname="Blake"/>
<author fullname="F. Baker" initials="F." surname="Baker"/> <reference anchor="RFC9599" target="https://www.rfc-editor.org/info/rfc9599">
<author fullname="D. Black" initials="D." surname="Black"/> <front>
<date month="December" year="1998"/> <title>Guidelines for Adding Congestion Notification to Protocols that Encapsula
<abstract> te IP</title>
<t>This document defines the IP header field, called the DS (for d <author initials='B' surname='Briscoe' fullname='Bob Briscoe'>
ifferentiated services) field. [STANDARDS-TRACK]</t> <organization />
</abstract> </author>
</front> <author initials='J' surname='Kaippallimalil' fullname='John Kaippallimalil'>
<seriesInfo name="RFC" value="2474"/> <organization />
<seriesInfo name="DOI" value="10.17487/RFC2474"/> </author>
</reference> <date month='August' year='2024' />
<reference anchor="RFC2661" target="https://www.rfc-editor.org/info/rfc2 </front>
661" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2661.xml"> <seriesInfo name="RFC" value="9599"/>
<front> <seriesInfo name="DOI" value="10.17487/RFC9599"/>
<title>Layer Two Tunneling Protocol "L2TP"</title> </reference>
<author fullname="W. Townsley" initials="W." surname="Townsley"/>
<author fullname="A. Valencia" initials="A." surname="Valencia"/>
<author fullname="A. Rubens" initials="A." surname="Rubens"/>
<author fullname="G. Pall" initials="G." surname="Pall"/>
<author fullname="G. Zorn" initials="G." surname="Zorn"/>
<author fullname="B. Palter" initials="B." surname="Palter"/>
<date month="August" year="1999"/>
<abstract>
<t>This document describes the Layer Two Tunneling Protocol (L2TP)
. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2661"/>
<seriesInfo name="DOI" value="10.17487/RFC2661"/>
</reference>
<reference anchor="RFC2784" target="https://www.rfc-editor.org/info/rfc2
784" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2784.xml">
<front>
<title>Generic Routing Encapsulation (GRE)</title>
<author fullname="D. Farinacci" initials="D." surname="Farinacci"/>
<author fullname="T. Li" initials="T." surname="Li"/>
<author fullname="S. Hanks" initials="S." surname="Hanks"/>
<author fullname="D. Meyer" initials="D." surname="Meyer"/>
<author fullname="P. Traina" initials="P." surname="Traina"/>
<date month="March" year="2000"/>
<abstract>
<t>This document specifies a protocol for encapsulation of an arbi
trary network layer protocol over another arbitrary network layer protocol. [STA
NDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2784"/>
<seriesInfo name="DOI" value="10.17487/RFC2784"/>
</reference>
<reference anchor="RFC3168" target="https://www.rfc-editor.org/info/rfc3
168" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3168.xml">
<front>
<title>The Addition of Explicit Congestion Notification (ECN) to IP<
/title>
<author fullname="K. Ramakrishnan" initials="K." surname="Ramakrishn
an"/>
<author fullname="S. Floyd" initials="S." surname="Floyd"/>
<author fullname="D. Black" initials="D." surname="Black"/>
<date month="September" year="2001"/>
<abstract>
<t>This memo specifies the incorporation of ECN (Explicit Congesti
on Notification) to TCP and IP, including ECN's use of two bits in the IP header
. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3168"/>
<seriesInfo name="DOI" value="10.17487/RFC3168"/>
</reference>
<reference anchor="RFC3931" target="https://www.rfc-editor.org/info/rfc3
931" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3931.xml">
<front>
<title>Layer Two Tunneling Protocol - Version 3 (L2TPv3)</title>
<author fullname="J. Lau" initials="J." role="editor" surname="Lau"/
>
<author fullname="M. Townsley" initials="M." role="editor" surname="
Townsley"/>
<author fullname="I. Goyret" initials="I." role="editor" surname="Go
yret"/>
<date month="March" year="2005"/>
<abstract>
<t>This document describes "version 3" of the Layer Two Tunneling
Protocol (L2TPv3). L2TPv3 defines the base control protocol and encapsulation fo
r tunneling multiple Layer 2 connections between two IP nodes. Additional docume
nts detail the specifics for each data link type being emulated. [STANDARDS-TRAC
K]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3931"/>
<seriesInfo name="DOI" value="10.17487/RFC3931"/>
</reference>
<reference anchor="RFC4301" target="https://www.rfc-editor.org/info/rfc4
301" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4301.xml">
<front>
<title>Security Architecture for the Internet Protocol</title>
<author fullname="S. Kent" initials="S." surname="Kent"/>
<author fullname="K. Seo" initials="K." surname="Seo"/>
<date month="December" year="2005"/>
<abstract>
<t>This document describes an updated version of the "Security Arc
hitecture for IP", which is designed to provide security services for traffic at
the IP layer. This document obsoletes RFC 2401 (November 1998). [STANDARDS-TRAC
K]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4301"/>
<seriesInfo name="DOI" value="10.17487/RFC4301"/>
</reference>
<reference anchor="RFC4380" target="https://www.rfc-editor.org/info/rfc4
380" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4380.xml">
<front>
<title>Teredo: Tunneling IPv6 over UDP through Network Address Trans
lations (NATs)</title>
<author fullname="C. Huitema" initials="C." surname="Huitema"/>
<date month="February" year="2006"/>
<abstract>
<t>We propose here a service that enables nodes located behind one
or more IPv4 Network Address Translations (NATs) to obtain IPv6 connectivity by
tunneling packets over UDP; we call this the Teredo service. Running the servic
e requires the help of "Teredo servers" and "Teredo relays". The Teredo servers
are stateless, and only have to manage a small fraction of the traffic between T
eredo clients; the Teredo relays act as IPv6 routers between the Teredo service
and the "native" IPv6 Internet. The relays can also provide interoperability wit
h hosts using other transition mechanisms such as "6to4". [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4380"/>
<seriesInfo name="DOI" value="10.17487/RFC4380"/>
</reference>
<reference anchor="RFC5129" target="https://www.rfc-editor.org/info/rfc5
129" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5129.xml">
<front>
<title>Explicit Congestion Marking in MPLS</title>
<author fullname="B. Davie" initials="B." surname="Davie"/>
<author fullname="B. Briscoe" initials="B." surname="Briscoe"/>
<author fullname="J. Tay" initials="J." surname="Tay"/>
<date month="January" year="2008"/>
<abstract>
<t>RFC 3270 defines how to support the Diffserv architecture in MP
LS networks, including how to encode Diffserv Code Points (DSCPs) in an MPLS hea
der. DSCPs may be encoded in the EXP field, while other uses of that field are n
ot precluded. RFC 3270 makes no statement about how Explicit Congestion Notifica
tion (ECN) marking might be encoded in the MPLS header. This document defines ho
w an operator might define some of the EXP codepoints for explicit congestion no
tification, without precluding other uses. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5129"/>
<seriesInfo name="DOI" value="10.17487/RFC5129"/>
</reference>
<reference anchor="RFC6040" target="https://www.rfc-editor.org/info/rfc6
040" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6040.xml">
<front>
<title>Tunnelling of Explicit Congestion Notification</title>
<author fullname="B. Briscoe" initials="B." surname="Briscoe"/>
<date month="November" year="2010"/>
<abstract>
<t>This document redefines how the explicit congestion notificatio
n (ECN) field of the IP header should be constructed on entry to and exit from a
ny IP-in-IP tunnel. On encapsulation, it updates RFC 3168 to bring all IP-in-IP
tunnels (v4 or v6) into line with RFC 4301 IPsec ECN processing. On decapsulatio
n, it updates both RFC 3168 and RFC 4301 to add new behaviours for previously un
used combinations of inner and outer headers. The new rules ensure the ECN field
is correctly propagated across a tunnel whether it is used to signal one or two
severity levels of congestion; whereas before, only one severity level was supp
orted. Tunnel endpoints can be updated in any order without affecting pre-existi
ng uses of the ECN field, thus ensuring backward compatibility. Nonetheless, ope
rators wanting to support two severity levels (e.g., for pre-congestion notifica
tion -- PCN) can require compliance with this new specification. A thorough anal
ysis of the reasoning for these changes and the implications is included. In the
unlikely event that the new rules do not meet a specific need, RFC 4774 gives g
uidance on designing alternate ECN semantics, and this document extends that to
include tunnelling issues. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6040"/>
<seriesInfo name="DOI" value="10.17487/RFC6040"/>
</reference>
<reference anchor="RFC6660" target="https://www.rfc-editor.org/info/rfc6
660" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6660.xml">
<front>
<title>Encoding Three Pre-Congestion Notification (PCN) States in th
e IP Header Using a Single Diffserv Codepoint (DSCP)</title>
<author fullname="B. Briscoe" initials="B." surname="Briscoe"/>
<author fullname="T. Moncaster" initials="T." surname="Moncaster"/>
<author fullname="M. Menth" initials="M." surname="Menth"/>
<date month="July" year="2012"/>
<abstract>
<t>The objective of Pre-Congestion Notification (PCN) is to protec
t the quality of service (QoS) of inelastic flows within a Diffserv domain. The
overall rate of PCN-traffic is metered on every link in the PCN- domain, and PCN
-packets are appropriately marked when certain configured rates are exceeded. Eg
ress nodes pass information about these PCN-marks to Decision Points that then d
ecide whether to admit or block new flow requests or to terminate some already a
dmitted flows during serious pre-congestion.</t>
<t>This document specifies how PCN-marks are to be encoded into th
e IP header by reusing the Explicit Congestion Notification (ECN) codepoints wit
hin a PCN-domain. The PCN wire protocol for non-IP protocol headers will need to
be defined elsewhere. Nonetheless, this document clarifies the PCN encoding for
MPLS in an informational appendix. The encoding for IP provides for up to three
different PCN marking states using a single Diffserv codepoint (DSCP): not-mark
ed (NM), threshold-marked (ThM), and excess-traffic-marked (ETM). Hence, it is c
alled the 3-in-1 PCN encoding. This document obsoletes RFC 5696. [STANDARDS-TRAC
K]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6660"/>
<seriesInfo name="DOI" value="10.17487/RFC6660"/>
</reference>
<reference anchor="RFC7450" target="https://www.rfc-editor.org/info/rfc7
450" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7450.xml">
<front>
<title>Automatic Multicast Tunneling</title>
<author fullname="G. Bumgardner" initials="G." surname="Bumgardner"/
>
<date month="February" year="2015"/>
<abstract>
<t>This document describes Automatic Multicast Tunneling (AMT), a
protocol for delivering multicast traffic from sources in a multicast-enabled ne
twork to receivers that lack multicast connectivity to the source network. The p
rotocol uses UDP encapsulation and unicast replication to provide this functiona
lity.</t>
<t>The AMT protocol is specifically designed to support rapid depl
oyment by requiring minimal changes to existing network infrastructure.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7450"/>
<seriesInfo name="DOI" value="10.17487/RFC7450"/>
</reference>
<reference anchor="I-D.ietf-tsvwg-ecn-encap-guidelines" target="https://
datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-encap-guidelines-21" xml:base
="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-tsvwg-ecn-encap-
guidelines.xml">
<front>
<title>Guidelines for Adding Congestion Notification to Protocols th
at Encapsulate IP</title>
<author fullname="Bob Briscoe" initials="B." surname="Briscoe">
<organization>Independent</organization>
</author>
<author fullname="John Kaippallimalil" initials="J." surname="Kaippa
llimalil">
<organization>Futurewei</organization>
</author>
<date day="10" month="November" year="2023"/>
<abstract>
<t>The purpose of this document is to guide the design of congesti
on notification in any lower layer or tunnelling protocol that encapsulates IP.
The aim is for explicit congestion signals to propagate consistently from lower
layer protocols into IP. Then the IP internetwork layer can act as a portability
layer to carry congestion notification from non-IP-aware congested nodes up to
the transport layer (L4). Following these guidelines should assure interworking
among IP layer and lower layer congestion notification mechanisms, whether speci
fied by the IETF or other standards bodies. This document is included in BCP 89
and updates the advice to subnetwork designers about ECN in RFC 3819.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-tsvwg-ecn-encap-gu
idelines-21"/>
</reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC1701" target="https://www.rfc-editor.org/info/rfc1
701" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1701.xml"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1701.xml"
<front> />
<title>Generic Routing Encapsulation (GRE)</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2332.xml"
<author fullname="S. Hanks" initials="S." surname="Hanks"/> />
<author fullname="T. Li" initials="T." surname="Li"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2637.xml"
<author fullname="D. Farinacci" initials="D." surname="Farinacci"/> />
<author fullname="P. Traina" initials="P." surname="Traina"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2983.xml"
<date month="October" year="1994"/> />
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3260.xml"
<t>This document specifies a protocol for performing encapsulation />
of an arbitrary network layer protocol over another arbitrary network layer pro <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3308.xml"
tocol. This memo provides information for the Internet community. This memo does />
not specify an Internet standard of any kind.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5415.xml"
</abstract> />
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5944.xml"
<seriesInfo name="RFC" value="1701"/> />
<seriesInfo name="DOI" value="10.17487/RFC1701"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6275.xml"
</reference> />
<reference anchor="RFC2332" target="https://www.rfc-editor.org/info/rfc2 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5845.xml"
332" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2332.xml"> />
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7296.xml"
<title>NBMA Next Hop Resolution Protocol (NHRP)</title> />
<author fullname="J. Luciani" initials="J." surname="Luciani"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9300.xml"
<author fullname="D. Katz" initials="D." surname="Katz"/> />
<author fullname="D. Piscitello" initials="D." surname="Piscitello"/ <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7059.xml"
> />
<author fullname="B. Cole" initials="B." surname="Cole"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7348.xml"
<author fullname="N. Doraswamy" initials="N." surname="Doraswamy"/> />
<date month="April" year="1998"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7637.xml"
<abstract> />
<t>This document describes the NBMA Next Hop Resolution Protocol ( <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7665.xml"
NHRP). NHRP can be used by a source station (host or router) connected to a Non- />
Broadcast, Multi-Access (NBMA) subnetwork to determine the internetworking layer <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8085.xml"
address and NBMA subnetwork addresses of the "NBMA next hop" towards a destinat />
ion station. [STANDARDS-TRACK]</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8087.xml"
</abstract> />
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8159.xml"
<seriesInfo name="RFC" value="2332"/> />
<seriesInfo name="DOI" value="10.17487/RFC2332"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"
</reference> />
<reference anchor="RFC2637" target="https://www.rfc-editor.org/info/rfc2 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8300.xml"
637" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2637.xml"> />
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8311.xml"
<title>Point-to-Point Tunneling Protocol (PPTP)</title> />
<author fullname="K. Hamzeh" initials="K." surname="Hamzeh"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8926.xml"
<author fullname="G. Pall" initials="G." surname="Pall"/> />
<author fullname="W. Verthein" initials="W." surname="Verthein"/>
<author fullname="J. Taarud" initials="J." surname="Taarud"/> <!-- [I-D.ietf-nvo3-vxlan-gpe] IESG state I-D Exists -->
<author fullname="W. Little" initials="W." surname="Little"/>
<author fullname="G. Zorn" initials="G." surname="Zorn"/> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-nv
<date month="July" year="1999"/> o3-vxlan-gpe.xml"/>
<abstract>
<t>This document specifies a protocol which allows the Point to Po <reference anchor="I-D.ietf-sfc-nsh-ecn-support" target="https://datatracker.iet
int Protocol (PPP) to be tunneled through an IP network. This memo provides info f.org/doc/html/draft-ietf-sfc-nsh-ecn-support-13">
rmation for the Internet community.</t> <front>
</abstract> <title>
</front> Explicit Congestion Notification (ECN) and Congestion Feedback Using the Network
<seriesInfo name="RFC" value="2637"/> Service Header (NSH) and IPFIX
<seriesInfo name="DOI" value="10.17487/RFC2637"/> </title>
</reference> <author initials="D." surname="Eastlake 3rd" fullname="Donald E. Eastlake 3rd">
<reference anchor="RFC2983" target="https://www.rfc-editor.org/info/rfc2 <organization>Independent</organization>
983" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2983.xml"> </author>
<front> <author initials="B." surname="Briscoe" fullname="Bob Briscoe">
<title>Differentiated Services and Tunnels</title> </author>
<author fullname="D. Black" initials="D." surname="Black"/> <author initials="S." surname="Zhuang" fullname="Shunwan Zhuang">
<date month="October" year="2000"/> <organization>Huawei Technologies</organization>
<abstract> </author>
<t>This document considers the interaction of Differentiated Servi <author initials="A." surname="Malis" fullname="Andrew G. Malis">
ces (diffserv) with IP tunnels of various forms. This memo provides information <organization>Malis Consulting</organization>
for the Internet community.</t> </author>
</abstract> <author initials="X." surname="Wei" fullname="Xinpeng Wei">
</front> <organization>Huawei Technologies</organization>
<seriesInfo name="RFC" value="2983"/> </author>
<seriesInfo name="DOI" value="10.17487/RFC2983"/> <date month="April" day="15" year="2024"/>
</reference> </front>
<reference anchor="RFC3260" target="https://www.rfc-editor.org/info/rfc3 <seriesInfo name="Internet-Draft" value="draft-ietf-sfc-nsh-ecn-support-13"/>
260" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3260.xml"> </reference>
<front>
<title>New Terminology and Clarifications for Diffserv</title> <!-- [I-D.ietf-intarea-tunnels] IESG state Expired -->
<author fullname="D. Grossman" initials="D." surname="Grossman"/>
<date month="April" year="2002"/> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-in
<abstract> tarea-tunnels.xml"/>
<t>This memo captures Diffserv working group agreements concerning <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9329.xml"
new and improved terminology, and provides minor technical clarifications. It i />
s intended to update RFC 2474, RFC 2475 and RFC 2597. When RFCs 2474 and 2597 ad <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9331.xml"
vance on the standards track, and RFC 2475 is updated, it is intended that the r />
evisions in this memo will be incorporated, and that this memo will be obsoleted
by the new RFCs. This memo provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3260"/>
<seriesInfo name="DOI" value="10.17487/RFC3260"/>
</reference>
<reference anchor="RFC3308" target="https://www.rfc-editor.org/info/rfc3
308" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3308.xml">
<front>
<title>Layer Two Tunneling Protocol (L2TP) Differentiated Services E
xtension</title>
<author fullname="P. Calhoun" initials="P." surname="Calhoun"/>
<author fullname="W. Luo" initials="W." surname="Luo"/>
<author fullname="D. McPherson" initials="D." surname="McPherson"/>
<author fullname="K. Peirce" initials="K." surname="Peirce"/>
<date month="November" year="2002"/>
</front>
<seriesInfo name="RFC" value="3308"/>
<seriesInfo name="DOI" value="10.17487/RFC3308"/>
</reference>
<reference anchor="RFC5415" target="https://www.rfc-editor.org/info/rfc5
415" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5415.xml">
<front>
<title>Control And Provisioning of Wireless Access Points (CAPWAP) P
rotocol Specification</title>
<author fullname="P. Calhoun" initials="P." role="editor" surname="C
alhoun"/>
<author fullname="M. Montemurro" initials="M." role="editor" surname
="Montemurro"/>
<author fullname="D. Stanley" initials="D." role="editor" surname="S
tanley"/>
<date month="March" year="2009"/>
<abstract>
<t>This specification defines the Control And Provisioning of Wire
less Access Points (CAPWAP) Protocol, meeting the objectives defined by the CAPW
AP Working Group in RFC 4564. The CAPWAP protocol is designed to be flexible, al
lowing it to be used for a variety of wireless technologies. This document descr
ibes the base CAPWAP protocol, while separate binding extensions will enable its
use with additional wireless technologies. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5415"/>
<seriesInfo name="DOI" value="10.17487/RFC5415"/>
</reference>
<reference anchor="RFC5944" target="https://www.rfc-editor.org/info/rfc5
944" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5944.xml">
<front>
<title>IP Mobility Support for IPv4, Revised</title>
<author fullname="C. Perkins" initials="C." role="editor" surname="P
erkins"/>
<date month="November" year="2010"/>
<abstract>
<t>This document specifies protocol enhancements that allow transp
arent routing of IP datagrams to mobile nodes in the Internet. Each mobile node
is always identified by its home address, regardless of its current point of att
achment to the Internet. While situated away from its home, a mobile node is als
o associated with a care-of address, which provides information about its curren
t point of attachment to the Internet. The protocol provides for registering the
care-of address with a home agent. The home agent sends datagrams destined for
the mobile node through a tunnel to the care-of address. After arriving at the e
nd of the tunnel, each datagram is then delivered to the mobile node. [STANDARDS
-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5944"/>
<seriesInfo name="DOI" value="10.17487/RFC5944"/>
</reference>
<reference anchor="RFC6275" target="https://www.rfc-editor.org/info/rfc6
275" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6275.xml">
<front>
<title>Mobility Support in IPv6</title>
<author fullname="C. Perkins" initials="C." role="editor" surname="P
erkins"/>
<author fullname="D. Johnson" initials="D." surname="Johnson"/>
<author fullname="J. Arkko" initials="J." surname="Arkko"/>
<date month="July" year="2011"/>
<abstract>
<t>This document specifies Mobile IPv6, a protocol that allows nod
es to remain reachable while moving around in the IPv6 Internet. Each mobile nod
e is always identified by its home address, regardless of its current point of a
ttachment to the Internet. While situated away from its home, a mobile node is a
lso associated with a care-of address, which provides information about the mobi
le node's current location. IPv6 packets addressed to a mobile node's home addre
ss are transparently routed to its care-of address. The protocol enables IPv6 no
des to cache the binding of a mobile node's home address with its care-of addres
s, and to then send any packets destined for the mobile node directly to it at t
his care-of address. To support this operation, Mobile IPv6 defines a new IPv6 p
rotocol and a new destination option. All IPv6 nodes, whether mobile or stationa
ry, can communicate with mobile nodes. This document obsoletes RFC 3775. [STANDA
RDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6275"/>
<seriesInfo name="DOI" value="10.17487/RFC6275"/>
</reference>
<reference anchor="RFC5845" target="https://www.rfc-editor.org/info/rfc5
845" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5845.xml">
<front>
<title>Generic Routing Encapsulation (GRE) Key Option for Proxy Mobi
le IPv6</title>
<author fullname="A. Muhanna" initials="A." surname="Muhanna"/>
<author fullname="M. Khalil" initials="M." surname="Khalil"/>
<author fullname="S. Gundavelli" initials="S." surname="Gundavelli"/
>
<author fullname="K. Leung" initials="K." surname="Leung"/>
<date month="June" year="2010"/>
<abstract>
<t>This specification defines a new mobility option for allowing t
he mobile access gateway and the local mobility anchor to negotiate Generic Rout
ing Encapsulation (GRE) encapsulation mode and exchange the downlink and uplink
GRE keys that are used for marking the downlink and uplink traffic that belong t
o a specific mobility session. In addition, the same mobility option can be used
to negotiate the GRE encapsulation mode without exchanging the GRE keys. [STAND
ARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5845"/>
<seriesInfo name="DOI" value="10.17487/RFC5845"/>
</reference>
<reference anchor="RFC7296" target="https://www.rfc-editor.org/info/rfc7
296" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7296.xml">
<front>
<title>Internet Key Exchange Protocol Version 2 (IKEv2)</title>
<author fullname="C. Kaufman" initials="C." surname="Kaufman"/>
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
<author fullname="Y. Nir" initials="Y." surname="Nir"/>
<author fullname="P. Eronen" initials="P." surname="Eronen"/>
<author fullname="T. Kivinen" initials="T." surname="Kivinen"/>
<date month="October" year="2014"/>
<abstract>
<t>This document describes version 2 of the Internet Key Exchange
(IKE) protocol. IKE is a component of IPsec used for performing mutual authentic
ation and establishing and maintaining Security Associations (SAs). This documen
t obsoletes RFC 5996, and includes all of the errata for it. It advances IKEv2 t
o be an Internet Standard.</t>
</abstract>
</front>
<seriesInfo name="STD" value="79"/>
<seriesInfo name="RFC" value="7296"/>
<seriesInfo name="DOI" value="10.17487/RFC7296"/>
</reference>
<reference anchor="RFC9300" target="https://www.rfc-editor.org/info/rfc9
300" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9300.xml">
<front>
<title>The Locator/ID Separation Protocol (LISP)</title>
<author fullname="D. Farinacci" initials="D." surname="Farinacci"/>
<author fullname="V. Fuller" initials="V." surname="Fuller"/>
<author fullname="D. Meyer" initials="D." surname="Meyer"/>
<author fullname="D. Lewis" initials="D." surname="Lewis"/>
<author fullname="A. Cabellos" initials="A." role="editor" surname="
Cabellos"/>
<date month="October" year="2022"/>
<abstract>
<t>This document describes the data plane protocol for the Locator
/ID Separation Protocol (LISP). LISP defines two namespaces: Endpoint Identifier
s (EIDs), which identify end hosts; and Routing Locators (RLOCs), which identify
network attachment points. With this, LISP effectively separates control from d
ata and allows routers to create overlay networks. LISP-capable routers exchange
encapsulated packets according to EID-to-RLOC mappings stored in a local Map-Ca
che.</t>
<t>LISP requires no change to either host protocol stacks or under
lay routers and offers Traffic Engineering (TE), multihoming, and mobility, amon
g other features.</t>
<t>This document obsoletes RFC 6830.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9300"/>
<seriesInfo name="DOI" value="10.17487/RFC9300"/>
</reference>
<reference anchor="RFC7059" target="https://www.rfc-editor.org/info/rfc7
059" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7059.xml">
<front>
<title>A Comparison of IPv6-over-IPv4 Tunnel Mechanisms</title>
<author fullname="S. Steffann" initials="S." surname="Steffann"/>
<author fullname="I. van Beijnum" initials="I." surname="van Beijnum
"/>
<author fullname="R. van Rein" initials="R." surname="van Rein"/>
<date month="November" year="2013"/>
<abstract>
<t>This document provides an overview of various ways to tunnel IP
v6 packets over IPv4 networks. It covers mechanisms in current use, touches on s
everal mechanisms that are now only of historic interest, and discusses some new
er tunnel mechanisms that are not widely used at the time of publication. The go
al of the document is helping people with an IPv6-in-IPv4 tunneling need to sele
ct the mechanisms that may apply to them.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7059"/>
<seriesInfo name="DOI" value="10.17487/RFC7059"/>
</reference>
<reference anchor="RFC7348" target="https://www.rfc-editor.org/info/rfc7
348" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7348.xml">
<front>
<title>Virtual eXtensible Local Area Network (VXLAN): A Framework fo
r Overlaying Virtualized Layer 2 Networks over Layer 3 Networks</title>
<author fullname="M. Mahalingam" initials="M." surname="Mahalingam"/
>
<author fullname="D. Dutt" initials="D." surname="Dutt"/>
<author fullname="K. Duda" initials="K." surname="Duda"/>
<author fullname="P. Agarwal" initials="P." surname="Agarwal"/>
<author fullname="L. Kreeger" initials="L." surname="Kreeger"/>
<author fullname="T. Sridhar" initials="T." surname="Sridhar"/>
<author fullname="M. Bursell" initials="M." surname="Bursell"/>
<author fullname="C. Wright" initials="C." surname="Wright"/>
<date month="August" year="2014"/>
<abstract>
<t>This document describes Virtual eXtensible Local Area Network (
VXLAN), which is used to address the need for overlay networks within virtualize
d data centers accommodating multiple tenants. The scheme and the related protoc
ols can be used in networks for cloud service providers and enterprise data cent
ers. This memo documents the deployed VXLAN protocol for the benefit of the Inte
rnet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7348"/>
<seriesInfo name="DOI" value="10.17487/RFC7348"/>
</reference>
<reference anchor="RFC7637" target="https://www.rfc-editor.org/info/rfc7
637" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7637.xml">
<front>
<title>NVGRE: Network Virtualization Using Generic Routing Encapsula
tion</title>
<author fullname="P. Garg" initials="P." role="editor" surname="Garg
"/>
<author fullname="Y. Wang" initials="Y." role="editor" surname="Wang
"/>
<date month="September" year="2015"/>
<abstract>
<t>This document describes the usage of the Generic Routing Encaps
ulation (GRE) header for Network Virtualization (NVGRE) in multi-tenant data cen
ters. Network Virtualization decouples virtual networks and addresses from physi
cal network infrastructure, providing isolation and concurrency between multiple
virtual networks on the same physical network infrastructure. This document als
o introduces a Network Virtualization framework to illustrate the use cases, but
the focus is on specifying the data-plane aspect of NVGRE.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7637"/>
<seriesInfo name="DOI" value="10.17487/RFC7637"/>
</reference>
<reference anchor="RFC7665" target="https://www.rfc-editor.org/info/rfc7
665" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7665.xml">
<front>
<title>Service Function Chaining (SFC) Architecture</title>
<author fullname="J. Halpern" initials="J." role="editor" surname="H
alpern"/>
<author fullname="C. Pignataro" initials="C." role="editor" surname=
"Pignataro"/>
<date month="October" year="2015"/>
<abstract>
<t>This document describes an architecture for the specification,
creation, and ongoing maintenance of Service Function Chains (SFCs) in a network
. It includes architectural concepts, principles, and components used in the con
struction of composite services through deployment of SFCs, with a focus on thos
e to be standardized in the IETF. This document does not propose solutions, prot
ocols, or extensions to existing protocols.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7665"/>
<seriesInfo name="DOI" value="10.17487/RFC7665"/>
</reference>
<reference anchor="RFC8085" target="https://www.rfc-editor.org/info/rfc8
085" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8085.xml">
<front>
<title>UDP Usage Guidelines</title>
<author fullname="L. Eggert" initials="L." surname="Eggert"/>
<author fullname="G. Fairhurst" initials="G." surname="Fairhurst"/>
<author fullname="G. Shepherd" initials="G." surname="Shepherd"/>
<date month="March" year="2017"/>
<abstract>
<t>The User Datagram Protocol (UDP) provides a minimal message-pas
sing transport that has no inherent congestion control mechanisms. This document
provides guidelines on the use of UDP for the designers of applications, tunnel
s, and other protocols that use UDP. Congestion control guidelines are a primary
focus, but the document also provides guidance on other topics, including messa
ge sizes, reliability, checksums, middlebox traversal, the use of Explicit Conge
stion Notification (ECN), Differentiated Services Code Points (DSCPs), and ports
.</t>
<t>Because congestion control is critical to the stable operation
of the Internet, applications and other protocols that choose to use UDP as an I
nternet transport must employ mechanisms to prevent congestion collapse and to e
stablish some degree of fairness with concurrent traffic. They may also need to
implement additional mechanisms, depending on how they use UDP.</t>
<t>Some guidance is also applicable to the design of other protoco
ls (e.g., protocols layered directly on IP or via IP-based tunnels), especially
when these protocols do not themselves provide congestion control.</t>
<t>This document obsoletes RFC 5405 and adds guidelines for multic
ast UDP usage.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="145"/>
<seriesInfo name="RFC" value="8085"/>
<seriesInfo name="DOI" value="10.17487/RFC8085"/>
</reference>
<reference anchor="RFC8087" target="https://www.rfc-editor.org/info/rfc8
087" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8087.xml">
<front>
<title>The Benefits of Using Explicit Congestion Notification (ECN)<
/title>
<author fullname="G. Fairhurst" initials="G." surname="Fairhurst"/>
<author fullname="M. Welzl" initials="M." surname="Welzl"/>
<date month="March" year="2017"/>
<abstract>
<t>The goal of this document is to describe the potential benefits
of applications using a transport that enables Explicit Congestion Notification
(ECN). The document outlines the principal gains in terms of increased throughp
ut, reduced delay, and other benefits when ECN is used over a network path that
includes equipment that supports Congestion Experienced (CE) marking. It also di
scusses challenges for successful deployment of ECN. It does not propose new alg
orithms to use ECN nor does it describe the details of implementation of ECN in
endpoint devices (Internet hosts), routers, or other network devices.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8087"/>
<seriesInfo name="DOI" value="10.17487/RFC8087"/>
</reference>
<reference anchor="RFC8159" target="https://www.rfc-editor.org/info/rfc8
159" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8159.xml">
<front>
<title>Keyed IPv6 Tunnel</title>
<author fullname="M. Konstantynowicz" initials="M." role="editor" su
rname="Konstantynowicz"/>
<author fullname="G. Heron" initials="G." role="editor" surname="Her
on"/>
<author fullname="R. Schatzmayr" initials="R." surname="Schatzmayr"/
>
<author fullname="W. Henderickx" initials="W." surname="Henderickx"/
>
<date month="May" year="2017"/>
<abstract>
<t>This document describes a tunnel encapsulation for Ethernet ove
r IPv6 with a mandatory 64-bit cookie for connecting Layer 2 (L2) Ethernet attac
hment circuits identified by IPv6 addresses. The encapsulation is based on the L
ayer 2 Tunneling Protocol Version 3 (L2TPv3) over IP and does not use the L2TPv3
control plane.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8159"/>
<seriesInfo name="DOI" value="10.17487/RFC8159"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC8300" target="https://www.rfc-editor.org/info/rfc8
300" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8300.xml">
<front>
<title>Network Service Header (NSH)</title>
<author fullname="P. Quinn" initials="P." role="editor" surname="Qui
nn"/>
<author fullname="U. Elzur" initials="U." role="editor" surname="Elz
ur"/>
<author fullname="C. Pignataro" initials="C." role="editor" surname=
"Pignataro"/>
<date month="January" year="2018"/>
<abstract>
<t>This document describes a Network Service Header (NSH) imposed
on packets or frames to realize Service Function Paths (SFPs). The NSH also prov
ides a mechanism for metadata exchange along the instantiated service paths. The
NSH is the Service Function Chaining (SFC) encapsulation required to support th
e SFC architecture (defined in RFC 7665).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8300"/>
<seriesInfo name="DOI" value="10.17487/RFC8300"/>
</reference>
<reference anchor="RFC8311" target="https://www.rfc-editor.org/info/rfc8
311" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8311.xml">
<front>
<title>Relaxing Restrictions on Explicit Congestion Notification (EC
N) Experimentation</title>
<author fullname="D. Black" initials="D." surname="Black"/>
<date month="January" year="2018"/>
<abstract>
<t>This memo updates RFC 3168, which specifies Explicit Congestion
Notification (ECN) as an alternative to packet drops for indicating network con
gestion to endpoints. It relaxes restrictions in RFC 3168 that hinder experiment
ation towards benefits beyond just removal of loss. This memo summarizes the ant
icipated areas of experimentation and updates RFC 3168 to enable experimentation
in these areas. An Experimental RFC in the IETF document stream is required to
take advantage of any of these enabling updates. In addition, this memo makes re
lated updates to the ECN specifications for RTP in RFC 6679 and for the Datagram
Congestion Control Protocol (DCCP) in RFCs 4341, 4342, and 5622. This memo also
records the conclusion of the ECN nonce experiment in RFC 3540 and provides the
rationale for reclassification of RFC 3540 from Experimental to Historic; this
reclassification enables new experimental use of the ECT(1) codepoint.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8311"/>
<seriesInfo name="DOI" value="10.17487/RFC8311"/>
</reference>
<reference anchor="RFC8926" target="https://www.rfc-editor.org/info/rfc8
926" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8926.xml">
<front>
<title>Geneve: Generic Network Virtualization Encapsulation</title>
<author fullname="J. Gross" initials="J." role="editor" surname="Gro
ss"/>
<author fullname="I. Ganga" initials="I." role="editor" surname="Gan
ga"/>
<author fullname="T. Sridhar" initials="T." role="editor" surname="S
ridhar"/>
<date month="November" year="2020"/>
<abstract>
<t>Network virtualization involves the cooperation of devices with
a wide variety of capabilities such as software and hardware tunnel endpoints,
transit fabrics, and centralized control clusters. As a result of their role in
tying together different elements of the system, the requirements on tunnels are
influenced by all of these components. Therefore, flexibility is the most impor
tant aspect of a tunneling protocol if it is to keep pace with the evolution of
technology. This document describes Geneve, an encapsulation protocol designed t
o recognize and accommodate these changing capabilities and needs.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8926"/>
<seriesInfo name="DOI" value="10.17487/RFC8926"/>
</reference>
<reference anchor="I-D.ietf-nvo3-vxlan-gpe" target="https://datatracker.
ietf.org/doc/html/draft-ietf-nvo3-vxlan-gpe-13" xml:base="https://bib.ietf.org/p
ublic/rfc/bibxml-ids/reference.I-D.ietf-nvo3-vxlan-gpe.xml">
<front>
<title>Generic Protocol Extension for VXLAN (VXLAN-GPE)</title>
<author fullname="Fabio Maino" initials="F." surname="Maino">
<organization>Cisco Systems</organization>
</author>
<author fullname="Larry Kreeger" initials="L." surname="Kreeger">
<organization>Arrcus</organization>
</author>
<author fullname="Uri Elzur" initials="U." surname="Elzur">
<organization>Intel</organization>
</author>
<date day="4" month="November" year="2023"/>
<abstract>
<t>This document describes extending Virtual eXtensible Local Area
Network (VXLAN), via changes to the VXLAN header, with four new capabilities: s
upport for multi-protocol encapsulation, support for operations, administration
and maintenance (OAM) signaling, support for ingress-replicated BUM Traffic (i.e
. Broadcast, Unknown unicast, or Multicast), and explicit versioning. New protoc
ol capabilities can be introduced via shim headers.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-nvo3-vxlan-gpe-13"
/>
</reference>
<reference anchor="I-D.ietf-sfc-nsh-ecn-support" target="https://datatra
cker.ietf.org/doc/html/draft-ietf-sfc-nsh-ecn-support-12" xml:base="https://bib.
ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-sfc-nsh-ecn-support.xml">
<front>
<title>Explicit Congestion Notification (ECN) and Congestion Feedbac
k Using the Network Service Header (NSH) and IPFIX</title>
<author fullname="Donald E. Eastlake 3rd" initials="D. E." surname="
Eastlake">
<organization>Futurewei Technologies</organization>
</author>
<author fullname="Bob Briscoe" initials="B." surname="Briscoe">
<organization>Independent</organization>
</author>
<author fullname="Shunwan Zhuang" initials="S." surname="Zhuang">
<organization>Huawei Technologies</organization>
</author>
<author fullname="Andrew G. Malis" initials="A. G." surname="Malis">
<organization>Malis Consulting</organization>
</author>
<author fullname="Xinpeng Wei" initials="X." surname="Wei">
<organization>Huawei Technologies</organization>
</author>
<date day="23" month="October" year="2023"/>
<abstract>
<t>Explicit Congestion Notification (ECN) allows a forwarding elem
ent to notify downstream devices of the onset of congestion without having to dr
op packets. Coupled with a means to feed information about congestion back to up
stream nodes, this can improve network efficiency through better congestion cont
rol, frequently without packet drops. This document specifies ECN and congestion
feedback support within a Service Function Chaining (SFC) enabled domain throug
h use of the Network Service Header (NSH, RFC 8300) and IP Flow Information Expo
rt (IPFIX, RFC 7011) protocol.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-sfc-nsh-ecn-suppor
t-12"/>
</reference>
<reference anchor="I-D.ietf-intarea-tunnels" target="https://datatracker
.ietf.org/doc/html/draft-ietf-intarea-tunnels-13" xml:base="https://bib.ietf.org
/public/rfc/bibxml-ids/reference.I-D.ietf-intarea-tunnels.xml">
<front>
<title>IP Tunnels in the Internet Architecture</title>
<author fullname="Dr. Joseph D. Touch" initials="J. D." surname="Tou
ch">
<organization>Independent Consultant</organization>
</author>
<author fullname="Mark Townsley" initials="M." surname="Townsley">
<organization>Cisco</organization>
</author>
<date day="26" month="March" year="2023"/>
<abstract>
<t>This document discusses the role of IP tunnels in the Internet
architecture. An IP tunnel transits IP datagrams as payloads in non- link layer
protocols. This document explains the relationship of IP tunnels to existing pro
tocol layers and the challenges in supporting IP tunneling, based on the equival
ence of tunnels to links. The implications of this document updates RFC 4459 and
its MTU and fragmentation recommendations for IP tunnels.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-intarea-tunnels-13
"/>
</reference>
<reference anchor="RFC9329" target="https://www.rfc-editor.org/info/rfc9
329" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9329.xml">
<front>
<title>TCP Encapsulation of Internet Key Exchange Protocol (IKE) and
IPsec Packets</title>
<author fullname="T. Pauly" initials="T." surname="Pauly"/>
<author fullname="V. Smyslov" initials="V." surname="Smyslov"/>
<date month="November" year="2022"/>
<abstract>
<t>This document describes a method to transport Internet Key Exch
ange Protocol (IKE) and IPsec packets over a TCP connection for traversing netwo
rk middleboxes that may block IKE negotiation over UDP. This method, referred to
as "TCP encapsulation", involves sending both IKE packets for Security Associat
ion (SA) establishment and Encapsulating Security Payload (ESP) packets over a T
CP connection. This method is intended to be used as a fallback option when IKE
cannot be negotiated over UDP.</t>
<t>TCP encapsulation for IKE and IPsec was defined in RFC 8229. Th
is document clarifies the specification for TCP encapsulation by including addit
ional clarifications obtained during implementation and deployment of this metho
d. This documents obsoletes RFC 8229.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9329"/>
<seriesInfo name="DOI" value="10.17487/RFC9329"/>
</reference>
<reference anchor="RFC9331" target="https://www.rfc-editor.org/info/rfc9
331" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9331.xml">
<front>
<title>The Explicit Congestion Notification (ECN) Protocol for Low L
atency, Low Loss, and Scalable Throughput (L4S)</title>
<author fullname="K. De Schepper" initials="K." surname="De Schepper
"/>
<author fullname="B. Briscoe" initials="B." role="editor" surname="B
riscoe"/>
<date month="January" year="2023"/>
<abstract>
<t>This specification defines the protocol to be used for a new ne
twork service called Low Latency, Low Loss, and Scalable throughput (L4S). L4S u
ses an Explicit Congestion Notification (ECN) scheme at the IP layer that is sim
ilar to the original (or 'Classic') ECN approach, except as specified within. L4
S uses 'Scalable' congestion control, which induces much more frequent control s
ignals from the network, and it responds to them with much more fine-grained adj
ustments so that very low (typically sub-millisecond on average) and consistentl
y low queuing delay becomes possible for L4S traffic without compromising link u
tilization. Thus, even capacity-seeking (TCP-like) traffic can have high bandwid
th and very low delay at the same time, even during periods of high traffic load
.</t>
<t>The L4S identifier defined in this document distinguishes L4S f
rom 'Classic' (e.g., TCP-Reno-friendly) traffic. Then, network bottlenecks can b
e incrementally modified to distinguish and isolate existing traffic that still
follows the Classic behaviour, to prevent it from degrading the low queuing dela
y and low loss of L4S traffic. This Experimental specification defines the rules
that L4S transports and network elements need to follow, with the intention tha
t L4S flows neither harm each other's performance nor that of Classic traffic. I
t also suggests open questions to be investigated during experimentation. Exampl
es of new Active Queue Management (AQM) marking algorithms and new transports (w
hether TCP-like or real time) are specified separately.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9331"/>
<seriesInfo name="DOI" value="10.17487/RFC9331"/>
</reference>
<reference anchor="GTPv1"> <reference anchor="GTPv1">
<front> <front>
<title>GPRS Tunnelling Protocol (GTP) across the Gn and Gp <title>General Packet Radio Service (GPRS); GPRS Tunnelling
interface</title> Protocol (GTP) across the Gn and Gp interface</title>
<author> <author>
<organization>3GPP</organization> <organization>3GPP</organization>
</author> </author>
<date/>
</front> </front>
<seriesInfo name="Technical Specification" value="TS 29.060"/> <seriesInfo name="Technical Specification" value="29.060"/>
</reference> </reference>
<reference anchor="GTPv1-U"> <reference anchor="GTPv1-U">
<front> <front>
<title>General Packet Radio System (GPRS) Tunnelling Protocol User <title>General Packet Radio System (GPRS) Tunnelling Protocol User
Plane (GTPv1-U)</title> Plane (GTPv1-U)</title>
<author> <author>
<organization>3GPP</organization> <organization>3GPP</organization>
</author> </author>
<date/>
</front> </front>
<seriesInfo name="Technical Specification" value="TS 29.281"/> <seriesInfo name="Technical Specification" value="29.281"/>
</reference> </reference>
<reference anchor="GTPv2-C"> <reference anchor="GTPv2-C">
<front> <front>
<title>Evolved General Packet Radio Service (GPRS) Tunnelling <title>3GPP Evolved Packet System (EPS); Evolved General Packet
Protocol for Control plane (GTPv2-C)</title> Radio Service (GPRS) Tunnelling Protocol for Control plane
(GTPv2-C); Stage 3</title>
<author> <author>
<organization>3GPP</organization> <organization>3GPP</organization>
</author> </author>
<date year=""/> <date year=""/>
</front> </front>
<seriesInfo name="Technical Specification" value="TS 29.274"/> <seriesInfo name="Technical Specification" value="29.274"/>
</reference> </reference>
<reference anchor="decap-test" target="https://arxiv.org/abs/2311.16825" > <reference anchor="decap-test" target="https://arxiv.org/abs/2311.16825" >
<front> <front>
<title>A Test for IP-ECN Propagation over a Tunnel</title> <title>A Test for IP-ECN Propagation by a Remote Tunnel Endpoint</ti tle>
<author fullname="Bob" initials="B." surname="Briscoe"> <author fullname="Bob" initials="B." surname="Briscoe">
<organization>Independent</organization> <organization>Independent</organization>
</author> </author>
<date month="November" year="2023"/> <date month="November" year="2023"/>
</front> </front>
<seriesInfo name="DOI" value="10.48550/arXiv.2311.16825"/> <seriesInfo name="DOI" value="10.48550/arXiv.2311.16825"/>
<refcontent>Technical Report, TR-BB-2023-003</refcontent> <refcontent>Technical Report, TR-BB-2023-003</refcontent>
<format target="https://arxiv.org/pdf/2311.16825.pdf" type="PDF"/> <format target="https://arxiv.org/pdf/2311.16825.pdf" type="PDF"/>
</reference> </reference>
</references> </references>
</references> </references>
<!-- ================================================================ -->
<section anchor="rfc6040up_Comments_Solicited" numbered="false" removeInRFC=
"true" toc="default">
<name>Comments Solicited</name>
<t>Comments and questions are encouraged and very welcome. They can be
addressed to the IETF Transport Area working group mailing list
&lt;tsvwg@ietf.org&gt;, and/or to the authors.</t>
</section>
<!-- ================================================================ -->
<section numbered="false" toc="default"> <section numbered="false" toc="default">
<name>Acknowledgements</name> <name>Acknowledgements</name>
<t>Thanks to Ing-jyh (Inton) Tsang for initial discussions on the need <t>Thanks to <contact fullname="Ing-jyh (Inton) Tsang"/> for initial
for ECN propagation in L2TP and its applicability. Thanks also to Carlos discussions on the need for ECN propagation in L2TP and its
Pignataro, Tom Herbert, Ignacio Goyret, Alia Atlas, Praveen applicability. Thanks also to <contact fullname="Carlos Pignataro"/>,
Balasubramanian, Joe Touch, Mohamed Boucadair, David Black, Jake <contact fullname="Tom Herbert"/>, <contact fullname="Ignacio Goyret"/>,
Holland, Sri Gundavelli, Gorry Fairhurst and Martin Duke for helpful <contact fullname="Alia Atlas"/>, <contact fullname="Praveen
advice and comments. "A Comparison of IPv6-over-IPv4 Tunnel Mechanisms" Balasubramanian"/>, <contact fullname="Joe Touch"/>, <contact
<xref target="RFC7059" format="default"/> helped to identify a number of t fullname="Mohamed Boucadair"/>, <contact fullname="David Black"/>,
unnelling <contact fullname="Jake Holland"/>, <contact fullname="Sri
protocols to include within the scope of this document.</t> Gundavelli"/>, <contact fullname="Gorry Fairhurst"/>, and <contact
<t>Bob Briscoe was part-funded by the Research Council of Norway through fullname="Martin Duke"/> for helpful advice and comments. <xref
the TimeIn project for early drafts, and for final drafts (from -17) he target="RFC7059" format="default"/> helped to identify a number of
was funded by Apple Inc. The views expressed here are solely those of tunnelling protocols to include within the scope of this document.</t>
<t><contact fullname="Bob Briscoe"/> was part-funded by the Research Co
uncil of Norway through
the TimeIn project for early drafts, and he was funded by Apple Inc. for late
r draft versions (from -17). The views expressed here are solely those of
the authors.</t> the authors.</t>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 181 change blocks. 
1462 lines changed or deleted 644 lines changed or added

This html diff was produced by rfcdiff 1.48.