Summary

  • RFC 5350 created an IPv4 Router Alert value registry and repaired inconsistencies in the IPv6 table. An allocation makes a codepoint unique and reviewable; it does not prove that a router parses the option, recognizes the value, or sends the packet to a control-plane application.
  • The operational decision remains local. RFC 6398 documents routers that punt Router Alert traffic to a slow path, process it in a fast path, ignore the Value field, ignore the option, filter it, rate-limit it, or tunnel it. A registered signal can be valid while the operator refuses it access to scarce control-plane capacity.
  • RFC 9805 closed the IPv6 value registry for new allocations in 2025 and forbade new standardized protocols from using the option, while allowing listed legacy protocols to continue. Closure is a governance decision about future use, not evidence that existing packets disappeared or that every network treats them alike.

The table solved a coordination problem

RFC 5350 began with an asymmetry. The IPv6 Router Alert option already had an IANA-managed table. IPv4 had value zero, described by RFC 2113 as “Router shall examine packet,” while the remaining values had no registry and no allocation policy. RFC 3175 had used the field for aggregation levels, and the IPv4 and IPv6 number spaces no longer lined up cleanly.

The repair was real. RFC 5350 created the IPv4 registry, reconciled initial uses, reserved an experimental range, removed a duplicate IPv6 entry and placed future IPv4 allocations under IETF Review. Before that change, two specifications could make incompatible claims on a field without a durable coordination point. After it, a reviewer could ask whether a proposed value was already occupied, experimental, reserved or eligible for assignment.

That is what a registry can do exceptionally well. It can prevent accidental collision, preserve references, publish allocation procedure and make a shared symbol legible across implementations. None of those functions is the same as running the implementation.

An entry does not install parser code. It does not move option processing into a fast path. It does not configure a punt policer. It does not tell an operator which external senders are trusted. It does not authenticate the upper-layer message, create RSVP state or prove that multicast control traffic was honored. Coordination produces a common name for a requested behavior; the router still owns the behavior.

“Should examine” contains a local predicate

The original Router Alert idea was economical. A router should be able to notice a packet that is not addressed to it without deeply inspecting every datagram. Ordinary traffic could stay on an efficient forwarding path; a marked packet could receive closer attention from routers participating in the relevant function.

That last condition matters. RFC 7126 states the semantic more precisely: routers should examine the packet more closely if they participate in the functionality denoted by the Value. A value therefore identifies a class of interest. It does not turn every transit node into a participant.

A router may not implement the protocol. It may implement it only on selected interfaces. The operator may confine it to one administrative domain. A control-plane protection rule may discard the packet before a protocol process sees it. A platform may forward it normally while ignoring the option. Each of those outcomes is compatible with the deeper architecture: an on-wire request cannot appoint a router to a service or compel expenditure of its control-plane resources.

The word “registered” is particularly easy to overread in dashboards. It can mean that IANA has a row and an RFC reference. It cannot mean “recognized on this box,” “permitted on this interface,” “safe at this rate,” “accepted from this source,” or “acted upon by the intended protocol.” Those are different fields and require different evidence.

The scarce resource was not the codepoint

There are 65,536 possible values. The operational scarcity lies elsewhere: parsing budget, forwarding exceptions, punt bandwidth, general-purpose CPU, protocol queues and the attention of the process expected to interpret the payload.

RFC 6398 describes the resulting split. Some routers can process Router Alert inside a fast path. Many implementations send most or all marked packets to a slow path unless configured to ignore or drop them. Some reported IPv4 implementations did not use the Value for useful classification and instead treated any Router Alert packet as interesting. A small header field could therefore select a much more expensive processing path than the ordinary packet would receive.

That is why allocation and admission cannot be the same act. IETF Review can decide whether a value is appropriate for a protocol. It cannot know a provider's line-card design, punt capacity, current attack load, customer trust relationship or failure budget. The party bearing that cost needs an independent right to say no.

RFC 6398 gives that right operational form. Providers should protect themselves from externally generated Router Alert traffic and must implement strong protection against Router-Alert-based attacks. Filtering, rate limiting, tunneling and leak-controlled overlays are not violations of the registry. They are mechanisms that keep the registry's symbol from becoming an unauthenticated claim on control-plane resources.

One value produced several possible receipts

Suppose a capture shows value zero or another assigned value. The capture proves something narrow: those bits were present at that observation point. It does not reconstruct the rest of the path.

A defensible evidence chain needs separate receipts:

  1. IANA allocated or reserved the value at the relevant time.
  2. The packet actually carried the correct option format and value.
  3. A particular node received the packet on a particular interface.
  4. That node parsed the option rather than dropping or ignoring it.
  5. The node recognized the value and participated in the denoted function.
  6. Local policy permitted inspection or a protected control-plane punt.
  7. The encapsulated protocol message passed its own validation and authorization.
  8. The intended reservation, membership or signaling state changed.
  9. Forwarding behavior and the measured service reflected that state.

