RFC 6550
RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks
Internet Engineering Task Force (IETF) T. Winter, Ed. Request for Comments: 6550 Category: Standards Track P. Thubert, Ed. ISSN: 2070-1721 Cisco Systems A. Brandt Sigma Designs J. Hui Arch Rock Corporation R. Kelsey Ember Corporation P. Levis Stanford University K. Pister Dust Networks R. Struik Struik Security Consultancy JP. Vasseur Cisco Systems R. Alexander Cooper Power Systems March 2012 RPL: IPv6 Routing Protocol for Low-Power and Lossy NetworksAbstract
Low-Power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained. LLN routers typically operate with constraints on processing power, memory, and energy (battery power). Their interconnects are characterized by high loss rates, low data rates, and instability. LLNs are comprised of anything from a few dozen to thousands of routers. Supported traffic flows include point-to-point (between devices inside the LLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN towards a central control point). This document specifies the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point as well as point-to-multipoint traffic from the central control point to the devices inside the LLN are supported. Support for point-to-point traffic is also available.
Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6550. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction ....................................................8 1.1. Design Principles ..........................................8 1.2. Expectations of Link-Layer Type ...........................10 2. Terminology ....................................................10 3. Protocol Overview ..............................................13 3.1. Topologies ................................................13 3.1.1. Constructing Topologies ............................13 3.1.2. RPL Identifiers ....................................14 3.1.3. Instances, DODAGs, and DODAG Versions ..............14 3.2. Upward Routes and DODAG Construction ......................16 3.2.1. Objective Function (OF) ............................17 3.2.2. DODAG Repair .......................................17 3.2.3. Security ...........................................17 3.2.4. Grounded and Floating DODAGs .......................18 3.2.5. Local DODAGs .......................................18 3.2.6. Administrative Preference ..........................18 3.2.7. Data-Path Validation and Loop Detection ............18 3.2.8. Distributed Algorithm Operation ....................19 3.3. Downward Routes and Destination Advertisement .............19 3.4. Local DODAGs Route Discovery ..............................20 3.5. Rank Properties ...........................................20 3.5.1. Rank Comparison (DAGRank()) ........................21 3.5.2. Rank Relationships .................................22 3.6. Routing Metrics and Constraints Used by RPL ...............23 3.7. Loop Avoidance ............................................24 3.7.1. Greediness and Instability .........................24 3.7.2. DODAG Loops ........................................26 3.7.3. DAO Loops ..........................................27 4. Traffic Flows Supported by RPL .................................27 4.1. Multipoint-to-Point Traffic ...............................27 4.2. Point-to-Multipoint Traffic ...............................27 4.3. Point-to-Point Traffic ....................................27 5. RPL Instance ...................................................28 5.1. RPL Instance ID ...........................................29 6. ICMPv6 RPL Control Message .....................................30 6.1. RPL Security Fields .......................................32 6.2. DODAG Information Solicitation (DIS) ......................38 6.2.1. Format of the DIS Base Object ......................38 6.2.2. Secure DIS .........................................38 6.2.3. DIS Options ........................................38 6.3. DODAG Information Object (DIO) ............................38 6.3.1. Format of the DIO Base Object ......................39 6.3.2. Secure DIO .........................................41 6.3.3. DIO Options ........................................41 6.4. Destination Advertisement Object (DAO) ....................41 6.4.1. Format of the DAO Base Object ......................42
6.4.2. Secure DAO .........................................43
6.4.3. DAO Options ........................................43
6.5. Destination Advertisement Object Acknowledgement
(DAO-ACK) .................................................43
6.5.1. Format of the DAO-ACK Base Object ..................44
6.5.2. Secure DAO-ACK .....................................45
6.5.3. DAO-ACK Options ....................................45
6.6. Consistency Check (CC) ....................................45
6.6.1. Format of the CC Base Object .......................46
6.6.2. CC Options .........................................47
6.7. RPL Control Message Options ...............................47
6.7.1. RPL Control Message Option Generic Format ..........47
6.7.2. Pad1 ...............................................48
6.7.3. PadN ...............................................48
6.7.4. DAG Metric Container ...............................49
6.7.5. Route Information ..................................50
6.7.6. DODAG Configuration ................................52
6.7.7. RPL Target .........................................54
6.7.8. Transit Information ................................55
6.7.9. Solicited Information ..............................58
6.7.10. Prefix Information ................................59
6.7.11. RPL Target Descriptor .............................63
7. Sequence Counters ..............................................63
7.1. Sequence Counter Overview .................................63
7.2. Sequence Counter Operation ................................64
8. Upward Routes ..................................................66
8.1. DIO Base Rules ............................................67
8.2. Upward Route Discovery and Maintenance ....................67
8.2.1. Neighbors and Parents within a DODAG Version .......67
8.2.2. Neighbors and Parents across DODAG Versions ........68
8.2.3. DIO Message Communication ..........................73
8.3. DIO Transmission ..........................................74
8.3.1. Trickle Parameters .................................75
8.4. DODAG Selection ...........................................75
8.5. Operation as a Leaf Node ..................................75
8.6. Administrative Rank .......................................76
9. Downward Routes ................................................77
9.1. Destination Advertisement Parents .........................77
9.2. Downward Route Discovery and Maintenance ..................78
9.2.1. Maintenance of Path Sequence .......................79
9.2.2. Generation of DAO Messages .........................79
9.3. DAO Base Rules ............................................80
9.4. Structure of DAO Messages .................................80
9.5. DAO Transmission Scheduling ...............................83
9.6. Triggering DAO Messages ...................................83
9.7. Non-Storing Mode ..........................................84
9.8. Storing Mode ..............................................85
9.9. Path Control ..............................................86
9.9.1. Path Control Example ...............................88
9.10. Multicast Destination Advertisement Messages .............89
10. Security Mechanisms ...........................................90
10.1. Security Overview ........................................90
10.2. Joining a Secure Network .................................91
10.3. Installing Keys ..........................................92
10.4. Consistency Checks .......................................93
10.5. Counters .................................................93
10.6. Transmission of Outgoing Packets .........................94
10.7. Reception of Incoming Packets ............................95
10.7.1. Timestamp Key Checks ..............................97
10.8. Coverage of Integrity and Confidentiality ................97
10.9. Cryptographic Mode of Operation ..........................98
10.9.1. CCM Nonce .........................................98
10.9.2. Signatures ........................................99
11. Packet Forwarding and Loop Avoidance/Detection ................99
11.1. Suggestions for Packet Forwarding ........................99
11.2. Loop Avoidance and Detection ............................101
11.2.1. Source Node Operation ............................102
11.2.2. Router Operation .................................102
12. Multicast Operation ..........................................104
13. Maintenance of Routing Adjacency .............................105
14. Guidelines for Objective Functions ...........................106
14.1. Objective Function Behavior .............................106
15. Suggestions for Interoperation with Neighbor Discovery .......108
16. Summary of Requirements for Interoperable Implementations ....109
16.1. Common Requirements .....................................109
16.2. Operation as a RPL Leaf Node (Only) .....................110
16.3. Operation as a RPL Router ...............................110
16.3.1. Support for Upward Routes (Only) .................110
16.3.2. Support for Upward Routes and Downward
Routes in Non-Storing ............................110
16.3.3. Support for Upward Routes and Downward
Routes in Storing Mode ...........................111
16.4. Items for Future Specification ..........................111
17. RPL Constants and Variables ..................................112
18. Manageability Considerations .................................113
18.1. Introduction ............................................114
18.2. Configuration Management ................................115
18.2.1. Initialization Mode ..............................115
18.2.2. DIO and DAO Base Message and Options
Configuration ....................................115
18.2.3. Protocol Parameters to Be Configured on
Every Router in the LLN ..........................116
18.2.4. Protocol Parameters to Be Configured on
Every Non-DODAG-Root .............................117
18.2.5. Parameters to Be Configured on the DODAG Root ....117
18.2.6. Configuration of RPL Parameters Related
to DAO-Based Mechanisms ..........................118
18.2.7. Configuration of RPL Parameters Related
to Security Mechanisms ...........................119
18.2.8. Default Values ...................................119
18.3. Monitoring of RPL Operation .............................120
18.3.1. Monitoring a DODAG Parameters ....................120
18.3.2. Monitoring a DODAG Inconsistencies and
Loop Detection ...................................121
18.4. Monitoring of the RPL Data Structures ...................121
18.4.1. Candidate Neighbor Data Structure ................121
18.4.2. Destination-Oriented Directed Acyclic
Graph (DODAG) Table ..............................122
18.4.3. Routing Table and DAO Routing Entries ............122
18.5. Fault Management ........................................123
18.6. Policy ..................................................124
18.7. Fault Isolation .........................................125
18.8. Impact on Other Protocols ...............................125
18.9. Performance Management ..................................126
18.10. Diagnostics ............................................126
19. Security Considerations ......................................126
19.1. Overview ................................................126
20. IANA Considerations ..........................................128
20.1. RPL Control Message .....................................128
20.2. New Registry for RPL Control Codes ......................128
20.3. New Registry for the Mode of Operation (MOP) ............129
20.4. RPL Control Message Option ..............................130
20.5. Objective Code Point (OCP) Registry .....................131
20.6. New Registry for the Security Section Algorithm .........131
20.7. New Registry for the Security Section Flags .............132
20.8. New Registry for Per-KIM Security Levels ................132
20.9. New Registry for DODAG Informational
Solicitation (DIS) Flags ................................133
20.10. New Registry for the DODAG Information Object
(DIO) Flags ............................................134
20.11. New Registry for the Destination Advertisement
Object (DAO) Flags .....................................134
20.12. New Registry for the Destination Advertisement
Object (DAO) Flags .....................................135
20.13. New Registry for the Consistency Check (CC) Flags ......135
20.14. New Registry for the DODAG Configuration Option Flags ..136
20.15. New Registry for the RPL Target Option Flags ...........136
20.16. New Registry for the Transit Information Option Flags ..137
20.17. New Registry for the Solicited Information
Option Flags ...........................................137
20.18. ICMPv6: Error in Source Routing Header .................138
20.19. Link-Local Scope Multicast Address .....................138
21. Acknowledgements .............................................138
22. Contributors .................................................139 23. References ...................................................139 23.1. Normative References ....................................139 23.2. Informative References ..................................140 Appendix A. Example Operation ....................................143 A.1. Example Operation in Storing Mode with Node-Owned Prefixes .................................................143 A.1.1. DIO Messages and PIO ..............................144 A.1.2. DAO Messages ......................................145 A.1.3. Routing Information Base ..........................145 A.2. Example Operation in Storing Mode with Subnet-Wide Prefix ...................................................146 A.2.1. DIO Messages and PIO ..............................147 A.2.2. DAO Messages ......................................148 A.2.3. Routing Information Base ..........................148 A.3. Example Operation in Non-Storing Mode with Node-Owned Prefixes .................................................149 A.3.1. DIO Messages and PIO ..............................150 A.3.2. DAO Messages ......................................150 A.3.3. Routing Information Base ..........................151 A.4. Example Operation in Non-Storing Mode with Subnet-Wide Prefix .......................................151 A.4.1. DIO Messages and PIO ..............................152 A.4.2. DAO Messages ......................................153 A.4.3. Routing Information Base ..........................153 A.5. Example with External Prefixes ...........................154
1. Introduction
Low-power and Lossy Networks (LLNs) consist largely of constrained nodes (with limited processing power, memory, and sometimes energy when they are battery operated or energy scavenging). These routers are interconnected by lossy links, typically supporting only low data rates, that are usually unstable with relatively low packet delivery rates. Another characteristic of such networks is that the traffic patterns are not simply point-to-point, but in many cases point-to- multipoint or multipoint-to-point. Furthermore, such networks may potentially comprise up to thousands of nodes. These characteristics offer unique challenges to a routing solution: the IETF ROLL working group has defined application-specific routing requirements for a Low-power and Lossy Network (LLN) routing protocol, specified in [RFC5867], [RFC5826], [RFC5673], and [RFC5548]. This document specifies the IPv6 Routing Protocol for LLNs (RPL). Note that although RPL was specified according to the requirements set forth in the aforementioned requirement documents, its use is in no way limited to these applications.1.1. Design Principles
RPL was designed with the objective to meet the requirements spelled out in [RFC5867], [RFC5826], [RFC5673], and [RFC5548]. A network may run multiple instances of RPL concurrently. Each such instance may serve different and potentially antagonistic constraints or performance criteria. This document defines how a single instance operates. In order to be useful in a wide range of LLN application domains, RPL separates packet processing and forwarding from the routing optimization objective. Examples of such objectives include minimizing energy, minimizing latency, or satisfying constraints. This document describes the mode of operation of RPL. Other companion documents specify routing Objective Functions. A RPL implementation, in support of a particular LLN application, will include the necessary Objective Function(s) as required by the application. RPL operations require bidirectional links. In some LLN scenarios, those links may exhibit asymmetric properties. It is required that the reachability of a router be verified before the router can be used as a parent. RPL expects an external mechanism to be triggered during the parent selection phase in order to verify link properties and neighbor reachability. Neighbor Unreachability Detection (NUD) is such a mechanism, but alternates are possible, including
Bidirectional Forwarding Detection (BFD) [RFC5881] and hints from lower layers via Layer 2 (L2) triggers like [RFC5184]. In a general fashion, a detection mechanism that is reactive to traffic is favored in order to minimize the cost of monitoring links that are not being used. RPL also expects an external mechanism to access and transport some control information, referred to as the "RPL Packet Information", in data packets. The RPL Packet Information is defined in Section 11.2 and enables the association of a data packet with a RPL Instance and the validation of RPL routing states. The RPL option [RFC6553] is an example of such mechanism. The mechanism is required for all packets except when strict source routing is used (that is for packets going Downward in Non-Storing mode as detailed further in Section 9), which by nature prevents endless loops and alleviates the need for the RPL Packet Information. Future companion specifications may propose alternate ways to carry the RPL Packet Information in the IPv6 packets and may extend the RPL Packet Information to support additional features. RPL provides a mechanism to disseminate information over the dynamically formed network topology. This dissemination enables minimal configuration in the nodes, allowing nodes to operate mostly autonomously. This mechanism uses Trickle [RFC6206] to optimize the dissemination as described in Section 8.3. In some applications, RPL assembles topologies of routers that own independent prefixes. Those prefixes may or may not be aggregatable depending on the origin of the routers. A prefix that is owned by a router is advertised as on-link. RPL also introduces the capability to bind a subnet together with a common prefix and to route within that subnet. A source can inject information about the subnet to be disseminated by RPL, and that source is authoritative for that subnet. Because many LLN links have non-transitive properties, a common prefix that RPL disseminates over the subnet must not be advertised as on-link. In particular, RPL may disseminate IPv6 Neighbor Discovery (ND) information such as the [RFC4861] Prefix Information Option (PIO) and the [RFC4191] Route Information Option (RIO). ND information that is disseminated by RPL conserves all its original semantics for router to host, with limited extensions for router to router, though it is not to be confused with routing advertisements and it is never to be directly redistributed in another routing protocol. A RPL node often combines host and router behaviors. As a host, it will process the options as specified in [RFC4191], [RFC4861], [RFC4862], and [RFC6275]. As a router, the RPL node may advertise the information
from the options as required for the specific link, for instance, in an ND Router Advertisement (RA) message, though the exact operation is out of scope. A set of companion documents to this specification will provide further guidance in the form of applicability statements specifying a set of operating points appropriate to the Building Automation, Home Automation, Industrial, and Urban application scenarios.1.2. Expectations of Link-Layer Type
In compliance with the layered architecture of IP, RPL does not rely on any particular features of a specific link-layer technology. RPL is designed to be able to operate over a variety of different link layers, including ones that are constrained, potentially lossy, or typically utilized in conjunction with highly constrained host or router devices, such as but not limited to, low-power wireless or PLC (Power Line Communication) technologies. Implementers may find [RFC3819] a useful reference when designing a link-layer interface between RPL and a particular link-layer technology.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Additionally, this document uses terminology from [ROLL-TERMS], and introduces the following terminology: DAG: Directed Acyclic Graph. A directed graph having the property that all edges are oriented in such a way that no cycles exist. All edges are contained in paths oriented toward and terminating at one or more root nodes. DAG root: A DAG root is a node within the DAG that has no outgoing edge. Because the graph is acyclic, by definition, all DAGs must have at least one DAG root and all paths terminate at a DAG root. Destination-Oriented DAG (DODAG): A DAG rooted at a single destination, i.e., at a single DAG root (the DODAG root) with no outgoing edges.
DODAG root: A DODAG root is the DAG root of a DODAG. The DODAG root
may act as a border router for the DODAG; in particular, it may
aggregate routes in the DODAG and may redistribute DODAG routes
into other routing protocols.
Virtual DODAG root: A Virtual DODAG root is the result of two or more
RPL routers, for instance, 6LoWPAN Border Routers (6LBRs),
coordinating to synchronize DODAG state and act in concert as
if they are a single DODAG root (with multiple interfaces),
with respect to the LLN. The coordination most likely occurs
between powered devices over a reliable transit link, and the
details of that scheme are out of scope for this specification
(to be defined in future companion specifications).
Up: Up refers to the direction from leaf nodes towards DODAG roots,
following DODAG edges. This follows the common terminology
used in graphs and depth-first-search, where vertices further
from the root are "deeper" or "down" and vertices closer to the
root are "shallower" or "up".
Down: Down refers to the direction from DODAG roots towards leaf
nodes, in the reverse direction of DODAG edges. This follows
the common terminology used in graphs and depth-first-search,
where vertices further from the root are "deeper" or "down" and
vertices closer to the root are "shallower" or "up".
Rank: A node's Rank defines the node's individual position relative
to other nodes with respect to a DODAG root. Rank strictly
increases in the Down direction and strictly decreases in the
Up direction. The exact way Rank is computed depends on the
DAG's Objective Function (OF). The Rank may analogously track
a simple topological distance, may be calculated as a function
of link metrics, and may consider other properties such as
constraints.
Objective Function (OF): An OF defines how routing metrics,
optimization objectives, and related functions are used to
compute Rank. Furthermore, the OF dictates how parents in the
DODAG are selected and, thus, the DODAG formation.
Objective Code Point (OCP): An OCP is an identifier that indicates
which Objective Function the DODAG uses.
RPLInstanceID: A RPLInstanceID is a unique identifier within a
network. DODAGs with the same RPLInstanceID share the same
Objective Function.
RPL Instance: A RPL Instance is a set of one or more DODAGs that
share a RPLInstanceID. At most, a RPL node can belong to one
DODAG in a RPL Instance. Each RPL Instance operates
independently of other RPL Instances. This document describes
operation within a single RPL Instance.
DODAGID: A DODAGID is the identifier of a DODAG root. The DODAGID is
unique within the scope of a RPL Instance in the LLN. The
tuple (RPLInstanceID, DODAGID) uniquely identifies a DODAG.
DODAG Version: A DODAG Version is a specific iteration ("Version") of
a DODAG with a given DODAGID.
DODAGVersionNumber: A DODAGVersionNumber is a sequential counter that
is incremented by the root to form a new Version of a DODAG. A
DODAG Version is identified uniquely by the (RPLInstanceID,
DODAGID, DODAGVersionNumber) tuple.
Goal: The Goal is an application-specific goal that is defined
outside the scope of RPL. Any node that roots a DODAG will
need to know about this Goal to decide whether or not the Goal
can be satisfied. A typical Goal is to construct the DODAG
according to a specific Objective Function and to keep
connectivity to a set of hosts (e.g., to use an Objective
Function that minimizes a metric and is connected to a specific
database host to store the collected data).
Grounded: A DODAG is grounded when the DODAG root can satisfy the
Goal.
Floating: A DODAG is floating if it is not grounded. A floating
DODAG is not expected to have the properties required to
satisfy the goal. It may, however, provide connectivity to
other nodes within the DODAG.
DODAG parent: A parent of a node within a DODAG is one of the
immediate successors of the node on a path towards the DODAG
root. A DODAG parent's Rank is lower than the node's. (See
Section 3.5.1).
Sub-DODAG: The sub-DODAG of a node is the set of other nodes whose
paths to the DODAG root pass through that node. Nodes in the
sub-DODAG of a node have a greater Rank than that node. (See
Section 3.5.1).
Local DODAG: Local DODAGs contain one and only one root node, and
they allow that single root node to allocate and manage a RPL
Instance, identified by a local RPLInstanceID, without
coordination with other nodes. Typically, this is done in
order to optimize routes to a destination within the LLN. (See
Section 5).
Global DODAG: A Global DODAG uses a global RPLInstanceID that may be
coordinated among several other nodes. (See Section 5).
DIO: DODAG Information Object (see Section 6.3)
DAO: Destination Advertisement Object (see Section 6.4)
DIS: DODAG Information Solicitation (see Section 6.2)
CC: Consistency Check (see Section 6.6)
As they form networks, LLN devices often mix the roles of host and
router when compared to traditional IP networks. In this document,
"host" refers to an LLN device that can generate but does not forward
RPL traffic; "router" refers to an LLN device that can forward as
well as generate RPL traffic; and "node" refers to any RPL device,
either a host or a router.
(page 13 continued on part 2)
