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

<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.5.6 -->
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-mpls-lspping-norao-08" number="9570" consensus="true" ipr="trust200902" updates="8029" obsoletes="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.18.0 -->

  <front>
    <title abbrev="RAO-less Label Switched Path (LSP) Ping">Deprecating the Use of Router Alert in LSP Ping</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-mpls-lspping-norao-08"/> name="RFC" value="9570"/>
    <author fullname="Kireeti Kompella" initials="K." surname="Kompella">
      <organization>Juniper Networks</organization>
      <address>
        <postal>
          <street>1133 Innovation Way</street>
          <city>Sunnyvale</city>
          <region>CA</region>
          <code>94089</code>
          <country>United States</country> States of America</country>
        </postal>
        <email>kireeti.ietf@gmail.com</email>
      </address>
    </author>
    <author fullname="Ron Bonica" initials="R." surname="Bonica">
      <organization>Juniper Networks</organization>
      <address>
        <postal>
          <street>1133 Innovation Way</street>
          <city>Sunnyvale</city>
          <region>CA</region>
          <code>94089</code>
          <country>United States</country> States of America</country>
        </postal>
        <email>rbonica@juniper.net</email>
      </address>
    </author>
    <author fullname="Greg Mirsky" initials="G." surname="Mirsky" role="editor">
      <organization>Ericsson</organization>
      <address>
        <email>gregimirsky@gmail.com</email>
      </address>
    </author>
    <date year="2024"/>
    <area>Routing</area>
    <workgroup>MPLS WG</workgroup> year="2024" month="April"/>

    <area>RTG</area>
    <workgroup>mpls</workgroup>

    <keyword>LSP ping, router ping</keyword>
    <keyword>router alert</keyword>
    <abstract>
      <t>The MPLS echo request and MPLS echo response messages, defined in RFC 8029 8029, "Detecting
  Multiprotocol Label Switched (MPLS) Data-Plane Failures" (usually referred to as LSP
  ping messages), are encapsulated in IP whose headers
  include a Router Alert Option (RAO).
<!--[rfced] Please clarify "are encapsulated in IP whose headers include".

Original:
 [The LSP ping messages] are encapsulated in IP whose headers include
 a Router Alert Option (RAO).

Perhaps:
 [The LSP ping messages] are encapsulated in IP packets with headers
 that include a Router Alert Option (RAO).

Or:
 [The LSP ping messages] are encapsulated in IP headers
 that include a Router Alert Option (RAO).
-->
In actual deployments, the RAO was neither required nor used.
   Furthermore, RFC 6398 identifies security
  vulnerabilities associated with the RAO in non-controlled environments, e.g., the case of
   using the MPLS echo request/reply as inter-area Operations, Administration, and Maintenance (OAM),
   and recommends against its use outside of controlled environments.</t>
      <t>Therefore, this document retires the RAO for MPLS OAM and updates RFC 8029 to remove the RAO from LSP
   ping message encapsulations. Furthermore, this document explains why RFC 7506 has been reclassified as Historic.</t>
      <t>Also, the use of an IPv6 loopback address
      (::1/128) as the IPv6 destination address for an MPLS echo request message is RECOMMENDED. <bcp14>RECOMMENDED</bcp14>. <!-- and not the use of an IPv4 loopback address mapped to
      IPv6. --></t>
    </abstract>
  </front>

  <middle>

      <section anchor="rfc-editor-note" numbered="true" toc="default">
      <name>Note for the RFC Editor</name>
      <t>
      Per IESG decision, this document MUST be processed only after the status
      of RFC 7506 is changed to Historical. This note must
<!--[rfced] These phrases do not match. Should "messages" be removed before
from the publication.
      </t>
      </section> abstract?

Abstract: (usually referred to as LSP ping messages)

