15 The RPL Standard (RFC 6550)

routing

rpl

iot

Keywords

RPL specification, RFC 6550, RPL Instance, DODAG, Rank, Objective Function, DIO, DIS, DAO, DAO-ACK, Storing mode, Non-Storing mode

15.1 Start With the Contract

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.

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.

RFC 6550 is the base document, with companion RFCs defining metrics, Objective Functions, Trickle behavior, and packet headers.

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.

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.

Rank must preserve the graph direction: upward forwarding moves toward lower Rank and the DODAG root.

Identify the RPL Instance and root. Control messages and packets only make sense once the instance identifier and DODAG root are known.

Read the DIO context. DIO messages advertise the instance, DODAG version, Rank, configuration, and enough graph information for joining nodes to compare candidate parents.

Confirm the Objective Function. The Objective Function explains how metrics and constraints become parent choices and Rank values.

Check downward routing mode. Storing mode places descendant route state along parents. Non-Storing mode concentrates downward route state at the root and uses source routing.

Inspect DAO and packet behavior. DAO and DAO-ACK messages explain destination advertisements; RPL packet information and source-route headers show how data packets cross the domain.

Protocol piece

What it answers

Common mistake

DIO

Which graph, version, Rank, and configuration did the node hear?

Treating a node as joined without checking the DODAG context it actually received.

Objective Function

How are candidate parents compared, and how is Rank derived?

Treating Rank as plain hop count instead of the value produced by the selected function.

DAO

Which destinations were advertised upward for downward traffic?

Expecting downward packets to work when destination reachability was never advertised.

Routing mode

Where does downward route state live?

Judging Storing and Non-Storing traces by the same packet-state expectations.

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.

RPL builds and maintains the DODAG with three control messages: DIO advertises, DIS solicits, and DAO reports reachability upward.

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.

15.2 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.

Key Takeaway

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.