<?xml version="1.0" encoding="US-ASCII"?>
<!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-02"
     ipr="trust200902" obsoletes="RFC 2711">
     
<front>
  <title abbrev="Deprecate IPv6 Router Alert">
  Deprecation Of The IPv6 Router Alert Option
  </title>

  <author fullname="Ron Bonica" initials="R." surname="Bonica">
    <organization>Juniper Networks</organization>
    <address>
      <postal>
        <country>USA</country>
      </postal>
      <email>rbonica@juniper.net</email>
    </address>
  </author>

  <date day="5" month="November" year="2024"/>
  <area>INT Area</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, protocols that are standardized 
    in the future must not use the Router Alert Option.</t>

    <t>This document obsoletes RFC 2711.</t>

  </abstract>
</front>

<middle>
  <section title="Introduction">
    <t>In <xref target="RFC8200">IPv6</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 Alert Option
    </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, "routers should 
    examine this datagram more closely". Not including this option 
    tells the router that there is no need to closely examine the 
    contents of the datagram.</t>

    <t><xref target="RFC6398"/> 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, 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 plain 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.</t>

    <t><xref target="RFC6192"/> demonstrates how a network operator can
    deploy Access Control Lists (ACL) that protect the control plane from
    DoS attack. 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 operators can address the security considerations
    raised in RFC 6398 by:</t>

    <t><list style="symbols">
       <t>Deploying the operationally complex and computationally 
      expensive ACLs described in RFC 6192.</t>
      <t>Configuring their routers to ignore the Router
      Alert Option.</t>
      <t>Dropping or severely rate limiting packets that contain the 
      IPv6 Hop-by-hop Options header.</t>
    </list></t>
    
    <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> seeks to eliminate 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, 
    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>
    <t>
    Therefore, 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, protocols that are standardized 
    in the future MUST NOT use the Router Alert Option.
    <xref target="Legacy"/> contains a list of protocols that may 
    continue to use the Router Alert Option.
    </t>

    <t>This document obsoletes RFC 2711.</t>


  </section>

  <section anchor="ReqLang" title="Requirements Language">
    <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 
    "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", 
    "MAY", and "OPTIONAL" in this document are to be interpreted as 
    described in <xref target="RFC2119">BCP 14</xref> 
    <xref target="RFC8174"/> when, and only when, they appear in all 
    capitals, as shown here.</t>
  </section>

  <section title="Alternatives To The Router Alert Option">

    <t>The following is an alternative to the Router Address Option
    for unicast traffic being sent from a source node to an ultimate
    destination node along a delivery path:</t>

    <t><list style="symbols">
      <t>The source node encodes the ultimate destination node's
       address in the message body.</t>
      <t>The source node sets packet's destination address 
      to that of the next node along the delivery path.</t>
      <t>The source node sends the packet to the next node
      along the delivery path.</t>
      <t>The next node along the delivery path processes the packet
      and repeats the process.</t>
    </list></t>

    <t>The following is an alternative to the Router Address Option
    for multicast traffic being sent from a source node to all nodes
    on the directly connected subnetwork:</t>

      <t><list style="symbols">
      <t>The source node encodes the target multicast address
      in the message body.</t>
      <t>The source node sends the packet to a well-known
      multicast address (e.g., All-PROTOCOL-X-ROUTERS).</t>
    </list></t>
    </section>

  <section anchor="Security" title="Security Considerations">
    <t>This document extends the security considerations provided in RFC
    2711, RFC 6192 and RFC 6398.</t>
  </section>

  <section title="IANA Considerations">
    <t>IANA is requested to mark the Router Alert Option as 
    Deprecated in the Destination Options and Hop-by-hop Options 
    Registry (
    https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-2)
    and add a pointer to this document.</t>
    </section>

  <section title="Acknowledgements">
    <t>Thanks to Brian Carpenter, Toerless Eckert, David Farmer, 
    Adrian Farrel, and Bob Hinden 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>

    <references title="Informative References">
      <?rfc include="reference.RFC.6192"?>

      <?rfc include='reference.RFC.1633"?>

      <?rfc include='reference.RFC.3810'?>

      <?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 That Use The Router Alert Option">
     <t><xref target="Depend"/> contains a list of protocols that use the
      IPv6 Router Alert Option. There are no known IPv6 implementations of
      MPLS PING. Neither INTSERV nor NSIS are widely deployed. All NSIS
      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>

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

        <c>IPv6 Multicast</c>

        <c/>

        <c/>

        <c/>

        <c>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 Reservation Protocol (RSVP)</c>

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

        <c><xref target="RFC1633">Integrated Services (INTSERV) </xref> (Not
        Traffic engineering or MPLS signaling)</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>

  </back>
</rfc>