Section 1: (usually referred to as LSP ping)
-->
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>RFC 8029 - "Detecting
      <t>"Detecting Multiprotocol Label Switched (MPLS) Data-Plane
  Failures" (usually referred to as LSP Ping) ping) <xref target="RFC8029" format="default"/> detects data-plane data plane failures in
  MPLS Label Switched Paths (LSPs). It can operate in "ping mode" or
  "traceroute mode". mode." When operating in ping mode, it checks LSP connectivity.
  When operating in traceroute mode, it can trace an LSP
   and localize failures to a particular node along an LSP.</t>
      <t>The reader is assumed be familiar with <xref target="RFC8029" format="default"/> and its terminology.</t>
      <t>LSP ping defines a probe message called the "MPLS echo
      request".
      request." It also defines a response message called the
      "MPLS echo reply". reply." Both messages are encapsulated in UDP and
      IP. The MPLS echo request message is further encapsulated in an MPLS label
      stack, except when all of the Forwarding Equivalency Classes in the
   stack correspond to Implicit Null labels.</t>
      <t>When operating in ping mode, LSP ping sends a single MPLS echo request
      message, with the MPLS TTL set to 255. This message
      is intended to reach the egress Label Switching Router (LSR). When
      operating in traceroute mode, MPLS ping sends multiple MPLS echo request
      messages as defined in Section 4.3 of <xref target="RFC8029" format="default"/>. format="default" section="4.3"/>.
      It manipulates the MPLS TTL so that the first message expires
      on the first LSR along the path path, and subsequent messages expire on
      subsequent LSRs.</t>
      <t>According to <xref target="RFC8029"/>, the IP header that encapsulates an MPLS echo
   request message must include a Router Alert Option (RAO). Furthermore,
   <xref target="RFC8029"/> also says that the IP header that encapsulates an MPLS echo
   reply message must include an RAO if the value of the Reply Mode in
   the corresponding MPLS echo request message is "Reply via an
   IPv4/IPv6 UDP packet with Router Alert". Alert." This document explains why an RAO was not needed in both cases.
   Furthermore, <xref target="RFC6398" format="default"/>
      identifies security vulnerabilities associated with the RAO in non-controlled environments, e.g., the case of
   using the MPLS echo request/reply as inter-domain OAM over the public Internet, and recommends against its use outside of controlled
   environments, e.g., outside a single administrative domain.</t>

