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
Protocols that use the Router Alert Option may continue to do so, 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 IPv6 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 IPv6 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 IPv6 Router Alert option <xref target="RFC2711" format=
Among these is the <xref target="RFC2711">Router Alert Option "default"></xref>.
</xref>.</t> </t>
<t>The IPv6 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 IPv6 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 IPv6 Router Alert option introduces many issues
<t>As explained below, the Router Alert Option introduces many issues.</t> .</t>
<t>This document updates <xref target="RFC2711" format="default"/>.
<t>This document updates <xref target="RFC2711"/>.</t> Implementers of protocols that continue to use the IPv6 Router Alert
option can continue to reference <xref target="RFC2711" format="default"/>
<t>Implementers of protocols that continue to use the Router for IPv6 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">
</section> <name>Requirements Language</name>
<t>
<section anchor="ReqLang" title="Requirements Language"> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
"MAY", and "OPTIONAL" in this document are to be interpreted as RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
described in <xref target="RFC2119">BCP 14</xref> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
<xref target="RFC8174"/> when, and only when, they appear in all be interpreted as
capitals, as shown here.</t> described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
</section> when, and only when, they appear in all capitals, as shown here.
</t>
<section title= "Issues Associated With The IPv6 Router Alert Option"> </section>
<t><xref target="RFC6398"/> identifies security considerations <section numbered="true" toc="default">
associated with the Router Alert Option. In a nutshell, <name>Issues Associated with the IPv6 Router Alert Option</name>
<t><xref target="RFC6398" format="default"/> identifies security considera
tions
associated with the IPv6 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>
<aside>
<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>
</aside>
<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 a Hop-by-Hop Options header, searching for the
Router Alert Option.</t> IPv6 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>
Alert Option.</t> <t>Configuring their routers to ignore the IPv6 Router
<t>Dropping or severely rate limiting packets that contain the Alert option.</t>
IPv6 Hop-by-hop Options header at the network edge.</t> </li>
</list></t> <li>
<t>Dropping or severely rate limiting packets that contain the
<t>These options become less viable as protocol designers continue Hop-by-Hop Options header at the network edge.</t>
to design protocols that use the Router Alert Option.</t> </li>
</ul>
<t>These options become less viable as protocol designers continue
to design protocols that use the IPv6 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 IPv6 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 IPv6 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. <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 IPv6 Router Alert option <bcp14>MAY</bcp14> 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. in the future <bcp14>MUST NOT</bcp14> use the IPv6 Router Alert option.
<xref target="Legacy"/> contains an exhaustive list of protocols that may <xref target="Legacy" format="default"/> contains an exhaustive list of prot
continue to use the Router Alert Option. </t> ocols that <bcp14>MAY</bcp14>
continue to use the IPv6 Router Alert option. </t>
<t>This document updates <xref target="RFC2711"/>.</t>
</section>
<section title="Future Work">
<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 IPv6 Router Alert option; these are listed in <xref target="Legacy" form
at="default"/>. The only protocols in
<xref target="Legacy" format="default"/> that have widespread deployment are
Multicast Listener Discovery Version 2 (MLDv2) <xref target="RFC9777" 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 IPv6 Router Alert option. That task is out of scope for this docum ent.
</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 IPv6 Router Alert option as "DEPRECATED for New Pro
Options and Hop-by-hop Options Registry (https://www.iana.org/assignments/ip tocols" in the <eref brackets="angle" target="https://www.iana.org/assignments/i
v6-parameters/ipv6-parameters.xhtml#ipv6-parameters-2) pv6-parameters">"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'?>
<?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.9
777.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">
<name>Protocols That Use the IPv6 Router Alert Option</name>
<t><xref target="Depend" format="default"/> contains an exhaustive list of
protocols that use the
IPv6 Router Alert option. There are no known IPv6 implementations of
MPLS Ping. Neither Integrated Services (Intserv) nor Next Steps in Signali
ng (NSIS) are widely deployed. All NSIS
protocols are experimental. Pragmatic Generic Multicast (PGM) is
experimental, and there are no known IPv6 implementations.</t>
<section anchor="Legacy" title="Protocols That Use The Router Alert Optio <table anchor="Depend" align="center">
n"> <name>Protocols That Use the IPv6 Router Alert Option</name>
<t><xref target="Depend"/> contains an exhaustive list of protocols that us <thead>
e the <tr>
IPv6 Router Alert Option. There are no known IPv6 implementations of <th align="left">Protocol</th>
MPLS PING. Neither INTSERV nor NSIS are widely deployed. All NSIS <th align="left">References</th>
protocols are EXPERIMENTAL. Pragmatic Generic Multicast (PGM) is <th align="left">Application</th>
EXPERIMENTAL and there are no known IPv6 implementations.</t> </tr>
</thead>
<texttable anchor="Depend" style="full" <tbody>
title="Protocols That Use The IPv6 Router Alert Option"> <tr>
<ttcol>Protocol</ttcol> <td align="left">Multicast Listener Discovery Version 2 (MLDv2)</td>
<td align="left"><xref target="RFC9777" format="default"/></td>
<ttcol>References</ttcol> <td align="left">IPv6 Multicast</td>
</tr>
<ttcol>Application</ttcol> <tr>
<td align="left">Multicast Router Discovery (MRD)</td>
<c>Multicast Listener Discovery Version 2 (MLDv2)</c> <td align="left"><xref target="RFC4286" format="default"/></td>
<td align="left">IPv6 Multicast</td>
<c><xref target="RFC3810"/></c> </tr>
<tr>
<c>IPv6 Multicast</c> <td align="left">Pragmatic General Multicast (PGM)</td>
<td align="left"><xref target="RFC3208" format="default"/></td>
<c/> <td align="left">IPv6 Multicast</td>
</tr>
<c/> <tr>
<td align="left">MPLS Ping (Use of the IPv6 Router Alert option is d
<c/> eprecated)</td>
<td align="left"><xref target="RFC7506" format="default"/><xref targ
<c>Multicast Router Discovery (MRD)</c> et="RFC8029" format="default"/><xref target="RFC9570" format="default"/></td>
<td align="left">MPLS Operations, Administration, and Maintenance (O
<c><xref target="RFC4286"/></c> AM)</td>
</tr>
<c>IPv6 Multicast</c> <tr>
<td align="left">Resource Reservation Protocol (RSVP): Both IPv4 and
<c/> IPv6 implementations</td>
<td align="left"><xref target="RFC3175" format="default"/> <xref tar
<c/> get="RFC5946" format="default"/> <xref target="RFC6016" format="default"/> <xref
target="RFC6401" format="default"/></td>
<c/> <td align="left">Integrated Services (Intserv) <xref target="RFC1633
"
<c>Pragmatic General Multicast (PGM)</c> format="default"></xref> and Multiprotocol Label Switching
(MPLS) <xref
<c><xref target="RFC3208"/></c> target="RFC3031" format="default"></xref></td>
</tr>
<c>IPv6 Multicast</c> <tr>
<td align="left">Next Steps in Signaling (NSIS)</td>
<c/> <td align="left"><xref target="RFC5979" format="default"/> <xref tar
get="RFC5971" format="default"/></td>
<c/> <td align="left">NSIS <xref target="RFC4080" format="default"></xref
></td>
<c/> </tr>
</tbody>
<c>MPLS PING (Use of router alert deprecated)</c> </table>
<c><xref target="RFC7506"/><xref target="RFC8029"/><xref target="RFC9570
"/></c>
<c>MPLS OAM</c>
<c/>
<c/>
<c/>
<c>Resource Reservation Protocol (RSVP): Both IPv4 and IPv6 implementati
ons</c>
<c><xref target="RFC3175"/> <xref target="RFC5946"/> <xref
target="RFC6016"/> <xref target="RFC6401"/></c>
<c><xref target="RFC1633">Integrated Services (INTSERV) </xref>
and
<xref target="RFC3031">Multiprotocol Label Switching (MPLS)</xref></c>
<c/>
<c/>
<c/>
<c>Next Steps In Signaling (NSIS)</c>
<c><xref target="RFC5979"/> <xref target="RFC5971"/></c>
<c><xref target="RFC4080">NSIS </xref></c>
</texttable>
</section> </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>
</back>
</rfc> </rfc>
 End of changes. 31 change blocks. 
300 lines changed or deleted 284 lines changed or added

This html diff was produced by rfcdiff 1.48.