Summary

  • RFC 9926 lets a 6LoWPAN node register a unicast prefix with a neighbouring router. P-Field value 3 and the R flag can install and redistribute a local RPL route; that is a scoped control-plane commitment, not a universal statement about the prefix.
  • The right to register can itself require prior local provisioning of a prefix/ROVR association. Route propagation, receiver selection, packet forwarding and a service result remain different evidence records.

The review sheet looked complete. A prefix appeared in the register. The neighbour router held a route. The R flag was present, and the network team could point to a clean control-plane entry. Someone wrote the conclusion in the margin: the branch is reachable.

That conclusion was larger than the record.

The entry could be correct and useful. It could mean that a 6LoWPAN Router accepted a prefix-registration exchange and maintained state for it. It could mean that the router injected a corresponding route into RPL under the behavior RFC 9926 specifies. It did not identify how the prefix had been allocated, whether a local right-to-register check was provisioned, whether another router made the same decision, which of several registrants would receive traffic, what a packet encountered beyond the next hop, or whether an application worked.

Those are not bureaucratic caveats around one finished fact. They are separate facts, owned by different systems.

RFC 9926, Prefix Registration for IPv6 Neighbor Discovery, is valuable precisely because it keeps its mechanism narrow. It extends Subnet Neighbor Discovery so a node that owns or is directly connected to a prefix can register that prefix with neighbour routers. The registration can request redistribution into another routing domain, regardless of which routing protocol operates there. In a route-over low-power and lossy network, the extension lets a 6LoWPAN Router inject the prefix into RPL.

The document does not create an Internet-wide allocation registry. It does not make a 6LR a global adjudicator of a prefix. It does not turn a route entry into a packet trace or a service-level result. It defines a carefully bounded way for cooperating local components to express and act on a routing relationship.

A prefix field is not an allocation ledger

Earlier 6LoWPAN Neighbor Discovery registration was oriented around unicast addresses. RFC 9926 reuses the Extended Address Registration Option, EARO, and the related EDAR/EDAC exchanges to carry a prefix. P-Field value 3 says that the registered address represents a unicast prefix rather than a single address. The prefix-length field supplies the span, with values from 16 through 120 bits in the relevant messages.

That design choice matters. The RFC does not invent a new record that says who owns IPv6 space in the broad public sense. It reuses a local registration protocol because the operational question is local: can a router retain state and forward traffic toward a node that has registered a reachable prefix?

When a 6LR receives an NS(EARO) with P-Field 3, it installs a route to that prefix through the source address of the solicitation. When the R flag is set, the 6LR injects the prefix into RPL using a prefix Route Target Option. The F capability bit tells a node that a 6LR supports prefix registration, will route matching packets to registered nodes, and will redistribute the route when the R flag is set.

These are meaningful statements about a protocol relationship. They still need their proper scope. The RFC says that IPv6 ND is agnostic to the routing protocol used in the subnet discovery environment, and that the router is agnostic to the method used to allocate the prefix to the node. Agnosticism makes the mechanism portable. It also prevents the registration message from silently carrying facts that a separate allocation or provisioning system must establish.

An operations dashboard should therefore resist a tempting rewrite: “registered” does not become “publicly entitled,” and “RPL injected” does not become “globally reachable.” The first is a claim about a different custody system; the second depends on a different path and a later observation.

The router records an origin, not a single destiny

The details make the boundary sharper. RFC 9926 permits more than one 6LN to register the same prefix. A 6LR holds registration state for the tuple of IPv6 prefix, prefix length and Registration Ownership Verifier, or ROVR. A 6LBR maintains related prefix/ROVR state. The protocol preserves enough identity and freshness information to compare registration forms and retain the appropriate current state.

That is not the same as declaring one permanent owner or one inevitable recipient. Where a matching packet arrives, the 6LR can deliver a copy to exactly one node that registered the prefix, using longest-prefix matching to select the best 6LN. In the RFC's hub-and-spoke example, multiple routers serving the same stub prefix can register it, and the hub router applies its own load-balancing logic.

So even the apparently simple phrase “the registered prefix receives traffic” hides choices. Which origin registrations are still live? Which lifetime has not expired? Was the origin determined well enough for freshness comparison? Did the local router choose a particular registrant? Did forwarding continue from there? These questions have answers at different points in the system. A single entry should not claim them all.

The lifetime and reboot rules underline the point. A router that reboots can lose registration state; RFC 9926 provides a refresh mechanism so prior registrants can register again. In a partially upgraded network, a legacy 6LR may not advertise support, and an upgraded 6LN may register elsewhere rather than there. A state table can be valid at its capture time while the network around it is mid-refresh, partially upgraded, or about to expire.

This is not an argument against the state table. It is an argument for retaining its time, origin, lifetime and observed effect separately.

“Right to register” is a local control, not a slogan

Security language can make over-reading more likely. RFC 9926 updates Address-Protected Neighbor Discovery, AP-ND, because a prefix registration needs a way to enforce a right to register when that protection is deployed. But the condition is explicit. A prefix can have several registering nodes, so node-local automatically generated keys are not enough to protect it as a single address.

The RFC instead describes a prior association: a keypair and ROVR for the prefix must be created before the prefix is deployed, and the prefix/ROVR association must be installed in the 6LBR at or before first registration. That installation can come through an external local mechanism such as IP Address Management or DHCPv6 snooping. The 6LBR can then recognise later registrations and validate the right to register against the ROVR.

This is a strong and useful local security design. It is not a shortcut around the provisioning source. The signed registration is evidence that the protocol's configured registration-right check can be satisfied. It is not, without the separate provisioning evidence, a public allocation certificate, a legal title, an Internet routing-origin authorization, or proof that a chosen service should be trusted.

Heng Lu's Minimum Initial Specification principle helps explain why the separation is healthy. A shared protocol should carry the smallest interoperable claim that participating systems can validate. It should not attempt to settle every upstream custody question or every downstream use decision. The 6LBR's job is to apply the registration rule it has been given; it is not made sovereign over the rest of the Internet by receiving a well-formed EARO.

What a complete assurance chain must retain

The practical remedy is not a larger status label. It is an evidence chain that does not collapse owners.

Start with the control-plane record: prefix and length, registration source, P-Field, R/F flags, transaction identity, ROVR, requested lifetime and capture time. Then retain the policy decision: which local registration rule applied, whether AP-ND was active, where the prefix/ROVR association came from, and which party owns that provisioning record. Retain the 6LR and 6LBR state, EDAR/EDAC results, RPL/DAO injection state, expiry events and any refresh after a reboot.

Next, observe the data plane separately. A route lookup is not a forwarded packet; a forwarded packet is not a correct return path; a correct packet exchange is not a functioning service. The evidence should say which question it answers. A reachability probe can establish a bounded observation at a time and vantage point. It cannot retroactively transform a registration record into every other form of authority.

Finally, verify the service layer independently. An application may reject a request after transport succeeds. A receiving branch may have its own local policy. A business process may deliberately decline to proceed. Running-Code Primacy is useful here not as a slogan for decentralisation, but as an audit discipline: the fact that matters is the fact a running component actually validated and acted upon, with its scope and time preserved.

Sources