<t>Therefore, this document updates RFC 8029 <xref target="RFC8029"/> to retire the RAO from both
   LSP ping message encapsulations and explains why RFC 7506 <xref target="RFC7506"/> has been reclassified as Historic.</t>

        <section numbered="true" toc="default">
        <name>Requirements Language</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 14 BCP&nbsp;14 <xref target="RFC2119" format="default"/> target="RFC2119"/> <xref target="RFC8174" format="default"/>
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
        </t>
      </section>
  <!--
      <section anchor="terminology" numbered="true" toc="default">
        <name>Terminology</name>
        <dl newline="false" spacing="normal">
          <dt>LSP:</dt>
          <dd>Label Switched Path</dd>
          <dt>LSR:</dt>
          <dd>Label Switching Router</dd>
          <dt>RAO:</dt>
          <dd>Router Alert Option</dd>
        </dl>
      </section>
      -->
    </section>
    <section anchor="router-alert-for-lsp-ping-rfc-8029" numbered="true" toc="default">
      <name>Router Alert for LSP Ping (RFC 8029)</name>
      <section anchor="echo-request" numbered="true" toc="default">
        <name>MPLS Echo Request</name>
        <t>While the MPLS echo request message must traverse every node in the
        LSP under test, it must not traverse any other node. nodes. Specifically, the
        message must not be forwarded beyond the egress Label Switching Router
        (LSR). To achieve this, a set of the mechanisms that are used concurrently
        to prevent leaking MPLS echo request messages has been defined in <xref target="RFC8029" format="default"/>:</t>
        <ol spacing="normal" type="1"><li>When type="1">
	  <li>When the MPLS echo request message is encapsulated in IPv4, the IPv4
            destination address must be chosen from the subnet 127/8. When the
            MPLS echo request message is encapsulated in IPv6, the IPv6 destination
            address must be chosen from the subnet
            0:0:0:0:0:FFFF:7F00:0/104.</li>
          <li>When the MPLS echo request message is encapsulated in IPv4, the IPv4
        TTL must be equal to 1.  When the MPLS echo request message is
        encapsulated in IPv6, the IPv6 Hop Limit must be equal to 1.
        For further information on the encoding of the TTL/Hop TTL / Hop Limit in an
        MPLS echo request message, see Section 4.3 of <xref target="RFC8029" format="default"/>.</li> format="default" section="4.3"/>.</li>
          <li>When the MPLS echo request message is encapsulated in IPv4, the IPv4
            header must include an RAO with the option value set to "Router shall examine packet" <xref target="RFC2113" format="default"/>.
            When the MPLS echo request message is
            encapsulated in IPv6, the IPv6 header chain must include a
            Hop-by-hop
            hop-by-hop extension header and the Hop-by-hop hop-by-hop extension header
            must include an RAO with the option value set to MPLS OAM <xref target="RFC7506" format="default"/>.</li>
        </ol>
        <t>Currently, all of these are required. However, any one is
        sufficient to prevent forwarding the packet beyond the egress LSR.</t>
        <t>Therefore, this document updates RFC 8029 <xref target="RFC8029"/> in that Requirement 3 is
        removed.</t>
        <t>No implementation that relies on the RAO to prevent packets from being
   forwarded beyond the egress LSR have has been reported to the MPLS working group.</t> Working Group.</t>
      </section>
      <section anchor="echo-reply" numbered="true" toc="default">
        <name>MPLS Echo Reply</name>
        <t>An LSP ping replies to the MPLS echo request message with an MPLS echo
        reply message. Four reply modes are defined in <xref target="RFC8029" format="default"/>:</t>
        <ol spacing="normal" type="1"><li>Do not reply</li>
          <li>Reply via an IPv4/IPv6 UDP packet</li>
          <li>Reply via an IPv4/IPv6 UDP packet with Router Alert</li>
          <li>Reply via application-level control channel</li>
        </ol>
        <t>The rationale for mode 3 is questionable, if not wholly misguided.
        According to RFC 8029 <xref target="RFC8029"/>, "If the normal IP return path is deemed
        unreliable, one may use 3 (Reply via an IPv4/IPv6 UDP packet with
        Router Alert)."</t>
        <t>However, it is not clear that the use of the RAO increases the
        reliability of the return path. In fact, one can argue it decreases
        the reliability in many instances, due to the additional burden of
        processing the RAO. This document updates RFC 8029 <xref target="RFC8029"/> in that mode 3 is removed.</t>
        <t>No implementations of mode 3 have been reported to the MPLS working group.</t> Working Group.</t>
        <t/>
      </section>
    </section>
    <section anchor="update-to-rfc-7506" numbered="true" toc="default">
      <name>Reclassification of RFC 7506 as Historic</name>
      <t>RFC 7506 <xref target="RFC7506"/> defines the IPv6 Router Alert Option for MPLS Operations,
      Administration, and Management. Maintenance. This document explains why RFC 7506 <xref target="RFC7506"/> has been reclassified as
      Historic.</t>
    </section>

    <section numbered="true" toc="default">
      <name>Update to RFC 8029</name>
      <t><xref target="RFC8029" format="default"/> requires that the IPv6 Destination Address
      used in IP/UDP encapsulation of an MPLS echo request packet is be selected from
      the IPv4 loopback address range mapped to IPv6. Such packets do not have
      the same behavior as prescribed in <xref target="RFC1122" format="default"/> for an IPv4
      loopback addressed packet.</t>
      <t><xref target="RFC4291" format="default"/> defines ::1/128 as the single IPv6 loopback
      address. Considering that, this specification updates Section 2.1 of <xref target="RFC8029" section="2.1" sectionFormat="of" format="default"/> regarding the selection of an IPv6 destination
      address for an MPLS echo request message as follows:</t>
      <t>OLD</t>

      <t>OLD:</t>
<blockquote>
      <t>The 127/8 range for IPv4 and that same range embedded in an
   IPv4-mapped IPv6 address for IPv6 was chosen for a number of reasons.</t>
   <t>RFC 1122 allocates the 127/8 as the "Internal host loopback address"
   and states: "Addresses of this form MUST NOT <bcp14>MUST NOT</bcp14> appear outside a host."
   Thus, the default behavior of hosts is to discard such packets.  This
   helps to ensure that if a diagnostic packet is misdirected to a host,
   it will be silently discarded.</t>
   <t>RFC 1812 <xref target="RFC1812"/> states:</t>
   <ul spacing="normal">
   <li>A
   <t indent="3">
     A router SHOULD NOT <bcp14>SHOULD NOT</bcp14> forward, except over a loopback
     interface, any packet that has a destination address on network 127.  A
     router
      MAY <bcp14>MAY</bcp14> have a switch that allows the network manager to
     disable these checks.  If such a switch is provided, it MUST <bcp14>MUST</bcp14>
     default to performing the checks.</li>
      </ul> checks.
   </t>
  <t>This helps to ensure that diagnostic packets are never IP forwarded.</t>
  <t>   The 127/8 address range provides 16M addresses allowing wide
   flexibility in varying addresses to exercise ECMP paths. Finally, as
   an implementation optimization, the 127/8 range provides an easy
   means of identifying possible LSP packets.</t>
   <t>NEW</t>
