8 The RPL Standard (RFC 6550)
A building sensor’s product sheet lists support for the RPL standard. Standard support must cover the installer’s required return command as well as the bench reading sent toward the root. The second direction exposes what the short support label leaves unspecified.
8.1 Start With the Contract
Turn a Routing Claim Into Things You Can Observe
Picture a building sensor that says it supports the standard used by low-power mesh routes. It can send upward once on a bench, but the network owner needs proof of graph identity, parent choice, downward reach, loop avoidance, and repair after a weak link.
Choose one node and record the root, network instance, graph identity, rank, parent choices, route mode, and control messages it sends or hears. Keep the software, settings, objective rule, and test time with the trace. State which traffic must travel up, down, or both ways.
Lower link quality, remove the parent, restart the root, join a second graph, send a downward command, and inject old control state. Check the new parent, rank direction, route table, packet path, repair time, and any loop or loss. Compare on-air evidence with the node’s own view.
Keep urgent local action outside a route whose repair time can miss the safe deadline. A formed graph or a product label does not prove the needed packet path. Preserve source, event time, route state, and software version when reviewing a failure.
This opening does not restate the full standard or certify a stack. Practitioner builds the message and path checklist. Under the Hood examines graph rules, control objects, rank, parent choice, downward modes, headers, and recovery limits.
A specification is useful when a device, simulator, or stack claims RPL support and someone has to verify what that claim means. The contract is not just the name RPL; it is DODAG identity, Rank rules, control messages, routing mode, and packet behavior.
Read the specification as a checklist for evidence. If the implementation cannot show compatible DIOs, parent selection, DAO handling where needed, and traceable route state, the deployment may be using RPL vocabulary without proving RPL behavior.
8.2 Overview: RFC 6550 Defines the RPL Contract
RPL is the IPv6 routing protocol specified for low-power and lossy networks. RFC 6550 defines the protocol objects, control messages, routing modes, and packet-processing rules that let constrained routers form a Destination-Oriented Directed Acyclic Graph, or DODAG.
The standard is easiest to read as a contract between four ideas: an RPL Instance gives the routing context, the DODAG root starts the graph, Rank keeps movement oriented toward the root, and the configured Objective Function turns route metrics into parent choices.
For course review, the contract matters because each term prevents a different overclaim. Instance and DODAG identity keep traces from different graphs apart. Rank and Objective Function keep parent choice from becoming a hop-count guess. DAO and routing mode keep downward reachability separate from upward telemetry.
The specification does not remove the need for deployment evidence. It gives the vocabulary for deciding which field, message, header, or mode setting must be inspected before a route claim is accepted.
If you only need the mental model, keep this sequence in mind: a root advertises a DODAG, a node hears DIO messages, the node chooses a lower-Rank parent through the Objective Function, and DAO messages support downward reachability when the network needs traffic back toward devices.
Before accepting the overview: rfc 6550 defines the rpl contract claim, examine Figure 8.1 to connect the protocol description to observable control-plane, route-state, and packet evidence. This matters because a routing label or formed topology alone cannot prove that the required traffic path works or recovers at its boundaries.
In Figure 8.1, the visual shows rFC 6550 connected to related RFCs for metrics, Objective Functions, Trickle, packet information, and source routing. Start with the input or initial condition, follow the labelled relationships through each intermediate stage, and finish at the decision, output, or feedback path; at every transition, identify what evidence would confirm the change. This ordered reading connects the overview: rfc 6550 defines the rpl contract discussion to the chapter’s running argument: a routing decision is credible only when its control state, forwarding result, failure response, and retest trigger can be checked together.
The labels “RFC 6550” and “base RPL” define the central comparison in Figure 8.1. Bring “spec” into the reading to confirm how rFC 6550 is the base document, with companion RFCs defining metrics, Objective Functions, Trickle behavior, and packet headers. That evidence resolves the question posed by Overview: RFC 6550 Defines the RPL Contract.
Instance
An RPL Instance is a routing context. The same network can carry different routing objectives or administrative policies by keeping their instance identifiers separate.
DODAG
A DODAG is the directed graph that points toward the root. Nodes join the graph through parents that keep forwarding oriented toward lower Rank.
Rank
Rank is a scalar position relative to the root. It is not simply hop count; the Objective Function controls how metrics become Rank.
Messages
DIO, DIS, DAO, and DAO-ACK messages maintain graph knowledge, solicit information, advertise destinations, and acknowledge route advertisements.
8.3 Practitioner: Check the Protocol Pieces in Order
When a device, stack, or simulator says it supports RPL, check the specification pieces in a stable order. Start with the graph identity, then parent selection, then downward route state, then packet headers. That order keeps a diagnosis from mixing unrelated failures.
Keep the exact specification family visible in the record. RFC 6550 gives the base protocol contract, while Objective Function, metric, Trickle, packet information, and source-route details may come from companion specifications and implementation settings.
Treat Practitioner: Check the Protocol Pieces in Order as a hypothesis to test against Figure 8.2. Because it shows how rank must preserve the graph direction: upward forwarding moves toward lower Rank and the DODAG root, the diagram reveals which named component should produce each piece of evidence.
Before accepting the practitioner: check the protocol pieces in order claim, examine Figure 8.2 to connect the protocol description to observable control-plane, route-state, and packet evidence. This matters because a routing label or formed topology alone cannot prove that the required traffic path works or recovers at its boundaries.
In Figure 8.2, the visual shows rPL DODAG formation: the root advertises Rank 0 and nodes at increasing ranks of 256, 512, and 768 build the graph, with downward DIO messages carrying the DODAG ID, version, rank, and objective function so nodes compute their. Start with the input or initial condition, follow the labelled relationships through each intermediate stage, and finish at the decision, output, or feedback path; at every transition, identify what evidence would confirm the change. This ordered reading connects the practitioner: check the protocol pieces in order discussion to the chapter’s running argument: a routing decision is credible only when its control state, forwarding result, failure response, and retest trigger can be checked together.
8.4 Under The Hood: Messages, Modes, and Headers
Under the hood, RPL separates graph maintenance from packet carriage. ICMPv6 control messages build and maintain the DODAG. Data packets then move through the domain using the chosen route state and the relevant RPL packet information.
That separation is important during packet review. A valid DIO or DAO exchange can coexist with a data-plane failure caused by missing packet information, an oversized source route, incompatible mode assumptions, or a stale route after repair.
So the under-the-hood checklist should align the control message, route mode, and data packet evidence. If those three views disagree, the reviewer should fail the claim closed rather than treating specification support as proof of working delivery.
Before accepting the under the hood: messages, modes, and headers claim, examine Figure 8.3 to connect the protocol description to observable control-plane, route-state, and packet evidence. This matters because a routing label or formed topology alone cannot prove that the required traffic path works or recovers at its boundaries.
In Figure 8.3, the visual shows rPL control messages: DIO multicast advertises the DODAG, DIS solicits DIOs from neighbors, and DAO propagates reachability upward to parents, with the key fields carried by each message. Start with the input or initial condition, follow the labelled relationships through each intermediate stage, and finish at the decision, output, or feedback path; at every transition, identify what evidence would confirm the change. This ordered reading connects the under the hood: messages, modes, and headers discussion to the chapter’s running argument: a routing decision is credible only when its control state, forwarding result, failure response, and retest trigger can be checked together.
DIO and DIS
DIO messages advertise DODAG information. DIS messages solicit that information when a router needs nearby RPL routers to send or refresh DIO context.
DAO and DAO-ACK
DAO messages advertise destination reachability upward. DAO-ACK can acknowledge a DAO when acknowledgement or error reporting is part of the exchange.
Storing mode
Intermediate routers keep downward next-hop state for descendants, so downward packets can be forwarded hop by hop through stored state.
Non-Storing mode
The root keeps downward route state and uses source routing inside the RPL domain. Intermediate routers do not keep the same descendant state.
The packet side uses the RPL specification family. RFC 6553 defines RPL Packet Information carried in an IPv6 Hop-by-Hop option, and RFC 6554 defines the RPL Source Route Header. Those headers are separate from the DIO and DAO control messages, but both sides must agree with the same instance, mode, and graph direction.
A useful packet trace separates the control plane from the data plane: DIO, DIS, DAO, and DAO-ACK show how route state is built; packet information and source-route headers show how actual traffic is carried through the RPL domain.
8.5 Turn a Support Claim into an Upward-and-Downward Test
Start the standard review by fixing the implementation version, routing mode, instance and graph identity for the test. Capture the DIO information a leaf hears, its candidate parents and the Rank it computes after selection. These observations show how the claimed standard is being used; a diagram drawn after the test cannot replace the actual control messages.
Use an illustrative run of 20 upward readings and 5 downward commands. If all readings arrive but only 3 commands do, the two delivery proportions are 20 divided by 20 = 100% and 3 divided by 5 = 60%. A combined 23 out of 25, or 92%, conceals which direction is weak, and none of these small-sample proportions constitutes standard certification.
Read Figure 8.1 from the base document to the companion specifications for metrics, objective functions, timing and packet headers. The standard’s ecosystem matters because a stack’s selected objective function and downward mode determine which evidence to inspect. In storing mode, examine router-held downward entries; in non-storing mode, inspect the root’s state and the source-route information used for the command.
The standard review should then repeat the command after removing the chosen parent, keeping the fault time and new route state beside the packet capture. A leaf may regain an upward route before the return path is repaired. Record that interval instead of calling the whole mesh recovered as soon as one reading succeeds.
Predict whether matching the standard’s message names proves that the routes are loop-free under every fault. It does not; field tests still need to examine Rank direction, stale state and observed packet paths under the claimed conditions. Next, restart the root and compare its graph state with the leaf’s retained state before resuming the command trial.
This is the practical purpose of reading a routing standard: turn each supported feature into compatible settings, observable messages and a bounded path test. Urgent local action should retain its own safe behaviour when routing repair exceeds the application’s deadline, even if the implementation remains a valid RPL participant.
8.6 Summary
- RFC 6550 defines the base RPL protocol for constrained IPv6 routing in low-power and lossy networks.
- An RPL Instance gives the routing context, while a DODAG organizes routers around a root.
- Rank increases away from the root, and parent choices must preserve movement toward lower Rank for upward forwarding.
- Objective Functions such as OF0 or MRHOF explain how route metrics and constraints become Rank and parent-selection decisions.
- DIO, DIS, DAO, and DAO-ACK are the main RPL control messages to understand before interpreting route state.
- Storing and Non-Storing modes differ mainly in where downward route state lives and how downward packets are carried.
Read RFC 6550 as a routing contract: identify the instance, graph, Rank direction, Objective Function, control messages, routing mode, and packet headers before deciding whether an RPL implementation is behaving as expected.