<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type='text/xsl' href='https://xml.resource.org/authoring/rfc2629.xslt' ?>
<!-- Alterations to I-D/RFC boilerplate -->
<?rfc private="" ?>
<!-- Default private="" Produce an internal memo 2.5pp shorter than an I-D or RFC -->
<?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 latest 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; otherwise 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" submissionType="IETF" category="std" consensus="true" docName="draft-ietf-tsvwg-rfc6040update-shim-23" number="9601" ipr="pre5378Trust200902" updates="6040, 2661, 2784, 3931, 4380, 7450" obsoletes="" submissionType="IETF" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3">

  <front>
<!-- xml2rfc v2v3 conversion 3.18.2 [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
-->
  <front>
    <title abbrev="ECN over IP-shim-(L2)-IP Tunnels">Propagating Explicit
    Congestion Notification Across across IP Tunnel Headers Separated by a
    Shim</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-tsvwg-rfc6040update-shim-23"/> name="RFC" value="9601"/>
    <author fullname="Bob Briscoe" initials="B." surname="Briscoe">
      <organization>Independent</organization>
      <address>
        <postal>
          <street/>
          <country>UK</country>
          <country>United Kingdom</country>
        </postal>
        <email>ietf@bobbriscoe.net</email>
        <uri>https://bobbriscoe.net/</uri>
      </address>
    </author>
    <date year=""/>
    <area>Transport</area>
    <workgroup>Transport Area Working Group</workgroup> year="2024" month="June"/>
    <area>tsv</area>
    <workgroup>tsvwg</workgroup>
    <keyword>Congestion Control and Management</keyword>
    <keyword>Congestion Notification</keyword>
    <keyword>Information Security</keyword>
    <keyword>Tunnelling</keyword>
    <keyword>Encapsulation &amp; Decapsulation</keyword>
    <keyword>Protocol</keyword>
    <keyword>ECN</keyword>
    <keyword>Layering</keyword>
    <abstract>
      <t>RFC 6040 on "Tunnelling of Explicit Congestion Notification" made the
      rules for propagation of ECN Explicit Congestion Notification (ECN) consistent for all forms of IP in IP IP-in-IP
      tunnel. This specification updates RFC 6040 to clarify that its scope
      includes tunnels where two IP headers are separated by at least one shim
      header that is not sufficient on its own for wide area wide-area packet
      forwarding. It surveys widely deployed IP tunnelling protocols that use
      such shim header(s) headers and updates the specifications of those that do not
      mention ECN propagation (that is RFC (including RFCs 2661, RFC 3931, RFC 2784, RFC 4380
      and RFC 7450, which respectively 7450; these RFCs specify L2TPv2, L2TPv3, GRE, Teredo Generic Routing Encapsulation (GRE), Teredo, and
      AMT).
      Automatic Multicast Tunneling (AMT), respectively). This specification also updates RFC 6040 with configuration
      requirements needed to make any legacy tunnel ingress safe.</t>
    </abstract>
  </front>
  <!-- ================================================================ -->
  <middle>
    <!-- ================================================================ -->

    <section anchor="rfc6040up_Introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>RFC 6040
      <t><xref target="RFC6040"/> on "Tunnelling of Explicit Congestion Notification" <xref target="RFC6040" format="default"/> made the rules for propagation of Explicit Congestion
      Notification (ECN (ECN) <xref target="RFC3168" format="default"/>) format="default"/> consistent for all forms of
      IP in IP
      IP-in-IP tunnel.</t>
      <t>A common pattern for many tunnelling protocols is to encapsulate an
      inner IP header (v4 or v6) with one or more shim header(s) headers then an outer IP header
      (v4 or v6). Some of these shim headers are designed as generic
      encapsulations, so they do not necessarily directly encapsulate an inner
      IP header. Instead, they can encapsulate headers such as link-layer (L2) protocols that that, in turn
turn, often encapsulate IP.</t>
      <t>To clear up confusion, this specification clarifies that the scope of
      RFC 6040
      <xref target="RFC6040"/> includes any IP-in-IP tunnel, including those with one or more shim
      header(s)
      headers and other encapsulations between the IP headers. Where
      necessary, it updates the specifications of the relevant encapsulation
      protocols with the specific text necessary to comply with RFC 6040.</t> <xref target="RFC6040"/>.</t>
      <t>This specification also updates RFC 6040 <xref target="RFC6040"/> to state how operators ought
      to configure a legacy tunnel ingress to avoid unsafe system
      configurations.</t>
    </section>
    <!-- ================================================================ -->
    <section anchor="rfc6040up_Reqs_Language" numbered="true" toc="default">
      <name>Terminology</name>
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
      "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and
      "OPTIONAL"
      "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in
      BCP&nbsp;14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/> when, and
      only when, they appear in all capitals, as shown here.</t>
      <t>This specification uses the terminology defined in RFC 6040 <xref target="RFC6040" format="default"/>.</t>
    </section>
    <section anchor="rfc6040up_scope" numbered="true" toc="default">
      <name>Scope of RFC 6040</name>
      <t>In section 1.1 of RFC 6040, <xref target="RFC6040" section="1.1" sectionFormat="of"/>, its scope is defined as: </t>
      <ul empty="true" spacing="normal">
        <li>
          <t>"...ECN

      <blockquote>
          ...ECN field processing at encapsulation and decapsulation for
          any IP-in-IP tunnelling, whether IPsec or non-IPsec tunnels. It
          applies irrespective of whether IPv4 or IPv6 is used for either the
          inner or outer headers. ..."</t>
        </li>
      </ul>
      </blockquote>

      <t>This was intended to include cases where one or more shim header(s) sit headers sits between
      the IP headers. Many tunnelling implementers have interpreted the scope
      of RFC 6040 <xref target="RFC6040"/> as it was intended, but it is ambiguous. Therefore, this
      specification updates RFC 6040 <xref target="RFC6040"/> by adding the following scoping text
      after the sentences quoted above:</t>
      <ul empty="true" spacing="normal">
        <li>
          <t>It

        <blockquote>
          It applies in cases where an outer IP header encapsulates an
          inner IP header either directly or indirectly by encapsulating other
          headers that in turn encapsulate (or might encapsulate) an inner IP
          header.</t>
        </li>
      </ul>
          header.
	</blockquote>

      <t>There is another problem with the scope of RFC 6040. <xref target="RFC6040"/>. Like many IETF
      specifications, RFC 6040 <xref target="RFC6040"/> is written as a specification that
      implementations can choose to claim compliance with. This means it does
      not cover two important cases:</t>
      <ol spacing="normal" type="1"><li>
          <t>those cases
          <t>Cases where it is infeasible for an implementation to
          access an inner IP header when adding or removing an outer IP
          header;</t>
          header</t>
        </li>
        <li>
          <t>those implementations
          <t>Implementations that choose not to propagate ECN between IP
          headers.</t>
          headers</t>
        </li>
      </ol>
      <t>However, the ECN field is a non-optional part of the IP header (v4
      and v6). So v6), so any implementation that creates an outer IP header has to
      give the ECN field some value. There is only one safe value a tunnel
      ingress can use if it does not know whether the egress supports
      propagation of the ECN field; it has to clear the ECN field in any outer
      IP header to 0b00.</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
      not to comply with it or cannot comply with it, including all those
      implementations that predated the RFC. Therefore, it would have been
      unreasonable to add such a requirement to RFC 6040. <xref target="RFC6040"/>. Nonetheless, to
      ensure safe propagation of the ECN field over tunnels, it is reasonable
      to add requirements on operators, operators to ensure they configure their tunnels
      safely (where possible). Before stating these configuration requirements
      in <xref target="rfc6040up_sec_safe" format="default"/>, the factors that determine
      whether propagating ECN is feasible or desirable will be briefly
      introduced.</t>
      <section anchor="rfc6040up_feasibility" numbered="true" toc="default">
        <name>Feasibility of ECN Propagation between Tunnel Headers</name>
        <t>In many cases cases, one or more shim header(s) headers and an outer IP header are always
        added to (or removed from) an inner IP packet as part of the same
        procedure. We call this a tightly coupled shim header.

<!-- [rfced] We note several instances where the terms "inner"
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 cases, it will often be
        feasible for an implementation to propagate the ECN field between the
        IP headers.</t>
        <t>In some cases cases, a tunnel adds an outer IP header and a tightly
        coupled shim header to an inner header that is not an IP header, but
        that
        that, in turn turn, encapsulates an IP header (or might encapsulate an IP
        header). For instance instance, an inner Ethernet (or other link layer) link-layer) header
        might encapsulate an inner IP header as its payload. We call this a
        tightly coupled shim over an encapsulating header.</t>
        <t>Digging to arbitrary depths to find an inner IP header within an
        encapsulation is strictly a layering violation violation, so it cannot be a
        required behaviour. behavior.

