rfc9570.original.xml   rfc9570.xml 
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.5.6 --> tf-mpls-lspping-norao-08" number="9570" consensus="true" ipr="trust200902" updat
<?rfc toc="yes"?> es="8029" obsoletes="" submissionType="IETF" xml:lang="en" tocInclude="true" sor
<?rfc sortrefs="yes"?> tRefs="true" symRefs="true" version="3">
<?rfc symrefs="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
tf-mpls-lspping-norao-08" ipr="trust200902" updates="8029" obsoletes="" submissi
onType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" ver
sion="3">
<!-- xml2rfc v2v3 conversion 3.18.0 -->
<front> <front>
<title abbrev="RAO-less Label Switched Path (LSP) Ping">Deprecating the Use of Router Alert in LSP Ping</title> <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"/> <seriesInfo name="RFC" value="9570"/>
<author fullname="Kireeti Kompella" initials="K." surname="Kompella"> <author fullname="Kireeti Kompella" initials="K." surname="Kompella">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<postal> <postal>
<street>1133 Innovation Way</street> <street>1133 Innovation Way</street>
<city>Sunnyvale</city> <city>Sunnyvale</city>
<region>CA</region> <region>CA</region>
<code>94089</code> <code>94089</code>
<country>United States</country> <country>United States of America</country>
</postal> </postal>
<email>kireeti.ietf@gmail.com</email> <email>kireeti.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Ron Bonica" initials="R." surname="Bonica"> <author fullname="Ron Bonica" initials="R." surname="Bonica">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<postal> <postal>
<street>1133 Innovation Way</street> <street>1133 Innovation Way</street>
<city>Sunnyvale</city> <city>Sunnyvale</city>
<region>CA</region> <region>CA</region>
<code>94089</code> <code>94089</code>
<country>United States</country> <country>United States of America</country>
</postal> </postal>
<email>rbonica@juniper.net</email> <email>rbonica@juniper.net</email>
</address> </address>
</author> </author>
<author fullname="Greg Mirsky" initials="G." surname="Mirsky" role="editor"> <author fullname="Greg Mirsky" initials="G." surname="Mirsky" role="editor">
<organization>Ericsson</organization> <organization>Ericsson</organization>
<address> <address>
<email>gregimirsky@gmail.com</email> <email>gregimirsky@gmail.com</email>
</address> </address>
</author> </author>
<date year="2024"/> <date year="2024" month="May"/>
<area>Routing</area>
<workgroup>MPLS WG</workgroup> <area>RTG</area>
<keyword>LSP ping, router alert</keyword> <workgroup>mpls</workgroup>
<keyword>LSP ping</keyword>
<keyword>router alert</keyword>
<abstract> <abstract>
<t>The MPLS echo request and MPLS echo response messages, defined in RFC 8 <t>The MPLS echo request and MPLS echo response messages, defined in RFC
029 "Detecting 8029, "Detecting Multiprotocol Label Switched (MPLS) Data-Plane
Multiprotocol Label Switched (MPLS) Data-Plane Failures" (usually referred to Failures" (usually referred to as LSP ping), are encapsulated in IP
as LSP packets with headers that include a Router Alert Option (RAO). In actual
ping messages), are encapsulated in IP whose headers deployments, the RAO was neither required nor used. Furthermore, RFC
include a Router Alert Option (RAO). In actual deployments, the RAO was neithe 6398 identifies security vulnerabilities associated with the RAO in
r required nor used. non-controlled environments, e.g., the case of using the MPLS echo
Furthermore, RFC 6398 identifies security request/reply as inter-area Operations, Administration, and Maintenance
vulnerabilities associated with the RAO in non-controlled environments, e.g., (OAM), and recommends against its use outside of controlled
the case of environments.</t>
using the MPLS echo request/reply as inter-area Operations, Administration, a <t>Therefore, this document retires the RAO for MPLS OAM and updates RFC
nd Maintenance (OAM), 8029 to remove the RAO from LSP ping message
and recommends against its use outside of controlled environments.</t> encapsulations. Furthermore, this document explains why RFC 7506 has
<t>Therefore, this document retires the RAO for MPLS OAM and updates RFC 8 been reclassified as Historic.</t>
029 to remove the RAO from LSP <t>Also, this document recommends the use of an IPv6 loopback address
ping message encapsulations. Furthermore, this document explains why RFC 7506 (::1/128) as the IPv6 destination address for an MPLS echo request
has been reclassified as Historic.</t> message.</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. <!-- and not the use of an IPv4 loopback address mapped to
IPv6. --></t>
</abstract> </abstract>
</front> </front>
<middle> <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 be removed before the
publication.
</t>
</section>
<section anchor="introduction" numbered="true" toc="default"> <section anchor="introduction" numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t>RFC 8029 - "Detecting Multiprotocol Label Switched (MPLS) Data-Plane <t>"Detecting Multiprotocol Label Switched (MPLS) Data-Plane
Failures" (usually referred to as LSP Ping) <xref target="RFC8029" format="def Failures" (usually referred to as LSP ping) <xref target="RFC8029" format="def
ault"/> detects data-plane failures in ault"/> detects data plane failures in
MPLS Label Switched Paths (LSPs). It can operate in "ping mode" or MPLS Label Switched Paths (LSPs). It can operate in "ping mode" or
"traceroute mode". When operating in ping mode, it checks LSP connectivity. "traceroute mode." When operating in ping mode, it checks LSP connectivity.
When operating in traceroute mode, it can trace an LSP When operating in traceroute mode, it can trace an LSP
and localize failures to a particular node along an LSP.</t> and localize failures to a particular node along an LSP.</t>
<t>The reader is assumed be familiar with <xref target="RFC8029" format="d efault"/> and its terminology.</t> <t>The reader is assumed be familiar with <xref target="RFC8029" format="d efault"/> and its terminology.</t>
<t>LSP ping defines a probe message called the "MPLS echo <t>LSP ping defines a probe message called the "MPLS echo
request". It also defines a response message called the request." It also defines a response message called the
"MPLS echo reply". Both messages are encapsulated in UDP and "MPLS echo reply." Both messages are encapsulated in UDP and
IP. The MPLS echo request message is further encapsulated in an MPLS label 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, except when all of the Forwarding Equivalency Classes in the
stack correspond to Implicit Null labels.</t> stack correspond to Implicit Null labels.</t>
<t>When operating in ping mode, LSP ping sends a single MPLS echo request <t>When operating in ping mode, LSP ping sends a single MPLS echo request
message, with the MPLS TTL set to 255. This message message, with the MPLS TTL set to 255. This message
is intended to reach the egress Label Switching Router (LSR). When is intended to reach the egress Label Switching Router (LSR). When
operating in traceroute mode, MPLS ping sends multiple MPLS echo request operating in traceroute mode, MPLS ping sends multiple MPLS echo request
messages as defined in Section 4.3 of <xref target="RFC8029" format="defau lt"/>. messages as defined in <xref target="RFC8029" format="default" section="4. 3"/>.
It manipulates the MPLS TTL so that the first message expires It manipulates the MPLS TTL so that the first message expires
on the first LSR along the path and subsequent messages expire on on the first LSR along the path, and subsequent messages expire on
subsequent LSRs.</t> subsequent LSRs.</t>
<t>According to <xref target="RFC8029"/>, the IP header that encapsulates an MPLS echo <t>According to <xref target="RFC8029"/>, the IP header that encapsulates an MPLS echo
request message must include a Router Alert Option (RAO). Furthermore, request message must include a Router Alert Option (RAO). Furthermore,
<xref target="RFC8029"/> also says that the IP header that encapsulates an MP LS echo <xref target="RFC8029"/> also says that the IP header that encapsulates an MP LS echo
reply message must include an RAO if the value of the Reply Mode in reply message must include an RAO if the value of the Reply Mode in
the corresponding MPLS echo request message is "Reply via an the corresponding MPLS echo request message is "Reply via an
IPv4/IPv6 UDP packet with Router Alert". This document explains why RAO was n ot needed in both cases. IPv4/IPv6 UDP packet with Router Alert." This document explains why an RAO wa s not needed in both cases.
Furthermore, <xref target="RFC6398" format="default"/> Furthermore, <xref target="RFC6398" format="default"/>
identifies security vulnerabilities associated with the RAO in non-control led environments, e.g., the case of identifies security vulnerabilities associated with the RAO in non-control led environments, e.g., the case of
using the MPLS echo request/reply as inter-domain OAM over the public Interne t, and recommends against its use outside of controlled using the MPLS echo request/reply as inter-domain OAM over the public Interne t, and recommends against its use outside of controlled
environments, e.g., outside a single administrative domain.</t> environments, e.g., outside a single administrative domain.</t>
<t>Therefore, this document updates RFC 8029 <xref target="RFC8029"/> to r
etire the RAO from both <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="RFC75 06"/> has been reclassified as Historic.</t> LSP ping message encapsulations and explains why RFC 7506 <xref target="RFC75 06"/> has been reclassified as Historic.</t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Requirements Language</name> <name>Requirements Language</name>
<t> <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
"MAY", and "OPTIONAL" in this document are to be interpreted as ",
described in BCP 14 <xref target="RFC2119" format="default"/> <xref target="R "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
FC8174" format="default"/> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
when, and only when, they appear in all capitals, as shown here. "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be
interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t> </t>
</section> </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>
<section anchor="router-alert-for-lsp-ping-rfc-8029" numbered="true" toc="de fault"> <section anchor="router-alert-for-lsp-ping-rfc-8029" numbered="true" toc="de fault">
<name>Router Alert for LSP Ping (RFC 8029)</name> <name>Router Alert for LSP Ping (RFC 8029)</name>
<section anchor="echo-request" numbered="true" toc="default"> <section anchor="echo-request" numbered="true" toc="default">
<name>MPLS Echo Request</name> <name>MPLS Echo Request</name>
<t>While the MPLS echo request message must traverse every node in the <t>While the MPLS echo request message must traverse every node in the
LSP under test, it must not traverse any other node. Specifically, the LSP under test, it must not traverse any other nodes. Specifically, the
message must not be forwarded beyond the egress Label Switching Router message must not be forwarded beyond the egress Label Switching Router
(LSR). To achieve this, a set of the mechanisms that are used concurrent ly (LSR). To achieve this, a set of the mechanisms that are used concurrent ly
to prevent leaking MPLS echo request messages has been defined in <xref target="RFC8029" format="default"/>:</t> to prevent leaking MPLS echo request messages has been defined in <xref target="RFC8029" format="default"/>:</t>
<ol spacing="normal" type="1"><li>When the MPLS echo request message is <ol spacing="normal" type="1">
encapsulated in IPv4, the IPv4 <li>When the MPLS echo request message is encapsulated in IPv4, the IPv
4
destination address must be chosen from the subnet 127/8. When the destination address must be chosen from the subnet 127/8. When the
MPLS echo request message is encapsulated in IPv6, the IPv6 destinat ion MPLS echo request message is encapsulated in IPv6, the IPv6 destinat ion
address must be chosen from the subnet address must be chosen from the subnet
0:0:0:0:0:FFFF:7F00:0/104.</li> 0:0:0:0:0:FFFF:7F00:0/104.</li>
<li>When the MPLS echo request message is encapsulated in IPv4, the IP v4 <li>When the MPLS echo request message is encapsulated in IPv4, the IP v4
TTL must be equal to 1. When the MPLS echo request message is 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. encapsulated in IPv6, the IPv6 Hop Limit must be equal to 1.
For further information on the encoding of the TTL/Hop Limit in an For further information on the encoding of the TTL / Hop Limit in an
MPLS echo request message, see Section 4.3 of <xref target="RFC8029" for MPLS echo request message, see <xref target="RFC8029" format="default" s
mat="default"/>.</li> ection="4.3"/>.</li>
<li>When the MPLS echo request message is encapsulated in IPv4, the IP v4 <li>When the MPLS echo request message is encapsulated in IPv4, the IP v4
header must include an RAO with the option value set to "Router shal l examine packet" <xref target="RFC2113" format="default"/>. header must include an RAO with the option value set to "Router shal l examine packet" <xref target="RFC2113" format="default"/>.
When the MPLS echo request message is When the MPLS echo request message is
encapsulated in IPv6, the IPv6 header chain must include a encapsulated in IPv6, the IPv6 header chain must include a
Hop-by-hop extension header and the Hop-by-hop extension header hop-by-hop extension header and the hop-by-hop extension header
must include an RAO with the option value set to MPLS OAM <xref targ et="RFC7506" format="default"/>.</li> must include an RAO with the option value set to MPLS OAM <xref targ et="RFC7506" format="default"/>.</li>
</ol> </ol>
<t>Currently, all of these are required. However, any one is <t>Currently, all of these are required. However, any one is
sufficient to prevent forwarding the packet beyond the egress LSR.</t> 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 <t>Therefore, this document updates RFC 8029 <xref target="RFC8029"/> in that Requirement 3 is
removed.</t> removed.</t>
<t>No implementation that relies on the RAO to prevent packets from bein g <t>No implementation that relies on the RAO to prevent packets from bein g
forwarded beyond the egress LSR have been reported to the MPLS working group. </t> forwarded beyond the egress LSR has been reported to the MPLS Working Group.< /t>
</section> </section>
<section anchor="echo-reply" numbered="true" toc="default"> <section anchor="echo-reply" numbered="true" toc="default">
<name>MPLS Echo Reply</name> <name>MPLS Echo Reply</name>
<t>An LSP ping replies to the MPLS echo request message with an MPLS ech o <t>An LSP ping replies to the MPLS echo request message with an MPLS ech o
reply message. Four reply modes are defined in <xref target="RFC8029" fo rmat="default"/>:</t> reply message. Four reply modes are defined in <xref target="RFC8029" fo rmat="default"/>:</t>
<ol spacing="normal" type="1"><li>Do not reply</li> <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</li>
<li>Reply via an IPv4/IPv6 UDP packet with Router Alert</li> <li>Reply via an IPv4/IPv6 UDP packet with Router Alert</li>
<li>Reply via application-level control channel</li> <li>Reply via application-level control channel</li>
</ol> </ol>
<t>The rationale for mode 3 is questionable, if not wholly misguided. <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 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 unreliable, one may use 3 (Reply via an IPv4/IPv6 UDP packet with
Router Alert)."</t> Router Alert)."</t>
<t>However, it is not clear that the use of the RAO increases the <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 reliability of the return path. In fact, one can argue it decreases
the reliability in many instances, due to the additional burden of 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> 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 g roup.</t> <t>No implementations of mode 3 have been reported to the MPLS Working G roup.</t>
<t/> <t/>
</section> </section>
</section> </section>
<section anchor="update-to-rfc-7506" numbered="true" toc="default"> <section anchor="update-to-rfc-7506" numbered="true" toc="default">
<name>Reclassification of RFC 7506 as Historic</name> <name>Reclassification of RFC 7506 as Historic</name>
<t>RFC 7506 <xref target="RFC7506"/> defines the IPv6 Router Alert Option for MPLS Operations, <t>RFC 7506 <xref target="RFC7506"/> defines the IPv6 Router Alert Option for MPLS Operations,
Administration, and Management. This document explains why RFC 7506 <xref target="RFC7506"/> has been reclassified as Administration, and Maintenance. This document explains why RFC 7506 <xref target="RFC7506"/> has been reclassified as
Historic.</t> Historic.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Update to RFC 8029</name> <name>Update to RFC 8029</name>
<t><xref target="RFC8029" format="default"/> requires that the IPv6 Destin ation Address <t><xref target="RFC8029" format="default"/> requires that the IPv6 Destin ation Address
used in IP/UDP encapsulation of an MPLS echo request packet is selected fr om used in IP/UDP encapsulation of an MPLS echo request packet be selected fr om
the IPv4 loopback address range mapped to IPv6. Such packets do not have 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 the same behavior as prescribed in <xref target="RFC1122" format="default" /> for an IPv4
loopback addressed packet.</t> loopback addressed packet.</t>
<t><xref target="RFC4291" format="default"/> defines ::1/128 as the single IPv6 loopback <t><xref target="RFC4291" format="default"/> defines ::1/128 as the single IPv6 loopback
address. Considering that, this specification updates Section 2.1 of address. Considering that, this specification updates <xref target="RFC802
<xref target="RFC8029" format="default"/> regarding the selection of an IP 9" section="2.1" sectionFormat="of" format="default"/> regarding the selection o
v6 destination f an IPv6 destination
address for an MPLS echo request message as follows:</t> 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 <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> 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" <t>RFC 1122 allocates the 127/8 as the "Internal host loopback address"
and states: "Addresses of this form MUST NOT appear outside a host." and states: "Addresses of this form <bcp14>MUST NOT</bcp14> appear outside a host."
Thus, the default behavior of hosts is to discard such packets. This 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, helps to ensure that if a diagnostic packet is misdirected to a host,
it will be silently discarded.</t> it will be silently discarded.</t>
<t>RFC 1812 <xref target="RFC1812"/> states:</t> <t>RFC 1812 <xref target="RFC1812"/> states:</t>
<ul spacing="normal"> <t indent="3">
<li>A router SHOULD NOT forward, except over a loopback interface, any A router <bcp14>SHOULD NOT</bcp14> forward, except over a loopback
packet that has a destination address on network 127. A router interface, any packet that has a destination address on network 127. A
MAY have a switch that allows the network manager to disable these router <bcp14>MAY</bcp14> have a switch that allows the network manager to
checks. If such a switch is provided, it MUST default to disable these checks. If such a switch is provided, it <bcp14>MUST</bcp14>
performing the checks.</li> default to performing the checks.
</ul> </t>
<t>This helps to ensure that diagnostic packets are never IP forwarded.</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 <t> The 127/8 address range provides 16M addresses allowing wide
flexibility in varying addresses to exercise ECMP paths. Finally, as flexibility in varying addresses to exercise ECMP paths. Finally, as
an implementation optimization, the 127/8 range provides an easy an implementation optimization, the 127/8 range provides an easy
means of identifying possible LSP packets.</t> 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>The 127/8 range for IPv4 was chosen for a number of reasons.</t>
<t> RFC 1122 <xref target="RFC1122"/> allocates the 127/8 as the "Internal <t>RFC 1122 <xref target="RFC1122"/> allocates the 127/8 as the "Internal hos
host loopback address" t loopback address"
and states: "Addresses of this form MUST NOT appear outside a host." and states: "Addresses of this form <bcp14>MUST NOT</bcp14> appear outside a
host."
Thus, the default behavior of hosts is to discard such packets. This 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, helps to ensure that if a diagnostic packet is misdirected to a host,
it will be silently discarded.</t> it will be silently discarded.</t>
<t>RFC 1812 <xref target="RFC1812"/> states:</t> <t>RFC 1812 <xref target="RFC1812"/> states:</t>
<ul spacing="normal"> <t indent="3">
<li>A router SHOULD NOT forward, except over a loopback interface, any A router <bcp14>SHOULD NOT</bcp14> forward, except over a
packet that has a destination address on network 127. A router loopback interface, any packet that has a destination address on network
MAY have a switch that allows the network manager to disable these 127. A router <bcp14>MAY</bcp14> have a switch that allows the network
checks. If such a switch is provided, it MUST default to manager to disable these checks. If such a switch is provided, it
performing the checks.</li> <bcp14>MUST</bcp14> default to performing the checks.
</ul> </t>
<t>This helps to ensure that diagnostic packets are never IP forwarded.</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 <t>The 127/8 address range provides 16M addresses allowing wide
flexibility in varying addresses to exercise ECMP paths. Finally, as flexibility in varying addresses to exercise ECMP paths. Finally, as
an implementation optimization, the 127/8 range provides an easy an implementation optimization, the 127/8 range provides an easy
means of identifying possible LSP packets.</t> means of identifying possible LSP packets.</t>
<t> The IPv6 destination address for an MPLS echo request message is <t> The IPv6 destination address for an MPLS echo request message is
selected as follows:</t> selected as follows:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The IPv6 loopback address ::1/128 SHOULD be used.</li> <li>The IPv6 loopback address ::1/128 <bcp14>SHOULD</bcp14> be used.</li
<li>The sender of an MPLS echo request MAY select the IPv6 destination >
<li>The sender of an MPLS echo request <bcp14>MAY</bcp14> select the IPv
6 destination
address from the 0:0:0:0:0:FFFF:7F00/104 range.</li> 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 <li>To exercise all paths in an ECMP environment, the source of entropy other
than the IP destination address SHOULD be used. For example, MPLS Entr opy Label <xref target="RFC6790"/> than the IP destination address <bcp14>SHOULD</bcp14> be used. For exa mple, the MPLS Entropy Label <xref target="RFC6790"/>
or IPv6 Flow Label <xref target="RFC6438"/> can be used as the source of entropy.</li> or IPv6 Flow Label <xref target="RFC6438"/> can be used as the source of entropy.</li>
</ul> </ul>
<t>END</t> </blockquote>
<t>Additionally, this specification updates Section 2.2 of <xref target="RFC8029 "/> to <t>Additionally, this specification updates <xref target="RFC8029" section="2.2" sectionFormat="of" /> to
replace the whole of the section with the following text:</t> replace the whole of the section with the following text:</t>
<ul empty="true"> <blockquote>
<li>LSP Ping implementations SHOULD ignore RAO options when they arrive <t>LSP Ping implementations <bcp14>SHOULD</bcp14> ignore RAO options when
on incoming MPLS echo request and MPLS echo reply messages.</li> they arrive
</ul> on incoming MPLS echo request and MPLS echo reply messages.</t>
</blockquote>
<t> <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"/>), 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"/> by remo this specification updates <xref target="RFC8029" section="4.5" sectionFor
ving the following text:</t> mat="of" /> by removing the following text:</t>
<ul empty="true"> <blockquote>
<li> If the Reply Mode in the echo request is "Reply via an
If the Reply Mode in the echo request is "Reply via an IPv4 UDP packet with Router Alert", then the IP header <bcp14>MUST</bcp14> co
IPv4 UDP packet with Router Alert", then the IP header MUST contain ntain
the Router Alert IP Option of value 0x0 [RFC2113] for IPv4 or 69 the Router Alert IP Option of value 0x0 <xref target="RFC2113"/> for IPv4 or
[RFC7506] for IPv6. If the reply is sent over an LSP, the topmost 69
label MUST in this case be the Router Alert label (1) (see [RFC3032]). <xref target="RFC7506"/> for IPv6. If the reply is sent over an LSP, the topm
</li> ost
</ul> label <bcp14>MUST</bcp14> in this case be the Router Alert label (1) (see <xr
ef target="RFC3032"/>).
</blockquote>
<t>Furthermore, this specification updates Section 4.3 of <xref target="RFC80 29"/> as follows:</t> <t>Furthermore, this specification updates <xref target="RFC8029" section="4. 3" sectionFormat="of" /> as follows:</t>
<t>OLD:</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 <t>The Router Alert IP Option of value 0x0 <xref target="RFC2113"/> for IPv4 or value 69 <xref target="RFC7506"/> for IPv6
MUST be set in the IP header.</t> <bcp14>MUST</bcp14> be set in the IP header.</t>
</blockquote>
<t>NEW:</t> <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 <t>The Router Alert IP Option of value 0x0 <xref target="RFC2113"/> for IPv4 or value 69 <xref target="RFC7506"/> for IPv6
MUST NOT be set in the IP header.</t> <bcp14>MUST NOT</bcp14> be set in the IP header.</t>
<t>END</t> </blockquote>
</section> </section>
<section anchor="backwards-compatibility" numbered="true" toc="default"> <section anchor="backwards-compatibility" numbered="true" toc="default">
<name>Backwards Compatibility</name> <name>Backwards Compatibility</name>
<t>LSP Ping implementations that conform to this specification SHOULD <t>LSP Ping implementations that conform to this specification <bcp14>SHOU LD</bcp14>
ignore RAO options when they arrive on incoming MPLS echo request and ignore RAO options when they arrive on incoming MPLS echo request and
MPLS echo reply messages. However, this will not harm backwards MPLS echo reply messages. However, this will not harm backwards
compatibility because other mechanisms will also be in use by all compatibility because other mechanisms will also be in use by all
legacy implementations in the messages they send and receive.</t> legacy implementations in the messages they send and receive.</t>
<t> <t>
<xref target="iana-considerations"/> of this document deprecates the IPv6 RAO value for MPLS OAM <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 IP v4/IPv6 (69) in <xref target="IANA-IPV6-RAO"/> and the Reply Mode 3 ("Reply via an IP v4/IPv6
UDP packet with Router Alert") in <xref target="IANA-LSP-PING"/>. UDP packet with Router Alert") in <xref target="IANA-LSP-PING"/>.
</t> </t>
<t> <t>
<xref target="RFC8126"/> offers a formal description of the word "Deprecated" . In <xref target="RFC8126"/> offers a formal description of the word "Deprecated" . In
this context, "Deprecated" means that the deprecated values SHOULD this context, "Deprecated" means that the deprecated values <bcp14>SHOULD
NOT be used in new implementations, and that deployed implementations NOT</bcp14> be used in new implementations, and that deployed implementations
that already use these values continue to work seamlessly. that already use these values continue to work seamlessly.
</t> </t>
</section> </section>
<section anchor="iana-considerations" numbered="true" toc="default"> <section anchor="iana-considerations" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t> IANA is requested to mark the IPv6 RAO value of MPLS OAM (69) in <t> IANA has marked the IPv6 RAO value of MPLS OAM (69) in
<xref target="IANA-IPV6-RAO"/> as "Deprecated".</t> <xref target="IANA-IPV6-RAO"/> as "DEPRECATED".</t>
<t> IANA is also requested to mark Reply Mode 3 ("Reply via an IPv4/IPv6 <t> IANA has marked Reply Mode 3 ("Reply via an IPv4/IPv6
UDP packet with Router Alert") in "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) UDP packet with Router Alert") in "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs)
Ping Parameters"<xref target="IANA-LSP-PING"/> as "Deprecated".</t> Ping Parameters" <xref target="IANA-LSP-PING"/> as "DEPRECATED".</t>
</section> </section>
<section anchor="security-considerations" numbered="true" toc="default"> <section anchor="security-considerations" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>The recommendations this document makes do not compromise <t>The recommendations this document makes do not compromise
security. In case of using IPv6 loopback address ::1/128 strengthens secur security.
ity Using the IPv6 loopback address ::1/128 strengthens security
for LSP Ping by using the standardized loopback address with well-defined for LSP ping because it is standardized and has well-defined behavior.
behavior.</t> </t>
</section>
<section numbered="true" toc="default">
<name>Acknowledgments</name>
<t>
The authors express their appreciation to Adrian Farrel and Gyan Mishra for thei
r suggestions that improved the readability of the document.
</t>
</section> </section>
</middle> </middle>
<back> <back>
<references> <references>
<name>Normative References</name> <name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.802
.8029.xml"/> 9.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.639
.6398.xml"/> 8.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.750
.7506.xml"/> 6.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.211
.2119.xml"/> 9.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.817
.8174.xml"/> 4.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.429
.4291.xml"/> 1.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.112
.1122.xml"/> 2.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.812
.8126.xml"/> 6.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.181
.1812.xml"/> 2.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.211
.2113.xml"/> 3.xml"/>
</references> </references>
<references> <references>
<name>Informational References</name> <name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.303
.6438.xml"/> 2.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.643
.6790.xml"/> 8.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.679
0.xml"/>
<reference anchor="IANA-IPV6-RAO" target="https://www.iana.org/assignments /ipv6-routeralert-values"> <reference anchor="IANA-IPV6-RAO" target="https://www.iana.org/assignments /ipv6-routeralert-values">
<front> <front>
<title>IPv6 Router Alert Option Values</title> <title>IPv6 Router Alert Option Values</title>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
<reference anchor="IANA-LSP-PING" target="https://www.iana.org/assignments
/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xml"> <reference anchor="IANA-LSP-PING" target="https://www.iana.org/assignments
/mpls-lsp-ping-parameters">
<front> <front>
<title>Multiprotocol Label Switching (MPLS) Label Switched Paths <title>Multiprotocol Label Switching (MPLS) Label Switched Paths
(LSPs) Ping Parameters</title> (LSPs) Ping Parameters</title>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
</references> </references>
</references>
<section numbered="false">
<name>Acknowledgments</name>
<t>
The authors express their appreciation to Adrian Farrel and Gyan Mishra for thei
r suggestions that improved the readability of the document.
</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 58 change blocks. 
187 lines changed or deleted 185 lines changed or added

This html diff was produced by rfcdiff 1.48.