Summary

  • RFC 9854 pairs an RREQ-Instance with an RREP-Instance, but the control direction of each temporary DODAG is opposite to the data direction its discovered route supports.
  • The six-bit Delta, endpoint addresses and local InstanceIDs keep one discovery from being confused with another; they do not attest to current route installation, packet use or application success.
  • A bidirectional service claim requires time-aligned evidence for both directional routes, both packet directions and the completed request-response exchange.

The reply could not borrow the request's road

In a lossy radio network, hearing a neighbour is not the same as being heard by it. A route request may cross a series of links that satisfy the objective in one direction while the reverse direction requires different relays. The ordinary conversational picture—one path, used both ways—therefore hides the condition RFC 9854 was designed to handle.

RFC 9854 adapts Ad Hoc On-Demand Distance Vector discovery to RPL-based low-power and lossy networks. Its decisive move is not merely that it adds Route Request and Route Reply options to DIO messages. It creates two paired, directional instances. The first control wave travels from OrigNode to TargNode. The second can construct a different DODAG from TargNode back toward OrigNode. The pair makes asymmetric communication representable without pretending the two directions share the same links.

The naming invites a dangerous shortcut. The RREQ-Instance is built by control messages moving from origin to target, yet its discovered upward route carries data from target to origin. The RREP-Instance is built by control messages moving from target to origin, yet its route carries data from origin to target. Control propagation and data service point in opposite directions. An audit that stores only “RREQ succeeded” or “RREP received” has already lost the direction of the claim.

Two DODAGs, one discovery, potentially different nodes

The S bit determines whether the first discovery has preserved symmetry. It begins set at OrigNode. At each hop, a router keeps it set only if the other direction of the incoming link also satisfies the Objective Function. Once cleared, it stays cleared. A target receiving S=1 has a route whose two directions satisfy the OF. It can send the RREP by unicast over the known vector or route entry, without building a second DODAG.

S=0 changes the work. The target must create the RREP-Instance rooted at itself and multicast the RREP-DIO. Routers evaluate the target-facing direction and may join this second DODAG through a different preferred parent. The two paths may therefore contain different intermediate nodes. “Bidirectional” here means that two directional routes can be discovered for an exchange. It does not mean a single symmetric chain exists.

That distinction also limits what S proves. The criteria for deciding link symmetry are outside the specification. RFC 9854 offers ETX/RSSI as an example and mentions prior knowledge, test traffic and OAM, but it does not mandate one measurement procedure. S=1 is a control statement produced by the participating routers under their chosen evaluation method and time. It is not a timeless radio measurement, and it is not a receipt from every later forwarding action.

Pairing is identity discipline, not delivery evidence

RPLInstanceID is assigned locally. Multiple discoveries between the same endpoints may run simultaneously with different Objective Functions, and two originators may choose the same numerical value. RFC 9854 therefore places the local value inside endpoint context. An RREQ-InstanceID is the ordered pair of the origin's RPLInstanceID and origin address; the RREP equivalent uses the target's value and address.

The target may discover that the obvious RREP value is already occupied by an active instance with its DODAGID. It must then choose another. The RREP option's six-bit Delta records how much was added to the received RREQ numerical value, with arithmetic wrapping after 255. A receiver subtracts Delta to recover the paired RREQ value when it installs the target route. DODAGID supplies the endpoint identity that the octet alone lacks.

This mechanism closes a genuine control hazard: state for one discovery or Objective Function must not be attached to another. It proves that a conforming receiver can identify the intended pair. It does not prove that the RREP-Instance was built at every necessary router, that either route entry survived, or that the pair describes one current epoch. A dashboard that colours two matching identifiers green has shown successful bookkeeping.

Rank, sequence and lifetime answer different questions

Rank is often presented as if it were a path score. RFC 9854 explicitly repeats the base RPL warning from RFC 6550: Rank expresses a node's relative position within a DODAG Version and is not necessarily a good indication of distance or path cost. The AODV-RPL text goes further—its Rank measurements do not indicate distance or path cost to the root. The metrics and constraints available to an Objective Function are catalogued separately in RFC 6551.

