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>
			<!-- [rfced] For clarity, may the short title be updated as follows or
			otherwise? This appears in the running header of the PDF.
			Original:
			ECN over IP-shim-(L2)-IP Tunnels
			Perhaps:
			ECN over IP-in-IP Tunnels with Shim
			-->
	<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="June"/>
	<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; these RFCs specify L2TPv2, L2TPv3, Generic Routing Encapsulation
	AMT). This specification also updates RFC 6040 with configuration		(GRE), 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.</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>This was intended to include cases where one or more shim headers sits
			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>There is another problem with the scope of <xref target="RFC6040"/>. Li
	specifications, RFC 6040 is written as a specification that		ke many IETF
			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 cases:</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>Implementations that 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>
			<!-- [rfced] Please clarify; what does "it" refer to here - the ECN field
			or the RFC itself?
			Original:
			However, an RFC has no jurisdiction over implementations that choose
			not to comply with it or cannot comply with it, including all those
			implementations that predated the RFC.
			Perhaps (if the former):
			However, an RFC has no jurisdiction over implementations that choose
			not to comply or cannot comply with the ECN field, including all
			implementations that predated the RFC.
			-->
	<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 with it or cannot comply with it, including all those
	implementations that predated the RFC. Therefore, it would have been		implementations that predated the RFC. 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 stating these configuration requirements
	in <xref target="rfc6040up_sec_safe" format="default"/>, the factors that determine		in <xref target="rfc6040up_sec_safe" format="default"/>, the factors that 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 al ways
	added to (or removed from) an inner IP packet as part of the same		added to (or removed from) an inner IP packet as part of the same
	procedure. We call this a tightly coupled shim header. Processing the		procedure. We call this a tightly coupled shim header.
	shim and outer together is often necessary because the shim(s) are not
	sufficient for packet forwarding in their own right; not unless		<!-- [rfced] We note several instances where the terms "inner"
	complemented by an outer header. In these cases it will often be		and "outer" appear on their own without context. We suggest that adding the
			word "header" (or otherwise) will make it more clear to the reader what
			is intended (e.g., inner header, outer IP header, etc.).
			Please review the following occurrences and let us know if/how they
			should be updated by providing OLD/NEW text (or by editing the XML file).
			Original (Section 3.1):
			Processing the shim and outer together is often
			necessary because the shim(s) are not sufficient for packet forwarding in
			their own right; not unless complemented by an outer header.
			Original (Section 4):
			- it MUST NOT treat the former ToS octet (IPv4) or the
			former Traffic Class octet (IPv6) as a single 8-bit field, as the resulting
			linkage of ECN and Diffserv field propagation between inner and outer is not
			consistent with the definition of the 6-bit Diffserv field in [RFC2474] and
			[RFC3260];
			Original (Section 4):
			For instance, if a tunnel ingress with no ECN-specific
			logic had a configuration capability to refer to the last 2 bits of the old
			ToS Byte of the outer (e.g. with a 0x3 mask) and set them to zero
			Original (Section 6):
			Some of the listed protocols enable encapsulation of a
			variety of network layer protocols as inner and/or outer.
			Original (Section 6.1.1.2):
			If the egress supports ECN propagation, the
			ingress LCCE can use the normal mode of encapsulation (copying the ECN field
			from inner to outer).
			Original (Section 6.1.1.2.1):
			Then, for any sessions created by that control
			connection, both ends of the tunnel can use the normal mode of RFC 6040,
			i.e. they can copy the IP ECN field from inner to outer when encapsulating
			data packets.
			Original (Section 6.1.4.2):
			Then whenever it tunnels datagrams towards this
			gateway, it MUST use the normal mode of RFC 6040 to propagate the ECN field
			when encapsulating datagrams (i.e. it copies the IP ECN field from inner to
			outer).
			-->
			Processing the
			shim and outer together is often necessary because the shim(s) is not
			sufficient for packet forwarding in its own right; not unless
			complemented by an outer header. In these cases, it will often be
	feasible for an implementation to propagate the ECN field between the		feasible for an implementation to propagate the ECN field between the
	IP headers.</t>		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 behavior.
	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
			"/>, 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 any of the following		configured to zero the outer ECN field in any 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>
			<!-- [rfced] Some author comments are present in the XML. Please confirm
			that no updates related to these comments are outstanding. Note that the
			comments will be deleted prior to publication.
			-->
	<!--...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).-->		<!--...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"/>); or</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.-->		<!--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>		<!-- [rfced] We are having trouble parsing the following text. Specifically,
	<li>		the phrase "in order that the network operator" seems awkwardly
	<t>In order that the network operator can comply with the above		phrased. Does the suggested text convey the intended meaning?
			Original:
			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:
			Perhaps:
			In order for the network operator to comply with the above safety
			rules, even if an implementation of a tunnel ingress does not claim to support
			[RFC6040], [RFC4301], or the full functionality mode of [RFC3168]:
			-->
			<t>In order that the network operator can comply with the above
	safety rules, even if an implementation of a tunnel ingress does not		safety rules, even if an implementation of a tunnel ingress does not
	claim to support RFC 6040, RFC 4301 or the full functionality mode		claim to support <xref target="RFC6040"/>, <xref target="RFC4301"/>, o
	of RFC 3168:</t>		r the full functionality mode
			of <xref target="RFC3168"/>:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	<t>it MUST NOT treat the former ToS octet (IPv4) or the former		<t>The network operator <bcp14>MUST NOT</bcp14> treat the former Type of Service (ToS) octet (IPv4) or the former
	Traffic Class octet (IPv6) as a single 8-bit field, as the		Traffic Class octet (IPv6) as a single 8-bit field, as 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 is not consistent with the definition of the
	6-bit Diffserv field in <xref target="RFC2474" format="default"/> 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		<!-- [rfced] We are having difficulty parsing the following text. May we
			rephrase the following list item for readability?
			Original:
			- it SHOULD be able to be configured to zero the ECN field of the
			outer header.
			Perhaps:
			* The network operator SHOULD be able to configure the ECN field of
			the outer header to zero.
			Or ("zero" as a verb):
			* The network operator SHOULD be able to zero the ECN field of
			the outer header.
			-->
			<t>The network operator <bcp14>SHOULD</bcp14> be able to be config
			ured to zero the ECN field of
	the outer header.</t>		the outer header.</t>
	</li>		</li>
	</ul>		</ul>
	<t>"</t>		</blockquote>
	</li>		<t>For instance, if a tunnel ingress with no ECN-specific logic had a
	</ul>
	<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.</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 requirements		<t><xref target="RFC3168" section="5.3" sectionFormat="of"/> specifies ECN 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 rea-tunnels" format="default"/>). The following two additional		the tunnel egress can reassemble the fragments <xref target="I-D.ietf-inta 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		<!-- [rfced] FYI, we have rephrased the following paragraph to limit
	coupled shim header(s), in rough chronological order. The list is		redundancy. Please let us know if this conveys the intended meaning.
	confined to standards track or widely deployed protocols. The list is
	not necessarily exhaustive so, for the avoidance of doubt, the scope of		Original:
	RFC 6040 is defined in <xref target="rfc6040up_scope" format="default"/> a		There follows a list of specifications of encapsulations with tightly
	nd is not		coupled shim header(s), in rough chronological order. The list is
	limited to this list. </t>		confined to standards track or widely deployed protocols. The list
			is not necessarily exhaustive so, for the avoidance of doubt, the
			scope of RFC 6040 is defined in Section 3 and is not limited to this
			list.
			Current:
			Below is a list of specifications of encapsulations with tightly
			coupled shim header(s) in rough chronological order. This list is
			confined to Standards Track or widely deployed protocols and
			is not necessarily exhaustive, so for the avoidance of doubt, the
			scope of [RFC6040] is defined in Section 3.
			-->
			<t>Below is a list of specifications of encapsulations with tightly coupled
			shim header(s) in rough chronological order. This list is confined to
			Standards Track or widely deployed protocols and is not necessarily
			exhaustive, so for the avoidance of doubt, the scope of <xref
			target="RFC6040"/> is defined in <xref target="rfc6040up_scope"
			format="default"/>.</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 2 Tunnelling Protocol (L2TP), specifically L2TPv2 <xref targe t="RFC2661" format="default"/> and L2TPv3 <xref target="RFC3931" format="default "/>, 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 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. In contrast, Generic Protocol Extensio
	Protocol Extension) is being documented under IETF change control. It is		n for VXLAN (VXLAN-GPE) is being documented under IETF change control. It is
	RECOMMENDED that VXLAN and VXLAN-GPE implementations comply with RFC		<bcp14>RECOMMENDED</bcp14> that VXLAN and VXLAN-GPE implementations comply
	6040 when the VXLAN header is inserted between (or removed from between)		with <xref target="RFC6040"/> when the VXLAN header is inserted between (or rem
			oved from between)
	IP headers. The authors of any future update to these specifications are		IP headers. The authors of any future update to these specifications are
	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 updated by
	the present specification.<!--{ToDo: Update this text if the VXLAN-GPE dra ft gets updated before the present draft reaches the RFC Editor.}-->		the present specification.<!--{ToDo: Update this text if the VXLAN-GPE dra ft gets updated before the present draft reaches the RFC Editor.}-->
	</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		when handling transport encapsulation <xref target="RFC9600" format="defau
	upport" format="default"/>.</t>		lt"/>.</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
	<xref target="rfc6040up_scope" format="default"/> of the present specifica		arget="RFC6040"/> when propagating the ECN field between inner and outer IP head
	tion updates		ers.
	RFC 6040 to clarify that its scope includes cases with a shim header		<xref target="rfc6040up_scope" format="default"/> updates
	between the IP headers. So it indirectly updates the scope of RFC 8085		<xref target="RFC6040"/> to clarify that its scope includes cases with a s
			him header
			between the IP headers. It indirectly updates the scope of <xref target="R
			FC8085"/>
	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 indirectly update the UDP usage gui
			delines 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.</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		<!-- [rfced] May we rephrase the following sentence to avoid repetition of
	stack of headers can be encapsulated optionally within an outer UDP		"then" and clarify the text?
	header then an outer PSN header that is typically IP (v4 or v6).</t>
			Original:
			Then this whole stack of headers can be
			encapsulated optionally within an outer UDP header then an outer PSN
			header that is typically IP (v4 or v6).
			Perhaps:
			Afterwards, this whole stack of headers can be encapsulated
			optionally within an outer UDP header, then an outer PSN header that is
			typically IP (v4 or v6).
			Or:
			Afterwards, this whole stack of headers can be encapsulated
			optionally within an outer UDP header, which is then encapsulated
			by an outer PSN header that is typically IP (v4 or v6).
			-->
			Then this whole stack of headers can be encapsulated optionally within an
			outer UDP header then an outer PSN header that is typically IP (v4 or v6).
			</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 that is 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
	follow the rules for propagation of the ECN field at ingress and		follow the rules for propagation of the ECN field at ingress and
	egress in Section 4 of RFC 6040 <xref target="RFC6040" format="defau		egress in <xref target="RFC6040" section="4" sectionFormat="of"/> to
	lt"/>.</t>		comply with <xref target="RFC6040"/>.</t>
	<t>Before encapsulating any data packets, RFC 6040 requires an		<t>Before encapsulating any data packets, <xref target="RFC6040"/>
	ingress LCCE to check that the egress LCCE supports ECN		requires an ingress LCCE to check that the egress LCCE supports
	propagation as defined in RFC 6040 or one of its compatible		ECN propagation as defined in <xref target="RFC6040"/> or one of
	predecessors (<xref target="RFC4301" format="default"/> or the full		its compatible predecessors (<xref target="RFC4301"
	functionality		format="default"/> or the full functionality mode of <xref
	mode of <xref target="RFC3168" format="default"/>). If the egress su		target="RFC3168" format="default"/>).
	pports ECN		If the egress supports 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		. 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>
	</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"/>.
	<xref target="RFC5129" format="default"/>. Where no specification exis		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
			the ECN field when encapsulating datagrams (i.e., it
	copies the IP ECN field from inner to outer).</t>		copies the IP ECN field from inner to outer).</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"/>
	<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"/>		<!-- [I-D.ietf-tsvwg-ecn-encap-guidelines] in REF state as of 04/29/24; companio
	<author fullname="D. Black" initials="D." surname="Black"/>		n document RFC 9599 -->
	<date month="December" year="1998"/>
	<abstract>		<reference anchor="RFC9599" target="https://www.rfc-editor.org/info/rfc9599">
	<t>This document defines the IP header field, called the DS (for d		<front>
	ifferentiated services) field. [STANDARDS-TRACK]</t>		<title>Guidelines for Adding Congestion Notification to Protocols that Encapsula
	</abstract>		te IP</title>
	</front>		<author initials='B' surname='Briscoe' fullname='Bob Briscoe'>
	<seriesInfo name="RFC" value="2474"/>		<organization />
	<seriesInfo name="DOI" value="10.17487/RFC2474"/>		</author>
	</reference>		<author initials='J' surname='Kaippallimalil' fullname='John Kaippallimalil'>
	<reference anchor="RFC2661" target="https://www.rfc-editor.org/info/rfc2		<organization />
	661" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2661.xml">		</author>
	<front>		<date month='June' year='2024' />
	<title>Layer Two Tunneling Protocol "L2TP"</title>		</front>
	<author fullname="W. Townsley" initials="W." surname="Townsley"/>		<seriesInfo name="RFC" value="9599"/>
	<author fullname="A. Valencia" initials="A." surname="Valencia"/>		<seriesInfo name="DOI" value="10.17487/RFC9599"/>
	<author fullname="A. Rubens" initials="A." surname="Rubens"/>		</reference>
	<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		<!-- [I-D.ietf-sfc-nsh-ecn-support] in REF state as of 4/29/2024; companion doc
	int Protocol (PPP) to be tunneled through an IP network. This memo provides info		RFC 9600 -->
	rmation for the Internet community.</t>		<reference anchor="RFC9600" target="https://www.rfc-editor.org/info/rfc9600">
	</abstract>		<front>
	</front>		<title>
	<seriesInfo name="RFC" value="2637"/>		Explicit Congestion Notification (ECN) and Congestion Feedback Using the Network
	<seriesInfo name="DOI" value="10.17487/RFC2637"/>		Service Header (NSH) and IPFIX
	</reference>		</title>
	<reference anchor="RFC2983" target="https://www.rfc-editor.org/info/rfc2		<author initials="D." surname="Eastlake" fullname="Donald E. Eastlake 3rd">
	983" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2983.xml">		<organization>Futurewei Technologies</organization>
	<front>		</author>
	<title>Differentiated Services and Tunnels</title>		<author initials="B." surname="Briscoe" fullname="Bob Briscoe">
	<author fullname="D. Black" initials="D." surname="Black"/>		<organization>Independent</organization>
	<date month="October" year="2000"/>		</author>
	<abstract>		<author initials="S." surname="Zhuang" fullname="Shunwan Zhuang">
	<t>This document considers the interaction of Differentiated Servi		<organization>Huawei Technologies</organization>
	ces (diffserv) with IP tunnels of various forms. This memo provides information		</author>
	for the Internet community.</t>		<author initials="A." surname="Malis" fullname="Andrew G. Malis">
	</abstract>		<organization>Malis Consulting</organization>
	</front>		</author>
	<seriesInfo name="RFC" value="2983"/>		<author initials="X." surname="Wei" fullname="Xinpeng Wei">
	<seriesInfo name="DOI" value="10.17487/RFC2983"/>		<organization>Huawei Technologies</organization>
	</reference>		</author>
	<reference anchor="RFC3260" target="https://www.rfc-editor.org/info/rfc3		<date month="June" year="2024"/>
	260" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3260.xml">		</front>
	<front>		<seriesInfo name="RFC" value="9600"/>
	<title>New Terminology and Clarifications for Diffserv</title>		<seriesInfo name="DOI" value="10.17487/RFC9600"/>
	<author fullname="D. Grossman" initials="D." surname="Grossman"/>		</reference>
	<date month="April" year="2002"/>
	<abstract>		<!-- [I-D.ietf-intarea-tunnels] IESG state Expired -->
	<t>This memo captures Diffserv working group agreements concerning
	new and improved terminology, and provides minor technical clarifications. It i		<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-in
	s intended to update RFC 2474, RFC 2475 and RFC 2597. When RFCs 2474 and 2597 ad		tarea-tunnels.xml"/>
	vance on the standards track, and RFC 2475 is updated, it is intended that the r		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9329.xml"
	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>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9331.xml"
	</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 discu
	for ECN propagation in L2TP and its applicability. Thanks also to Carlos		ssions on the need
	Pignataro, Tom Herbert, Ignacio Goyret, Alia Atlas, Praveen		for ECN propagation in L2TP and its applicability. Thanks also to <contact
	Balasubramanian, Joe Touch, Mohamed Boucadair, David Black, Jake		fullname="Carlos
	Holland, Sri Gundavelli, Gorry Fairhurst and Martin Duke for helpful		Pignataro"/>, <contact fullname="Tom Herbert"/>, <contact fullname="Ignaci
	advice and comments. "A Comparison of IPv6-over-IPv4 Tunnel Mechanisms"		o Goyret"/>, <contact fullname="Alia Atlas"/>, <contact fullname="Praveen
	<xref target="RFC7059" format="default"/> helped to identify a number of t		Balasubramanian"/>, <contact fullname="Joe Touch"/>, <contact fullname="Mo
	unnelling		hamed Boucadair"/>, <contact fullname="David Black"/>, <contact fullname="Jake
			Holland"/>, <contact fullname="Sri Gundavelli"/>, <contact fullname="Gorry
			Fairhurst"/>, and <contact fullname="Martin Duke"/> for helpful
			advice and comments. <xref target="RFC7059" format="default"/> helped to i
			dentify a number of tunnelling
	protocols to include within the scope of this document.</t>		protocols to include within the scope of this document.</t>
	<t>Bob Briscoe was part-funded by the Research Council of Norway through
	the TimeIn project for early drafts, and for final drafts (from -17) he		<t><contact fullname="Bob Briscoe"/> Bob Briscoe was part-funded by the
	was funded by Apple Inc. The views expressed here are solely those of		Research Council 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>
			<!-- [rfced] We note that "tunnelling" was used consistently in the original
			with the exception of a few expanded abbreviations, for example,
			"Automatic Multicast Tunneling (AMT)". We suggest updating instances of
			"tunnelling" to "tunneling" except where it appears in the title of
			another document; please let us know if this is acceptable.
			For example, we suggest updating to the form on the right:
			Layer 2 Tunnelling Protocol (L2TP) vs. Layer 2 Tunneling Protocol (L2TP)
			GPRS Tunnelling Protocol (GTP) vs. GPRS Tunneling Protocol (GTP)
			-->
			<!-- [rfced] FYI - We have added expansions for abbreviations upon first use
			per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
			expansion in the document carefully to ensure correctness.
			-->
			<!-- [rfced] Please review the "Inclusive Language" portion of the online
			Style Guide
			<https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let
			us know if any changes are needed. Note that our script did not flag any
			words in particular, but this should still be reviewed as a best
			practice.
			-->
	</back>		</back>
	</rfc>		</rfc>
End of changes. 187 change blocks.
	1437 lines changed or deleted		780 lines changed or added
This html diff was produced by rfcdiff 1.48.