RFC 9805

Deprecation of the IPv6 Router Alert Option for New Protocols

📅 published June 2025, from ietf

RFC 9805: Deprecation of the IPv6 Router Alert Option for New Protocols 💖

Internet Engineering Task Force (IETF). Request for Comments: 9805. Author: R. Bonica, Juniper Networks. Published June 2025 as a Standards Track document (ISSN 2070-1721). This one updates RFC 2711 🦋

Abstract 🌸

Okay, the TL;DR: this doc deprecates the IPv6 Router Alert option. Protocols already using it can keep using it, even in future versions 🫶 But brand-new protocols standardized down the road are not allowed to use it at all 💅 This document also updates RFC 2711.

Status of This Memo ✨

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9805.

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

Table of Contents 📚

1.  Introduction
2.  Requirements Language
3.  Issues Associated with the IPv6 Router Alert Option
4.  Deprecation of the IPv6 Router Alert Option
5.  Future Work
6.  Security Considerations
7.  IANA Considerations
8.  References
  8.1.  Normative References
  8.2.  Informative References
Appendix A.  Protocols That Use the IPv6 Router Alert Option
Acknowledgements
Author's Address

1. Introduction ✨

Okay bestie, so in IPv6 [RFC8200], optional internet-layer info lives in separate headers that can sit between the IPv6 header and the upper-layer header in a packet. There aren't many of these extension headers, and each one is identified by its own distinct Next Header value 🧚

One of them is the Hop-by-Hop Options header. Its whole job is carrying optional info that every single node along a packet's delivery path might need to examine and process 👀

The Hop-by-Hop Options header can carry one or more options, and one of them is the IPv6 Router Alert option [RFC2711].

So the IPv6 Router Alert option is basically how routers can tell when to step in and intercept datagrams that aren't addressed to them, without having to dig through every single datagram. Its meaning is that "routers should examine this datagram more closely". And if the option is left out, the router gets the message that there's no need to look any closer 🙈

As we'll see below, this option causes a lot of issues 💀

This document updates [RFC2711]. If you're an implementer of a protocol that keeps using the IPv6 Router Alert option, you can keep referencing [RFC2711] for the option details 🫶

2. Requirements Language 🎀

Here's the important bit: 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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Lowercase versions are just regular words, no cap 💅

3. Issues Associated with the IPv6 Router Alert Option 🔥

[RFC6398] identifies security considerations associated with the IPv6 Router Alert option. In a nutshell, the IP Router Alert Option doesn't offer a universal way to accurately and reliably tell apart the IP Router Alert packets you actually want from the unwanted ones. That's a real security concern, because unless the router has its own implementation-specific mechanisms, the router's control plane is at risk of getting flooded with unwanted traffic 😭

NOTE: The next block is a note from the original text, copied exactly.
|  NOTE: Many routers maintain separation between forwarding and
|  control plane hardware.  The forwarding plane is implemented on
|  high-performance Application-Specific Integrated Circuits
|  (ASICs) and Network Processors (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.

[RFC6192] shows how a network operator can deploy Access Control Lists (ACLs) that protect the control plane from DoS attacks. These ACLs work well and efficiently when they pick packets based on information sitting in a fixed position. But they get less effective and less efficient when they have to parse a Hop-by-Hop Options header to look for the IPv6 Router Alert option 🥴

So, to address the security considerations raised in [RFC6398], network operators can:

  • Deploy the operationally complex and computationally expensive ACLs described in [RFC6192].
  • Configure their routers to ignore the IPv6 Router Alert option.
  • Drop or severely rate limit packets that contain the Hop-by-Hop Options header at the network edge.

Honestly though, these options get less and less viable as protocol designers keep designing protocols that use the IPv6 Router Alert option 😩

[RFC9673] seeks to eliminate hop-by-hop processing on the control plane. However, because of its unique function, the IPv6 Router Alert option gets an exception to this rule. One approach would be to deprecate the IPv6 Router Alert option, because current usage beyond the local network seems to be limited, and packets containing Hop-by-Hop options are frequently dropped. Deprecation would let current implementations keep using it, but its use could be phased out over time 🦋

4. Deprecation of the IPv6 Router Alert Option 💅

Alright, here's the decision. 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 in the future MUST NOT use the IPv6 Router Alert option. Appendix A contains an exhaustive list of protocols that MAY continue to use the IPv6 Router Alert option 🌈

This document updates [RFC2711].

8.2. Informative References 🦋

okay so these are the references that are just here for context, so you can go read them if you're curious 💅

Appendix A. Protocols That Use the IPv6 Router Alert Option 🌈

Table 1 is the exhaustive list of protocols that use the IPv6 Router Alert option, so this is the one to check if you're wondering who's actually using it 👑 Quick tea: there are no known IPv6 implementations of MPLS Ping 💀. Intserv and NSIS aren't widely deployed either, and all the NSIS protocols are experimental 🧪. PGM is experimental too, and there are no known IPv6 implementations of it.

+=================+=============================+==================+
| Protocol        | References                  | Application      |
+=================+=============================+==================+
| Multicast       | [RFC9777]                   | IPv6 Multicast   |
| Listener        |                             |                  |
| Discovery       |                             |                  |
| Version 2       |                             |                  |
| (MLDv2)         |                             |                  |
+-----------------+-----------------------------+------------------+
| Multicast       | [RFC4286]                   | IPv6 Multicast   |
| Router          |                             |                  |
| Discovery (MRD) |                             |                  |
+-----------------+-----------------------------+------------------+
| Pragmatic       | [RFC3208]                   | IPv6 Multicast   |
| General         |                             |                  |
| Multicast (PGM) |                             |                  |
+-----------------+-----------------------------+------------------+
| MPLS Ping (Use  | [RFC7506][RFC8029][RFC9570] | MPLS Operations, |
| of the IPv6     |                             | Administration,  |
| Router Alert    |                             | and Maintenance  |
| option is       |                             | (OAM)            |
| deprecated)     |                             |                  |
+-----------------+-----------------------------+------------------+
| Resource        | [RFC3175] [RFC5946]         | Integrated       |
| Reservation     | [RFC6016] [RFC6401]         | Services         |
| Protocol        |                             | (Intserv)        |
| (RSVP): Both    |                             | [RFC1633] and    |
| IPv4 and IPv6   |                             | Multiprotocol    |
| implementations |                             | Label Switching  |
|                 |                             | (MPLS) [RFC3031] |
+-----------------+-----------------------------+------------------+
| Next Steps in   | [RFC5979] [RFC5971]         | NSIS [RFC4080]   |
| Signaling       |                             |                  |
| (NSIS)          |                             |                  |
+-----------------+-----------------------------+------------------+

      Table 1: Protocols That Use the IPv6 Router Alert Option

Acknowledgements 🫶

Huge thanks to Zafar Ali, Brian Carpenter, Toerless Eckert, David Farmer, Adrian Farrel, Bob Hinden, and Jen Linkova for reviewing this document 💖

Author's Address 🍓

Ron Bonica
Juniper Networks
United States of America
Email: rbonica@juniper.net
📦 where this page comes from