Sequence numbers protect another dimension. OrigNode increments its sequence number for a new discovery. Hop-by-hop state toward the origin carries Orig SeqNo; state toward the target carries the ART Destination Sequence Number. A stale entry matching source, destination and instance must be deleted. Freshness here is relative route-entry ordering, not proof that hardware installed the entry or that the link still works.

Time is split again. The RREQ/RREP L field limits participation in the temporary instance. It is explicitly independent from route lifetime. Route-entry lifetime comes from DODAG configuration and may be extended by actual use. Operators who treat “instance alive,” “route not expired” and “packet recently observed” as one clock will retain contradictory evidence without noticing.

Hop-by-hop and source routing leave different receipts

With H=1, intermediate routers build entries containing source, instance, destination, next hop, lifetime and sequence state. For the target-facing route, a symmetric case can use the RREP sender as next hop; an asymmetric case follows the preferred parent of the RREP DODAG. A defensible installation record must therefore name direction, node, next hop, sequence, configured expiry and installation generation.

With H=0, the path is carried as an Address Vector. The vector collected by an asymmetric RREP records the nodes it actually passed on the second control wave. In a symmetric case the target returns the first vector unchanged. Duplicate-address checks reduce loop hazards, but a vector is still a control object. It does not show that every listed interface remained reachable when a later packet used it.

The final sentence of RREP processing is carefully bounded: once OrigNode receives the reply, it can start transmitting application data. “Can start” marks the end of discovery and the beginning of evidence that the RFC cannot manufacture. The first outgoing packet may meet an absent entry, expired state, a newly asymmetric link, congestion or an application that never responds.

Five receipts for one round trip

A useful operational record starts with discovery identity: both endpoint addresses, both DODAGIDs, numerical InstanceIDs, Delta, Objective Function, H and S bits, sequence numbers, temporary-instance clocks and the observer that collected them.

The second receipt covers the TargNode-to-OrigNode direction discovered by RREQ. In hop-by-hop mode, each relevant node reports its installed route and expiry. In source-routing mode, the origin of the vector, exact vector and packet header context are retained.

The third receipt independently covers OrigNode-to-TargNode through the RREP result. Matching the pair is necessary, but the installed nodes or vector may differ. Absence on one side cannot be repaired by stronger evidence on the other.

The fourth receipt is directional packet observation. Counters or probes need a time window, denominator, reset history, source/destination and instance context. One-way delivery proves one-way delivery. Even successful probes in both directions may have occurred at different times or over state that never coexisted.

The fifth receipt belongs to the application. It joins a unique request at OrigNode to target acceptance, response generation and response receipt before a declared deadline. That round trip is the service fact. It cannot be inferred from a paired control exchange.

Security constrains speakers, not outcomes

RFC 9854 inherits RPL's optional security framework and points to the threat analysis in RFC 7416. A participant needs the key used by a secure discovery, but a rogue router possessing that key can still advertise false information, inject discoveries or alter replies. A hostile source-routing vector can create a loop; a forged gratuitous RREP can support denial of service.

Authentication therefore raises confidence about message handling inside a configured security domain; it does not turn a participating router into an independent witness of downstream service. The current IANA RPL registry records MOP 4 and the RFC 9854 RREQ, RREP and ART option codes. Registration proves the shared encoding. It does not prove deployment.

The RFC Editor information page and Datatracker record establish Proposed Standard status and publication history. The errata record showed no matching errata at review time. None supplies an implementation census or observed service result.

Heng Lu's Running-Code Primacy gives the governing discipline: a specification and registry describe a compatibility surface, while actual operation must be shown by systems that run it. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption keeps shared rules narrow and local verification explicit. The essay on reality layers supplies the final separation: the symbolic neatness of a matched pair cannot substitute for executable evidence from each route, each direction and the application.

Sources