RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks
updated by
- rfc-9008 — Using RPI Option Type, Routing Header for Source Routes, and IPv6-in-IPv6 Encapsulation in the RPL Data Plane
- rfc-9010 — Routing for RPL (Routing Protocol for Low-Power and Lossy Networks) Leaves
- rfc-9685 — Listener Subscription for IPv6 Neighbor Discovery Multicast and Anycast Addresses
- rfc-9914 — Root-Initiated Routing State in the Routing Protocol for Low-Power and Lossy Networks (RPL)
- rfc-9926 — Prefix Registration for IPv6 Neighbor Discovery
Extracted elements (29)
DIO messages are disseminated using the Trickle algorithm (RFC 6206), which suppresses redundant transmissions when the network is stable and rapidly increases transmission rate upon detecting an inconsistency, minimizing control-plane overhead in energy-constrained LLNs.
RPL decouples packet forwarding from routing optimization by defining an Objective Function (OF) abstraction. This allows the same protocol to serve diverse LLN applications — minimizing energy, latency, or satisfying constraints — without modifying the core protocol, at the cost of requiring companion OF specifications.
RPL prohibits 'greedy' parent selection (a node moving to a deeper Rank to gain additional parents) and forbids processing DIOs from sub-DODAG nodes, preventing the count-to-infinity oscillation that would otherwise arise when two nodes each attempt to optimize against the other's Rank.
RPL provides two modes of downward routing — Storing (fully stateful, intermediate nodes maintain routing tables) and Non-Storing (fully source-routed from the root) — to span the range of LLN device memory capacities. No implementation is expected to support both simultaneously, and hybrid modes are out of scope.
RPL uses on-demand loop detection via data-packet Rank inspection rather than continuous topology tracking, because transient LLN connectivity changes are common, often innocuous, and costly to track; detection and local repair are triggered only when a forwarding loop is actually encountered.
No single implementation is expected to support both Storing and Non-Storing downward-route modes simultaneously. A given RPL Instance is either entirely Storing or entirely Non-Storing; hybrid operation is out of scope for this specification.
RPL requires an external mechanism to carry RPL Packet Information (RPLInstanceID, sender Rank, loop-detection flags) in data packets. The RPL option (RFC 6553) is the designated mechanism; strict source routing in Non-Storing Downward mode is the one exception where RPL Packet Information is not required.
RPL requires an external mechanism to verify bidirectional link properties and neighbor reachability before selecting a parent; NUD, BFD (RFC 5881), and L2 triggers (RFC 5184) are cited examples. A traffic-reactive detection mechanism is preferred to minimize energy spent monitoring idle links.
A global RPLInstanceID MUST be unique to the whole LLN. Up to 128 global instances and up to 64 local instances per DODAGID are supported.
A local RPLInstanceID MUST be unique for its DODAGID. The DODAGID MUST be a reachable IPv6 address of the owning node and MUST be used as an endpoint of all communications within that Local instance.
If a node receives a RPL control message with an unknown Code field, it MUST discard the message without further processing and MUST NOT send any messages in response; it MAY raise a management alert.
In a local RPL instance, if the 'D' flag is set to 1, the destination address of the IPv6 packet MUST be the DODAGID; if cleared, the source address MUST be the DODAGID.
Reserved fields in the RPL Security section MUST be initialized to zero by the sender and MUST be ignored by the receiver.
Some dampening or filtering is RECOMMENDED to keep the routing topology stable, so that Rank does not change as fast as underlying link or node metrics; a new DODAG Version is the appropriate opportunity to reconcile discrepancies.
The Rank presented by a node MUST be strictly greater than that presented by any of its DODAG parents; DAGRank(N) must exceed DAGRank of every parent in the DODAG parent set.
The Consistency Check (CC, Code 0x8A) is used to verify security state between nodes and synchronize counters for replay protection; it is the only RPL control message that operates outside the scope of a single link.
The DAGRank() macro computes the integer portion of Rank as floor(rank / MinHopRankIncrease). MinHopRankIncrease is provisioned by the DODAG root and governs a trade-off between hop cost precision and the maximum number of hops a DODAG can support.
The DAO Acknowledgement (DAO-ACK, Code 0x03) is an optional unicast response confirming receipt of a DAO. Its use mitigates DAO loops caused by missed No-Path DAO messages.
The Destination Advertisement Object (DAO, Code 0x02) establishes downward routes. In Storing mode, DAOs are sent to DODAG parents; in Non-Storing mode, DAOs are unicast over multiple hops to the DODAG root using global or unique-local addresses.
The DODAG Information Object (DIO, Code 0x01) is the primary RPL control message. Nodes multicast DIOs to the all-RPL-nodes address (ff02::1a) to advertise DODAG membership, Rank, Objective Function, and routing metrics, enabling neighbor DODAG joining and maintenance.
The DODAG Information Solicitation (DIS, Code 0x00) allows a node to solicit DIO messages from RPL neighbors, used when joining a DODAG or re-synchronizing after a period of inactivity.
RFC 6550 creates 19 new IANA registries including: RPL Control Codes, Mode of Operation (MOP), RPL Control Message Options, Objective Code Point (OCP), Security Algorithm, Security Flags, Per-KIM Security Levels, and per-message Flags registries for DIS, DIO, DAO, DAO-ACK, CC, DODAG Configuration, RPL Target, Transit Information, and Solicited Information options.
RPL defines three security modes: unsecured (relies on link-layer security), preinstalled (pre-deployed keys protect RPL control messages), and authenticated (pre-installed key allows leaf-only joining; becoming a router requires a key from an external authentication authority whose key-distribution mechanism is out of scope and must be specified in a companion document).
RPL networks face routing-specific threats including sinkhole attacks (a malicious node advertising an attractive Rank to intercept traffic), selective forwarding, wormhole attacks, and Rank spoofing. The integrity-protection mechanisms in Section 10 mitigate these for secured-mode deployments, but unsecured mode relies entirely on link-layer security.
The sole defined cryptographic suite (Algorithm=0) uses CCM with AES-128 for encryption and MAC, and RSA with SHA-256 for signatures. Security Level (LVL) selects among MAC-only and encrypt-then-MAC variants at 32-bit or 64-bit MAC lengths; replay protection uses a Counter field that can be either a monotonic counter or a timestamp.
A DODAG transitions between versions when the DODAG root increments DODAGVersionNumber (global repair). Nodes re-joining the new version are not constrained by their Rank in the old version. Local repair within a version may use INFINITE_RANK poisoning to detach nodes from the sub-DODAG before reattachment.
RPL control messages are ICMPv6 (Type 155) messages. The body consists of a Type (8 bits), Code (8 bits), Checksum (16 bits), a code-dependent Base, and optional Options. High-order bit (0x80) of Code indicates a secure variant, which inserts a Security section between Checksum and Base.
The RPL Security section contains: T flag (1 bit, timestamp vs. counter), Reserved (7 bits), Algorithm (8 bits), KIM (2 bits), Resvd (3 bits), LVL (3 bits), Flags (8 bits), Counter (32 bits), and a variable-length Key Identifier (0, 1, or 9 octets depending on KIM mode).
The RPLInstanceID is an 8-bit field: MSB=0 identifies a global instance (ID in bits 0–6, range 0–127); MSB=1 identifies a local instance with a D flag in bit 6 and local ID in bits 0–5 (range 0–63).