Collapsing those receipts produces bad incident conclusions. A registry screenshot cannot show that the packet entered the slow path. A packet capture upstream cannot show how the next router was configured. A punt counter cannot show that the protocol handler accepted the message. A successful RSVP exchange cannot by itself show the user's eventual application performance.

The same distinction protects against false negatives. If the final service did not appear, it is premature to blame an unregistered value. The failure may have been an ingress filter, an unsupported option, a rate limiter, a protocol validation error, missing downstream state or a separate forwarding problem. Evidence must follow the chain instead of jumping from symbol to outcome.

Experimental space was bounded by administrative reality

RFC 5350 set aside values for experimentation, but it did not describe them as globally conflict-free. It warned that production networks might not support experimental IP-option codepoints and that experiments crossing administrative domains could encounter the same value used for another purpose.

That is a compact example of namespace scope. Within one controlled domain, administrators can coordinate a value, configure participating routers and police the traffic. Across domains, the same bits no longer carry one guaranteed local meaning. An experimental allocation can prevent collision within the rules of the registry while still colliding with another experiment's assumptions or with a network that treats all such traffic as unwanted.

The right operational record therefore includes a scope statement: which interfaces, devices, neighbors and administrative domains agreed to the experiment; which value and protocol were expected; how leakage was contained; what rate limits applied; and when the configuration expired. “Experimental value present” is not enough to establish that the receiving network joined the experiment.

This is also why a fallback matters. If a router ignores the option, can the packet continue as ordinary traffic, or does the application fail? If the option is filtered, is there a bounded alternate signaling path? An experiment that assumes universal participation has converted a local symbol into an external dependency without obtaining the external operator's agreement.

IPv4 and IPv6 no longer tell the same future story

The frozen IANA records now expose a policy divergence. The IPv4 Router Alert value registry remains under IETF Review. The IPv6 value registry says “Registry closed,” reflecting RFC 9805. A reader who looks only at RFC 5350's 2008 allocation procedure would miss that later change.

RFC 9805 did not erase every legacy user. It permits protocols already using IPv6 Router Alert to continue, even in future versions, while requiring that new standardized protocols not adopt the option. It identifies MLDv2 and MRD as the widely deployed entries in its list and characterizes the remaining uses as limited, experimental or without known implementation. Those statements set a standards boundary; they are not a live global inventory.

Closure changes the commissioning decision for protocol designers. It does not tell an operator whether a particular network still carries MLDv2 Router Alert packets, whether an old platform punts them, whether a provider filters Hop-by-Hop options at an edge or whether a tunnel hides the option through a core. The registry can close prospectively while legacy operational states remain heterogeneous for years.

This distinction prevents another common mistake: treating deprecation as disappearance. “Must not be used by new protocols” is not “must be dropped everywhere.” “Existing users may continue” is not “existing users will work across every domain.” The normative boundary and the observed path need separate evidence.

The control plane needed a principal, not just a label

Router Alert can expose a router's general-purpose control plane to traffic originated outside its administrative boundary. RFC 6398 contrasts this with arrangements such as BGP peering, where the router can restrict a control-plane relationship to identified peers and defined edges. Router Alert does not inherently supply that peer identity or trust relationship.

A valid value therefore answers the wrong question for authorization. It says what kind of closer examination is requested. It does not say who is entitled to request it, at what rate, through which ingress, for which protocol instance or at whose operational risk.

The principal is the operator responsible for the device and service. That principal expresses authority through configuration: allow-lists, interface scope, policers, filters, tunneling, protocol enablement and monitoring. A standards body can define interoperable syntax and safe expectations. IANA can maintain the codepoint. Neither should be represented as having accepted an arbitrary sender's packet into a specific router's control plane.

This is where security automation can fail silently. A policy engine may see a recognized IANA value and classify the packet as legitimate before checking origin, interface, rate or enabled protocol. The registry lookup is useful enrichment; it is not the verdict. The verdict belongs to the local rule set and must be explainable after the packet is gone.

A minimal registry can preserve local choice

Lu Heng's Minimum Initial Specification note supplies a later analytical lens, not historical evidence about RFC 5350. The useful principle is narrow: shared coordination should define the minimum common object and leave future operational choices with the participants running the system.

Applied here, the registry supplies unique values, references and allocation policy. It should not be inflated into a universal processing mandate. Local implementations can then decide whether and how to support the option, while operators retain the ability to protect scarce resources and withdraw participation.

His Reality Layers note adds a second discipline. The IANA row is a symbolic fact. The packet bits are an observed fact. Parser behavior, punt disposition, protocol state and delivered service are operational facts. They are related, but one cannot be substituted for another. Neither note caused, endorsed or interprets the RFCs authoritatively; the RFC and IANA records remain the primary evidence.

The leadership value of that separation is practical. It tells an organization which control it can actually own. It cannot retroactively change a registry allocation. It can inventory supported values, define trust boundaries, cap expensive processing, preserve packet-to-state telemetry and make protocol dependencies visible before a platform replacement silently removes them.