Nonetheless, some tunnel endpoints already look
        within a L2 Layer 2 (L2) header for an IP header, for instance instance, to map the Diffserv
        codepoint between an encapsulated IP header and an outer IP header
        <xref target="RFC2983" format="default"/>. In such cases at least, it should be
        feasible to also (independently) propagate the ECN field between the
        same IP headers. Thus, access to the ECN field within an encapsulating
        header can be a useful and benign optimization. The guidelines in
        section 5 of
        <xref target="I-D.ietf-tsvwg-ecn-encap-guidelines" format="default"/> target="RFC9599" section="5" sectionFormat="of"/> give
        the conditions for this layering violation to be benign.</t>
      </section>
      <section anchor="rfc6040up_desirability" numbered="true" toc="default">
        <name>Desirability of ECN Propagation between Tunnel Headers</name>
        <t>Developers and network operators are encouraged to implement and
        deploy tunnel endpoints compliant with RFC 6040 <xref target="RFC6040"/> (as updated by the
        present specification) in order to provide the benefits of wider ECN
        deployment <xref target="RFC8087" format="default"/>. Nonetheless, propagation of ECN
        between IP headers, whether separated by shim headers or not, has to
        be optional to implement and to use, because:</t>
        <ul spacing="normal">
          <li>
            <t>Legacy
            <t>legacy implementations of tunnels without any ECN support
            already exist</t> exist;</t>
          </li>
          <li>
            <t>A
            <t>a network might be designed so that there is usually no
            bottleneck within the tunnel</t> tunnel; and</t>
          </li>
          <li>
            <t>If
            <t>if the tunnel endpoints would have to search within an L2
            header to find an encapsulated IP header, it might not be worth
            the potential performance hit.</t>
          </li>
        </ul>
      </section>
    </section>
    <section anchor="rfc6040up_sec_safe" numbered="true" toc="default">
      <name>Making a non-ECN Non-ECN Tunnel Ingress Safe by Configuration</name>
      <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
      operator to render a tunnel ingress safe by configuration. The main
      safety concern is to disable (clear to zero) the ECN capability in the
      outer IP header at the ingress if the egress of the tunnel does not
      implement ECN logic to propagate any ECN markings into the packet
      forwarded beyond the tunnel. Otherwise, the non-ECN egress could discard
      any ECN marking introduced within the tunnel, which would break all the
      ECN-based control loops that regulate the traffic load over the
      tunnel.</t>
      <t>Therefore
      <t>Therefore, this specification updates RFC 6040 <xref target="RFC6040" section="4.3"/> by inserting the
      following text at the end of section 4.3:</t>
      <ul empty="true" spacing="normal">
        <li>
          <t>"</t> the section:</t>

      <blockquote>

<t>Whether or not an ingress implementation
          claims compliance with RFC 6040, RFC 4301 <xref target="RFC6040"/>, <xref target="RFC4301"/>, or RFC3168, <xref target="RFC3168"/>, when the outer
          tunnel header is IP (v4 or v6), if possible, the ingress MUST <bcp14>MUST</bcp14> be
          configured to zero the outer ECN field in any of the following
          cases:</t>
          <ul spacing="normal">
            <li>
	      <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
              4301 (<xref target="RFC6040"/>, <xref target="RFC4301"/>, or the full functionality mode of RFC 3168);</t> <xref target="RFC3168"/>);</t>
            </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).-->

              <li>
              <t>or if
             <t>if the behaviour of the egress is not known or an egress
              with unknown behaviour might be dynamically paired with the
              ingress (one way for an operator of a tunnel ingress to
              determine the behaviour of an otherwise unknown egress is
              described in <xref target="decap-test" format="default"/>);</t> format="default"/>); or</t>
            </li>
            <li>
              <t>or if
            <t>if an IP header might be encapsulated within a non-IP
              header that the tunnel ingress is encapsulating, but the ingress
              does not inspect within the encapsulation.</t>
            </li>

            <!--Not sure this last bullet is needed. The above commented addition to the first bullet would be better.-->
            </ul>
         <t>For the avoidance of doubt, the above only concerns the
          outer IP header. The ingress MUST NOT <bcp14>MUST NOT</bcp14> alter the ECN field of the
          arriving IP header that will become the inner IP header.</t>
        </li>
        <li>
          <t>In
<!-- [rfced] We are having trouble parsing the following text. Specifically,
the phrase "in order that the network operator" seems awkwardly
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:</t> 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
          claim to support <xref target="RFC6040"/>, <xref target="RFC4301"/>, or the full functionality mode
          of <xref target="RFC3168"/>:</t>
          <ul spacing="normal">
            <li>
              <t>it MUST NOT