</blockquote>

   <t>NEW:</t>
<blockquote>
   <t>The 127/8 range for IPv4 was chosen for a number of reasons.</t>
   <t>   RFC
   <t>RFC 1122 <xref target="RFC1122"/> allocates the 127/8 as the "Internal host loopback address"
   and states: "Addresses of this form MUST NOT <bcp14>MUST NOT</bcp14> appear outside a host."
   Thus, the default behavior of hosts is to discard such packets.  This
   helps to ensure that if a diagnostic packet is misdirected to a host,
   it will be silently discarded.</t>
   <t>RFC 1812 <xref target="RFC1812"/> states:</t>
   <ul spacing="normal">
   <li>A
   <t indent="3">
     A router SHOULD NOT <bcp14>SHOULD NOT</bcp14> forward, except over a
     loopback interface, any packet that has a destination address on network
     127.  A router
      MAY <bcp14>MAY</bcp14> have a switch that allows the network
     manager to disable these checks.  If such a switch is provided, it MUST
     <bcp14>MUST</bcp14> default to performing the checks.</li>
      </ul> checks.
   </t>
      <t>This helps to ensure that diagnostic packets are never IP forwarded.</t>
      <t>   The
      <t>The 127/8 address range provides 16M addresses allowing wide
   flexibility in varying addresses to exercise ECMP paths.  Finally, as
   an implementation optimization, the 127/8 range provides an easy
   means of identifying possible LSP packets.</t>
   <t>   The IPv6 destination address for an MPLS echo request message is
   selected as follows:</t>

      <ul spacing="normal">
        <li>The
<!--[rfced] RECOMMENDED (Abstract) vs. SHOULD (Section 4)
Even though these keywords are equivalent per RFC 2119,
please consider using the same requirement keyword in the abstract
that is used within the body of the document, for the ease of the reader.

Abstract:
   Also, the use of an IPv6 loopback address (::1/128) as the IPv6
   destination address for an MPLS echo request message is RECOMMENDED.

Section 4:
     *  The IPv6 loopback address ::1/128 SHOULD be used.
-->
        <li>The IPv6 loopback address ::1/128 <bcp14>SHOULD</bcp14> be used.</li>
        <li>The sender of an MPLS echo request MAY <bcp14>MAY</bcp14> select the IPv6 destination
          address from the 0:0:0:0:0:FFFF:7F00/104 range.</li>
        <li>To exercise all paths in an ECMP environment, the source of entropy other
          than the IP destination address SHOULD <bcp14>SHOULD</bcp14> be used. For example, the MPLS Entropy Label <xref target="RFC6790"/>
          or IPv6 Flow Label <xref target="RFC6438"/> can be used as the source of entropy.</li>
      </ul>
      <t>END</t>
</blockquote>

<t>Additionally, this specification updates Section 2.2 of <xref target="RFC8029"/> target="RFC8029" section="2.2" sectionFormat="of" /> to
   replace the whole of the section with the following text:</t>
<ul empty="true">
      <li>LSP
<blockquote>
      <t>LSP Ping implementations SHOULD <bcp14>SHOULD</bcp14> ignore RAO options when they arrive
      on incoming MPLS echo request and MPLS echo reply messages.</li>
</ul> messages.</t>
</blockquote>

      <t>
      Resulting from the removal of the Reply mode 3 "Reply via an IPv4/IPv6 UDP packet with Router Alert" (see <xref target="echo-reply"/>),
      this specification updates Section 4.5 of <xref target="RFC8029"/> target="RFC8029" section="4.5" sectionFormat="of" /> by removing the following text:</t>
<ul empty="true">
<li>
<blockquote>
   If the Reply Mode in the echo request is "Reply via an
   IPv4 UDP packet with Router Alert", then the IP header MUST <bcp14>MUST</bcp14> contain
   the Router Alert IP Option of value 0x0 [RFC2113] <xref target="RFC2113"/> for IPv4 or 69
   [RFC7506]
   <xref target="RFC7506"/> for IPv6. If the reply is sent over an LSP, the topmost
   label MUST <bcp14>MUST</bcp14> in this case be the Router Alert label (1) (see [RFC3032]).
</li>
</ul> <xref target="RFC3032"/>).
</blockquote>

   <t>Furthermore, this specification updates Section 4.3 of <xref target="RFC8029"/> target="RFC8029" section="4.3" sectionFormat="of" /> as follows:</t>
   <t>OLD:</t>
