Summary

  • RFC 9685 extends 6LoWPAN Neighbor Discovery so a node can subscribe to IPv6 multicast or anycast addresses, with optional reachability service through RPL.
  • A router keeps state per subscriber but merges multiple subscriptions for one address into a single route advertisement, and route injection happens asynchronously to registration.
  • Operational proof therefore needs separate records for admission, registrar validation, effective lifetime, route propagation, forwarding choice, link delivery and application receipt.

The node received a successful Neighbor Advertisement. Its multicast address, ownership verifier and requested lifetime were accepted. The operations console colored the subscription green. Minutes later, the application was still waiting for the first packet.

Nothing in that sequence contradicted RFC 9685. The standard gives constrained IPv6 nodes a disciplined way to tell a nearby router which multicast or anycast addresses they listen to. It also defines how that state can enter RPL. It deliberately does not turn one accepted subscription into a synchronous end-to-end delivery promise.

The distinction is easy to lose because the request looks like a service order. The node sends an NS carrying an Extended Address Registration Option. The P-field says whether the address is multicast or anycast. The R flag asks the router for reachability behavior. A registration lifetime bounds the state. The router may validate the request with the 6LoWPAN Border Router and return an NA. Each field answers a real question. None answers whether an application packet later reached this listener.

Subscription changes the subject of registration

RFC 8505 uses registration for unicast addresses a node owns. RFC 9685 introduces “subscription” for multicast or anycast addresses a node listens to or accepts. That change matters. Several nodes can legitimately present the same address without creating a duplicate-address conflict.

The P-field carries this address type. Value 1 denotes multicast and value 2 denotes anycast. The R flag remains separate. When R is set, a conforming 6LoWPAN Router can provide reachability, including injection into RPL. A valid P-field does not imply that R was requested. A successful subscription without reachability service is not evidence of a missing route; it may be exactly the transaction the node sent.

Where listener rights are checked, the router still needs the EDAR/EDAC exchange with the registrar. RFC 9685 inherits the Registration Ownership Verifier protection from RFC 8928. That protection helps prevent another node from stealing or corrupting the registration identity. It does not decide whether the application is authorized to join a commercial group, whether its software is trustworthy or whether a downstream packet arrived.

The narrow receipt should therefore retain the subscriber, address, P-field, R flag, Transaction ID, lifetime, ROVR, link identity, EDAR/EDAC result and returned status. A dashboard label such as “member active” erases the question the protocol actually answered.

One injected route can conceal several listeners

RFC 9685 requires routers to keep a registration per party or origin for a shared multicast or anycast address. The router then merges those advertisements and injects the route only once for the address. The route count is not the listener count.

This compression is operationally useful. RPL does not need a separate address advertisement for every leaf. It is also an evidence boundary. Three listeners can have different origins, sequence state and remaining lifetimes while an upstream observer sees one target. A merged advertisement cannot prove which origin is still current unless the per-origin ledger remains available.

Lifetime makes the gap sharper. If one or more nodes set R for the same address, the router bases injection on the longest active subscription lifetime. The shared route can remain legitimate after a shorter-lived listener has expired. An upstream route that still exists is therefore not proof that a particular leaf remains subscribed.

The reverse is equally important. Registration and route injection are asynchronous. An accepted NA(EARO) can precede the route's appearance in the routing system. The node has a subscription receipt, not a propagation receipt. Measuring the interval between those events is an operational task, not a contradiction in the protocol.

Storing and Non-Storing modes create different delivery chains

RFC 9685 extends RPL in two materially different ways. In Storing mode, DAO state for a multicast address percolates along preferred parents and marks a multicast tree. Routers forward a multicast packet as individual unicast MAC frames along that tree, except toward the neighbor from which it arrived.

In the new Non-Storing multicast mode, the Root performs ingress replication. The DAO announces multicast addresses as targets, and the Root encapsulates copies toward the 6LRs that transit for that address using the source-routing machinery associated with RFC 9008. A healthy Root-side target is not the same artifact as installed tree state at an intermediate Storing-mode router.

Anycast narrows rather than replicates the choice. Multiple children or RPL nodes can advertise the same anycast address, but a given packet is forwarded toward only one of them. Counting valid anycast subscribers and calling that number “delivery fanout” reverses the protocol's meaning.

The data-plane dependencies are similarly bounded. RFC 6553 supplies RPL option behavior; it does not report application receipt. RFC 3810 describes MLDv2 listener discovery in a different environment, while RFC 7731 provides MPL for low-power multicast. Their existence does not let an operator silently substitute one state machine's evidence for another.

A radio transmission is not an application receipt

Low-power links make the final gap visible. RFC 9685 notes that Direct MAC Broadcast can be unreliable and that asynchronous broadcast can force a sleeping listener to remain awake. It therefore expects 6LRs, when possible, to deliver multicast packets as individual unicast MAC frames to subscribed leaves.

“Expected” is not “observed.” A route can be installed while the relevant 6LR lost its per-origin state. The router can transmit while the leaf sleeps. The leaf can receive the frame while an upper-layer filter rejects it. The application can accept a datagram but fail to perform the business action leadership is monitoring.

Each boundary needs its own subject and timestamp: route-injection event; DAO propagation; Root or intermediate state; anycast choice or multicast replication; per-hop transmission; link acknowledgment where available; network-layer receive; application receipt; service outcome. Without that sequence, “subscription succeeded” is being asked to testify about systems it cannot observe.

State loss is not hypothetical in the protocol design. A reboot can erase registration state that was not persisted. A router that may have missed or lost state should send an asynchronous refresh request. If it does not, recovery can wait until periodic renewal, and packets can be lost in the interval. An earlier green registration remains historically true while current reachability is false.

Scope and migration constrain where the promise can exist

RFC 7346 gives IPv6 multicast its scope vocabulary. RFC 9685 applies Realm-Local scope to a RPL DODAG and Admin-Local scope when traffic must span a federated RPL Instance. Correct scope prevents one class of error; it does not prove every required router carries current state.

The new Non-Storing multicast MOP also imposes a deployment discontinuity. RFC 9685 says an operator cannot update a live network instance in place to MOP 5. A new instance must be created and nodes migrated into it. In a brown field, legacy unicast may remain in one instance while multicast and anycast use another.

Coverage then depends on capable-router density. Every listener must reach a 6LR that supports the necessary behavior; Storing mode also needs enough supporting routers to form a DODAG to the Root. A capability indication, configuration declaration or procurement list is not a topology receipt. The operative question is whether the required path existed for this listener at this time.

This is where the doctrine in Minimum initial specification becomes practical. The common protocol should be precise enough for interoperability without pretending to make each deployment decision. Reality layers keeps subscription, route state and reception from collapsing into one administrative word. Running-code primacy asks for the final observation from the network that actually forwarded the packet.

RFC 9685 gives constrained listeners a route into multicast and anycast service without requiring every leaf to speak RPL. That is a valuable reduction of authority: a RPL-Unaware Leaf can request service without gaining permission to inject routing messages. Leadership should preserve the same discipline in reporting. Admission belongs to Neighbor Discovery. Redistribution belongs to RPL. Delivery belongs to the forwarding path and receiving application.

Sources