<t>The network operator <bcp14>MUST NOT</bcp14> treat the former ToS Type of Service (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 <xref target="RFC2474" format="default"/> and <xref target="RFC3260" format="default"/>;</t> format="default"/>.</t>
            </li>
            <li>
              <t>it
<!-- [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 configured to zero the ECN field of
              the outer header.</t>
            </li>
          </ul>
          <t>"</t>
        </li>
      </ul>
      </blockquote>
<t>For instance, if a tunnel ingress with no ECN-specific logic had a
      configuration capability to refer to the last 2 bits of the old ToS Byte
      of the outer (e.g.&nbsp;with (e.g., with a 0x3 mask) and set them to zero, while
      also being able to allow the DSCP to be re-mapped independently, that
      would be sufficient to satisfy both the above implementation
      requirements.</t>
      requirements above.</t>
      <t>There might be concern that the above "MUST NOT" "<bcp14>MUST NOT</bcp14>" makes compliant
      implementations non-compliant at a stroke. However, by definition definition, it
      solely applies to equipment that provides Diffserv configuration. Any
      such Diffserv equipment that is configuring treatment of the former ToS
      octet (IPv4) or the former Traffic Class octet (IPv6) as a single 8-bit
      field must have always been non-compliant with the definition of the
      6-bit Diffserv field in <xref target="RFC2474" format="default"/> and <xref 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
      seriously unsafe bug that risks breaking the feedback loops that
      regulate load on a tunnel.</t>
      <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
      6040 <xref target="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> section="4.3" sectionFormat="of"/>).</t>
    </section>
    <section numbered="true" toc="default">
      <name>ECN Propagation and Fragmentation/Reassembly</name>
      <t>The following requirements update RFC6040, <xref target="RFC6040"/>, which omitted handling of
      the ECN field during fragmentation or reassembly. These changes might
      alter how many ECN-marked packets are propagated by a tunnel that
      fragments packets, but this would not raise any backward compatibility
      issues:</t>
      issues.</t>
      <t>If a tunnel ingress fragments a packet, it MUST <bcp14>MUST</bcp14> set the outer ECN
      field of all the fragments to the same value as it would have set if it
      had not fragmented the packet.</t>
      <t>Section 5.3 of <xref
      <t><xref target="RFC3168" format="default"/> section="5.3" sectionFormat="of"/> specifies ECN requirements
      for reassembly of sets of outer fragments into packets (in outer
      fragmentation, the fragmentation is visible in the outer header so that
      the tunnel egress can reassemble the fragments <xref target="I-D.ietf-intarea-tunnels" format="default"/>). The Additionally, the following two additional
      requirements apply at a tunnel egress:</t>
      <ul spacing="normal">
        <li>
          <t>During
          During reassembly of outer fragments, the packet <bcp14>MUST</bcp14> be discarded if the ECN fields of the
          outer headers being reassembled into a single packet consist of a
          mixture of Not-ECT Not ECN-Capable Transport (Not-ECT) and other ECN codepoints, the packet MUST be
          discarded.</t> codepoints.
        </li>
        <li>
          <t>If
          If there is mix of ECT(0) and ECT(1) outer fragments, then the
          reassembled packet MUST <bcp14>MUST</bcp14> be set to ECT(1).</t>
          <t>Reasoning: Originally ECT(1).</li>
</ul>
          <t indent="3">Reasoning: <xref target="RFC3168" format="default"/>
          originally defined ECT(0) and ECT(1) as equivalent, but RFC 3168 <xref target="RFC3168"/> has been
          updated by <xref target="RFC8311" format="default"/> to make ECT(1) available for
          congestion marking differences. The rule is independent of the
          current experimental use of ECT(1) for L4S Low Latency, Low Loss, and Scalable throughput (L4S) <xref target="RFC9331" format="default"/>.
          The rule is compatible with PCN Pre-Congestion Notification (PCN) <xref target="RFC6660" format="default"/>, which uses
          2 levels of congestion severity, with the ranking of severity from
          highest to lowest being CE, Congestion Experienced (CE), ECT(1), ECT(0)). ECT(0). The decapsulation rules
          in <xref target="RFC6040" format="default"/> take a similar approach.</t>
        </li>
      </ul>
    </section>
    <section anchor="rfc6040up_IP-IP_Coupled_Shim_Tunnels" numbered="true" toc="default">
      <name>IP-in-IP Tunnels with Tightly Coupled Shim Headers</name>
      <t>There
<!-- [rfced] FYI, we have rephrased the following paragraph to limit
redundancy. Please let us know if this conveys the intended meaning.

Original:
   There follows a list of specifications of encapsulations with tightly
   coupled shim header(s), in rough chronological order.  The list is
   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 <xref target="rfc6040up_scope" format="default"/> Section 3 and is not limited to this
   list. </t>

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">
        <li>
          <t>PPTP (Point-to-Point
          <t>Point-to-Point Tunneling Protocol) Protocol (PPTP) <xref target="RFC2637" format="default"/>;</t> format="default"/></t>
        </li>
        <li>
          <t>L2TP (Layer
          <t>Layer 2 Tunnelling Protocol), Protocol (L2TP), specifically L2TPv2 <xref target="RFC2661" format="default"/> and L2TPv3 <xref target="RFC3931" format="default"/>, which not
          only includes all the L2-specific specializations of L2TP, but also
          derivatives such as the Keyed IPv6 Tunnel <xref target="RFC8159" format="default"/>;</t> format="default"/></t>
        </li>
        <li>
          <t>GRE (Generic
          <t>Generic Routing Encapsulation) Encapsulation (GRE) <xref target="RFC2784" format="default"/> and
          NVGRE (Network Network Virtualization using GRE) GRE (NVGRE) <xref target="RFC7637" format="default"/>;</t> format="default"/></t>
        </li>
        <li>
          <t>GTP (GPRS
          <t>GPRS Tunnelling Protocol), Protocol (GTP), specifically GTPv1 <xref target="GTPv1" format="default"/>, GTP v1 User Plane <xref target="GTPv1-U" format="default"/>, and GTP v2
          Control Plane <xref target="GTPv2-C" format="default"/>;</t> format="default"/></t>
        </li>
        <li>
          <t>Teredo <xref target="RFC4380" format="default"/>;</t> format="default"/></t>
        </li>
        <li>
          <t>CAPWAP (Control
          <t>Control And Provisioning of Wireless Access Points) Points (CAPWAP) <xref target="RFC5415" format="default"/>;</t> format="default"/></t>
        </li>
        <li>
          <t>LISP (Locator/Identifier
          <t>Locator/Identifier Separation Protocol) Protocol (LISP) <xref target="RFC9300" format="default"/>;</t> format="default"/></t>
        </li>
        <li>
          <t>AMT (Automatic
          <t>Automatic Multicast Tunneling) Tunneling (AMT) <xref target="RFC7450" format="default"/>;</t> format="default"/></t>
        </li>
        <li>
          <t>VXLAN (Virtual
          <t>Virtual eXtensible Local Area Network) Network (VXLAN) <xref target="RFC7348" format="default"/> and VXLAN-GPE <xref target="I-D.ietf-nvo3-vxlan-gpe" format="default"/>;</t> format="default"/></t>
        </li>
        <li>
          <t>The Network Service Header (NSH (NSH) <xref target="RFC8300" format="default"/>) format="default"/> for
          Service Function Chaining (SFC);</t> (SFC)</t>
        </li>
        <li>
          <t>Geneve <xref target="RFC8926" format="default"/>;</t> format="default"/></t>
        </li>
        <li>
          <t>Direct tunnelling of an IP packet within a UDP/IP datagram (see
          Section 3.1.11 of <xref target="RFC8085" format="default"/>);</t> section="3.1.11" sectionFormat="of"/>)</t>
        </li>
        <li>
          <t>TCP Encapsulation of IKE Internet Key Exchange Protocol (IKE) and IPsec Packets (see Section 9.5 of <xref target="RFC9329" format="default"/>).</t> section="9.5" sectionFormat="of"/>)</t>
        </li>
      </ul>
      <t>Some of the listed protocols enable encapsulation of a variety of
      network layer protocols as inner and/or outer. This specification
      applies in to the cases where there is an inner and outer IP header as
      described in <xref target="rfc6040up_scope" format="default"/>. Otherwise Otherwise, <xref target="I-D.ietf-tsvwg-ecn-encap-guidelines" target="RFC9599" format="default"/> gives guidance on how to
      design propagation of ECN into other protocols that might encapsulate
      IP.</t>
      <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
      in the following subsections. For those not under IETF control, it is
      RECOMMENDED
      <bcp14>RECOMMENDED</bcp14> that implementations of encapsulation and decapsulation
      comply with RFC 6040. <xref target="RFC6040"/>. It is also RECOMMENDED <bcp14>RECOMMENDED</bcp14> that their specifications
      are updated to add a requirement to comply with RFC 6040 <xref target="RFC6040"/> (as updated by
      the present document).</t>
      <t>PPTP is not under the change control of the IETF, but it has been
      documented in an informational Informational RFC <xref target="RFC2637" format="default"/>. However,
      there is no need for the present specification to update PPTP because
      L2TP has been developed as a standardized replacement.</t>
      <t>NVGRE is not under the change control of the IETF, but it has been
      documented in an informational Informational RFC <xref target="RFC7637" format="default"/>. NVGRE is a
      specific use-case use case of GRE (it re-purposes the key field from the initial
      specification of GRE <xref target="RFC1701" format="default"/> as a Virtual Subnet ID).
      Therefore
      Therefore, the text that updates GRE in <xref target="rfc6040up_GRE" format="default"/>
      below is also intended to update NVGRE.</t>
      <t>Although the definition of the various GTP shim headers is under the
      control of the 3rd Third Generation Partnership Project (3GPP), it is hard to
      determine whether the 3GPP or the IETF controls standardization of the
      <em>process</em> of adding both a GTP and an IP
      header to an inner IP header. Nonetheless, the present specification is
      provided so that the 3GPP can refer to it from any of its own
      specifications of GTP and IP header processing.</t>
      <t>The specification of CAPWAP already specifies RFC 3168 <xref target="RFC3168"/> ECN
      propagation and ECN capability negotiation. Without modification modification, the
      CAPWAP specification already interworks with the backward compatible backward-compatible
      updates to RFC 3168 <xref target="RFC3168"/> in RFC 6040.</t> <xref target="RFC6040"/>.</t>
      <t>LISP made the ECN propagation procedures in RFC 3168 <xref target="RFC3168"/> mandatory from
      the start. RFC 3168 <xref target="RFC3168"/> has since been updated by RFC 6040, <xref target="RFC6040"/>, but the changes
      are backwards compatible compatible, so there is still no need for LISP tunnel
      endpoints to negotiate their ECN capabilities.</t>
      <t>VXLAN is not under the change control of the IETF IETF, but it has been
      documented in an informational Informational RFC. In contrast, VXLAN-GPE (Generic Generic Protocol Extension) Extension for VXLAN (VXLAN-GPE) is being documented under IETF change control. It is
      RECOMMENDED
      <bcp14>RECOMMENDED</bcp14> that VXLAN and VXLAN-GPE implementations comply with RFC
      6040 <xref target="RFC6040"/> when the VXLAN header is inserted between (or removed from between)
      IP headers. The authors of any future update to these specifications are
      encouraged to add a requirement to comply with RFC 6040 <xref target="RFC6040"/> as updated by
      the present specification.<!--{ToDo: Update this text if the VXLAN-GPE draft gets updated before the present draft reaches the RFC Editor.}-->
      </t>
      <t>The Network Service Header (NSH (NSH) <xref target="RFC8300" format="default"/>) format="default"/> has been
      defined as a shim-based encapsulation to identify the Service Function
      Path (SFP) in the Service Function Chaining (SFC) architecture <xref target="RFC7665" format="default"/>. A proposal has been made for the processing of ECN
      when handling transport encapsulation <xref target="I-D.ietf-sfc-nsh-ecn-support" target="RFC9600" format="default"/>.</t>
      <t>The specification of Geneve already refers to RFC 6040 <xref target="RFC6040"/> for ECN
      encapsulation.</t>
      <t>Section 3.1.11 of RFC 8085
      <t><xref target="RFC8085" section="3.1.11" sectionFormat="of"/> already explains that a tunnel that
      encapsulates an IP header within a UDP/IP datagram needs to follow RFC
      6040 <xref target="RFC6040"/> when propagating the ECN field between inner and outer IP headers.
      <xref target="rfc6040up_scope" format="default"/> of the present specification updates
      RFC 6040
      <xref target="RFC6040"/> to clarify that its scope includes cases with a shim header
      between the IP headers. So it It indirectly updates the scope of RFC 8085 <xref target="RFC8085"/>
      to include cases with a shim header as well as a UDP header between the
      IP headers.</t>

      <t>The requirements in <xref target="rfc6040up_sec_safe" format="default"/> update RFC
      6040, <xref target="RFC6040"/>, and hence indirectly update the UDP usage guidelines in RFC 8085 <xref target="RFC8085"/>
      to add the important but previously unstated requirement that, if the
      UDP tunnel egress does not, or not (or might not, not) support ECN propagation, a UDP
      tunnel ingress has to clear the outer IP ECN field to 0b00, e.g.&nbsp;by e.g., by
      configuration.</t>
      <t>Section 9.5 of TCP Encapsulation of IKE and IPsec Packets <xref
      <t><xref target="RFC9329" format="default"/> sectionFormat="of" section="9.5"/> already recommends the compatibility mode of RFC 6040 <xref target="RFC6040"/>
      in this case, case because there is not a one-to-one mapping between inner
      and outer packets.</t>
      <section anchor="rfc6040up_rfc-updates" numbered="true" toc="default">
        <name>Specific Updates to Protocols under IETF Change Control</name>
        <section anchor="rfc6040up_L2TPv3" numbered="true" toc="default">
          <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>L2TPv3 <xref target="RFC3931" format="default"/> is used as a
          shim header between any packet-switched network (PSN) header (e.g.&nbsp;IPv4, (e.g.,
          IPv4, IPv6, and MPLS) and many types of layer 2 (L2) header. L2 headers. The L2TPv3 shim
          header encapsulates an L2-specific sub-layer sub-layer, then an L2 header that
          is likely to contain an inner IP header (v4 or v6).
<!-- [rfced] May we rephrase the following sentence to avoid repetition of
"then" and clarify the text?

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).</t> 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
          header, which
          header that is in turn likely to encapsulate an IP header.</t>
          <t>Even though these shims are rather fat (particularly in the case
          of L2TPv3), they still fit the definition of a tightly coupled shim
          header over an encapsulating header (<xref target="rfc6040up_feasibility" format="default"/>), format="default"/>) because all the headers
          encapsulating the L2 header are added (or removed) together. L2TPv2
          and L2TPv3 are therefore within the scope of RFC 6040, <xref target="RFC6040"/>, as updated by
          <xref target="rfc6040up_scope" format="default"/> above.</t> format="default"/>.</t>
          <t>Implementation of the ECN extension to L2TPv2 and L2TPv3 defined
          in <xref target="rfc6040up_L2TP_ECN" format="default"/> below is RECOMMENDED, <bcp14>RECOMMENDED</bcp14> in
          order to provide the benefits of ECN <xref target="RFC8087" format="default"/>, format="default"/>
          whenever a node within an L2TP tunnel becomes the bottleneck for an
          end-to-end traffic flow.</t>
          <section anchor="rfc6040up_L2TP_Safe" numbered="true" toc="default">
            <name>Safe Configuration of a 'Non-ECN' "Non-ECN" Ingress LCCE</name>
            <t>The following text is appended to both Section 5.3 of <xref target="RFC2661" format="default"/> section="5.3" sectionFormat="of"/> and Section 4.5 of <xref target="RFC3931" format="default"/> section="4.5" sectionFormat="of"/> as
            an update to the base L2TPv2 and L2TPv3 specifications:</t>
            <ul empty="true" spacing="normal">
              <li>
                <t>The
