Summary

  • RFC 9805 prohibits future newly standardized protocols from using the IPv6 Router Alert option and closes the IANA value registry, but it explicitly lets the exhaustive set of existing protocol uses continue.
  • The standards system can stop creating new control-plane exposure. Only local configuration, running-code migration and measured packet behavior can show whether the old exposure has actually declined.

A registry can close in an afternoon. A packet path cannot.

That is the tension inside RFC 9805, published on the IETF Standards Track in June 2025. Its rule is unusually clean. Protocols that already use the IPv6 Router Alert option may continue, even in later versions. A new protocol standardized in the future must not use it. Appendix A defines the complete exception set.

IANA has implemented the administrative half. The IPv6 parameters registry now labels option type 0x05 “Router Alert (DEPRECATED for New Protocols).” The separate Router Alert value registry says “Registry closed.” Its former experimental range is reserved.

None of those lines reaches into a router and changes a forwarding decision. The option number remains. Legacy packets remain valid under the listed protocols. Operators still decide what their equipment will inspect, ignore, rate-limit or drop. RFC 9805 closes the route by which standards could add future demand; it does not cancel the demand already installed.

The design began as an optimization. RFC 2711, published in 1999, observed that a transit router sometimes needs to process control information in a datagram addressed somewhere else. Parsing every packet deeply would be slow. Router Alert put a compact signal in the IPv6 Hop-by-Hop Options header: examine this datagram more closely. Ordinary packets without the option could stay on the fast path.

That arrangement contains a structural bargain. The sender is allowed to request scarce attention from devices it is traversing. The router must do enough work to decide whether the request is meaningful. RFC 2711 already warned that gratuitous use could hurt performance and that bogus marked datagrams could flood a router. It allowed transit routers to limit the traffic by rate or other means.

The vulnerability is not merely that malicious traffic exists. It is that wanted and unwanted requests do not arrive with a universal, cheap separator. RFC 6398 explains why Router Alert differs from an ordinary control session with a known peer. The marked datagram may carry any source and destination. It can invite closer inspection not only at an edge but along a path through core routers. An operator cannot assume that the mark itself grants authority.

Hardware asymmetry makes the invitation expensive. RFC 6192 describes the forwarding plane as high-rate machinery commonly implemented in ASICs, while the control plane runs broader routing and management functions on more general-purpose processors. The control plane is therefore more susceptible to packet-rate exhaustion, yet it must remain stable because it programs the forwarding plane.

Protection works best when unwanted traffic is classified and limited close to forwarding hardware. Router Alert makes that classification awkward. RFC 9805 notes that an access-control list is efficient when it can match information at a fixed position. Searching an IPv6 Hop-by-Hop Options header for Router Alert costs more. The operator can accept that complexity, configure the router to ignore the option, or drop or severely rate-limit Hop-by-Hop traffic at the edge. Each choice can protect one resource while impairing a legitimate function.

The more protocols that acquire the exception, the worse the trade becomes. That is what RFC 9805 changes. It does not claim to have invented a perfect classifier. It prevents the standards process from increasing the set that must be classified.

This is also why the RFC does not simply delete Router Alert. Its Appendix A identifies live dependencies. It says Multicast Listener Discovery Version 2, or MLDv2, and Multicast Router Discovery, or MRD, are the only listed uses with widespread deployment. Other uses are limited, experimental or lack known IPv6 implementations; Router Alert use for MPLS Ping has already been deprecated.

Developing replacement versions of MLDv2 and MRD is explicitly left for future work. That sentence matters more than a triumphal reading of “deprecated.” A standards body has authority to define what future standards may depend on. It does not possess a global switch that can migrate multicast behavior across installed networks.

The nearby history reinforces the point. RFC 9673 modernized IPv6 Hop-by-Hop processing and generally avoids sending such options to the control plane by default. Router Alert received an exception because asking for closer examination is its entire purpose. RFC 9805 contains that exception temporally: keep the bounded historical uses, admit no new standardized ones.

For an operator, five different statements must remain separate.

  1. RFC 9805 proves that a new standardized protocol is not allowed to select Router Alert.
  2. IANA proves that no new value allocation will be made under the closed registry.
  3. A legacy protocol specification proves that a particular existing packet is permitted to carry the option and explains the value.
  4. Device configuration and running software prove the local treatment of that packet.
  5. Packet captures, counters, queues and control-plane telemetry prove what happened under load.

A sixth statement—legacy dependency removed—needs its own evidence. It requires a replacement design, deployed implementations and observations showing that the old marked traffic is no longer necessary. A new RFC alone cannot supply that receipt.

This evidence ladder prevents two opposite mistakes. One is to say nothing changed because old packets are still legal. Something important did change: future protocol designers lost a convenient way to externalize parsing cost onto transit routers, and the allocation path was closed. The other mistake is to say the risk was retired because the registry is closed. The operational cost remains wherever the inherited protocols remain.

Minimum Initial Specification, Localized Future Decision and Voluntary Adoption offers the useful governance model. RFC 9805 is a deliberately small shared rule. It fixes the exception set and leaves local networks to choose policies compatible with their traffic, equipment and obligations. It also leaves later protocol work free to find replacements without appointing one central operator of every router.

Running-Code Primacy sets the test for retirement. A registry annotation is not a filter. A specification is not a deployed replacement. Progress appears in implementations, configurations and traffic measurements: fewer marked packets, narrower exception classes, stable multicast behavior, and reduced control-plane exposure under observed load.

Reality Layers explains why the boundary can feel unsatisfying. “Closed” is true at the allocation layer. “Must not” is true at the future-standardization layer. Neither sentence is true as a description of every live packet path. Refusing to merge them is not pedantry. It is how a real, useful policy change avoids becoming a fictional operational guarantee.

RFC 9805 is therefore neither a cleanup certificate nor a symbolic shrug. It is a ratchet. The standards community has stopped adding teeth in one dangerous direction. The installed base still turns until protocol designers, implementers and operators provide the rest of the mechanism.

Sources