rfc9805xml2.original.xml   rfc9805.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std"
docName="draft-ietf-6man-deprecate-router-alert-13"
ipr="trust200902" updates="2711">
<front>
<title abbrev="Deprecate IPv6 Router Alert For New Protocols">
Deprecation Of The IPv6 Router Alert Option For New Protocols
</title>
<author fullname="Ron Bonica" initials="R." surname="Bonica"> <!DOCTYPE rfc [
<organization>Juniper Networks</organization> <!ENTITY nbsp "&#160;">
<address> <!ENTITY zwsp "&#8203;">
<postal> <!ENTITY nbhy "&#8209;">
<country>USA</country> <!ENTITY wj "&#8288;">
</postal> ]>
<email>rbonica@juniper.net</email>
</address>
</author>
<date day="29" month="April" year="2025"/> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
<area>INT Area</area> tf-6man-deprecate-router-alert-13" number="9805" consensus="true" ipr="trust2009
<workgroup>6man</workgroup> 02" updates="2711" obsoletes="" submissionType="IETF" xml:lang="en" tocInclude="
<keyword>IPv6</keyword> true" tocDepth="3" symRefs="true" sortRefs="true" version="3">
<abstract> <front>
<t>This document deprecates the IPv6 Router Alert Option. <title abbrev="Deprecate IPv6 Router Alert for New Protocols">Deprecation of
the IPv6 Router Alert Option for New Protocols</title>
<seriesInfo name="RFC" value="9805"/>
<author fullname="Ron Bonica" initials="R." surname="Bonica">
<organization>Juniper Networks</organization>
<address>
<postal>
<country>United States of America</country>
</postal>
<email>rbonica@juniper.net</email>
</address>
</author>
<date month="June" year="2025"/>
<area>INT</area>
<workgroup>6man</workgroup>
<keyword>IPv6</keyword>
<abstract>
<t>This document deprecates the IPv6 Router Alert Option.
Protocols that use the Router Alert Option may continue to do so, Protocols that use the Router Alert Option may continue to do so,
even in future versions. However, new protocols that are standardized even in future versions. However, new protocols that are standardized
in the future must not use the Router Alert Option.</t> in the future must not use the Router Alert Option.</t>
<t>This document updates RFC 2711. </t>
<t>This document updates RFC 2711. </t> </abstract>
</front>
</abstract> <middle>
</front> <section numbered="true" toc="default">
<name>Introduction</name>
<middle> <t>In IPv6 <xref target="RFC8200" format="default"></xref>, optional inter
<section title="Introduction"> net-layer
<t>In <xref target="RFC8200">IPv6</xref>, optional internet-layer
information is encoded in separate headers that may be placed information is encoded in separate headers that may be placed
between the IPv6 header and the upper-layer header in a packet. between the IPv6 header and the upper-layer header in a packet.
There is a small number of such extension headers, each one There is a small number of such extension headers, each one
identified by a distinct Next Header value.</t> identified by a distinct Next Header value.</t>
<t>One of these extension headers is called the Hop-by-Hop Options
<t>One of these extension headers is called the Hop-by-Hop Options
header. The Hop-by-Hop Options header is used to carry optional header. The Hop-by-Hop Options header is used to carry optional
information that may be examined and processed by every node along information that may be examined and processed by every node along
a packet's delivery path.</t> a packet's delivery path.</t>
<t>The Hop-by-Hop Options header can carry one or more options.
<t>The Hop-by-Hop Options header can carry one or more options. Among these is the Router Alert Option <xref target="RFC2711" format="defa
Among these is the <xref target="RFC2711">Router Alert Option ult"></xref>.
</xref>.</t> </t>
<t>The Router Alert Option provides a mechanism whereby
<t>The Router Alert Option provides a mechanism whereby
routers can know when to intercept datagrams not addressed to routers can know when to intercept datagrams not addressed to
them without having to extensively examine every datagram. them without having to extensively examine every datagram.
The semantic of the Router Alert Option is, "routers should The semantic of the Router Alert Option is that "routers should
examine this datagram more closely". Excluding this option examine this datagram more closely". Excluding this option
tells the router that there is no need to examine this datagram tells the router that there is no need to examine this datagram
more closely.</t> more closely.</t>
<t>As explained below, the Router Alert Option introduces many issues.</t>
<t>As explained below, the Router Alert Option introduces many issues.</t> <t>This document updates <xref target="RFC2711" format="default"/>.
Implementers of protocols that continue to use the Router Alert
<t>This document updates <xref target="RFC2711"/>.</t> Option can continue to reference <xref target="RFC2711" format="default"/>
for Router
<t>Implementers of protocols that continue to use the Router
Option can continue to reference <xref target="RFC2711"/> for Router
Alert Option details. </t> Alert Option details. </t>
</section>
<section anchor="ReqLang" numbered="true" toc="default">
<name>Requirements Language</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</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 "<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>
</section>
<section numbered="true" toc="default">
<name>Issues Associated with the IPv6 Router Alert Option</name>
<!-- [rfced] May we update "between IP Router Alert packets of interest and
unwanted IP Router Alerts" as follows to improve readability?
</section> Original:
In a nutshell, the IP Router Alert Option does
not provide a universal mechanism to accurately and reliably
distinguish between IP Router Alert packets of interest and unwanted
IP Router Alerts.
<section anchor="ReqLang" title="Requirements Language"> Perhaps:
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", In a nutshell, the IP Router Alert Option does
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", not provide a universal mechanism to accurately and reliably
"MAY", and "OPTIONAL" in this document are to be interpreted as distinguish between IP Router Alert packets that are of interest
described in <xref target="RFC2119">BCP 14</xref> and those that are unwanted.
<xref target="RFC8174"/> when, and only when, they appear in all -->
capitals, as shown here.</t>
</section>
<section title= "Issues Associated With The IPv6 Router Alert Option"> <t><xref target="RFC6398" format="default"/> identifies security considera
<t><xref target="RFC6398"/> identifies security considerations tions
associated with the Router Alert Option. In a nutshell, associated with the Router Alert Option. In a nutshell,
the IP Router Alert Option does not provide a the IP Router Alert Option does not provide a
universal mechanism to accurately and reliably distinguish universal mechanism to accurately and reliably distinguish
between IP Router Alert packets of interest and unwanted IP Router between IP Router Alert packets of interest and unwanted IP Router
Alerts. This creates a security concern, because, short of Alerts. This creates a security concern because, short of
appropriate router-implementation-specific mechanisms, the router's appropriate router-implementation-specific mechanisms, the router's
control plane is at risk of being flooded by unwanted traffic.</t> control plane is at risk of being flooded by unwanted traffic.</t>
<t>NOTE: Many routers maintain separation between forwarding
<t>NOTE: Many routers maintain separation between forwarding
and control plane hardware. The forwarding plane is implemented and control plane hardware. The forwarding plane is implemented
on high-performance Application Specific Integrated Circuits (ASIC) on high-performance Application-Specific Integrated Circuits (ASICs)
and Network Processors (NP), while the control plane is implemented and Network Processors (NPs), while the control plane is implemented
on general-purpose processors. Given this difference, the control on general-purpose processors. Given this difference, the control
plane is more susceptible to a Denial-of-Service (DoS) attack than the plane is more susceptible to a Denial-of-Service (DoS) attack than the
forwarding plane.</t> forwarding plane.</t>
<t><xref target="RFC6192"/> demonstrates how a network operator can <t><xref target="RFC6192" format="default"/> demonstrates how a network oper
deploy Access Control Lists (ACL) that protect the control plane from ator can
DoS attack. These ACLs are effective and efficient when they select deploy Access Control Lists (ACLs) that protect the control plane from
DoS attacks. These ACLs are effective and efficient when they select
packets based upon information that can be found in a fixed position. packets based upon information that can be found in a fixed position.
However, they become less effective and less efficient when they However, they become less effective and less efficient when they
must parse an IPv6 Hop-by-Hop Options header, searching for the must parse an IPv6 Hop-by-Hop Options header, searching for the
Router Alert Option.</t> Router Alert Option.</t>
<t>Network operators can address the security considerations
<t>So, network operators can address the security considerations raised in <xref target="RFC6398" format="default"/> by:</t>
raised in <xref target="RFC6398"/> by:</t> <ul spacing="normal">
<li>
<t><list style="symbols"> <t>Deploying the operationally complex and computationally
<t>Deploying the operationally complex and computationally expensive ACLs described in <xref target="RFC6192" format="default"/>.</t>
expensive ACLs described in <xref target="RFC6192"/>.</t> </li>
<t>Configuring their routers to ignore the Router <li>
<t>Configuring their routers to ignore the Router
Alert Option.</t> Alert Option.</t>
<t>Dropping or severely rate limiting packets that contain the </li>
IPv6 Hop-by-hop Options header at the network edge.</t> <li>
</list></t> <t>Dropping or severely rate limiting packets that contain the
IPv6 Hop-by-Hop Options header at the network edge.</t>
<t>These options become less viable as protocol designers continue </li>
</ul>
<t>These options become less viable as protocol designers continue
to design protocols that use the Router Alert Option.</t> to design protocols that use the Router Alert Option.</t>
<t><xref target="RFC9673"></xref> seeks to eliminate Hop-by-Hop <t><xref target="RFC9673" format="default"/> seeks to eliminate hop-by-hop
processing on the control plane. However, because of its unique processing on the control plane. However, because of its unique
function, the Router Alert option is granted an exception to this rule. function, the Router Alert option is granted an exception to this rule.
One approach would be to deprecate the Router Alert option, because One approach would be to deprecate the Router Alert option, because
current usage beyond the local network appears to be limited, current usage beyond the local network appears to be limited
and packets containing Hop-by-Hop options are frequently dropped. and packets containing Hop-by-Hop options are frequently dropped.
Deprecation would allow current implementations to continue using it, Deprecation would allow current implementations to continue using it,
but its use could be phased out over time.</t> but its use could be phased out over time.</t>
</section> </section>
<section numbered="true" toc="default">
<section title= "Deprecate The IPv6 Router Alert Option"> <name>Deprecation of the IPv6 Router Alert Option</name>
<t>This document deprecates the IPv6 Router Alert Option. <!-- [rfced] Please confirm that "may" in last sentence is correct. Or does it
Protocols that use the Router Alert Option MAY continue to do so, need to be "MAY" to correspond with "MAY" in the first sentence?
even in future versions. However, new protocols that are standardized
in the future MUST NOT use the Router Alert Option.
<xref target="Legacy"/> contains an exhaustive list of protocols that may
continue to use the Router Alert Option. </t>
<t>This document updates <xref target="RFC2711"/>.</t> Original:
Protocols
that use the Router Alert Option MAY continue to do so, even in
future versions. However, new protocols that are standardized in the
future MUST NOT use the Router Alert Option. Appendix A contains an
exhaustive list of protocols that may continue to use the Router
Alert Option.
</section> Perhaps:
Protocols
that use the Router Alert Option MAY continue to do so, even in
future versions. However, new protocols that are standardized in the
future MUST NOT use the Router Alert Option. Appendix A contains an
exhaustive list of protocols that MAY continue to use the Router
Alert Option.
-->
<section title="Future Work"> <t>This document deprecates the IPv6 Router Alert Option.
Protocols that use the Router Alert Option <bcp14>MAY</bcp14> continue to do
so,
even in future versions. However, new protocols that are standardized
in the future <bcp14>MUST NOT</bcp14> use the Router Alert Option.
<xref target="Legacy" format="default"/> contains an exhaustive list of prot
ocols that may
continue to use the Router Alert Option. </t>
<t> <t>This document updates <xref target="RFC2711" format="default"/>.</t>
As listed in <xref target="Legacy"/>, there are a number of protocols </section>
that use the Router Alert option. The only protocols in <section numbered="true" toc="default">
the Appendix that have wide spread deployment are <name>Future Work</name>
<xref target="RFC3810">Multicast Listener Discovery Version 2 (MLDv2) </xref> <t>
A number of protocols
use the Router Alert option; these are listed in <xref target="Legacy" format="d
efault"/>. The only protocols in
<xref target="Legacy" format="default"/> that have widespread deployment are
Multicast Listener Discovery Version 2 (MLDv2) <xref target="RFC3810" format="de
fault"></xref>
and and
<xref target="RFC4286">Multicast Router Discovery (MRD) </xref>. Multicast Router Discovery (MRD) <xref target="RFC4286" format="default"></xref
The other protocols have either limited deployment, are Experimental, or have no >.
known implementation. The other protocols either have limited deployment, are experimental, or have no
known implementation.
</t> </t>
<t> <t>
It is left for future work to develop new versions of MLDv2 and MRD that do not It is left for future work to develop new versions of MLDv2 and MRD that do not
rely on the Router Alert option. That task is out of scope for this document. rely on the Router Alert option. That task is out of scope for this document.
</t> </t>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t>This document mitigates all security considerations associated with the I <t>This document mitigates all security considerations associated with the
Pv6 Router Alert IPv6 Router Alert
Option. These security considerations can be found in <xref target="RFC2711" Option. These security considerations can be found in <xref target="RFC2711"
></xref>, format="default"/>,
<xref target="RFC6192"></xref> and <xref target="RFC6398"></xref>.</t> <xref target="RFC6192" format="default"/>, and <xref target="RFC6398" format
</section> ="default"/>.</t>
</section>
<section title="IANA Considerations"> <section numbered="true" toc="default">
<t>IANA is requested to mark the Router Alert Option as "Deprecated for New <name>IANA Considerations</name>
Protocols" in the Destination <t>IANA has marked the Router Alert Option as "DEPRECATED for New Protocol
Options and Hop-by-hop Options Registry (https://www.iana.org/assignments/ip s" in the <eref brackets="angle" target="https://www.iana.org/assignments/ipv6-p
v6-parameters/ipv6-parameters.xhtml#ipv6-parameters-2) arameters">"Destination
and add a pointer to this document.</t> Options and Hop-by-Hop Options" registry</eref>
<t> and added this document as a reference.</t>
IANA is also requested to make a note in the IPv6 Router Alert Option Values <t>
Registry IANA has also made a note in the
(https://www.iana.org/assignments/ipv6-routeralert-values/ipv6-routeralert-v <eref brackets ="angle" target="https://www.iana.org/assignments/ipv6-router
alues.xhtml?) alert-values">"IPv6 Router Alert Option Values" registry</eref> stating that the
stating that this registry is closed for allocations along with a reference registry
to this document. is closed for allocations and added a reference to this document.
Please change all experimental codepoints in this registry as "reserved" (i. The experimental codepoints in this registry have been changed to "Reserved"
e., they are no longer (i.e., they are no longer
available for experimentation). available for experimentation).
</t> </t>
</section> </section>
</middle>
<section title="Acknowledgements">
<t>Thanks to Zafar Ali, Brian Carpenter, Toerless Eckert, David Farmer,
Adrian Farrel, Bob Hinden and Jen Linkova for their reviews of this document
.</t>
</section>
</middle>
<back> <back>
<references title="Normative References"> <references>
<?rfc include="reference.RFC.2711"?> <name>References</name>
<references>
<?rfc include="reference.RFC.6398"?>
<?rfc include="reference.RFC.2119"?>
<?rfc include='reference.RFC.8174'?>
<?rfc include='reference.RFC.8200'?>
<?rfc include='reference.RFC.9673'?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.6192"?>
<?rfc include='reference.RFC.1633"?>
<?rfc include='reference.RFC.3810'?>
<?rfc include='reference.RFC.3031'?>
<?rfc include='reference.RFC.4286'?>
<?rfc include='reference.RFC.5946'?>
<?rfc include='reference.RFC.5979'?>
<?rfc include='reference.RFC.6016'?>
<?rfc include='reference.RFC.8029'?>
<?rfc include='reference.RFC.5971'?>
<?rfc include='reference.RFC.6401'?>
<?rfc include='reference.RFC.3175'?>
<?rfc include='reference.RFC.4080'?>
<?rfc include='reference.RFC.7506'?>
<?rfc include='reference.RFC.3208'?> <!-- [rfced] Informative reference RFC 3810 has been obsoleted by
RFC 9777. We recommend replacing RFC 3810 with RFC 9777. However, if RFC
3810 must be referenced, we suggest mentioning RFC 9777 (e.g., RFC 3810 has
been obsoleted by RFC 9777). See Section 4.8.6 in the RFC Style Guide (RFC 7322)
.
-->
<?rfc include='reference.RFC.9570'?> <name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
711.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
398.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
200.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
673.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
192.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
633.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
810.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
031.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
286.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
946.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
979.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
016.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
029.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
971.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
401.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
175.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
080.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
506.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
208.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
570.xml"/>
</references>
</references> </references>
<section anchor="Legacy" numbered="true" toc="default">
<section anchor="Legacy" title="Protocols That Use The Router Alert Optio <name>Protocols That Use the Router Alert Option</name>
n"> <t><xref target="Depend" format="default"/> contains an exhaustive list of
<t><xref target="Depend"/> contains an exhaustive list of protocols that us protocols that use the
e the
IPv6 Router Alert Option. There are no known IPv6 implementations of IPv6 Router Alert Option. There are no known IPv6 implementations of
MPLS PING. Neither INTSERV nor NSIS are widely deployed. All NSIS MPLS Ping. Neither Integrated Services (INTSERV) nor Next Steps in Signali
protocols are EXPERIMENTAL. Pragmatic Generic Multicast (PGM) is ng (NSIS) are widely deployed. All NSIS
EXPERIMENTAL and there are no known IPv6 implementations.</t> protocols are experimental. Pragmatic Generic Multicast (PGM) is
experimental, and there are no known IPv6 implementations.</t>
<texttable anchor="Depend" style="full"
title="Protocols That Use The IPv6 Router Alert Option">
<ttcol>Protocol</ttcol>
<ttcol>References</ttcol>
<ttcol>Application</ttcol>
<c>Multicast Listener Discovery Version 2 (MLDv2)</c>
<c><xref target="RFC3810"/></c>
<c>IPv6 Multicast</c>
<c/>
<c/>
<c/>
<c>Multicast Router Discovery (MRD)</c>
<c><xref target="RFC4286"/></c>
<c>IPv6 Multicast</c>
<c/>
<c/>
<c/>
<c>Pragmatic General Multicast (PGM)</c> <!-- [rfced] Should "router alert" in this text in Table 1 be updated to
"Router Alert Option"?
<c><xref target="RFC3208"/></c> Original:
MPLS PING (Use of router alert deprecated)
<c>IPv6 Multicast</c> Perhaps:
MPLS Ping (Use of Router Alert Option is deprecated)
-->
<c/> <table anchor="Depend" align="center">
<name>Protocols That Use the IPv6 Router Alert Option</name>
<thead>
<tr>
<th align="left">Protocol</th>
<th align="left">References</th>
<th align="left">Application</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">Multicast Listener Discovery Version 2 (MLDv2)</td>
<td align="left"><xref target="RFC3810" format="default"/></td>
<td align="left">IPv6 Multicast</td>
</tr>
<tr>
<td align="left">Multicast Router Discovery (MRD)</td>
<td align="left"><xref target="RFC4286" format="default"/></td>
<td align="left">IPv6 Multicast</td>
</tr>
<tr>
<td align="left">Pragmatic General Multicast (PGM)</td>
<td align="left"><xref target="RFC3208" format="default"/></td>
<td align="left">IPv6 Multicast</td>
</tr>
<tr>
<td align="left">MPLS Ping (Use of router alert deprecated)</td>
<td align="left"><xref target="RFC7506" format="default"/><xref targ
et="RFC8029" format="default"/><xref target="RFC9570" format="default"/></td>
<td align="left">MPLS Operations, Administration, and Maintenance (O
AM)</td>
</tr>
<tr>
<td align="left">Resource Reservation Protocol (RSVP): Both IPv4 and
IPv6 implementations</td>
<td align="left"><xref target="RFC3175" format="default"/> <xref tar
get="RFC5946" format="default"/> <xref target="RFC6016" format="default"/> <xref
target="RFC6401" format="default"/></td>
<td align="left">Integrated Services (INTSERV) <xref target="RFC1633
"
format="default"></xref> and Multiprotocol Label Switching
(MPLS) <xref
target="RFC3031" format="default"></xref></td>
</tr>
<tr>
<td align="left">Next Steps in Signaling (NSIS)</td>
<td align="left"><xref target="RFC5979" format="default"/> <xref tar
get="RFC5971" format="default"/></td>
<td align="left">NSIS <xref target="RFC4080" format="default"></xref
></td>
</tr>
</tbody>
</table>
</section>
<section numbered="false" toc="default">
<name>Acknowledgements</name>
<t>Thanks to <contact fullname="Zafar Ali"/>, <contact fullname="Brian
Carpenter"/>, <contact fullname="Toerless Eckert"/>, <contact
fullname="David Farmer"/>, <contact fullname="Adrian Farrel"/>, <contact
fullname="Bob Hinden"/>, and <contact fullname="Jen Linkova"/> for their
reviews of this document.</t>
</section>
</back>
<c/> <!-- [rfced] Please review whether the note in Section 3
should be in the <aside> element. It is defined as "a container for
content that is semantically less important or tangential to the
content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside)
.
<c/> Original:
NOTE: Many routers maintain separation between forwarding and control
plane hardware. The forwarding plane is implemented on high-
performance Application Specific Integrated Circuits (ASIC) and
Network Processors (NP), while the control plane is implemented on
general-purpose processors. Given this difference, the control plane
is more susceptible to a Denial-of-Service (DoS) attack than the
forwarding plane.
-->
<c>MPLS PING (Use of router alert deprecated)</c> <!-- [rfced] Terminology
<c><xref target="RFC7506"/><xref target="RFC8029"/><xref target="RFC9570 a) We note inconsistencies in the terms listed below. We chose the latter form
"/></c> (i.e., capitalized "Option"). Please let us know if you prefer
differently.
<c>MPLS OAM</c> Router Alert option
Router Alert Option
Note: The capitalized "Option" is used in RFCs 6398, 7506, and 9673 (and is
more common in this document), and the lowercase "option" is used in RFCs 850
4
and 9288.
<c/> b) We see the following forms used in the document. Are any updates needed, or
are these okay as is?
<c/> Router Alert Option
IP Router Alert Option
IPv6 Router Alert Option
<c/> Hop-by-Hop Options header
IPv6 Hop-by-Hop Options header
<c>Resource Reservation Protocol (RSVP): Both IPv4 and IPv6 implementati ons</c> c) Should "Hop-by-Hop options" here be updated to "Hop-by-Hop Options header"?
<c><xref target="RFC3175"/> <xref target="RFC5946"/> <xref Original:
target="RFC6016"/> <xref target="RFC6401"/></c> One approach would be
to deprecate the Router Alert option, because current usage beyond
the local network appears to be limited, and packets containing Hop-
by-Hop options are frequently dropped.
<c><xref target="RFC1633">Integrated Services (INTSERV) </xref> Perhaps:
and One approach would be
<xref target="RFC3031">Multiprotocol Label Switching (MPLS)</xref></c> to deprecate the Router Alert Option, because current usage beyond
the local network appears to be limited and packets containing the Hop-
by-Hop Options header are frequently dropped.
<c/> d) We updated "PING" to "Ping" per usage in RFCs 7506, 8029, and 9570.
<c/> e) May we update "INTSERV" to either "Intserv" (RFCs 9522, 9064, and 7417) or
"IntServ" (RFCs 9049 and 6007), both of which are more common in the RFC
Series?
-->
<c/> <!-- [rfced] FYI - We have added expansions for the following abbreviation(s)
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
<c>Next Steps In Signaling (NSIS)</c> Operations, Administration, and Maintenance (OAM)
-->
<c><xref target="RFC5979"/> <xref target="RFC5971"/></c> <!-- [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. Updates of this nature typically
result in more precise language, which is helpful for readers.
<c><xref target="RFC4080">NSIS </xref></c> Note that our script did not flag any words in particular, but this should
</texttable> still be reviewed as a best practice.
</section> -->
</back>
</rfc> </rfc>
 End of changes. 58 change blocks. 
262 lines changed or deleted 373 lines changed or added

This html diff was produced by rfcdiff 1.48.