rfc-9854

AODV-RPL: The Routing Protocol for Low-Power and Lossy Networks (RPL) Based on Ad Hoc On-Demand Distance Vector (AODV) Routing

C.E. Perkins, S.V.R. Anand, S. Anamalamudi, B. Liu
date2025-10 streamIETF areartg wgroll statusPROPOSED STANDARD pages31 canonicalhttps://www.rfc-editor.org/rfc/rfc9854 doi10.17487/RFC9854
Route discovery for symmetric and asymmetric Peer-to-Peer (P2P) traffic flows is a desirable feature in Low-Power and Lossy Networks (LLNs). For that purpose, this document specifies AODV-RPL -- the Routing Protocol for Low-Power and Lossy Networks (RPL) based on Ad hoc On-demand Distance Vector (AODV) routing. AODV-RPL is a reactive P2P route discovery mechanism for both hop-by-hop routes and source routing. Paired instances are used to construct directional paths for cases where there are asymmetric links between source and target nodes.

Extracted elements (28)

design-rationale §1

AODV-RPL is designed as a reactive (on-demand) P2P routing protocol to discover shorter routes that avoid traversing the RPL root or common ancestor nodes, reducing hop count and congestion near the root. RPL in non-storing mode forces all P2P traffic through the root; AODV-RPL discovers direct paths instead.

routing

design-rationale §3

Paired DODAG Instances are required to support asymmetric links: on a bidirectional asymmetric link only one direction may satisfy the Objective Function, so a single DODAG cannot establish both directions simultaneously. The RREQ-Instance and RREP-Instance are built independently, allowing each direction to be routed optimally.

routing

design-rationale §6.3.3

The 6-bit Delta field in the RREP option allows TargNode to signal a modified RPLInstanceID without requiring global coordination: since RPLInstanceIDs are locally assigned, two simultaneous route discoveries from different OrigNodes to the same TargNode could collide on the same RPLInstanceID. Delta encodes the additive offset so intermediate routers can recover the correct RREQ-InstanceID.

routing

interoperability-note §1

AODV-RPL uses the same MOP value (4, 'P2P Route Discovery') as P2P-RPL (RFC 6997) but does not conflict with it because AODV-RPL uses newly defined DIO option types (0x0B, 0x0C, 0x0D) and a newly allocated multicast group (224.0.0.69). AODV-RPL can operate concurrently with P2P-RPL or base RPL (RFC 6550).

routing

normative-requirement §6.2.3 MUST

A route entry with the same source address, destination address, and RPLInstanceID but a stale Sequence Number (incoming SeqNo is less than the stored SeqNo) MUST be deleted, ensuring only the freshest route information is retained.

routing

normative-requirement §4.1 MUST

A router MUST discard an RREQ-DIO if the integer part of the advertised Rank equals or exceeds the RankLimit field value, and MUST NOT join an RREQ-Instance if its own computed Rank would equal or exceed RankLimit. A value of 0 in RankLimit means no limit.

routing

normative-requirement §4.3 MUST

An RREQ-DIO message MUST carry at least one ART option indicating the TargNode; an RREP-DIO message MUST carry exactly one ART option. Otherwise the message MUST be dropped.

routing

normative-requirement §4.1 MUST

Exactly one RREQ option MUST be present in an RREQ-DIO message and exactly one RREP option MUST be present in an RREP-DIO message; if either condition is violated the message MUST be dropped.

routing

normative-requirement §6.2.1 MUST

In source-routing mode (H=0), a router MUST drop an RREQ-DIO if one of its own addresses appears in the Address Vector (loop prevention). In hop-by-hop mode (H=1), a router MUST drop the RREQ if Orig SeqNo is older than the stored sequence number for an existing route to OrigNode.

routing

normative-requirement §6.2.5 MUST

In source-routing mode (H=0), an intermediate router propagating an RREQ-DIO MUST append its receiving interface address to the Address Vector and MUST also append the transmitting interface address if it differs from the receiving interface address.

routing

normative-requirement §4.1 MUST

The IPv6 address selected as the DODAGID by OrigNode in RREQ-DIO (or by TargNode in RREP-DIO) MUST have a scope that encompasses the entire domain where the route is built; a link-local address is insufficient and will cause route discovery to fail.

routing

normative-requirement §6.2.2 MUST

When a TargNode is one of multiple targets in a single RREQ-Instance, it MUST delete the ART option containing its own address from the RREQ-DIO before propagating it, so that downstream routers with higher Rank do not attempt to build a route to an already-reached target.

routing

normative-requirement §6.1 MUST

When OrigNode initiates route discovery it MUST increment its own Sequence Number to avoid conflicts with previously established routes; this value is placed in the Orig SeqNo field of the RREQ option.

routing

normative-requirement §6.3.2 MUST

When TargNode receives an RREQ-DIO with S=0 (asymmetric route), TargNode MUST build a DODAG in the RREP-Instance rooted at itself and transmit the RREP-DIO to the all-AODV-RPL-nodes multicast group to discover the return path independently.

routing

