<?xml version="1.0" encoding="US-ASCII"?> 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"?> [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-6man-deprecate-router-alert-13" number="9805" consensus="true" ipr="trust200902" updates="2711"> updates="2711" obsoletes="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3">

  <front>
    <title abbrev="Deprecate IPv6 Router Alert For for New Protocols">
  Deprecation Of The Protocols">Deprecation of the IPv6 Router Alert Option For for New Protocols
  </title> Protocols</title>
    <seriesInfo name="RFC" value="9805"/>
    <author fullname="Ron Bonica" initials="R." surname="Bonica">
      <organization>Juniper Networks</organization>
      <address>
        <postal>
        <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>rbonica@juniper.net</email>
      </address>
    </author>
    <date day="29" month="April" month="June" year="2025"/>
  <area>INT Area</area>
    <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,
    even in future versions. However, new protocols that are standardized
    in the future must not use the Router Alert Option.</t>
      <t>This document updates RFC 2711. </t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>In IPv6 <xref target="RFC8200">IPv6</xref>, target="RFC8200" format="default"></xref>, optional internet-layer
    information is encoded in separate headers that may be placed
    between the IPv6 header and the upper-layer header in a packet.
    There is a small number of such extension headers, each one
    identified by a distinct Next Header value.</t>
      <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
    information that may be examined and processed by every node along
    a packet's delivery path.</t>
      <t>The Hop-by-Hop Options header can carry one or more options.
      Among these is the <xref target="RFC2711">Router Router Alert Option
    </xref>.</t> <xref target="RFC2711" format="default"></xref>.
      </t>
      <t>The Router Alert Option provides a mechanism whereby
    routers can know when to intercept datagrams not addressed to
    them without having to extensively examine every datagram.
    The semantic of the Router Alert Option is, is that "routers should
    examine this datagram more closely". Excluding this option
    tells the router that there is no need to examine this datagram
    more closely.</t>
      <t>As explained below, the Router Alert Option introduces many issues.</t>
      <t>This document updates <xref target="RFC2711"/>.</t>

    <t>Implementers target="RFC2711" format="default"/>.
      Implementers of protocols that continue to use the Router Alert
     Option can continue to reference  <xref target="RFC2711"/> target="RFC2711" format="default"/> for Router
     Alert Option details. </t>
    </section>
    <section anchor="ReqLang" title="Requirements Language">
    <t>The 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&nbsp;14 <xref target="RFC2119">BCP 14</xref> target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
    </section>
    <section title= "Issues numbered="true" toc="default">
      <name>Issues Associated With The with the IPv6 Router Alert Option"> Option</name>
<!-- [rfced] May we update "between IP Router Alert packets of interest and
unwanted IP Router Alerts" as follows to improve readability?

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.

Perhaps:
   In a nutshell, the IP Router Alert Option does
   not provide a universal mechanism to accurately and reliably
   distinguish between IP Router Alert packets that are of interest
   and those that are unwanted.
-->

      <t><xref target="RFC6398"/> target="RFC6398" format="default"/> identifies security considerations
    associated with the Router Alert Option. 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.  This creates a security concern, concern because, short of
    appropriate router-implementation-specific mechanisms, the router's
    control plane is at risk of being flooded by unwanted traffic.</t>
      <t>NOTE: Many routers maintain separation between forwarding
    and control plane hardware. The forwarding plane is implemented
    on high-performance Application Specific Application-Specific Integrated Circuits (ASIC) (ASICs)
    and Network Processors (NP), (NPs), 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.</t>

    <t><xref target="RFC6192"/> target="RFC6192" format="default"/> demonstrates how a network operator can
    deploy Access Control Lists (ACL) (ACLs) that protect the control plane from
    DoS attack. attacks. These ACLs are effective and efficient when they select
    packets based upon information that can be found in a fixed position.
    However, they become less effective and less efficient when they
    must parse an IPv6 Hop-by-Hop Options header, searching for the
    Router Alert Option.</t>

    <t>So, network
      <t>Network operators can address the security considerations
    raised in <xref target="RFC6398"/> target="RFC6398" format="default"/> by:</t>

    <t><list style="symbols">
      <ul spacing="normal">
        <li>
          <t>Deploying the operationally complex and computationally
      expensive ACLs described in <xref target="RFC6192"/>.</t> target="RFC6192" format="default"/>.</t>
        </li>
        <li>
          <t>Configuring their routers to ignore the Router
      Alert Option.</t>
        </li>
        <li>
          <t>Dropping or severely rate limiting packets that contain the
      IPv6 Hop-by-hop Hop-by-Hop Options header at the network edge.</t>
    </list></t>
        </li>
      </ul>
      <t>These options become less viable as protocol designers continue
    to design protocols that use the Router Alert Option.</t>

    <t><xref target="RFC9673"></xref> target="RFC9673" format="default"/> seeks to eliminate Hop-by-Hop hop-by-hop
    processing on the control plane. However, because of its unique
    function, the Router Alert option is granted an exception to this rule.
    One approach would be to deprecate the Router Alert option, because
    current usage beyond the local network appears to be limited, limited
    and packets containing Hop-by-Hop options are frequently dropped.
    Deprecation would allow current implementations to continue using it,
    but its use could be phased out over time.</t>
    </section>
    <section title= "Deprecate The numbered="true" toc="default">
      <name>Deprecation of the IPv6 Router Alert Option"> Option</name>