<blockquote>
   <t>The Router Alert IP Option of value 0x0 <xref target="RFC2113"/> for IPv4 or value 69 <xref target="RFC7506"/> for IPv6
   MUST
   <bcp14>MUST</bcp14> be set in the IP header.</t>
</blockquote>
   <t>NEW:</t>
<blockquote>
   <t>The Router Alert IP Option of value 0x0  <xref target="RFC2113"/> for IPv4 or value 69 <xref target="RFC7506"/> for IPv6
   MUST NOT
   <bcp14>MUST NOT</bcp14> be set in the IP header.</t>
   <t>END</t>
</blockquote>
    </section>
    <section anchor="backwards-compatibility" numbered="true" toc="default">
      <name>Backwards Compatibility</name>
      <t>LSP Ping implementations that conform to this specification SHOULD <bcp14>SHOULD</bcp14>
   ignore RAO options when they arrive on incoming MPLS echo request and
   MPLS echo reply messages. However, this will not harm backwards
   compatibility because other mechanisms will also be in use by all
   legacy implementations in the messages they send and receive.</t>
   <t>
   <xref target="iana-considerations"/> of this document deprecates the IPv6 RAO value for MPLS OAM
   (69) in <xref target="IANA-IPV6-RAO"/> and the Reply Mode 3 ("Reply via an IPv4/IPv6
   UDP packet with Router Alert") in <xref target="IANA-LSP-PING"/>.
   </t>
   <t>
   <xref target="RFC8126"/> offers a formal description of the word "Deprecated". In
   this context, "Deprecated" means that the deprecated values SHOULD
   NOT <bcp14>SHOULD
   NOT</bcp14> be used in new implementations, and that deployed implementations
   that already use these values continue to work seamlessly.
   </t>

    </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>   IANA is requested to mark has marked the IPv6 RAO value of MPLS OAM (69) in
   <xref target="IANA-IPV6-RAO"/> as "Deprecated".</t>
      <t>   IANA is also requested to mark has marked Reply Mode 3 ("Reply via an IPv4/IPv6
   UDP packet with Router Alert") in "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs)
   Ping Parameters"<xref target="IANA-LSP-PING"/> as "Deprecated".</t>
    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The recommendations this document makes do not compromise
      security.
<!--[rfced] Please clarify this sentence; what is the intended meaning?

Original:
   In case of using IPv6 loopback address ::1/128 strengthens security
   for LSP Ping by using the standardized loopback address with well-defined behavior.</t>
    </section>

          <section numbered="true" toc="default">
      <name>Acknowledgments</name>
      <t>
The authors express their appreciation to Adrian Farrel and Gyan Mishra well-
   defined behavior.

Perhaps:
   Using the IPv6 loopback address ::1/128 strengthens security
   for their suggestions that improved LSP ping because it is standardized and has well-defined behavior.

Or:
   When using IPv6, the readability loopback address ::1/128 strengthens security
   for LSP ping because it has well-defined behavior.
-->
In case of using IPv6 loopback address ::1/128 strengthens security
      for LSP ping by using the document.
      </t> standardized loopback address with well-defined behavior.</t>
    </section>

  </middle>
  <back>
    <references>
      <name>Normative References</name>

      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8029.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6398.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7506.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4291.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1122.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1812.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2113.xml"/>

    </references>

      <references>
        <name>Informational
        <name>Informative References</name>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3032.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6438.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6790.xml"/>

      <reference anchor="IANA-IPV6-RAO" target="https://www.iana.org/assignments/ipv6-routeralert-values">
        <front>
          <title>IPv6 Router Alert Option Values</title>
          <author>
            <organization>IANA</organization>
          </author>
          <date>n.d.</date>
        </front>
      </reference>

      <reference anchor="IANA-LSP-PING" target="https://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xml"> target="https://www.iana.org/assignments/mpls-lsp-ping-parameters">
        <front>
          <title>Multiprotocol Label Switching (MPLS) Label Switched Paths
          (LSPs) Ping Parameters</title>
          <author>
            <organization>IANA</organization>
          </author>
          <date>n.d.</date>
        </front>
      </reference>

     </references>

          <section numbered="false">
      <name>Acknowledgments</name>
      <t>
The authors express their appreciation to Adrian Farrel and Gyan Mishra for their suggestions that improved the readability of the document.
      </t>
    </section>

<!-- [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>