normative-requirement §4.1 MUST NOT

When the duration specified by the L field has elapsed, a node SHOULD leave the RREQ-Instance and stop sending or receiving DIOs for it. After leaving, a node MUST NOT rejoin the same RREQ-Instance for at least the REJOIN_REENABLE interval (default 15 minutes), to prevent unnecessary consumption of memory and network resources.

routing

normative-requirement §6.3.3 MUST NOT

When the RPLInstanceID candidate for a new RREP-Instance is already occupied by an active RREP-Instance, the occupied RPLInstanceID MUST NOT be reused; TargNode MUST choose a different value and encode the offset from the RREQ-InstanceID in the 6-bit Delta field of the RREP option, rolling over at 255.

routing

protocol-element §7

An intermediate router MAY send a Gratuitous RREP-DIO (G bit=1) back to OrigNode when it already holds valid upward and downward routes to TargNode satisfying the OF and with a sufficiently fresh Destination Sequence Number, allowing OrigNode to begin sending data before the RREQ reaches TargNode. Upstream routers receiving a G-RREP MUST also generate and forward a G-RREP upstream.

routing

protocol-element §3

AODV-RPL uses paired DODAG Instances: the RREQ-Instance (built by RREQ-DIO messages flowing OrigNode→TargNode) establishes the path for data from TargNode to OrigNode, while the RREP-Instance (built by RREP-DIO messages flowing TargNode→OrigNode) establishes the path for data from OrigNode to TargNode.

routing

protocol-element §6.3

TargNode MAY defer transmitting the RREP-DIO by RREP_WAIT_TIME (default one-quarter of the duration encoded in the L field; 0 when L=0) to allow higher-quality (lower-Rank) RREQ-DIOs to arrive. Smaller values favor faster route formation; larger values favor better-Rank routes.

routing

protocol-element §5

The S (Symmetric) bit in the RREQ option is initialized to 1 by OrigNode and cleared to 0 by any intermediate router for which the downward direction of the incoming link does not satisfy the OF. TargNode reads the final S bit value to decide whether to unicast the RREP along the known symmetric path (S=1) or to multicast the RREP-DIO to rebuild the asymmetric path (S=0).

routing

protocol-element §8

Trickle timer operations (RFC 6206) following RPL Section 8.3 control multicast RREQ-DIO and RREP-DIO transmissions for RREQ-Instance and RREP-Instance. Symmetric-route RREP-DIOs are unicast and do not use the Trickle timer.

routing

registry §9

IANA allocated IPv4 multicast address 224.0.0.69 with link-local scope, named 'all-AODV-RPL-nodes', in the Local Network Control Block (224.0.0/24) registry for nodes implementing AODV-RPL. RFC 9854 is also added as an additional reference for MOP=4 ('P2P Route Discovery') in the RPL 'Mode of Operation' registry.

registry, routing, multicast

registry §9

IANA assigned three new values in the 'RPL Control Message Options' registry (within the RPL registry group): 0x0B (RREQ option), 0x0C (RREP option), and 0x0D (ART option), all referencing RFC 9854.

registry, routing

security-consideration §10

AODV-RPL relies on RPL's optional security framework (RFC 6550 Section 6.1) for confidentiality, authentication, replay protection, and delay protection. A rogue router that possesses the group key can join route discovery, advertise false DIOs to insert itself into routes, generate bogus RREQ-DIO/RREP-DIO messages, or launch DoS attacks via fake route discoveries; RPL's preinstalled key mode SHOULD be used when rogue routers may be present.

security, routing

security-consideration §10

In source-routing mode (H=0), a rogue router may populate the Address Vector with a crafted set of addresses that causes the RREP-DIO to traverse a routing loop. Additionally, a rogue router that can forge a G-RREP could mount denial-of-service attacks against OrigNode by causing it to send data along a false route.

security, routing

wire-format §4.3

The ART option (Type 0x0D) contains: Option Type (8-bit), Option Length (8-bit), Dest SeqNo (8-bit), 1 reserved X bit, Prefix Length (7 bits), and a variable-length Target Prefix/Address field of Ceil(Prefix Length/8) octets; if Prefix Length is 0 the address field is 128 bits and represents an IPv6 address rather than a prefix.

routing

wire-format §4.2

The RREP option (Type 0x0C) contains: Option Type (8-bit), Option Length (8-bit), G/H/X flags (3 bits), Compr (4 bits), L (2 bits), RankLimit (8 bits), Delta (6 bits), 2 reserved bits, and an optional variable-length Address Vector (H=0 only). For symmetric routes the Address Vector is copied unchanged from the arriving RREQ-DIO; for asymmetric routes it records the RREP-DIO path.

routing

wire-format §4.1

The RREQ option (Type 0x0B) contains: Option Type (8-bit), Option Length (8-bit), S/H/X flags (3 bits), Compr (4 bits), L (2 bits), RankLimit (8 bits), Orig SeqNo (8 bits), and an optional variable-length Address Vector present only in source-routing mode (H=0) with prefix bytes elided per Compr.

routing