<!-- [rfced] Please confirm that "may" in last sentence is correct. Or does it
need to be "MAY" to correspond with "MAY" in the first sentence?

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.

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.
-->

      <t>This document deprecates the IPv6 Router Alert Option.
    Protocols that use the Router Alert Option MAY <bcp14>MAY</bcp14> continue to do so,
    even in future versions. However, new protocols that are standardized
    in the future MUST NOT <bcp14>MUST NOT</bcp14> use the Router Alert Option.
    <xref target="Legacy"/> target="Legacy" format="default"/> contains an exhaustive list of protocols that may
    continue to use the Router Alert Option. </t>

    <t>This document updates <xref target="RFC2711"/>.</t> target="RFC2711" format="default"/>.</t>
    </section>
    <section title="Future Work"> numbered="true" toc="default">
      <name>Future Work</name>
      <t>
As listed in <xref target="Legacy"/>, there are a
A number of protocols
that
use the Router Alert option. option; these are listed in <xref target="Legacy" format="default"/>.    The only protocols in
the Appendix
<xref target="Legacy" format="default"/> that have wide spread widespread deployment  are
<xref target="RFC3810">Multicast
Multicast Listener Discovery Version 2 (MLDv2) </xref>
 and <xref target="RFC4286">Multicast target="RFC3810" format="default"></xref>
 and
 Multicast Router Discovery (MRD) </xref>. <xref target="RFC4286" format="default"></xref>.