<blockquote>The operator of an LCCE that does not support the ECN
                Extension extension in
<xref target="rfc6040up_L2TP_ECN" format="default"/> of [this
                document] MUST RFC 9601
<bcp14>MUST</bcp14> follow the configuration requirements in <xref
target="rfc6040up_sec_safe" format="default"/> of [this document] RFC 9601 to ensure it
clears the outer IP ECN field to 0b00 when the outer PSN header is IP (v4 or v6).</t>
              </li>
            </ul>
v6).
</blockquote>

            <t>In particular, for an L2TP Control Connection Endpoint (LCCE)
            implementation that does not support the ECN Extension, extension, this means
            that configuration of how it propagates the ECN field between
            inner and outer IP headers MUST <bcp14>MUST</bcp14> be independent of any
            configuration of the Diffserv extension of L2TP <xref target="RFC3308" format="default"/>.</t>
          </section>
          <section anchor="rfc6040up_L2TP_ECN" numbered="true" toc="default">
            <name>ECN Extension for L2TP (v2 or v3)</name>
            <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
            follow the rules for propagation of the ECN field at ingress and
            egress in Section 4 of RFC 6040 <xref target="RFC6040" format="default"/>.</t> section="4" sectionFormat="of"/> to comply with <xref target="RFC6040"/>.</t>
            <t>Before encapsulating any data packets, RFC 6040 <xref target="RFC6040"/>
            requires an ingress LCCE to check that the egress LCCE supports
            ECN propagation as defined in RFC 6040 <xref target="RFC6040"/> or one of
            its compatible predecessors (<xref target="RFC4301"
            format="default"/> or the full functionality mode of <xref
            target="RFC3168" format="default"/>).
If the egress supports ECN
            propagation, the ingress LCCE can use the normal mode of
            encapsulation (copying the ECN field from inner to outer).
            Otherwise, the ingress LCCE has to use compatibility mode <xref
            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
            statically (by configuration) or by dynamic discovery during setup
            of each control connection between the LCCEs, LCCEs using the ECN
            Capability AVP Attribute-Value Pair (AVP) defined in <xref target="rfc6040up_L2TP_ECN_Capability_AVP" format="default"/> below.</t> format="default"/>.</t>
            <t>Where the outer PSN header is some protocol other than IP that
            supports ECN, the appropriate ECN propagation specification will
            need to be followed, e.g.&nbsp;"Explicit Congestion Marking in
            MPLS" e.g., <xref target="RFC5129" format="default"/>. Where no specification exists for
            ECN propagation by a particular PSN, <xref target="I-D.ietf-tsvwg-ecn-encap-guidelines" target="RFC9599" format="default"/> gives general
            guidance on how to design ECN propagation into a protocol that
            encapsulates IP.</t>
            <section anchor="rfc6040up_L2TP_ECN_Capability_AVP" numbered="true" toc="default">
              <name>ECN Capability AVP for Negotiation between LCCEs</name>
              <t>The ECN Capability Attribute-Value Pair (AVP) AVP defined here
              has Attribute Type TBD. 103. The AVP has the following format:</t>
              <figure anchor="Fig_rfc6040up_LCCE_ECN_Capabiliy_AVP">
                <name>ECN Capability Attribute Value Pair AVP for L2TP (v2 or v3)</name>
                <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0|      Length       |          Vendor ID            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             TBD             103               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
              </figure>
              <t>This AVP MAY <bcp14>MAY</bcp14> be present in the following message types: SCCRQ
              and SCCRP (Start-Control-Connection-Request Start-Control-Connection-Request (SCCRQ) and
              Start-Control-Connection-Reply). Start-Control-Connection-Reply (SCCRP) message types. This AVP MAY <bcp14>MAY</bcp14> be hidden (the
              H-bit is set to 0 or 1) and is optional (M-bit (the M-bit is not set). The length
              (before hiding) of this AVP is 6 octets. The Vendor ID is the
              IETF Vendor ID of 0.</t>
              <t>When an LCCE sends an ECN Capability AVP, it indicates that
              it supports ECN propagation. When no ECN Capability AVP is
              present, it indicates that the sender does not support ECN
              propagation.</t>
              <t>If an LCCE initiating a control connection supports ECN
              propagation, it will send a Start-Control-Connection-Request
              (SCCRQ) an SCCRQ containing an ECN Capability AVP. If the tunnel
              terminator supports ECN, it will return a
              Start-Control-Connection-Reply (SCCRP) an
              SCCRP that also includes an ECN
              Capability AVP.
Then, for any sessions created by that control
              connection, both ends of the tunnel can use the normal mode of
              RFC 6040, i.e.&nbsp;they
              <xref target="RFC6040"/>; i.e., they can copy the IP ECN field from inner to
              outer when encapsulating data packets.</t>
              <t>If, on
              <t>On the other hand, if the tunnel terminator does not support
              ECN
              ECN, it will ignore the ECN Capability AVP and send an SCCRP to
              the tunnel initiator without an ECN Capability AVP. The tunnel
              initiator interprets the absence of the ECN Capability flag in
              the SCCRP as an indication that the tunnel terminator is
              incapable of supporting ECN. When encapsulating data packets for
              any sessions created by that control connection, the tunnel
              initiator will then use the compatibility mode of RFC 6040 <xref target="RFC6040"/> to
              clear the ECN field of the outer IP header to 0b00.</t>
              <t>If the tunnel terminator does not support this ECN extension,
              the network operator is still expected to configure it to comply
              with the safety provisions set out in <xref target="rfc6040up_L2TP_Safe" format="default"/> above, when it acts as an ingress
              LCCE.</t>
            </section>
          </section>
        </section>
        <section anchor="rfc6040up_GRE" numbered="true" toc="default">
          <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
          header between IP headers. Sometimes Sometimes, the GRE shim header
          encapsulates an L2 header, which might in turn encapsulate an IP
          header. Therefore Therefore, GRE is within the scope of RFC 6040 <xref target="RFC6040"/> as updated by
          <xref target="rfc6040up_scope" format="default"/> above.</t> format="default"/>.</t>
          <t>Implementation of support for <xref target="RFC6040" format="default"/> as updated
          by the present specification is RECOMMENDED <bcp14>RECOMMENDED</bcp14> for GRE tunnel
          endpoints,
          endpoints in order to provide the benefits of ECN <xref target="RFC8087" format="default"/> whenever a node within a GRE tunnel becomes the
          bottleneck for an end-to-end IP traffic flow tunnelled over GRE
          using IP as the delivery protocol (outer header).</t>
          <t>GRE itself does not support dynamic set-up setup and configuration of
          tunnels. However, control plane protocols protocols, such as Next Hop
          Resolution Protocol (NHRP) <xref target="RFC2332" format="default"/>, Mobile IPv4
          (MIP4) <xref target="RFC5944" format="default"/>, Mobile IPv6 (MIP6) <xref target="RFC6275" format="default"/>, Proxy Mobile IP (PMIP) <xref target="RFC5845" format="default"/> format="default"/>,
          and IKEv2 <xref target="RFC7296" format="default"/> format="default"/>, are sometimes used to set up GRE
          tunnels dynamically.</t>
          <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
          defined in RFC 6040 <xref target="RFC6040"/> or one of its compatible predecessors (RFC 4301 (<xref target="RFC4301"/>
          or the full functionality mode of RFC 3168). <xref target="RFC3168"/>). However, if they use a
          GRE encapsulation, this presumption is less sound.</t>
          <t>Therefore, if the outer delivery protocol is IP (v4 or v6) v6), the
          operator is obliged to follow the safe configuration requirements in
          <xref target="rfc6040up_sec_safe" format="default"/> above. format="default"/>. <xref target="rfc6040up_GRE_Safe" format="default"/> below updates the base GRE
          specification with this requirement, requirement to emphasize its
          importance.</t>
          <t>Where the delivery protocol is some protocol other than IP that
          supports ECN, the appropriate ECN propagation specification will
          need to be followed, e.g.&nbsp;Explicit Congestion Marking in MPLS e.g., <xref target="RFC5129" format="default"/>. Where no specification exists for ECN
          propagation by a particular PSN, <xref target="I-D.ietf-tsvwg-ecn-encap-guidelines" target="RFC9599" format="default"/> gives more general
          guidance on how to propagate ECN to and from protocols that
          encapsulate IP.</t>
          <section anchor="rfc6040up_GRE_Safe" numbered="true" toc="default">
            <name>Safe Configuration of a 'Non-ECN' "Non-ECN" GRE Ingress</name>
            <t>The following text is appended to Section 3 of <xref target="RFC2784" format="default"/> section="3" sectionFormat="of"/> as an update to the base GRE
            specification:</t>
            <ul empty="true" spacing="normal">
              <li>
                <t>The
       <blockquote>
