17 RPL Control Messages: DIO, DIS, DAO
RPL message flow, DIO message, DIS message, DAO message, DAO-ACK, RPL storing mode, RPL non-storing mode
17.1 Start With One Control Packet
RPL control messages are easier to learn when one packet has a job. A DIO advertises graph information, a DIS asks for it, a DAO records downward reachability, and a DAO-ACK can confirm that the route state was accepted.
Trace the control packet with the traffic claim in mind. Upward telemetry, root-to-node commands, and peer paths need different evidence, so the message flow should show which route state exists and which direction it actually supports.
Overview: RPL Message Flow Separates Discovery From Reachability
RPL builds a DODAG through control messages that answer different questions. DIO messages advertise DODAG information, DIS messages solicit nearby DIO information, DAO messages advertise downward reachability, and DAO-ACK messages confirm a DAO when acknowledgment is requested.
The practical review point is scope. A node can join a DODAG and send telemetry upward before every downward path is proven. Message-flow evidence should therefore separate parent selection from route registration and packet delivery.
That scope should be written before reading the trace. If the claim is "node joined the graph," DIO, Rank, and selected-parent evidence may be enough. If the claim is "the root can command the node," the trace must include mode-specific DAO or route-state evidence plus a packet test in the downward direction.
The same trace can support one claim while leaving another open. A DIS followed by a compatible DIO supports discovery; a DAO with current lifetime supports a downward route-state claim; an application packet and response support delivery under that condition.
A review note should say which of those claims is accepted and which needs another record.
If you only need the intuition, remember this sequence: DIO and DIS help a node discover and join the graph; DAO and DAO-ACK prove whether the network has the return-path evidence needed for commands, replies, or other downward traffic.
DIO
Advertises DODAG identity, configuration, version, and sender Rank so neighbors can evaluate candidate parents.
DIS
Solicits DODAG information from nearby RPL routers when waiting for ordinary DIO timing is not enough.
DAO
Advertises reachability for downward traffic, with meaning that depends on Storing or Non-Storing mode.
DAO-ACK
Confirms DAO reception and processing only when acknowledgment is requested by the exchange.
Overview Knowledge Check
Practitioner: Build a Reviewable Message-Flow Record
A useful trace does not just list packets. It tells the story in the order a reviewer can verify: which DODAG is in scope, which DIOs were compatible, how Rank was calculated, which parent was selected, and whether DAO behavior matches the traffic direction being tested.
Keep timestamps and repair events with the trace so a pre-repair DAO is not reused as proof after a parent switch.
Worked Record: Equal Candidate Rank
A joining node hears two compatible DIOs. Parent A advertises Rank 256 and the local link adds 384. Parent B advertises Rank 512 and the local link adds 128. Both candidates produce Rank 640, so the arithmetic alone does not prove the correct parent.
The practitioner record should preserve the tie-break rule, hysteresis state, current preferred parent, and stability evidence. If the node switches repeatedly while the path does not improve, the trace may show an operational problem even when every single candidate calculation is valid.
Practitioner Knowledge Check
Under the Hood: DAO Meaning Depends on Routing Mode
DAO is the message family most often misread in RPL reviews because its operational meaning depends on routing mode. In Storing mode, intermediate routers can store descendant route entries. In Non-Storing mode, route knowledge for downward traffic is concentrated at the root, which manages the source-routing behavior needed to reach nodes.
This difference changes the evidence checklist. A Storing-mode review should inspect route state at relevant ancestors. A Non-Storing-mode review should inspect root-side route knowledge and the packet evidence that follows from it. The same packet capture phrase, "DAO observed," is incomplete without naming the mode and the expected state location.
It also changes retesting. Parent churn, route lifetime expiry, root failover, and firmware changes can make the old DAO interpretation stale even when the packet capture remains accurate.
Storing Mode
Ancestors can keep route entries for descendants, so intermediate route tables and memory limits become review evidence.
Non-Storing Mode
The root keeps the route knowledge needed for downward forwarding, so root-side source-route evidence matters.
DAO-ACK Boundary
A missing DAO-ACK is only a fault when acknowledgment was expected for that exchange and no acceptable response appears.
Repair Boundary
After parent repair or DODAG version change, stale DAO evidence should be refreshed before accepting commands or replies.
Failure Boundaries
- A DIO trace can prove discovery context without proving a current downward route.
- A DIS storm can point to missing DIO reception or incompatible configuration, not to route registration by itself.
- A single DAO sighting does not prove current route health after parent changes or route lifetimes expire.
- A DAO-ACK should be matched to the expected DAO sequence and sender before it is treated as confirmation.
- Upward telemetry success should not be used as proof that root-to-node command traffic works.
Under-the-Hood Knowledge Check
17.2 Summary
- RPL message-flow review separates DODAG discovery, solicitation, parent selection, downward reachability, and packet proof.
- DIO advertises graph context and Rank; DIS solicits nearby DIO information.
- DAO advertises downward reachability, and DAO-ACK confirms DAO processing only when acknowledgment is requested.
- Parent selection should preserve compatibility, Objective Function context, candidate Rank, selected parent, and stability evidence.
- Storing and Non-Storing mode change where downward route state should be reviewed.
- A strong trace closes the loop with packet evidence that matches the stated traffic direction.
17.3 Key Takeaway
Treat RPL message flow as an evidence chain: DIO and DIS explain how the node joined, while DAO, optional DAO-ACK, mode-specific route state, and packet proof explain whether downward traffic can actually return to the node.
17.4 See Also
RPL Core Concepts
Review DODAG, Rank, parent selection, and route evidence before reading detailed message traces.
RPL DODAG Construction Process
Connect the message exchange to the larger formation and repair sequence.
RPL DODAG Trickle Timer
Use this when DIO timing and consistency behavior need deeper review.
RPL Routing Modes
Compare Storing and Non-Storing mode before accepting downward-route claims.