The other protocols have either have limited deployment, are Experimental, experimental, or have no known implementation.
</t>
      <t>
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.
</t>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This document mitigates all security considerations associated with the IPv6 Router Alert
    Option. These security considerations can be found in <xref target="RFC2711"></xref>, target="RFC2711" format="default"/>,
    <xref target="RFC6192"></xref> target="RFC6192" format="default"/>, and <xref target="RFC6398"></xref>.</t> target="RFC6398" format="default"/>.</t>
    </section>
    <section title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>IANA is requested to mark has marked the Router Alert Option as "Deprecated "DEPRECATED for New Protocols" in the Destination <eref brackets="angle" target="https://www.iana.org/assignments/ipv6-parameters">"Destination
    Options and Hop-by-hop Options Registry (https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-2) Hop-by-Hop Options" registry</eref>
    and add a pointer to added this document.</t> document as a reference.</t>
      <t>
    IANA is has also requested to make made a note in the IPv6
    <eref brackets ="angle" target="https://www.iana.org/assignments/ipv6-routeralert-values">"IPv6 Router Alert Option Values Registry
    (https://www.iana.org/assignments/ipv6-routeralert-values/ipv6-routeralert-values.xhtml?) Values" registry</eref> stating that this the registry
    is closed for allocations along with and added a reference to this document.
    Please change all
    The experimental codepoints in this registry as "reserved" have been changed to "Reserved" (i.e., they are no longer
    available for experimentation).
      </t>
    </section>

  <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>
    <references title="Normative References">
      <?rfc include="reference.RFC.2711"?>

      <?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>
      <name>References</name>
      <references>

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

        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2711.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6398.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9673.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6192.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1633.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3810.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3031.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4286.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5946.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5979.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6016.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8029.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5971.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6401.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3175.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4080.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7506.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3208.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9570.xml"/>
      </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'?>
    </references>
    <section anchor="Legacy" title="Protocols numbered="true" toc="default">
      <name>Protocols That Use The the Router Alert Option"> Option</name>
      <t><xref target="Depend"/> 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. Ping. Neither INTSERV Integrated Services (INTSERV) nor NSIS Next Steps in Signaling (NSIS) are widely deployed. All NSIS
      protocols are EXPERIMENTAL. experimental. Pragmatic Generic Multicast (PGM) is
      EXPERIMENTAL
      experimental, and there are no known IPv6 implementations.</t>

      <texttable

<!-- [rfced] Should "router alert" in this text in Table 1 be updated to
"Router Alert Option"?

Original:
  MPLS PING (Use of router alert deprecated)

Perhaps:
  MPLS Ping (Use of Router Alert Option is deprecated)
-->

      <table anchor="Depend" style="full"
                 title="Protocols align="center">
        <name>Protocols That Use The the IPv6 Router Alert Option">
        <ttcol>Protocol</ttcol>

        <ttcol>References</ttcol>

        <ttcol>Application</ttcol>

        <c>Multicast 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)</c>

        <c><xref target="RFC3810"/></c>

        <c>IPv6 Multicast</c>

        <c/>

        <c/>

        <c/>

        <c>Multicast (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)</c>

        <c><xref target="RFC4286"/></c>

        <c>IPv6 Multicast</c>

        <c/>

        <c/>

        <c/>

        <c>Pragmatic (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)</c>

        <c><xref target="RFC3208"/></c>

        <c>IPv6 Multicast</c>

        <c/>

        <c/>

        <c/>

        <c>MPLS PING (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)</c>

        <c><xref target="RFC7506"/><xref target="RFC8029"/><xref target="RFC9570"/></c>

        <c>MPLS OAM</c>

        <c/>

        <c/>

        <c/>

        <c>Resource deprecated)</td>
            <td align="left"><xref target="RFC7506" format="default"/><xref target="RFC8029" format="default"/><xref target="RFC9570" format="default"/></td>
            <td align="left">MPLS Operations, Administration, and Maintenance (OAM)</td>
          </tr>
          <tr>
            <td align="left">Resource Reservation Protocol (RSVP): Both IPv4 and IPv6 implementations</c>

        <c><xref target="RFC3175"/> <xref target="RFC5946"/> <xref
        target="RFC6016"/> <xref target="RFC6401"/></c>

        <c><xref target="RFC1633">Integrated implementations</td>
            <td align="left"><xref target="RFC3175" format="default"/> <xref target="RFC5946" format="default"/> <xref target="RFC6016" format="default"/> <xref target="RFC6401" format="default"/></td>
            <td align="left">Integrated Services (INTSERV) </xref>
        and <xref target="RFC3031">Multiprotocol target="RFC1633"
            format="default"></xref> and Multiprotocol Label Switching (MPLS)</xref></c>

        <c/>

        <c/>

        <c/>

        <c>Next
            (MPLS) <xref
            target="RFC3031" format="default"></xref></td>
          </tr>
          <tr>
            <td align="left">Next Steps In in Signaling (NSIS)</c>

        <c><xref target="RFC5979"/> <xref target="RFC5971"/></c>

        <c><xref target="RFC4080">NSIS </xref></c>
      </texttable> (NSIS)</td>
            <td align="left"><xref target="RFC5979" format="default"/> <xref target="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>

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

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.
-->

<!-- [rfced] Terminology

a) We note inconsistencies in the terms listed below. We chose the latter form
(i.e., capitalized "Option"). Please let us know if you prefer
differently.

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 8504
   and 9288.

b) We see the following forms used in the document. Are any updates needed, or
are these okay as is?

Router Alert Option
IP Router Alert Option
IPv6 Router Alert Option

Hop-by-Hop Options header
IPv6 Hop-by-Hop Options header

c) Should "Hop-by-Hop options" here be updated to "Hop-by-Hop Options header"?

Original:
   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.

Perhaps:
   One approach would be
   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.

d) We updated "PING" to "Ping" per usage in RFCs 7506, 8029, and 9570.

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?
-->

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

Operations, Administration, and Maintenance (OAM)
-->

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

Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->

</rfc>