The operator of a GRE tunnel ingress MUST <bcp14>MUST</bcp14> follow the configuration requirements in <xref target="rfc6040up_sec_safe" format="default"/> of [this document] RFC 9601 when the outer delivery protocol is IP (v4 or v6).</t>
              </li>
            </ul> v6).
</blockquote>

          </section>
        </section>
        <section numbered="true" toc="default">
          <name>Teredo</name>
          <t>Teredo <xref target="RFC4380" format="default"/> provides a way to tunnel IPv6
          over an IPv4 network, network with a UDP-based shim header between the
          two.</t>
          <t>For Teredo tunnel endpoints to provide the benefits of ECN, the
          Teredo specification would have to be updated to include negotiation
          of the ECN capability between Teredo tunnel endpoints. Otherwise Otherwise, it
          would be unsafe for a Teredo tunnel ingress to copy the ECN field to
          the IPv6 outer.</t>
          <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
          ECN field in the outer IPv6 header. However, the specification does
          not mention anything about this.</t>
          <t>To make existing Teredo deployments safe, it would be possible to
          add ECN capability negotiation to those that are subject to remote
          OS update. However, for those implementations not subject to remote
          OS update, it will not be feasible to require them to be configured
          correctly,
          correctly because Teredo tunnel endpoints are generally deployed on
          hosts.</t>
          <t>Therefore, until ECN support is added to the specification of
          Teredo, the only feasible further safety precaution available here
          is to update the specification of Teredo implementations with the
          following text, text as a new section 5.1.3:</t>
          <ul empty="true" spacing="normal">
            <li>
              <t>"5.1.3 section:</t>
<blockquote>
              <t>5.1.3.  Safe 'Non-ECN' "Non-ECN" Teredo Encapsulation</t>
              <t>A Teredo tunnel ingress implementation that does
              not support ECN propagation as defined in RFC 6040 <xref target="RFC6040"/> or one of its
              compatible predecessors (RFC 4301 (<xref target="RFC4301"/> or the full functionality mode
              of RFC 3168) MUST <xref target="RFC3168"/>) <bcp14>MUST</bcp14> zero the ECN field in the outer IPv6
              header."</t>
            </li>
          </ul>
              header.</t>
</blockquote>
        </section>
        <section anchor="rfc6040up_AMT" numbered="true" toc="default">
          <name>AMT</name>
          <t>Automatic Multicast Tunneling (AMT
          <t>AMT <xref target="RFC7450" format="default"/>) format="default"/> is a
          tightly coupled shim header that encapsulates an IP packet and is
          itself
          encapsulated within a UDP/IP datagram. Therefore Therefore, AMT is
          within the scope of RFC 6040 <xref target="RFC6040"/> as updated by <xref target="rfc6040up_scope" format="default"/> above.</t> format="default"/>.</t>
          <t>Implementation of support for <xref target="RFC6040" format="default"/> as updated
          by the present specification is RECOMMENDED <bcp14>RECOMMENDED</bcp14> for AMT tunnel
          endpoints,
          endpoints in order to provide the benefits of ECN <xref target="RFC8087" format="default"/> whenever a node within an AMT tunnel becomes the
          bottleneck for an IP traffic flow tunnelled over AMT.</t>
          <t>To comply with RFC 6040, <xref target="RFC6040"/>, an AMT relay and gateway will follow the
          rules for propagation of the ECN field at ingress and egress egress,
          respectively, as described in Section 4 of RFC 6040 <xref target="RFC6040" format="default"/>.</t> section="4" sectionFormat="of"/>.</t>
          <t>Before encapsulating any data packets, RFC 6040 <xref target="RFC6040"/> requires an
          ingress AMT relay to check that the egress AMT gateway supports ECN
          propagation as defined in RFC 6040 <xref target="RFC6040"/> or one of its compatible
          predecessors (RFC 4301 (<xref target="RFC4301"/> or the full functionality mode of RFC 3168). <xref target="RFC3168"/>).
          If the egress gateway supports ECN, the ingress relay can use the
          normal mode of encapsulation (copying the IP ECN field from inner to
          outer). Otherwise, the ingress relay has to use compatibility mode,
          which means it has to clear the outer ECN field to zero <xref target="RFC6040" format="default"/>.</t>
          <t>An AMT tunnel is created dynamically (not manually), so the relay
          will need to determine the remote gateway's support for ECN using
          the ECN capability declaration defined in <xref target="rfc6040up_AMT_ECN_Capability" format="default"/> below.</t> format="default"/>.</t>
          <section anchor="rfc6040up_AMT_Safe" numbered="true" toc="default">
            <name>Safe Configuration of a 'Non-ECN' "Non-ECN" Ingress AMT Relay</name>
            <t>The following text is appended to Section 4.2.2 of <xref target="RFC7450" format="default"/> section="4.2.2" sectionFormat="of"/> as an update to the AMT specification:</t>
            <ul empty="true" spacing="normal">
              <li>
                <t>The
            <blockquote>
                The operator of an AMT relay that does not support RFC 6040 <xref target="RFC6040"/>
                or one of its compatible predecessors (RFC 4301 (<xref target="RFC4301"/> or the full
                functionality mode of RFC 3168) MUST <xref target="RFC3168"/>) <bcp14>MUST</bcp14> follow the configuration
                requirements in <xref target="rfc6040up_sec_safe" format="default"/> of [this
                document] RFC 9601 to ensure it clears the outer IP ECN field to
                zero.</t>
              </li>
            </ul>
                zero.
            </blockquote>

          </section>
          <section anchor="rfc6040up_AMT_ECN_Capability" numbered="true" toc="default">
            <name>ECN Capability Declaration of an AMT Gateway</name>
            <figure anchor="Fig_rfc6040up_AMT_ECN_Capability_Declaration">
              <name>Updated AMT Request Message Format</name>
              <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  V=0  |Type=3 |  Reserved |E|P|            Reserved           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Request Nonce                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
            </figure>
            <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
            Gateway ECN Capability flag (E), (E) as shown in <xref target="Fig_rfc6040up_AMT_ECN_Capability_Declaration" format="default"/>. The
            definitions of all other fields in the AMT Request Message are
            unchanged from RFC 7450.</t> <xref target="RFC7450"/>.</t>
            <t>When the E flag is set to 1, it indicates that the sender of
            the message supports RFC 6040 <xref target="RFC6040"/> ECN propagation. When it is cleared
            to zero, it indicates the sender of the message does not support
            RFC 6040
            <xref target="RFC6040"/> ECN propagation. An AMT gateway "that supports RFC 6040 <xref target="RFC6040"/>
            ECN propagation" means one that propagates the ECN field to the
            forwarded data packet based on the combination of arriving inner
            and outer ECN fields, fields as defined in Section 4 of RFC 6040.</t> <xref target="RFC6040" section="4" sectionFormat="of"/>.</t>
            <t>The other bits of the Reserved field remain reserved. They will
            continue to be cleared to zero when sent and ignored when either
            received or forwarded, forwarded as specified in Section 5.1.3.3. of RFC
            7450.</t> <xref target="RFC7450" section="5.1.3.3" sectionFormat="of"/>.</t>
            <t>An AMT gateway that does not support RFC 6040 MUST NOT <xref target="RFC6040"/> <bcp14>MUST NOT</bcp14> set the
            E flag of its Request Message to 1.</t>
            <t>An AMT gateway that supports RFC 6040 <xref target="RFC6040"/> ECN propagation MUST <bcp14>MUST</bcp14> set
            the E flag of its Relay Discovery Message to 1.</t>
            <t>The action of the corresponding AMT relay that receives a
            Request message with the E flag set to 1 depends on whether the
            relay itself supports RFC 6040 <xref target="RFC6040"/> ECN propagation:</t>
            <ul spacing="normal">
              <li>
                <t>If the relay supports RFC 6040 <xref target="RFC6040"/> ECN propagation, it will
                store the ECN capability of the gateway along with its
                address. Then Then, whenever it tunnels datagrams towards this
                gateway, it MUST <bcp14>MUST</bcp14> use the normal mode of RFC 6040 <xref target="RFC6040"/> to propagate
                the ECN field when encapsulating datagrams (i.e.&nbsp;it (i.e., it
                copies the IP ECN field from inner to outer).</t>
              </li>
              <li>
                <t>If the discovered AMT relay does not support RFC 6040 <xref target="RFC6040"/> ECN
                propagation, it will ignore the E flag in the Reserved field, field
                as per section 5.1.3.3. of RFC 7450. <xref target="RFC7450" section="5.1.3.3" sectionFormat="of"/>. </t>
                <t>If the AMT relay does not support RFC 6040 <xref target="RFC6040"/> ECN
                propagation, the network operator is still expected to
                configure it to comply with the safety provisions set out in
                <xref target="rfc6040up_AMT_Safe" format="default"/> above.</t> format="default"/>.</t>
              </li>
            </ul>
          </section>
        </section>
      </section>
    </section>
    <!-- ================================================================ -->

    <section anchor="rfc6040up_IANA_Considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>IANA is requested to assign has assigned the following AVP in the L2TP Control "Control Message Attribute Value Pair:</t> Pairs" registry:</t>
      <table align="center">
        <thead>
          <tr>
            <th align="left">Attribute Type</th>
            <th align="left">Description</th>
            <th align="left">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">TBD</td> align="left">103</td>
            <td align="left">ECN Capability</td>
            <td align="left">[this document]</td> align="left">RFC 9601</td>
          </tr>
        </tbody>
      </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 anchor="rfc6040up_Security_Considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The Security Considerations in <xref target="RFC6040" format="default"/> and <xref target="I-D.ietf-tsvwg-ecn-encap-guidelines" target="RFC9599" format="default"/> apply equally to the
      scope defined for the present specification.</t>
    </section>
  </middle>
  <back>
    <!-- ================================================================ -->

<displayreference target="I-D.ietf-nvo3-vxlan-gpe" to="NVO3-VXLAN-GPE"/>
<displayreference target="I-D.ietf-intarea-tunnels" to="INTAREA-TUNNELS"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC2474" target="https://www.rfc-editor.org/info/rfc2474" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2474.xml">
          <front>
            <title>Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers</title>
            <author fullname="K. Nichols" initials="K." surname="Nichols"/>
            <author fullname="S. Blake" initials="S." surname="Blake"/>
            <author fullname="F. Baker" initials="F." surname="Baker"/>
            <author fullname="D. Black" initials="D." surname="Black"/>
            <date month="December" year="1998"/>
            <abstract>
              <t>This document defines the IP header field, called the DS (for differentiated services) field. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2474"/>
          <seriesInfo name="DOI" value="10.17487/RFC2474"/>
        </reference>
        <reference anchor="RFC2661" target="https://www.rfc-editor.org/info/rfc2661" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2661.xml">
          <front>
            <title>Layer Two Tunneling Protocol "L2TP"</title>
            <author fullname="W. Townsley" initials="W." surname="Townsley"/>
            <author fullname="A. Valencia" initials="A." surname="Valencia"/>
            <author fullname="A. Rubens" initials="A." surname="Rubens"/>
            <author fullname="G. Pall" initials="G." surname="Pall"/>
            <author fullname="G. Zorn" initials="G." surname="Zorn"/>
            <author fullname="B. Palter" initials="B." surname="Palter"/>
            <date month="August" year="1999"/>
            <abstract>
              <t>This document describes the Layer Two Tunneling Protocol (L2TP). [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2661"/>
          <seriesInfo name="DOI" value="10.17487/RFC2661"/>
        </reference>
        <reference anchor="RFC2784" target="https://www.rfc-editor.org/info/rfc2784" 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 arbitrary network layer protocol over another arbitrary network layer protocol. [STANDARDS-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/rfc3168" 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="Ramakrishnan"/>
            <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 Congestion Notification) to TCP and IP, including ECN's use of two bits

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2474.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2661.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2784.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3168.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3931.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4301.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4380.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5129.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6040.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6660.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7450.xml"/>

<!-- [I-D.ietf-tsvwg-ecn-encap-guidelines] 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/rfc3931" 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="Goyret"/>
            <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 for tunneling multiple Layer 2 connections between two IP nodes. Additional documents detail the specifics for each data link type being emulated. [STANDARDS-TRACK]</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/rfc4301" 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 Architecture for IP", which is designed to provide security services for traffic at the IP layer. This document obsoletes RFC 2401 (November 1998). [STANDARDS-TRACK]</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/rfc4380" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4380.xml">
          <front>
            <title>Teredo: Tunneling IPv6 over UDP through Network Address Translations (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 service 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 Teredo clients; the Teredo relays act as IPv6 routers between the Teredo service and the "native" IPv6 Internet. The relays can also provide interoperability with hosts using other transition mechanisms such REF state 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/rfc5129" 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 MPLS networks, including how to encode Diffserv Code Points (DSCPs) in an MPLS header. DSCPs may be encoded in the EXP field, while other uses of that field are not precluded. RFC 3270 makes no statement about how Explicit Congestion Notification (ECN) marking might be encoded in the MPLS header. This document defines how an operator might define some of the EXP codepoints for explicit congestion notification, 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/rfc6040" 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 notification (ECN) field of the IP header should be constructed on entry to and exit from any 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 decapsulation, it updates both RFC 3168 and RFC 4301 to add new behaviours for previously unused 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 supported. Tunnel endpoints can be updated in any order without affecting pre-existing uses of the ECN field, thus ensuring backward compatibility. Nonetheless, operators wanting to support two severity levels (e.g., for pre-congestion notification -- PCN) can require compliance with this new specification. A thorough analysis 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 guidance 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/rfc6660" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6660.xml">
          <front>
            <title>Encoding Three Pre-Congestion Notification (PCN) States in the 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 protect 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. Egress nodes pass information about these PCN-marks to Decision Points that then decide whether to admit or block new flow requests or to terminate some already admitted flows during serious pre-congestion.</t>
              <t>This 04/29/24; companion document specifies how PCN-marks are to be encoded into the IP header by reusing the Explicit Congestion Notification (ECN) codepoints within 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-marked (NM), threshold-marked (ThM), and excess-traffic-marked (ETM). Hence, it is called the 3-in-1 PCN encoding. This document obsoletes RFC 5696. [STANDARDS-TRACK]</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/rfc7450" 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 network to receivers that lack multicast connectivity to the source network. The protocol uses UDP encapsulation and unicast replication to provide this functionality.</t>
              <t>The AMT protocol is specifically designed to support rapid deployment by requiring minimal changes to existing network infrastructure.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7450"/>
          <seriesInfo name="DOI" value="10.17487/RFC7450"/>
        </reference> 9599 -->

<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"> anchor="RFC9599" target="https://www.rfc-editor.org/info/rfc9599">
<front>
<title>Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP</title>
<author fullname="Bob Briscoe" initials="B." surname="Briscoe">
              <organization>Independent</organization> initials='B' surname='Briscoe' fullname='Bob Briscoe'>
<organization />
</author>
<author fullname="John Kaippallimalil" initials="J." surname="Kaippallimalil">
              <organization>Futurewei</organization> initials='J' surname='Kaippallimalil' fullname='John Kaippallimalil'>
<organization />
</author>
<date day="10" month="November" year="2023"/>
            <abstract>
              <t>The purpose of this document is to guide the design of congestion 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 specified 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> month='June' year='2024' />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-tsvwg-ecn-encap-guidelines-21"/> name="RFC" value="9599"/>
<seriesInfo name="DOI" value="10.17487/RFC9599"/>
</reference>

      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="RFC1701" target="https://www.rfc-editor.org/info/rfc1701" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1701.xml">
          <front>
            <title>Generic Routing Encapsulation (GRE)</title>
            <author fullname="S. Hanks" initials="S." surname="Hanks"/>
            <author fullname="T. Li" initials="T." surname="Li"/>
            <author fullname="D. Farinacci" initials="D." surname="Farinacci"/>
            <author fullname="P. Traina" initials="P." surname="Traina"/>
            <date month="October" year="1994"/>
            <abstract>
              <t>This document specifies a protocol for performing encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="1701"/>
          <seriesInfo name="DOI" value="10.17487/RFC1701"/>
        </reference>
        <reference anchor="RFC2332" target="https://www.rfc-editor.org/info/rfc2332" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2332.xml">
          <front>
            <title>NBMA Next Hop Resolution Protocol (NHRP)</title>
            <author fullname="J. Luciani" initials="J." surname="Luciani"/>
            <author fullname="D. Katz" initials="D." surname="Katz"/>
            <author fullname="D. Piscitello" initials="D." surname="Piscitello"/>
            <author fullname="B. Cole" initials="B." surname="Cole"/>
            <author fullname="N. Doraswamy" initials="N." surname="Doraswamy"/>
            <date month="April" year="1998"/>
            <abstract>
              <t>This document describes the NBMA Next Hop Resolution Protocol (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 address and NBMA subnetwork addresses of the "NBMA next hop" towards a destination station. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2332"/>
          <seriesInfo name="DOI" value="10.17487/RFC2332"/>
        </reference>
        <reference anchor="RFC2637" target="https://www.rfc-editor.org/info/rfc2637" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2637.xml">
          <front>
            <title>Point-to-Point Tunneling Protocol (PPTP)</title>
            <author fullname="K. Hamzeh" initials="K." surname="Hamzeh"/>
            <author fullname="G. Pall" initials="G." surname="Pall"/>
            <author fullname="W. Verthein" initials="W." surname="Verthein"/>
            <author fullname="J. Taarud" initials="J." surname="Taarud"/>
            <author fullname="W. Little" initials="W." surname="Little"/>
            <author fullname="G. Zorn" initials="G." surname="Zorn"/>
            <date month="July" year="1999"/>
            <abstract>
              <t>This document specifies a protocol which allows the Point to Point Protocol (PPP) to be tunneled through an IP network. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2637"/>
          <seriesInfo name="DOI" value="10.17487/RFC2637"/>
        </reference>
        <reference anchor="RFC2983" target="https://www.rfc-editor.org/info/rfc2983" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2983.xml">
          <front>
            <title>Differentiated Services and Tunnels</title>
            <author fullname="D. Black" initials="D." surname="Black"/>
            <date month="October" year="2000"/>
            <abstract>
              <t>This document considers the interaction of Differentiated Services (diffserv) with IP tunnels of various forms. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2983"/>
          <seriesInfo name="DOI" value="10.17487/RFC2983"/>
        </reference>
        <reference anchor="RFC3260" target="https://www.rfc-editor.org/info/rfc3260" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3260.xml">
          <front>
            <title>New Terminology and Clarifications for Diffserv</title>
            <author fullname="D. Grossman" initials="D." surname="Grossman"/>
            <date month="April" year="2002"/>
            <abstract>
              <t>This memo captures Diffserv working group agreements concerning new and improved terminology, and provides minor technical clarifications. It is intended to update RFC 2474, RFC 2475 and RFC 2597. When RFCs 2474 and 2597 advance on the standards track, and RFC 2475 is updated, it is intended that the revisions in this memo will be incorporated, and that this memo will be obsoleted by the new RFCs. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3260"/>
          <seriesInfo name="DOI" value="10.17487/RFC3260"/>
        </reference>
        <reference anchor="RFC3308" target="https://www.rfc-editor.org/info/rfc3308" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3308.xml">
          <front>
            <title>Layer Two Tunneling Protocol (L2TP) Differentiated Services Extension</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/rfc5415" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5415.xml">
          <front>
            <title>Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification</title>
            <author fullname="P. Calhoun" initials="P." role="editor" surname="Calhoun"/>
            <author fullname="M. Montemurro" initials="M." role="editor" surname="Montemurro"/>
            <author fullname="D. Stanley" initials="D." role="editor" surname="Stanley"/>
            <date month="March" year="2009"/>
            <abstract>
              <t>This specification defines the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol, meeting the objectives defined by the CAPWAP Working Group in RFC 4564. The CAPWAP protocol is designed to be flexible, allowing it to be used for a variety of wireless technologies. This document describes 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/rfc5944" 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="Perkins"/>
            <date month="November" year="2010"/>
            <abstract>
              <t>This document specifies protocol enhancements that allow transparent 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 attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current 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 end 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/rfc6275" 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="Perkins"/>
            <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 nodes to remain reachable while moving around in the IPv6 Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option. All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes. This document obsoletes RFC 3775. [STANDARDS-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/rfc5845" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5845.xml">
          <front>
            <title>Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile 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 the mobile access gateway and the local mobility anchor to negotiate Generic Routing Encapsulation (GRE) encapsulation mode and exchange the downlink and uplink GRE keys that are used for marking the downlink and uplink traffic that belong to a specific mobility session. In addition, the same mobility option can be used to negotiate the GRE encapsulation mode without exchanging the GRE keys. [STANDARDS-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/rfc7296" 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 authentication and establishing and maintaining Security Associations (SAs). This document obsoletes RFC 5996, and includes all of the errata for it. It advances IKEv2 to 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/rfc9300" 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 Identifiers (EIDs), which identify end hosts; and Routing Locators (RLOCs), which identify network attachment points. With this, LISP effectively separates control from data and allows routers to create overlay networks. LISP-capable routers exchange encapsulated packets according to EID-to-RLOC mappings stored in a local Map-Cache.</t>
              <t>LISP requires no change to either host protocol stacks or underlay routers and offers Traffic Engineering (TE), multihoming, and mobility, among 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/rfc7059" 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 IPv6 packets over IPv4 networks. It covers mechanisms in current use, touches on several mechanisms that are now only of historic interest, and discusses some newer tunnel mechanisms that are not widely used at the time of publication. The goal of the document is helping people with an IPv6-in-IPv4 tunneling need to select 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/rfc7348" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7348.xml">
          <front>
            <title>Virtual eXtensible Local Area Network (VXLAN): A Framework for 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 virtualized data centers accommodating multiple tenants. The scheme and the related protocols can be used in networks for cloud service providers and enterprise data centers. This memo documents the deployed VXLAN protocol for the benefit of the Internet 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/rfc7637" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7637.xml">
          <front>
            <title>NVGRE: Network Virtualization Using Generic Routing Encapsulation</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 Encapsulation (GRE) header for Network Virtualization (NVGRE) in multi-tenant data centers. Network Virtualization decouples virtual networks and addresses from physical network infrastructure, providing isolation and concurrency between multiple virtual networks on the same physical network infrastructure. This document also 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/rfc7665" 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="Halpern"/>
            <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 construction of composite services through deployment of SFCs, with a focus on those to be standardized

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1701.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2332.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2637.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2983.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3260.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3308.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5415.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5944.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6275.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5845.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7296.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9300.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7059.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7348.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7637.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7665.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8085.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8087.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8159.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8300.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8311.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8926.xml"/>

<!-- [I-D.ietf-nvo3-vxlan-gpe] IESG state I-D Exists -->

<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-nvo3-vxlan-gpe.xml"/>

<!-- [I-D.ietf-sfc-nsh-ecn-support] in the IETF. This document does not propose solutions, protocols, 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/rfc8085" 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-passing transport that has no inherent congestion control mechanisms. This document provides guidelines on the use of UDP for the designers of applications, tunnels, and other protocols that use UDP. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, middlebox traversal, the use of Explicit Congestion 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 REF state as an Internet transport must employ mechanisms to prevent congestion collapse and to establish 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 protocols (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 multicast 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/rfc8087" 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 throughput, reduced delay, and other benefits when ECN is used over a network path that includes equipment that supports Congestion Experienced (CE) marking. It also discusses challenges for successful deployment of ECN. It does not propose new algorithms 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/rfc8159" 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" surname="Konstantynowicz"/>
            <author fullname="G. Heron" initials="G." role="editor" surname="Heron"/>
            <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 over IPv6 with a mandatory 64-bit cookie for connecting Layer 2 (L2) Ethernet attachment circuits identified by IPv6 addresses. The encapsulation is based on the Layer 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/rfc8174" 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</title>
            <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 protocol 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/rfc8300" 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="Quinn"/>
            <author fullname="U. Elzur" initials="U." role="editor" surname="Elzur"/>
            <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 provides a mechanism for metadata exchange along the instantiated service paths. The NSH is the Service Function Chaining (SFC) encapsulation required to support the SFC architecture (defined in 4/29/2024; companion doc RFC 7665).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8300"/>
          <seriesInfo name="DOI" value="10.17487/RFC8300"/>
        </reference> 9600 -->
<reference anchor="RFC8311" target="https://www.rfc-editor.org/info/rfc8311" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8311.xml"> anchor="RFC9600" target="https://www.rfc-editor.org/info/rfc9600">
<front>
            <title>Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation</title>
            <author fullname="D. Black" initials="D." surname="Black"/>
            <date month="January" year="2018"/>
            <abstract>
              <t>This memo updates RFC 3168, which specifies
<title>
Explicit Congestion Notification (ECN) as an alternative to packet drops for indicating network congestion to endpoints. It relaxes restrictions in RFC 3168 that hinder experimentation towards benefits beyond just removal of loss. This memo summarizes the anticipated 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 related 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/rfc8926" 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="Gross"/>
            <author fullname="I. Ganga" initials="I." role="editor" surname="Ganga"/>
            <author fullname="T. Sridhar" initials="T." role="editor" surname="Sridhar"/>
            <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 important aspect of a tunneling protocol if it is to keep pace with the evolution of technology. This document describes Geneve, an encapsulation protocol designed to 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/public/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: support 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 protocol 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://datatracker.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 Feedback Using the Network Service Header (NSH) and IPFIX</title> IPFIX
</title>
<author initials="D." surname="Eastlake" fullname="Donald E. Eastlake 3rd" initials="D. E." surname="Eastlake"> 3rd">
<organization>Futurewei Technologies</organization>
</author>
<author fullname="Bob Briscoe" initials="B." surname="Briscoe"> surname="Briscoe" fullname="Bob Briscoe">
<organization>Independent</organization>
</author>
<author fullname="Shunwan Zhuang" initials="S." surname="Zhuang"> surname="Zhuang" fullname="Shunwan Zhuang">
<organization>Huawei Technologies</organization>
</author>
<author initials="A." surname="Malis" fullname="Andrew G. Malis" initials="A. G." surname="Malis"> Malis">
<organization>Malis Consulting</organization>
</author>
<author fullname="Xinpeng Wei" initials="X." surname="Wei"> surname="Wei" fullname="Xinpeng Wei">
<organization>Huawei Technologies</organization>
</author>
<date day="23" month="October" year="2023"/>
            <abstract>
              <t>Explicit Congestion Notification (ECN) allows a forwarding element to notify downstream devices of the onset of congestion without having to drop packets. Coupled with a means to feed information about congestion back to upstream nodes, this can improve network efficiency through better congestion control, frequently without packet drops. This document specifies ECN and congestion feedback support within a Service Function Chaining (SFC) enabled domain through use of the Network Service Header (NSH, RFC 8300) and IP Flow Information Export (IPFIX, RFC 7011) protocol.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-sfc-nsh-ecn-support-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="Touch">
              <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 protocol layers and the challenges in supporting IP tunneling, based on the equivalence 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/rfc9329" 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 Exchange Protocol (IKE) and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP. This method, referred to as "TCP encapsulation", involves sending both IKE packets for Security Association (SA) establishment and Encapsulating Security Payload (ESP) packets over a TCP 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. This document clarifies the specification for TCP encapsulation by including additional clarifications obtained during implementation and deployment of this method. 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/rfc9331" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9331.xml">
          <front>
            <title>The Explicit Congestion Notification (ECN) Protocol for Low Latency, 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="Briscoe"/>
            <date month="January" year="2023"/>
            <abstract>
              <t>This specification defines the protocol to be used for a new network service called Low Latency, Low Loss, and Scalable throughput (L4S). L4S uses an Explicit Congestion Notification (ECN) scheme at the IP layer that is similar to the original (or 'Classic') ECN approach, except as specified within. L4S uses 'Scalable' congestion control, which induces much more frequent control signals from the network, and it responds to them with much more fine-grained adjustments so that very low (typically sub-millisecond on average) and consistently low queuing delay becomes possible for L4S traffic without compromising link utilization. Thus, even capacity-seeking (TCP-like) traffic can have high bandwidth 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 from 'Classic' (e.g., TCP-Reno-friendly) traffic. Then, network bottlenecks can be incrementally modified to distinguish and isolate existing traffic that still follows the Classic behaviour, to prevent it from degrading the low queuing delay and low loss of L4S traffic. This Experimental specification defines the rules that L4S transports and network elements need to follow, with the intention that L4S flows neither harm each other's performance nor that of Classic traffic. It also suggests open questions to be investigated during experimentation. Examples of new Active Queue Management (AQM) marking algorithms and new transports (whether TCP-like or real time) are specified separately.</t>
            </abstract> month="June" year="2024"/>
</front>
<seriesInfo name="RFC" value="9331"/> value="9600"/>
<seriesInfo name="DOI" value="10.17487/RFC9331"/> value="10.17487/RFC9600"/>
</reference>

<!-- [I-D.ietf-intarea-tunnels] IESG state Expired -->

<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-intarea-tunnels.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9329.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9331.xml"/>

        <reference anchor="GTPv1">
          <front>
            <title>GPRS
            <title>General Packet Radio Service (GPRS); GPRS Tunnelling
            Protocol (GTP) across the Gn and Gp interface</title>
            <author>
              <organization>3GPP</organization>
            </author>
            <date/>
          </front>
          <seriesInfo name="Technical Specification" value="TS 29.060"/> value="29.060"/>
        </reference>

        <reference anchor="GTPv1-U">
          <front>
            <title>General Packet Radio System (GPRS) Tunnelling Protocol User
          Plane (GTPv1-U)</title>
            <author>
              <organization>3GPP</organization>
            </author>
            <date/>
          </front>
          <seriesInfo name="Technical Specification" value="TS 29.281"/> value="29.281"/>
        </reference>

        <reference anchor="GTPv2-C">
          <front>
            <title>Evolved
            <title>3GPP Evolved Packet System (EPS); Evolved General Packet
            Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C)</title>
            (GTPv2-C); Stage 3</title>
            <author>
              <organization>3GPP</organization>
            </author>
            <date year=""/>
          </front>
          <seriesInfo name="Technical Specification" value="TS 29.274"/> value="29.274"/>
        </reference>

        <reference anchor="decap-test" target="https://arxiv.org/abs/2311.16825">
          <front>
            <title>A Test for IP-ECN Propagation over by a Tunnel</title> Remote Tunnel Endpoint</title>
            <author fullname="Bob" initials="B." surname="Briscoe">
              <organization>Independent</organization>
            </author>
            <date month="November" year="2023"/>
          </front>
          <seriesInfo name="DOI" value="10.48550/arXiv.2311.16825"/>
          <refcontent>Technical Report, TR-BB-2023-003</refcontent>
          <format target="https://arxiv.org/pdf/2311.16825.pdf" type="PDF"/>
        </reference>
      </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">
      <name>Acknowledgements</name>
      <t>Thanks to Ing-jyh <contact fullname="Ing-jyh (Inton) Tsang Tsang"/> for initial discussions on the need
      for ECN propagation in L2TP and its applicability. Thanks also to Carlos
      Pignataro, Tom Herbert, Ignacio Goyret, Alia Atlas, Praveen
      Balasubramanian, Joe Touch, Mohamed Boucadair, David Black, Jake
      Holland, Sri Gundavelli, Gorry Fairhurst and Martin Duke <contact fullname="Carlos
      Pignataro"/>, <contact fullname="Tom Herbert"/>, <contact fullname="Ignacio Goyret"/>, <contact fullname="Alia Atlas"/>, <contact fullname="Praveen
      Balasubramanian"/>, <contact fullname="Joe Touch"/>, <contact fullname="Mohamed 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. "A Comparison of IPv6-over-IPv4 Tunnel Mechanisms" <xref target="RFC7059" format="default"/> helped to identify a number of tunnelling
      protocols to include within the scope of this document.</t>
      <t>Bob

      <t><contact fullname="Bob Briscoe"/>    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 was funded by Apple Inc. for later draft versions (from -17). The views expressed here are solely those of
      the authors.</t>
    </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>
</rfc>