idnits 2.17.1 draft-pthubert-roll-rfc6550bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6550, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (4 December 2020) is 1239 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROLL P. Thubert, Ed. 3 Internet-Draft Cisco Systems 4 Updates: 6550 (if approved) T. Winter, Ed. 5 Intended status: Standards Track 4 December 2020 6 Expires: 7 June 2021 8 RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks 9 draft-pthubert-roll-rfc6550bis-00 11 Abstract 13 Low-Power and Lossy Networks (LLNs) are a class of network in which 14 both the routers and their interconnect are constrained. LLN routers 15 typically operate with constraints on processing power, memory, and 16 energy (battery power). Their interconnects are characterized by 17 high loss rates, low data rates, and instability. LLNs are comprised 18 of anything from a few dozen to thousands of routers. Supported 19 traffic flows include point-to-point (between devices inside the 20 LLN), point-to-multipoint (from a central control point to a subset 21 of devices inside the LLN), and multipoint-to-point (from devices 22 inside the LLN towards a central control point). This document 23 specifies the IPv6 Routing Protocol for Low-Power and Lossy Networks 24 (RPL), which provides a mechanism whereby multipoint-to-point traffic 25 from devices inside the LLN towards a central control point as well 26 as point-to-multipoint traffic from the central control point to the 27 devices inside the LLN are supported. Support for point-to-point 28 traffic is also available. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 7 June 2021. 47 Copyright Notice 49 Copyright (c) 2020 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Simplified BSD License text 58 as described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 64 1.1. Design Principles . . . . . . . . . . . . . . . . . . . . 7 65 1.2. Expectations of Link-Layer Type . . . . . . . . . . . . . 9 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12 68 3.1. Topologies . . . . . . . . . . . . . . . . . . . . . . . 12 69 3.1.1. Constructing Topologies . . . . . . . . . . . . . . . 12 70 3.1.2. RPL Identifiers . . . . . . . . . . . . . . . . . . . 13 71 3.1.3. Instances, DODAGs, and DODAG Versions . . . . . . . . 13 72 3.2. Upward Routes and DODAG Construction . . . . . . . . . . 15 73 3.2.1. Objective Function (OF) . . . . . . . . . . . . . . . 16 74 3.2.2. DODAG Repair . . . . . . . . . . . . . . . . . . . . 16 75 3.2.3. Security . . . . . . . . . . . . . . . . . . . . . . 16 76 3.2.4. Grounded and Floating DODAGs . . . . . . . . . . . . 17 77 3.2.5. Local DODAGs . . . . . . . . . . . . . . . . . . . . 17 78 3.2.6. Administrative Preference . . . . . . . . . . . . . . 17 79 3.2.7. Data-Path Validation and Loop Detection . . . . . . . 17 80 3.2.8. Distributed Algorithm Operation . . . . . . . . . . . 18 81 3.3. Downward Routes and Destination Advertisement . . . . . . 18 82 3.4. Local DODAGs Route Discovery . . . . . . . . . . . . . . 19 83 3.5. Rank Properties . . . . . . . . . . . . . . . . . . . . . 19 84 3.5.1. Rank Comparison (DAGRank()) . . . . . . . . . . . . . 20 85 3.5.2. Rank Relationships . . . . . . . . . . . . . . . . . 21 86 3.6. Routing Metrics and Constraints Used by RPL . . . . . . . 22 87 3.7. Loop Avoidance . . . . . . . . . . . . . . . . . . . . . 23 88 3.7.1. Greediness and Instability . . . . . . . . . . . . . 23 89 3.7.2. DODAG Loops . . . . . . . . . . . . . . . . . . . . . 25 90 3.7.3. DAO Loops . . . . . . . . . . . . . . . . . . . . . . 26 91 4. Traffic Flows Supported by RPL . . . . . . . . . . . . . . . 26 92 4.1. Multipoint-to-Point Traffic . . . . . . . . . . . . . . . 26 93 4.2. Point-to-Multipoint Traffic . . . . . . . . . . . . . . . 26 94 4.3. Point-to-Point Traffic . . . . . . . . . . . . . . . . . 26 96 5. RPL Instance . . . . . . . . . . . . . . . . . . . . . . . . 27 97 5.1. RPL Instance ID . . . . . . . . . . . . . . . . . . . . . 28 98 6. ICMPv6 RPL Control Message . . . . . . . . . . . . . . . . . 29 99 6.1. RPL Security Fields . . . . . . . . . . . . . . . . . . . 31 100 6.2. DODAG Information Solicitation (DIS) . . . . . . . . . . 35 101 6.2.1. Format of the DIS Base Object . . . . . . . . . . . . 36 102 6.2.2. Secure DIS . . . . . . . . . . . . . . . . . . . . . 36 103 6.2.3. DIS Options . . . . . . . . . . . . . . . . . . . . . 36 104 6.3. DODAG Information Object (DIO) . . . . . . . . . . . . . 36 105 6.3.1. Format of the DIO Base Object . . . . . . . . . . . . 36 106 6.3.2. Secure DIO . . . . . . . . . . . . . . . . . . . . . 38 107 6.3.3. DIO Options . . . . . . . . . . . . . . . . . . . . . 38 108 6.4. Destination Advertisement Object (DAO) . . . . . . . . . 39 109 6.4.1. Format of the DAO Base Object . . . . . . . . . . . . 39 110 6.4.2. Secure DAO . . . . . . . . . . . . . . . . . . . . . 40 111 6.4.3. DAO Options . . . . . . . . . . . . . . . . . . . . . 40 112 6.5. Destination Advertisement Object Acknowledgement 113 (DAO-ACK) . . . . . . . . . . . . . . . . . . . . . . . . 41 114 6.5.1. Format of the DAO-ACK Base Object . . . . . . . . . . 41 115 6.5.2. Secure DAO-ACK . . . . . . . . . . . . . . . . . . . 42 116 6.5.3. DAO-ACK Options . . . . . . . . . . . . . . . . . . . 42 117 6.6. Consistency Check (CC) . . . . . . . . . . . . . . . . . 42 118 6.6.1. Format of the CC Base Object . . . . . . . . . . . . 42 119 6.6.2. CC Options . . . . . . . . . . . . . . . . . . . . . 44 120 6.7. RPL Control Message Options . . . . . . . . . . . . . . . 44 121 6.7.1. RPL Control Message Option Generic Format . . . . . . 44 122 6.7.2. Pad1 . . . . . . . . . . . . . . . . . . . . . . . . 45 123 6.7.3. PadN . . . . . . . . . . . . . . . . . . . . . . . . 45 124 6.7.4. DAG Metric Container . . . . . . . . . . . . . . . . 46 125 6.7.5. Route Information . . . . . . . . . . . . . . . . . . 47 126 6.7.6. DODAG Configuration . . . . . . . . . . . . . . . . . 48 127 6.7.7. RPL Target . . . . . . . . . . . . . . . . . . . . . 50 128 6.7.8. Transit Information . . . . . . . . . . . . . . . . . 52 129 6.7.9. Solicited Information . . . . . . . . . . . . . . . . 55 130 6.7.10. Prefix Information . . . . . . . . . . . . . . . . . 56 131 6.7.11. RPL Target Descriptor . . . . . . . . . . . . . . . . 59 132 7. Sequence Counters . . . . . . . . . . . . . . . . . . . . . . 60 133 7.1. Sequence Counter Overview . . . . . . . . . . . . . . . . 60 134 7.2. Sequence Counter Operation . . . . . . . . . . . . . . . 61 135 8. Upward Routes . . . . . . . . . . . . . . . . . . . . . . . . 63 136 8.1. DIO Base Rules . . . . . . . . . . . . . . . . . . . . . 63 137 8.2. Upward Route Discovery and Maintenance . . . . . . . . . 64 138 8.2.1. Neighbors and Parents within a DODAG Version . . . . 64 139 8.2.2. Neighbors and Parents across DODAG Versions . . . . . 65 140 8.2.3. DIO Message Communication . . . . . . . . . . . . . . 70 141 8.3. DIO Transmission . . . . . . . . . . . . . . . . . . . . 71 142 8.3.1. Trickle Parameters . . . . . . . . . . . . . . . . . 72 143 8.4. DODAG Selection . . . . . . . . . . . . . . . . . . . . . 72 144 8.5. Operation as a Leaf Node . . . . . . . . . . . . . . . . 72 145 8.6. Administrative Rank . . . . . . . . . . . . . . . . . . . 73 146 9. Downward Routes . . . . . . . . . . . . . . . . . . . . . . . 74 147 9.1. Destination Advertisement Parents . . . . . . . . . . . . 74 148 9.2. Downward Route Discovery and Maintenance . . . . . . . . 75 149 9.2.1. Maintenance of Path Sequence . . . . . . . . . . . . 76 150 9.2.2. Generation of DAO Messages . . . . . . . . . . . . . 77 151 9.3. DAO Base Rules . . . . . . . . . . . . . . . . . . . . . 77 152 9.4. Structure of DAO Messages . . . . . . . . . . . . . . . . 78 153 9.5. DAO Transmission Scheduling . . . . . . . . . . . . . . . 80 154 9.6. Triggering DAO Messages . . . . . . . . . . . . . . . . . 80 155 9.7. Non-Storing Mode . . . . . . . . . . . . . . . . . . . . 81 156 9.8. Storing Mode . . . . . . . . . . . . . . . . . . . . . . 82 157 9.9. Path Control . . . . . . . . . . . . . . . . . . . . . . 83 158 9.9.1. Path Control Example . . . . . . . . . . . . . . . . 85 159 9.10. Multicast Destination Advertisement Messages . . . . . . 86 160 10. Security Mechanisms . . . . . . . . . . . . . . . . . . . . . 87 161 10.1. Security Overview . . . . . . . . . . . . . . . . . . . 87 162 10.2. Joining a Secure Network . . . . . . . . . . . . . . . . 89 163 10.3. Installing Keys . . . . . . . . . . . . . . . . . . . . 90 164 10.4. Consistency Checks . . . . . . . . . . . . . . . . . . . 90 165 10.5. Counters . . . . . . . . . . . . . . . . . . . . . . . . 90 166 10.6. Transmission of Outgoing Packets . . . . . . . . . . . . 91 167 10.7. Reception of Incoming Packets . . . . . . . . . . . . . 92 168 10.7.1. Timestamp Key Checks . . . . . . . . . . . . . . . . 94 169 10.8. Coverage of Integrity and Confidentiality . . . . . . . 94 170 10.9. Cryptographic Mode of Operation . . . . . . . . . . . . 95 171 10.9.1. CCM Nonce . . . . . . . . . . . . . . . . . . . . . 95 172 10.9.2. Signatures . . . . . . . . . . . . . . . . . . . . . 96 173 11. Packet Forwarding and Loop Avoidance/Detection . . . . . . . 97 174 11.1. Suggestions for Packet Forwarding . . . . . . . . . . . 97 175 11.2. Loop Avoidance and Detection . . . . . . . . . . . . . . 98 176 11.2.1. Source Node Operation . . . . . . . . . . . . . . . 99 177 11.2.2. Router Operation . . . . . . . . . . . . . . . . . . 99 178 12. Multicast Operation . . . . . . . . . . . . . . . . . . . . . 101 179 13. Maintenance of Routing Adjacency . . . . . . . . . . . . . . 103 180 14. Guidelines for Objective Functions . . . . . . . . . . . . . 103 181 14.1. Objective Function Behavior . . . . . . . . . . . . . . 104 182 15. Suggestions for Interoperation with Neighbor Discovery . . . 105 183 16. Summary of Requirements for Interoperable Implementations . . 106 184 16.1. Common Requirements . . . . . . . . . . . . . . . . . . 107 185 16.2. Operation as a RPL Leaf Node (Only) . . . . . . . . . . 107 186 16.3. Operation as a RPL Router . . . . . . . . . . . . . . . 107 187 16.3.1. Support for Upward Routes (Only) . . . . . . . . . . 108 188 16.3.2. Support for Upward Routes and Downward Routes in 189 Non-Storing . . . . . . . . . . . . . . . . . . . . . 108 190 16.3.3. Support for Upward Routes and Downward Routes in 191 Storing Mode . . . . . . . . . . . . . . . . . . . . 108 193 16.4. Items for Future Specification . . . . . . . . . . . . . 109 194 17. RPL Constants and Variables . . . . . . . . . . . . . . . . . 109 195 18. Manageability Considerations . . . . . . . . . . . . . . . . 111 196 18.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 111 197 18.2. Configuration Management . . . . . . . . . . . . . . . . 112 198 18.2.1. Initialization Mode . . . . . . . . . . . . . . . . 112 199 18.2.2. DIO and DAO Base Message and Options 200 Configuration . . . . . . . . . . . . . . . . . . . . 113 201 18.2.3. Protocol Parameters to Be Configured on Every Router 202 in the LLN . . . . . . . . . . . . . . . . . . . . . 113 203 18.2.4. Protocol Parameters to Be Configured on Every 204 Non-DODAG-Root Router in the LLN . . . . . . . . . . 114 205 18.2.5. Parameters to Be Configured on the DODAG Root . . . 115 206 18.2.6. Configuration of RPL Parameters Related to DAO-Based 207 Mechanisms . . . . . . . . . . . . . . . . . . . . . 116 208 18.2.7. Configuration of RPL Parameters Related to Security 209 Mechanisms . . . . . . . . . . . . . . . . . . . . . 116 210 18.2.8. Default Values . . . . . . . . . . . . . . . . . . . 117 211 18.3. Monitoring of RPL Operation . . . . . . . . . . . . . . 117 212 18.3.1. Monitoring a DODAG Parameters . . . . . . . . . . . 118 213 18.3.2. Monitoring a DODAG Inconsistencies and Loop 214 Detection . . . . . . . . . . . . . . . . . . . . . . 119 215 18.4. Monitoring of the RPL Data Structures . . . . . . . . . 119 216 18.4.1. Candidate Neighbor Data Structure . . . . . . . . . 119 217 18.4.2. Destination-Oriented Directed Acyclic Graph (DODAG) 218 Table . . . . . . . . . . . . . . . . . . . . . . . . 119 219 18.4.3. Routing Table and DAO Routing Entries . . . . . . . 120 220 18.5. Fault Management . . . . . . . . . . . . . . . . . . . . 121 221 18.6. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 122 222 18.7. Fault Isolation . . . . . . . . . . . . . . . . . . . . 123 223 18.8. Impact on Other Protocols . . . . . . . . . . . . . . . 123 224 18.9. Performance Management . . . . . . . . . . . . . . . . . 123 225 18.10. Diagnostics . . . . . . . . . . . . . . . . . . . . . . 124 226 19. Security Considerations . . . . . . . . . . . . . . . . . . . 124 227 19.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 124 228 20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 126 229 20.1. RPL Control Message . . . . . . . . . . . . . . . . . . 126 230 20.2. New Registry for RPL Control Codes> . . . . . . . . . . 126 231 20.3. New Registry for the Mode of Operation (MOP) . . . . . . 127 232 20.4. RPL Control Message Options . . . . . . . . . . . . . . 128 233 20.5. Objective Code Point (OCP) Registry . . . . . . . . . . 129 234 20.6. New Registry for the Security Section Algorithm . . . . 129 235 20.7. New Registry for the Security Section Flags . . . . . . 130 236 20.8. New Registry for Per-KIM Security Levels . . . . . . . . 130 237 20.9. New Registry for DODAG Informational Solicitation (DIS) 238 Flags . . . . . . . . . . . . . . . . . . . . . . . . . 131 239 20.10. New Registry for the DODAG Information Object (DIO) 240 Flags . . . . . . . . . . . . . . . . . . . . . . . . . 132 242 20.11. New Registry for the Destination Advertisement Object 243 (DAO) Flags . . . . . . . . . . . . . . . . . . . . . . 132 244 20.12. New Registry for the Destination Advertisement Object 245 (DAO) Acknowledgement Flags . . . . . . . . . . . . . . 133 246 20.13. New Registry for the Consistency Check (CC) Flags . . . 133 247 20.14. New Registry for the DODAG Configuration Option Flags . 134 248 20.15. New Registry for the RPL Target Option Flags . . . . . . 134 249 20.16. New Registry for the Transit Information Option Flags . 135 250 20.17. New Registry for the Solicited Information Option 251 Flags . . . . . . . . . . . . . . . . . . . . . . . . . 135 252 20.18. ICMPv6: Error in Source Routing Header . . . . . . . . . 136 253 20.19. Link-Local Scope Multicast Address . . . . . . . . . . . 136 254 21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 136 255 22. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 137 256 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 138 257 23.1. Normative References . . . . . . . . . . . . . . . . . . 138 258 23.2. Informative References . . . . . . . . . . . . . . . . . 140 259 Appendix A. Example Operation . . . . . . . . . . . . . . . . . 143 260 A.1. Example Operation in Storing Mode with Node-Owned 261 Prefixes . . . . . . . . . . . . . . . . . . . . . . . . 143 262 A.1.1. DIO Messages and PIO . . . . . . . . . . . . . . . . 144 263 A.1.2. DAO Messages . . . . . . . . . . . . . . . . . . . . 145 264 A.1.3. Routing Information Base . . . . . . . . . . . . . . 145 265 A.2. Example Operation in Storing Mode with Subnet-Wide 266 Prefix . . . . . . . . . . . . . . . . . . . . . . . . . 146 267 A.2.1. DIO Messages and PIO . . . . . . . . . . . . . . . . 147 268 A.2.2. DAO Messages . . . . . . . . . . . . . . . . . . . . 147 269 A.2.3. Routing Information Base . . . . . . . . . . . . . . 148 270 A.3. Example Operation in Non-Storing Mode with Node-Owned 271 Prefixes . . . . . . . . . . . . . . . . . . . . . . . . 148 272 A.3.1. DIO Messages and PIO . . . . . . . . . . . . . . . . 149 273 A.3.2. DAO Messages . . . . . . . . . . . . . . . . . . . . 149 274 A.3.3. Routing Information Base . . . . . . . . . . . . . . 150 275 A.4. Example Operation in Non-Storing Mode with Subnet-Wide 276 Prefix . . . . . . . . . . . . . . . . . . . . . . . . . 150 277 A.4.1. DIO Messages and PIO . . . . . . . . . . . . . . . . 151 278 A.4.2. DAO Messages . . . . . . . . . . . . . . . . . . . . 152 279 A.4.3. Routing Information Base . . . . . . . . . . . . . . 152 280 A.5. Example with External Prefixes . . . . . . . . . . . . . 153 281 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 154 283 1. Introduction 285 Low-power and Lossy Networks (LLNs) consist largely of constrained 286 nodes (with limited processing power, memory, and sometimes energy 287 when they are battery operated or energy scavenging). These routers 288 are interconnected by lossy links, typically supporting only low data 289 rates, that are usually unstable with relatively low packet delivery 290 rates. Another characteristic of such networks is that the traffic 291 patterns are not simply point-to-point, but in many cases point-to- 292 multipoint or multipoint-to-point. Furthermore, such networks may 293 potentially comprise up to thousands of nodes. These characteristics 294 offer unique challenges to a routing solution: the IETF ROLL working 295 group has defined application-specific routing requirements for a 296 Low-power and Lossy Network (LLN) routing protocol, specified in 297 [RFC5867], [RFC5826], [RFC5673], and [RFC5548]. 299 This document specifies the IPv6 Routing Protocol for LLNs (RPL). 300 Note that although RPL was specified according to the requirements 301 set forth in the aforementioned requirement documents, its use is in 302 no way limited to these applications. 304 1.1. Design Principles 306 RPL was designed with the objective to meet the requirements spelled 307 out in [RFC5867], [RFC5826], [RFC5673], and [RFC5548]. 309 A network may run multiple instances of RPL concurrently. Each such 310 instance may serve different and potentially antagonistic constraints 311 or performance criteria. This document defines how a single instance 312 operates. 314 In order to be useful in a wide range of LLN application domains, RPL 315 separates packet processing and forwarding from the routing 316 optimization objective. Examples of such objectives include 317 minimizing energy, minimizing latency, or satisfying constraints. 318 This document describes the mode of operation of RPL. Other 319 companion documents specify routing Objective Functions. A RPL 320 implementation, in support of a particular LLN application, will 321 include the necessary Objective Function(s) as required by the 322 application. 324 RPL operations require bidirectional links. In some LLN scenarios, 325 those links may exhibit asymmetric properties. It is required that 326 the reachability of a router be verified before the router can be 327 used as a parent. RPL expects an external mechanism to be triggered 328 during the parent selection phase in order to verify link properties 329 and neighbor reachability. Neighbor Unreachability Detection (NUD) 330 is such a mechanism, but alternates are possible, including 331 Bidirectional Forwarding Detection (BFD) [RFC5881] and hints from 332 lower layers via Layer 2 (L2) triggers like [RFC5184]. In a general 333 fashion, a detection mechanism that is reactive to traffic is favored 334 in order to minimize the cost of monitoring links that are not being 335 used. 337 RPL also expects an external mechanism to access and transport some 338 control information, referred to as the "RPL Packet Information", in 339 data packets. The RPL Packet Information is defined in Section 11.2 340 and enables the association of a data packet with a RPL Instance and 341 the validation of RPL routing states. The RPL option [RFC6553] is an 342 example of such mechanism. The mechanism is required for all packets 343 except when strict source routing is used (that is for packets going 344 Downward in Non-Storing mode as detailed further in Section 9), which 345 by nature prevents endless loops and alleviates the need for the RPL 346 Packet Information. Future companion specifications may propose 347 alternate ways to carry the RPL Packet Information in the IPv6 348 packets and may extend the RPL Packet Information to support 349 additional features. 351 RPL provides a mechanism to disseminate information over the 352 dynamically formed network topology. This dissemination enables 353 minimal configuration in the nodes, allowing nodes to operate mostly 354 autonomously. This mechanism uses Trickle [RFC6206] to optimize the 355 dissemination as described in Section 8.3. 357 In some applications, RPL assembles topologies of routers that own 358 independent prefixes. Those prefixes may or may not be aggregatable 359 depending on the origin of the routers. A prefix that is owned by a 360 router is advertised as on-link. 362 RPL also introduces the capability to bind a subnet together with a 363 common prefix and to route within that subnet. A source can inject 364 information about the subnet to be disseminated by RPL, and that 365 source is authoritative for that subnet. Because many LLN links have 366 non-transitive properties, a common prefix that RPL disseminates over 367 the subnet must not be advertised as on-link. 369 In particular, RPL may disseminate IPv6 Neighbor Discovery (ND) 370 information such as the [RFC4861] Prefix Information Option (PIO) and 371 the [RFC4191] Route Information Option (RIO). ND information that is 372 disseminated by RPL conserves all its original semantics for router 373 to host, with limited extensions for router to router, though it is 374 not to be confused with routing advertisements and it is never to be 375 directly redistributed in another routing protocol. A RPL node often 376 combines host and router behaviors. As a host, it will process the 377 options as specified in [RFC4191], [RFC4861], [RFC4862], and 378 [RFC6275]. As a router, the RPL node may advertise the information 379 from the options as required for the specific link, for instance, in 380 an ND Router Advertisement (RA) message, though the exact operation 381 is out of scope. 383 A set of companion documents to this specification will provide 384 further guidance in the form of applicability statements specifying a 385 set of operating points appropriate to the Building Automation, Home 386 Automation, Industrial, and Urban application scenarios. 388 1.2. Expectations of Link-Layer Type 390 In compliance with the layered architecture of IP, RPL does not rely 391 on any particular features of a specific link-layer technology. RPL 392 is designed to be able to operate over a variety of different link 393 layers, including ones that are constrained, potentially lossy, or 394 typically utilized in conjunction with highly constrained host or 395 router devices, such as but not limited to, low-power wireless or PLC 396 (Power Line Communication) technologies. 398 Implementers may find [RFC3819] a useful reference when designing a 399 link-layer interface between RPL and a particular link-layer 400 technology. 402 2. Terminology 404 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 405 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 406 "OPTIONAL" in this document are to be interpreted as described in RFC 407 2119 [RFC2119]. 409 Additionally, this document uses terminology from [ROLL-TERMS], and 410 introduces the following terminology: 412 DAG: Directed Acyclic Graph. A directed graph having the property 413 that all edges are oriented in such a way that no cycles exist. 414 All edges are contained in paths oriented toward and 415 terminating at one or more root nodes. 417 DAG root: A DAG root is a node within the DAG that has no outgoing 418 edge. Because the graph is acyclic, by definition, all DAGs 419 must have at least one DAG root and all paths terminate at a 420 DAG root. 422 Destination-Oriented DAG (DODAG): A DAG rooted at a single 423 destination, i.e., at a single DAG root (the DODAG root) with 424 no outgoing edges. 426 DODAG root: A DODAG root is the DAG root of a DODAG. The DODAG root 427 may act as a border router for the DODAG; in particular, it may 428 aggregate routes in the DODAG and may redistribute DODAG routes 429 into other routing protocols. 431 Virtual DODAG root: A Virtual DODAG root is the result of two or 432 more RPL routers, for instance, 6LoWPAN Border Routers (6LBRs), 433 coordinating to synchronize DODAG state and act in concert as 434 if they are a single DODAG root (with multiple interfaces), 435 with respect to the LLN. The coordination most likely occurs 436 between powered devices over a reliable transit link, and the 437 details of that scheme are out of scope for this specification 438 (to be defined in future companion specifications). 440 Up: Up refers to the direction from leaf nodes towards DODAG roots, 441 following DODAG edges. This follows the common terminology 442 used in graphs and depth-first-search, where vertices further 443 from the root are "deeper" or "down" and vertices closer to the 444 root are "shallower" or "up". 446 Down: Down refers to the direction from DODAG roots towards leaf 447 nodes, in the reverse direction of DODAG edges. This follows 448 the common terminology used in graphs and depth-first-search, 449 where vertices further from the root are "deeper" or "down" and 450 vertices closer to the root are "shallower" or "up". 452 Rank: A node's Rank defines the node's individual position relative 453 to other nodes with respect to a DODAG root. Rank strictly 454 increases in the Down direction and strictly decreases in the 455 Up direction. The exact way Rank is computed depends on the 456 DAG's Objective Function (OF). The Rank may analogously track 457 a simple topological distance, may be calculated as a function 458 of link metrics, and may consider other properties such as 459 constraints. 461 Objective Function (OF): An OF defines how routing metrics, 462 optimization objectives, and related functions are used to 463 compute Rank. Furthermore, the OF dictates how parents in the 464 DODAG are selected and, thus, the DODAG formation. 466 Objective Code Point (OCP): An OCP is an identifier that indicates 467 which Objective Function the DODAG uses. 469 RPLInstanceID: A RPLInstanceID is a unique identifier within a 470 network. DODAGs with the same RPLInstanceID share the same 471 Objective Function. 473 RPL Instance: A RPL Instance is a set of one or more DODAGs that 474 share a RPLInstanceID. At most, a RPL node can belong to one 475 DODAG in a RPL Instance. Each RPL Instance operates 476 independently of other RPL Instances. This document describes 477 operation within a single RPL Instance. 479 DODAGID: A DODAGID is the identifier of a DODAG root. The DODAGID 480 is unique within the scope of a RPL Instance in the LLN. The 481 tuple (RPLInstanceID, DODAGID) uniquely identifies a DODAG. 483 DODAG Version: A DODAG Version is a specific iteration ("Version") 484 of a DODAG with a given DODAGID. 486 DODAGVersionNumber: A DODAGVersionNumber is a sequential counter 487 that is incremented by the root to form a new Version of a 488 DODAG. A DODAG Version is identified uniquely by the 489 (RPLInstanceID, DODAGID, DODAGVersionNumber) tuple. 491 Goal: The Goal is an application-specific goal that is defined 492 outside the scope of RPL. Any node that roots a DODAG will 493 need to know about this Goal to decide whether or not the Goal 494 can be satisfied. A typical Goal is to construct the DODAG 495 according to a specific Objective Function and to keep 496 connectivity to a set of hosts (e.g., to use an Objective 497 Function that minimizes a metric and is connected to a specific 498 database host to store the collected data). 500 Grounded: A DODAG is grounded when the DODAG root can satisfy the 501 Goal. 503 Floating: A DODAG is floating if it is not grounded. A floating 504 DODAG is not expected to have the properties required to 505 satisfy the goal. It may, however, provide connectivity to 506 other nodes within the DODAG. 508 DODAG parent: A parent of a node within a DODAG is one of the 509 immediate successors of the node on a path towards the DODAG 510 root. A DODAG parent's Rank is lower than the node's. (See 511 Section 3.5.1). 513 Sub-DODAG: The sub-DODAG of a node is the set of other nodes whose 514 paths to the DODAG root pass through that node. Nodes in the 515 sub-DODAG of a node have a greater Rank than that node. (See 516 Section 3.5.1). 518 Local DODAG: Local DODAGs contain one and only one root node, and 519 they allow that single root node to allocate and manage a RPL 520 Instance, identified by a local RPLInstanceID, without 521 coordination with other nodes. Typically, this is done in 522 order to optimize routes to a destination within the LLN. (See 523 Section 5). 525 Global DODAG: A Global DODAG uses a global RPLInstanceID that may be 526 coordinated among several other nodes. (See Section 5). 528 DIO: DODAG Information Object (see Section 6.3) 530 DAO: Destination Advertisement Object (see Section 6.4) 532 DIS: DODAG Information Solicitation (see Section 6.2) 534 CC: Consistency Check (see Section 6.6) 536 As they form networks, LLN devices often mix the roles of host and 537 router when compared to traditional IP networks. In this document, 538 "host" refers to an LLN device that can generate but does not forward 539 RPL traffic; "router" refers to an LLN device that can forward as 540 well as generate RPL traffic; and "node" refers to any RPL device, 541 either a host or a router. 543 3. Protocol Overview 545 The aim of this section is to describe RPL in the spirit of 546 [RFC4101]. Protocol details can be found in further sections. 548 3.1. Topologies 550 This section describes the basic RPL topologies that may be formed, 551 and the rules by which these are constructed, i.e., the rules 552 governing DODAG formation. 554 3.1.1. Constructing Topologies 556 LLNs, such as Radio Networks, do not typically have predefined 557 topologies, for example, those imposed by point-to-point wires, so 558 RPL has to discover links and then select peers sparingly. 560 In many cases, because Layer 2 ranges overlap only partially, RPL 561 forms non-transitive / Non-Broadcast Multi-Access (NBMA) network 562 topologies upon which it computes routes. 564 RPL routes are optimized for traffic to or from one or more roots 565 that act as sinks for the topology. As a result, RPL organizes a 566 topology as a Directed Acyclic Graph (DAG) that is partitioned into 567 one or more Destination Oriented DAGs (DODAGs), one DODAG per sink. 568 If the DAG has multiple roots, then it is expected that the roots are 569 federated by a common backbone, such as a transit link. 571 3.1.2. RPL Identifiers 573 RPL uses four values to identify and maintain a topology: 575 * The first is a RPLInstanceID. A RPLInstanceID identifies a set of 576 one or more Destination Oriented DAGs (DODAGs). A network may 577 have multiple RPLInstanceIDs, each of which defines an independent 578 set of DODAGs, which may be optimized for different Objective 579 Functions (OFs) and/or applications. The set of DODAGs identified 580 by a RPLInstanceID is called a RPL Instance. All DODAGs in the 581 same RPL Instance use the same OF. 583 * The second is a DODAGID. The scope of a DODAGID is a RPL 584 Instance. The combination of RPLInstanceID and DODAGID uniquely 585 identifies a single DODAG in the network. A RPL Instance may have 586 multiple DODAGs, each of which has an unique DODAGID. 588 * The third is a DODAGVersionNumber. The scope of a 589 DODAGVersionNumber is a DODAG. A DODAG is sometimes reconstructed 590 from the DODAG root, by incrementing the DODAGVersionNumber. The 591 combination of RPLInstanceID, DODAGID, and DODAGVersionNumber 592 uniquely identifies a DODAG Version. 594 * The fourth is Rank. The scope of Rank is a DODAG Version. Rank 595 establishes a partial order over a DODAG Version, defining 596 individual node positions with respect to the DODAG root. 598 3.1.3. Instances, DODAGs, and DODAG Versions 600 A RPL Instance contains one or more DODAG roots. A RPL Instance may 601 provide routes to certain destination prefixes, reachable via the 602 DODAG roots or alternate paths within the DODAG. These roots may 603 operate independently, or they may coordinate over a network that is 604 not necessarily as constrained as an LLN. 606 A RPL Instance may comprise: 608 * a single DODAG with a single root 610 - For example, a DODAG optimized to minimize latency rooted at a 611 single centralized lighting controller in a Home Automation 612 application. 614 * multiple uncoordinated DODAGs with independent roots (differing 615 DODAGIDs) 617 - For example, multiple data collection points in an urban data 618 collection application that do not have suitable connectivity 619 to coordinate with each other or that use the formation of 620 multiple DODAGs as a means to dynamically and autonomously 621 partition the network. 623 * a single DODAG with a virtual root that coordinates LLN sinks 624 (with the same DODAGID) over a backbone network. 626 - For example, multiple border routers operating with a reliable 627 transit link, e.g., in support of an IPv6 Low-Power Wireless 628 Personal Area Network (6LoWPAN) application, that are capable 629 of acting as logically equivalent interfaces to the sink of the 630 same DODAG. 632 * a combination of the above as suited to some application scenario. 634 Each RPL packet is associated with a particular RPLInstanceID (see 635 Section 11 ) and, therefore, RPL Instance (Section 5). The 636 provisioning or automated discovery of a mapping between a 637 RPLInstanceID and a type or service of application traffic is out of 638 scope for this specification (to be defined in future companion 639 specifications). 641 Figure 1 depicts an example of a RPL Instance comprising three DODAGs 642 with DODAG roots R1, R2, and R3. Each of these DODAG roots 643 advertises the same RPLInstanceID. The lines depict connectivity 644 between parents and children. 646 Figure 2 depicts how a DODAGVersionNumber increment leads to a new 647 DODAG Version. This depiction illustrates a DODAGVersionNumber 648 increment that results in a different DODAG topology. Note that a 649 new DODAG Version does not always imply a different DODAG topology. 650 To accommodate certain topology changes requires a new DODAG Version, 651 as described later in this specification. 653 In the following examples, please note that tree-like structures are 654 depicted for simplicity, although the DODAG structure allows for each 655 node to have multiple parents when the connectivity supports it. 657 +----------------------------------------------------------------+ 658 | | 659 | +--------------+ | 660 | | | | 661 | | (R1) | (R2) (R3) | 662 | | / \ | /| \ / | \ | 663 | | / \ | / | \ / | \ | 664 | | (A) (B) | (C) | (D) ... (F) (G) (H) | 665 | | /|\ |\ | / | / |\ |\ | | | 666 | | : : : : : | : (E) : : : `: : | 667 | | | / \ | 668 | +--------------+ : : | 669 | DODAG | 670 | | 671 +----------------------------------------------------------------+ 672 RPL Instance 674 Figure 1: RPL Instance 676 +----------------+ +----------------+ 677 | | | | 678 | (R1) | | (R1) | 679 | / \ | | / | 680 | / \ | | / | 681 | (A) (B) | \ | (A) | 682 | /|\ / |\ | ------\ | /|\ | 683 | : : (C) : : | \ | : : (C) | 684 | | / | \ | 685 | | ------/ | \ | 686 | | / | (B) | 687 | | | |\ | 688 | | | : : | 689 | | | | 690 +----------------+ +----------------+ 691 Version N Version N+1 693 Figure 2: DODAG Version 695 3.2. Upward Routes and DODAG Construction 697 RPL provisions routes Up towards DODAG roots, forming a DODAG 698 optimized according to an Objective Function (OF). RPL nodes 699 construct and maintain these DODAGs through DODAG Information Object 700 (DIO) messages. 702 3.2.1. Objective Function (OF) 704 The Objective Function (OF) defines how RPL nodes select and optimize 705 routes within a RPL Instance. The OF is identified by an Objective 706 Code Point (OCP) within the DIO Configuration option. An OF defines 707 how nodes translate one or more metrics and constraints, which are 708 themselves defined in [RFC6551], into a value called Rank, which 709 approximates the node's distance from a DODAG root. An OF also 710 defines how nodes select parents. Further details may be found in 711 Section 14, [RFC6551], [RFC6552], and related companion 712 specifications. 714 3.2.2. DODAG Repair 716 A DODAG root institutes a global repair operation by incrementing the 717 DODAGVersionNumber. This initiates a new DODAG Version. Nodes in 718 the new DODAG Version can choose a new position whose Rank is not 719 constrained by their Rank within the old DODAG Version. 721 RPL also supports mechanisms that may be used for local repair within 722 the DODAG Version. The DIO message specifies the necessary 723 parameters as configured from and controlled by policy at the DODAG 724 root. 726 3.2.3. Security 728 RPL supports message confidentiality and integrity. It is designed 729 such that link-layer mechanisms can be used when available and 730 appropriate; yet, in their absence, RPL can use its own mechanisms. 731 RPL has three basic security modes. 733 In the first, called "unsecured", RPL control messages are sent 734 without any additional security mechanisms. Unsecured mode does not 735 imply that the RPL network is unsecure: it could be using other 736 present security primitives (e.g., link-layer security) to meet 737 application security requirements. 739 In the second, called "preinstalled", nodes joining a RPL Instance 740 have preinstalled keys that enable them to process and generate 741 secured RPL messages. 743 The third mode is called "authenticated". In authenticated mode, 744 nodes have preinstalled keys as in preinstalled mode, but the 745 preinstalled key may only be used to join a RPL Instance as a leaf. 746 Joining an authenticated RPL Instance as a router requires obtaining 747 a key from an authentication authority. The process by which this 748 key is obtained is out of scope for this specification. Note that 749 this specification alone does not provide sufficient detail for a RPL 750 implementation to securely operate in authenticated mode. For a RPL 751 implementation to operate securely in authenticated mode, it is 752 necessary for a future companion specification to detail the 753 mechanisms by which a node obtains/requests the authentication 754 material (e.g., key, certificate) and to determine from where that 755 material should be obtained. See also Section 10.3. 757 3.2.4. Grounded and Floating DODAGs 759 DODAGs can be grounded or floating: the DODAG root advertises which 760 is the case. A grounded DODAG offers connectivity to hosts that are 761 required for satisfying the application-defined goal. A floating 762 DODAG is not expected to satisfy the goal; in most cases, it only 763 provides routes to nodes within the DODAG. Floating DODAGs may be 764 used, for example, to preserve interconnectivity during repair. 766 3.2.5. Local DODAGs 768 RPL nodes can optimize routes to a destination within an LLN by 769 forming a Local DODAG whose DODAG root is the desired destination. 770 Unlike global DAGs, which can consist of multiple DODAGs, local DAGs 771 have one and only one DODAG and therefore one DODAG root. Local 772 DODAGs can be constructed on demand. 774 3.2.6. Administrative Preference 776 An implementation/deployment may specify that some DODAG roots should 777 be used over others through an administrative preference. 778 Administrative preference offers a way to control traffic and 779 engineer DODAG formation in order to better support application 780 requirements or needs. 782 3.2.7. Data-Path Validation and Loop Detection 784 The low-power and lossy nature of LLNs motivates RPL's use of on- 785 demand loop detection using data packets. Because data traffic can 786 be infrequent, maintaining a routing topology that is constantly up 787 to date with the physical topology can waste energy. Typical LLNs 788 exhibit variations in physical connectivity that are transient and 789 innocuous to traffic, but that would be costly to track closely from 790 the control plane. Transient and infrequent changes in connectivity 791 need not be addressed by RPL until there is data to send. This 792 aspect of RPL's design draws from existing, highly used LLN protocols 793 as well as extensive experimental and deployment evidence on its 794 efficacy. 796 The RPL Packet Information that is transported with data packets 797 includes the Rank of the transmitter. An inconsistency between the 798 routing decision for a packet (Upward or Downward) and the Rank 799 relationship between the two nodes indicates a possible loop. On 800 receiving such a packet, a node institutes a local repair operation. 802 For example, if a node receives a packet flagged as moving in the 803 Upward direction, and if that packet records that the transmitter is 804 of a lower (lesser) Rank than the receiving node, then the receiving 805 node is able to conclude that the packet has not progressed in the 806 Upward direction and that the DODAG is inconsistent. 808 3.2.8. Distributed Algorithm Operation 810 A high-level overview of the distributed algorithm, which constructs 811 the DODAG, is as follows: 813 * Some nodes are configured to be DODAG roots, with associated DODAG 814 configurations. 816 * Nodes advertise their presence, affiliation with a DODAG, routing 817 cost, and related metrics by sending link-local multicast DIO 818 messages to all-RPL-nodes. 820 * Nodes listen for DIOs and use their information to join a new 821 DODAG (thus, selecting DODAG parents), or to maintain an existing 822 DODAG, according to the specified Objective Function and Rank of 823 their neighbors. 825 * Nodes provision routing table entries, for the destinations 826 specified by the DIO message, via their DODAG parents in the DODAG 827 Version. Nodes that decide to join a DODAG can provision one or 828 more DODAG parents as the next hop for the default route and a 829 number of other external routes for the associated instance. 831 3.3. Downward Routes and Destination Advertisement 833 RPL uses Destination Advertisement Object (DAO) messages to establish 834 Downward routes. DAO messages are an optional feature for 835 applications that require point-to-multipoint (P2MP) or point-to- 836 point (P2P) traffic. RPL supports two modes of Downward traffic: 837 Storing (fully stateful) or Non-Storing (fully source routed); see 838 Section 9. Any given RPL Instance is either storing or non-storing. 839 In both cases, P2P packets travel Up toward a DODAG root then Down to 840 the final destination (unless the destination is on the Upward 841 route). In the Non-Storing case, the packet will travel all the way 842 to a DODAG root before traveling Down. In the Storing case, the 843 packet may be directed Down towards the destination by a common 844 ancestor of the source and the destination prior to reaching a DODAG 845 root. 847 As of the writing of this specification, no implementation is 848 expected to support both Storing and Non-Storing modes of operation. 849 Most implementations are expected to support either no Downward 850 routes, Non-Storing mode only, or Storing mode only. Other modes of 851 operation, such as a hybrid mix of Storing and Non-Storing mode, are 852 out of scope for this specification and may be described in other 853 companion specifications. 855 This specification describes a basic mode of operation in support of 856 P2P traffic. Note that more optimized P2P solutions may be described 857 in companion specifications. 859 3.4. Local DODAGs Route Discovery 861 Optionally, a RPL network can support on-demand discovery of DODAGs 862 to specific destinations within an LLN. Such Local DODAGs behave 863 slightly differently than Global DODAGs: they are uniquely defined by 864 the combination of DODAGID and RPLInstanceID. The RPLInstanceID 865 denotes whether a DODAG is a Local DODAG. 867 3.5. Rank Properties 869 The Rank of a node is a scalar representation of the location of that 870 node within a DODAG Version. The Rank is used to avoid and detect 871 loops and, as such, must demonstrate certain properties. The exact 872 calculation of the Rank is left to the Objective Function. Even 873 though the specific computation of the Rank is left to the Objective 874 Function, the Rank must implement generic properties regardless of 875 the Objective Function. 877 In particular, the Rank of the nodes must monotonically decrease as 878 the DODAG Version is followed towards the DODAG destination. In that 879 regard, the Rank can be considered a scalar representation of the 880 location or radius of a node within a DODAG Version. 882 The details of how the Objective Function computes Rank are out of 883 scope for this specification, although that computation may depend, 884 for example, on parents, link metrics, node metrics, and the node 885 configuration and policies. See Section 14 for more information. 887 The Rank is not a path cost, although its value can be derived from 888 and influenced by path metrics. The Rank has properties of its own 889 that are not necessarily those of all metrics: 891 Type: The Rank is an abstract numeric value. 893 Function: The Rank is the expression of a relative position within a 894 DODAG Version with regard to neighbors, and it is not 895 necessarily a good indication or a proper expression of a 896 distance or a path cost to the root. 898 Stability: The stability of the Rank determines the stability of the 899 routing topology. Some dampening or filtering is RECOMMENDED 900 to keep the topology stable; thus, the Rank does not 901 necessarily change as fast as some link or node metrics would. 902 A new DODAG Version would be a good opportunity to reconcile 903 the discrepancies that might form over time between metrics and 904 Ranks within a DODAG Version. 906 Properties: The Rank is incremented in a strictly monotonic fashion, 907 and it can be used to validate a progression from or towards 908 the root. A metric, like bandwidth or jitter, does not 909 necessarily exhibit this property. 911 Abstract: The Rank does not have a physical unit, but rather a range 912 of increment per hop, where the assignment of each increment is 913 to be determined by the Objective Function. 915 The Rank value feeds into DODAG parent selection, according to the 916 RPL loop-avoidance strategy. Once a parent has been added, and a 917 Rank value for the node within the DODAG has been advertised, the 918 node's further options with regard to DODAG parent selection and 919 movement within the DODAG are restricted in favor of loop avoidance. 921 3.5.1. Rank Comparison (DAGRank()) 923 Rank may be thought of as a fixed-point number, where the position of 924 the radix point between the integer part and the fractional part is 925 determined by MinHopRankIncrease. MinHopRankIncrease is the minimum 926 increase in Rank between a node and any of its DODAG parents. A 927 DODAG root provisions MinHopRankIncrease. MinHopRankIncrease creates 928 a trade-off between hop cost precision and the maximum number of hops 929 a network can support. A very large MinHopRankIncrease, for example, 930 allows precise characterization of a given hop's effect on Rank but 931 cannot support many hops. 933 When an Objective Function computes Rank, the Objective Function 934 operates on the entire (i.e., 16-bit) Rank quantity. When Rank is 935 compared, e.g., for determination of parent relationships or loop 936 detection, the integer portion of the Rank is to be used. The 937 integer portion of the Rank is computed by the DAGRank() macro as 938 follows, where floor(x) is the function that evaluates to the 939 greatest integer less than or equal to x: 941 DAGRank(rank) = floor(rank/MinHopRankIncrease) 943 For example, if a 16-bit Rank quantity is decimal 27, and the 944 MinHopRankIncrease is decimal 16, then DAGRank(27) = floor(1.6875) = 945 1. The integer part of the Rank is 1 and the fractional part is 946 11/16. 948 Following the conventions in this document, using the macro 949 DAGRank(node) may be interpreted as DAGRank(node.rank), where 950 node.rank is the Rank value as maintained by the node. 952 A Node A has a Rank less than the Rank of a Node B if DAGRank(A) is 953 less than DAGRank(B). 955 A Node A has a Rank equal to the Rank of a Node B if DAGRank(A) is 956 equal to DAGRank(B). 958 A Node A has a Rank greater than the Rank of a Node B if DAGRank(A) 959 is greater than DAGRank(B). 961 3.5.2. Rank Relationships 963 Rank computations maintain the following properties for any nodes M 964 and N that are neighbors in the LLN: 966 DAGRank(M) is less than DAGRank(N): 967 In this case, the position of M is closer to the DODAG root than 968 the position of N. Node M may safely be a DODAG parent for Node N 969 without risk of creating a loop. Further, for a Node N, all 970 parents in the DODAG parent set must be of a Rank less than 971 DAGRank(N). In other words, the Rank presented by a Node N MUST 972 be greater than that presented by any of its parents. 974 DAGRank(M) equals DAGRank(N): 975 In this case, the positions of M and N within the DODAG and with 976 respect to the DODAG root are similar or identical. Routing 977 through a node with equal Rank may cause a routing loop (i.e., if 978 that node chooses to route through a node with equal Rank as 979 well). 981 DAGRank(M) is greater than DAGRank(N): 982 In this case, the position of M is farther from the DODAG root 983 than the position of N. Further, Node M may in fact be in the 984 sub-DODAG of Node N. If Node N selects Node M as DODAG parent, 985 there is a risk of creating a loop. 987 As an example, the Rank could be computed in such a way so as to 988 closely track ETX (expected transmission count, a fairly common 989 routing metric used in LLN and defined in [RFC6551]) when the metric 990 that an Objective Function minimizes is ETX, or latency, or in a more 991 complicated way as appropriate to the Objective Function being used 992 within the DODAG. 994 3.6. Routing Metrics and Constraints Used by RPL 996 Routing metrics are used by routing protocols to compute shortest 997 paths. Interior Gateway Protocols (IGPs) such as IS-IS ([RFC5120]) 998 and OSPF ([RFC4915]) use static link metrics. Such link metrics can 999 simply reflect the bandwidth or can also be computed according to a 1000 polynomial function of several metrics defining different link 1001 characteristics. Some routing protocols support more than one 1002 metric: in the vast majority of the cases, one metric is used per 1003 (sub-)topology. Less often, a second metric may be used as a 1004 tiebreaker in the presence of Equal Cost Multiple Paths (ECMPs). The 1005 optimization of multiple metrics is known as an NP-complete problem 1006 and is sometimes supported by some centralized path computation 1007 engine. 1009 In contrast, LLNs do require the support of both static and dynamic 1010 metrics. Furthermore, both link and node metrics are required. In 1011 the case of RPL, it is virtually impossible to define one metric, or 1012 even a composite metric, that will satisfy all use cases. 1014 In addition, RPL supports constraint-based routing where constraints 1015 may be applied to both link and nodes. If a link or a node does not 1016 satisfy a required constraint, it is "pruned" from the candidate 1017 neighbor set, thus leading to a constrained shortest path. 1019 An Objective Function specifies the objectives used to compute the 1020 (constrained) path. Furthermore, nodes are configured to support a 1021 set of metrics and constraints and select their parents in the DODAG 1022 according to the metrics and constraints advertised in the DIO 1023 messages. Upstream and Downstream metrics may be merged or 1024 advertised separately depending on the OF and the metrics. When they 1025 are advertised separately, it may happen that the set of DIO parents 1026 is different from the set of DAO parents (a DAO parent is a node to 1027 which unicast DAO messages are sent). Yet, all are DODAG parents 1028 with regard to the rules for Rank computation. 1030 The Objective Function is decoupled from the routing metrics and 1031 constraints used by RPL. Whereas the OF dictates rules such as DODAG 1032 parent selection, load balancing, and so on, the set of metrics and/ 1033 or constraints used, and thus those that determine the preferred 1034 path, are based on the information carried within the DAG container 1035 option in DIO messages. 1037 The set of supported link/node constraints and metrics is specified 1038 in [RFC6551]. 1040 Example 1: Shortest path: path offering the shortest end-to-end 1041 delay. 1043 Example 2: Shortest Constrained path: the path that does not 1044 traverse any battery-operated node and that optimizes the 1045 path reliability. 1047 3.7. Loop Avoidance 1049 RPL tries to avoid creating loops when undergoing topology changes 1050 and includes Rank-based data-path validation mechanisms for detecting 1051 loops when they do occur (see Section 11 for more details). In 1052 practice, this means that RPL guarantees neither loop-free path 1053 selection nor tight delay convergence times, but it can detect and 1054 repair a loop as soon as it is used. RPL uses this loop detection to 1055 ensure that packets make forward progress within the DODAG Version 1056 and trigger repairs when necessary. 1058 3.7.1. Greediness and Instability 1060 A node is greedy if it attempts to move deeper (increase Rank) in the 1061 DODAG Version in order to increase the size of the parent set or 1062 improve some other metric. Once a node has joined a DODAG Version, 1063 RPL disallows certain behaviors, including greediness, in order to 1064 prevent resulting instabilities in the DODAG Version. 1066 Suppose a node is willing to receive and process a DIO message from a 1067 node in its own sub-DODAG and, in general, a node deeper than itself. 1068 In this case, a possibility exists that a feedback loop is created, 1069 wherein two or more nodes continue to try and move in the DODAG 1070 Version while attempting to optimize against each other. In some 1071 cases, this will result in instability. It is for this reason that 1072 RPL limits the cases where a node may process DIO messages from 1073 deeper nodes to some form of local repair. This approach creates an 1074 "event horizon", whereby a node cannot be influenced beyond some 1075 limit into an instability by the action of nodes that may be in its 1076 own sub-DODAG. 1078 3.7.1.1. Example: Greedy Parent Selection and Instability 1080 (A) (A) (A) 1081 |\ |\ |\ 1082 | `-----. | `-----. | `-----. 1083 | \ | \ | \ 1084 (B) (C) (B) \ | (C) 1085 \ | | / 1086 `-----. | | .-----' 1087 \| |/ 1088 (C) (B) 1090 -1- -2- -3- 1092 Figure 3: Greedy DODAG Parent Selection 1094 Figure 3 depicts a DODAG in three different configurations. A usable 1095 link between (B) and (C) exists in all three configurations. In 1096 Figure 3-1, Node (A) is a DODAG parent for Nodes (B) and (C). In 1097 Figure 3-2, Node (A) is a DODAG parent for Nodes (B) and (C), and 1098 Node (B) is also a DODAG parent for Node (C). In Figure 3-3, Node 1099 (A) is a DODAG parent for Nodes (B) and (C), and Node (C) is also a 1100 DODAG parent for Node (B). 1102 If a RPL node is too greedy, in that it attempts to optimize for an 1103 additional number of parents beyond its most preferred parents, then 1104 an instability can result. Consider the DODAG illustrated in 1105 Figure 3-1. In this example, Nodes (B) and (C) may most prefer Node 1106 (A) as a DODAG parent, but we will consider the case when they are 1107 operating under the greedy condition that will try to optimize for 1108 two parents. 1110 * Let Figure 3-1 be the initial condition. 1112 * Suppose Node (C) first is able to leave the DODAG and rejoin at a 1113 lower Rank, taking both Nodes (A) and (B) as DODAG parents as 1114 depicted in Figure 3-2. Now Node (C) is deeper than both Nodes 1115 (A) and (B), and Node (C) is satisfied to have two DODAG parents. 1117 * Suppose Node (B), in its greediness, is willing to receive and 1118 process a DIO message from Node (C) (against the rules of RPL), 1119 and then Node (B) leaves the DODAG and rejoins at a lower Rank, 1120 taking both Nodes (A) and (C) as DODAG parents. Now Node (B) is 1121 deeper than both Nodes (A) and (C) and is satisfied with two DAG 1122 parents. 1124 * Then, Node (C), because it is also greedy, will leave and rejoin 1125 deeper, to again get two parents and have a lower Rank then both 1126 of them. 1128 * Next, Node (B) will again leave and rejoin deeper, to again get 1129 two parents. 1131 * Again, Node (C) leaves and rejoins deeper. 1133 * The process will repeat, and the DODAG will oscillate between 1134 Figure 3-2 and Figure 3-3 until the nodes count to infinity and 1135 restart the cycle again. 1137 * This cycle can be averted through mechanisms in RPL: 1139 - Nodes (B) and (C) stay at a Rank sufficient to attach to their 1140 most preferred parent (A) and don't go for any deeper (worse) 1141 alternate parents (Nodes are not greedy). 1143 - Nodes (B) and (C) do not process DIO messages from nodes deeper 1144 than themselves (because such nodes are possibly in their own 1145 sub-DODAGs). 1147 These mechanisms are further described in Section 8.2.2.4. 1149 3.7.2. DODAG Loops 1151 A DODAG loop may occur when a node detaches from the DODAG and 1152 reattaches to a device in its prior sub-DODAG. In particular, this 1153 may happen when DIO messages are missed. Strict use of the 1154 DODAGVersionNumber can eliminate this type of loop, but this type of 1155 loop may possibly be encountered when using some local repair 1156 mechanisms. 1158 For example, consider the local repair mechanism that allows a node 1159 to detach from the DODAG, advertise a Rank of INFINITE_RANK (in order 1160 to poison its routes / inform its sub-DODAG), and then reattach to 1161 the DODAG. In some of these cases, the node may reattach to its own 1162 prior-sub-DODAG, causing a DODAG loop, because the poisoning may fail 1163 if the INFINITE_RANK advertisements are lost in the LLN environment. 1164 (In this case, the Rank-based data-path validation mechanisms would 1165 eventually detect and trigger correction of the loop). 1167 3.7.3. DAO Loops 1169 A DAO loop may occur when the parent has a route installed upon 1170 receiving and processing a DAO message from a child, but the child 1171 has subsequently cleaned up the related DAO state. This loop happens 1172 when a No-Path (a DAO message that invalidates a previously announced 1173 prefix, see Section 6.4.3) was missed and persists until all state 1174 has been cleaned up. RPL includes an optional mechanism to 1175 acknowledge DAO messages, which may mitigate the impact of a single 1176 DAO message being missed. RPL includes loop detection mechanisms 1177 that mitigate the impact of DAO loops and trigger their repair. (See 1178 Section 11.2.2.3). 1180 4. Traffic Flows Supported by RPL 1182 RPL supports three basic traffic flows: multipoint-to-point (MP2P), 1183 point-to-multipoint (P2MP), and point-to-point (P2P). 1185 4.1. Multipoint-to-Point Traffic 1187 Multipoint-to-point (MP2P) is a dominant traffic flow in many LLN 1188 applications ([RFC5867], [RFC5826], [RFC5673], and [RFC5548]). The 1189 destinations of MP2P flows are designated nodes that have some 1190 application significance, such as providing connectivity to the 1191 larger Internet or core private IP network. RPL supports MP2P 1192 traffic by allowing MP2P destinations to be reached via DODAG roots. 1194 4.2. Point-to-Multipoint Traffic 1196 Point-to-multipoint (P2MP) is a traffic pattern required by several 1197 LLN applications ([RFC5867], [RFC5826], [RFC5673], and [RFC5548]). 1198 RPL supports P2MP traffic by using a destination advertisement 1199 mechanism that provisions Down routes toward destinations (prefixes, 1200 addresses, or multicast groups), and away from roots. Destination 1201 advertisements can update routing tables as the underlying DODAG 1202 topology changes. 1204 4.3. Point-to-Point Traffic 1206 RPL DODAGs provide a basic structure for point-to-point (P2P) 1207 traffic. For a RPL network to support P2P traffic, a root must be 1208 able to route packets to a destination. Nodes within the network may 1209 also have routing tables to destinations. A packet flows towards a 1210 root until it reaches an ancestor that has a known route to the 1211 destination. As pointed out later in this document, in the most 1212 constrained case (when nodes cannot store routes), that common 1213 ancestor may be the DODAG root. In other cases, it may be a node 1214 closer to both the source and destination. 1216 RPL also supports the case where a P2P destination is a 'one-hop' 1217 neighbor. 1219 RPL neither specifies nor precludes additional mechanisms for 1220 computing and installing potentially more optimal routes to support 1221 arbitrary P2P traffic. 1223 5. RPL Instance 1225 Within a given LLN, there may be multiple, logically independent RPL 1226 Instances. A RPL node may belong to multiple RPL Instances, and it 1227 may act as a router in some and as a leaf in others. This document 1228 describes how a single instance behaves. 1230 There are two types of RPL Instances: Local and Global. RPL divides 1231 the RPLInstanceID space between Global and Local instances to allow 1232 for both coordinated and unilateral allocation of RPLInstanceIDs. 1233 Global RPL Instances are coordinated, have one or more DODAGs, and 1234 are typically long-lived. Local RPL Instances are always a single 1235 DODAG whose singular root owns the corresponding DODAGID and 1236 allocates the local RPLInstanceID in a unilateral manner. Local RPL 1237 Instances can be used, for example, for constructing DODAGs in 1238 support of a future on-demand routing solution. The mode of 1239 operation of Local RPL Instances is out of scope for this 1240 specification and may be described in other companion specifications. 1242 The definition and provisioning of RPL Instances are out of scope for 1243 this specification. Guidelines may be application and implementation 1244 specific, and they are expected to be elaborated in future companion 1245 specifications. Those operations are expected to be such that data 1246 packets coming from the outside of the RPL network can unambiguously 1247 be associated to at least one RPL Instance and be safely routed over 1248 any instance that would match the packet. 1250 Control and data packets within RPL network are tagged to 1251 unambiguously identify of which RPL Instance they are a part. 1253 Every RPL control message has a RPLInstanceID field. Some RPL 1254 control messages, when referring to a local RPLInstanceID as defined 1255 below, may also include a DODAGID. 1257 Data packets that flow within the RPL network expose the 1258 RPLInstanceID as part of the RPL Packet Information that RPL 1259 requires, as further described in Section 11.2. For data packets 1260 coming from outside the RPL network, the ingress router determines 1261 the RPLInstanceID and places it into the resulting packet that it 1262 injects into the RPL network. 1264 5.1. RPL Instance ID 1266 A global RPLInstanceID MUST be unique to the whole LLN. Mechanisms 1267 for allocating and provisioning global RPLInstanceID are out of scope 1268 for this specification. There can be up to 128 Global instance in 1269 the whole network. Local instances are always used in conjunction 1270 with a DODAGID (which is either given explicitly or implicitly in 1271 some cases), and up 64 Local instances per DODAGID can be supported. 1272 Local instances are allocated and managed by the node that owns the 1273 DODAGID, without any explicit coordination with other nodes, as 1274 further detailed below. 1276 A global RPLInstanceID is encoded in a RPLInstanceID field as 1277 follows: 1279 0 1 2 3 4 5 6 7 1280 +-+-+-+-+-+-+-+-+ 1281 |0| ID | Global RPLInstanceID in 0..127 1282 +-+-+-+-+-+-+-+-+ 1284 Figure 4: RPLInstanceID Field Format for Global Instances 1286 A local RPLInstanceID is autoconfigured by the node that owns the 1287 DODAGID and it MUST be unique for that DODAGID. The DODAGID used to 1288 configure the local RPLInstanceID MUST be a reachable IPv6 address of 1289 the node, and it MUST be used as an endpoint of all communications 1290 within that Local instance. 1292 A local RPLInstanceID is encoded in a RPLInstanceID field as follows: 1294 0 1 2 3 4 5 6 7 1295 +-+-+-+-+-+-+-+-+ 1296 |1|D| ID | Local RPLInstanceID in 0..63 1297 +-+-+-+-+-+-+-+-+ 1299 Figure 5: RPLInstanceID Field Format for Local Instances 1301 The 'D' flag in a local RPLInstanceID is always set to 0 in RPL 1302 control messages. It is used in data packets to indicate whether the 1303 DODAGID is the source or the destination of the packet. If the 'D' 1304 flag is set to 1, then the destination address of the IPv6 packet 1305 MUST be the DODAGID. If the 'D' flag is cleared, then the source 1306 address of the IPv6 packet MUST be the DODAGID. 1308 For example, consider a Node A that is the DODAG root of a Local RPL 1309 Instance, and has allocated a local RPLInstanceID. By definition, 1310 all traffic traversing that Local RPL Instance will either originate 1311 or terminate at Node A. In this case, the DODAGID will be the 1312 reachable IPv6 address of Node A. All traffic will contain the 1313 address of Node A, and thus the DODAGID, in either the source or 1314 destination address. Thus, the local RPLInstanceID may indicate that 1315 the DODAGID is equivalent to either the source address or the 1316 destination address by setting the 'D' flag appropriately. 1318 6. ICMPv6 RPL Control Message 1320 This document defines the RPL control message, a new ICMPv6 [RFC4443] 1321 message. A RPL control message is identified by a code and composed 1322 of a base that depends on the code (and a series of options). 1324 Most RPL control messages have the scope of a link. The only 1325 exception is for the DAO / DAO-ACK messages in Non-Storing mode, 1326 which are exchanged using a unicast address over multiple hops and 1327 thus uses global or unique-local addresses for both the source and 1328 destination addresses. For all other RPL control messages, the 1329 source address is a link-local address, and the destination address 1330 is either the all-RPL-nodes multicast address or a link-local unicast 1331 address of the destination. The all-RPL-nodes multicast address is a 1332 new address with a value of ff02::1a. 1334 In accordance with [RFC4443], the RPL Control Message consists of an 1335 ICMPv6 header followed by a message body. The message body is 1336 comprised of a message base and possibly a number of options as 1337 illustrated in Figure 6. 1339 0 1 2 3 1340 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1342 | Type | Code | Checksum | 1343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1344 | | 1345 . Base . 1346 . . 1347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1348 | | 1349 . Option(s) . 1350 . . 1351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1353 Figure 6: RPL Control Message 1355 The RPL control message is an ICMPv6 information message with a Type 1356 of 155. 1358 The Code field identifies the type of RPL control message. This 1359 document defines codes for the following RPL control message types 1360 (see Section 20.2)): 1362 * 0x00: DODAG Information Solicitation (Section 6.2) 1364 * 0x01: DODAG Information Object (Section 6.3) 1366 * 0x02: Destination Advertisement Object (Section 6.4) 1368 * 0x03: Destination Advertisement Object Acknowledgment 1369 (Section 6.5) 1371 * 0x80: Secure DODAG Information Solicitation (Section 6.2.2) 1373 * 0x81: Secure DODAG Information Object (Section 6.3.2) 1375 * 0x82: Secure Destination Advertisement Object (Section 6.4.2) 1377 * 0x83: Secure Destination Advertisement Object Acknowledgment 1378 (Section 6.5.2) 1380 * 0x8A: Consistency Check (Section 6.6) 1382 If a node receives a RPL control message with an unknown Code field, 1383 the node MUST discard the message without any further processing, MAY 1384 raise a management alert, and MUST NOT send any messages in response. 1386 The checksum is computed as specified in [RFC4443]. It is set to 1387 zero for the RPL security operations specified below and computed 1388 once the rest of the content of the RPL message including the 1389 security fields is all set. 1391 The high order bit (0x80) of the code denotes whether the RPL message 1392 has security enabled. Secure RPL messages have a format to support 1393 confidentiality and integrity, illustrated in Figure 7. 1395 0 1 2 3 1396 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1398 | Type | Code | Checksum | 1399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1400 | | 1401 . Security . 1402 . . 1403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1404 | | 1405 . Base . 1406 . . 1407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1408 | | 1409 . Option(s) . 1410 . . 1411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1413 Figure 7: Secure RPL Control Message 1415 The remainder of this section describes the currently defined RPL 1416 control message Base formats followed by the currently defined RPL 1417 Control Message options. 1419 6.1. RPL Security Fields 1421 Each RPL message has a secure variant. The secure variants provide 1422 integrity and replay protection as well as optional confidentiality 1423 and delay protection. Because security covers the base message as 1424 well as options, in secured messages the security information lies 1425 between the checksum and base, as shown in Figure 7. 1427 The level of security and the algorithms in use are indicated in the 1428 protocol messages as described below: 1430 0 1 2 3 1431 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1433 |T| Reserved | Algorithm |KIM|Resvd| LVL | Flags | 1434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1435 | Counter | 1436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1437 | | 1438 . Key Identifier . 1439 . . 1440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1442 Figure 8: Security Section 1444 Message Authentication Codes (MACs) and signatures provide 1445 authentication over the entire unsecured ICMPv6 RPL control message, 1446 including the Security section with all fields defined, but with the 1447 ICMPv6 checksum temporarily set to zero. Encryption provides 1448 confidentiality of the secured RPL ICMPv6 message starting at the 1449 first byte after the Security section and continuing to the last byte 1450 of the packet. The security transformation yields a secured ICMPv6 1451 RPL message with the inclusion of the cryptographic fields (MAC, 1452 signature, etc.). In other words, the security transformation itself 1453 (e.g., the Signature and/or Algorithm in use) will detail how to 1454 incorporate the cryptographic fields into the secured packet. The 1455 Security section itself does not explicitly carry those cryptographic 1456 fields. Use of the Security section is further detailed in Sections 1457 19 and 10. 1459 Counter is Time (T): If the counter's Time flag is set, then the 1460 Counter field is a timestamp. If the flag is cleared, then the 1461 counter is an incrementing counter. Section 10.5 describes the 1462 details of the 'T' flag and Counter field. 1464 Reserved: 7-bit unused field. The field MUST be initialized to zero 1465 by the sender and MUST be ignored by the receiver. 1467 Security Algorithm (Algorithm): The Security Algorithm field 1468 specifies the encryption, MAC, and signature scheme the network 1469 uses. Supported values of this field are as follows: 1471 +-----------+-------------------+------------------------+ 1472 | Algorithm | Encryption/MAC | Signature | 1473 +-----------+-------------------+------------------------+ 1474 | 0 | CCM with AES-128 | RSA with SHA-256 | 1475 | 1-255 | Unassigned | Unassigned | 1476 +-----------+-------------------+------------------------+ 1478 Figure 9: Security Algorithm (Algorithm) Encoding 1480 Section 10.9 describes the algorithms in greater detail. 1482 Key Identifier Mode (KIM): The Key Identifier Mode is a 2-bit field 1483 that indicates whether the key used for packet protection is 1484 determined implicitly or explicitly and indicates the 1485 particular representation of the Key Identifier field. The Key 1486 Identifier Mode is set one of the values from the table below: 1488 +------+-----+-----------------------------+------------+ 1489 | Mode | KIM | Meaning | Key | 1490 | | | | Identifier | 1491 | | | | Length | 1492 | | | | (octets) | 1493 +------+-----+-----------------------------+------------+ 1494 | 0 | 00 | Group key used. | 1 | 1495 | | | Key determined by Key Index | | 1496 | | | field. | | 1497 | | | | | 1498 | | | Key Source is not present. | | 1499 | | | Key Index is present. | | 1500 +------+-----+-----------------------------+------------+ 1501 | 1 | 01 | Per-pair key used. | 0 | 1502 | | | Key determined by source | | 1503 | | | and destination of packet. | | 1504 | | | | | 1505 | | | Key Source is not present. | | 1506 | | | Key Index is not present. | | 1507 +------+-----+-----------------------------+------------+ 1508 | 2 | 10 | Group key used. | 9 | 1509 | | | Key determined by Key Index | | 1510 | | | and Key Source Identifier. | | 1511 | | | | | 1512 | | | Key Source is present. | | 1513 | | | Key Index is present. | | 1514 +------+-----+-----------------------------+------------+ 1515 | 3 | 11 | Node's signature key used. | 0/9 | 1516 | | | If packet is encrypted, | 1517 | | | it uses a group key, Key | | 1518 | | | Index and Key Source | | 1519 | | | specify key. | | 1520 | | | | | 1521 | | | Key Source may be present. | | 1522 | | | Key Index may be present. | | 1523 +------+-----+-----------------------------+------------+ 1525 Figure 10: Key Identifier Mode (KIM) Encoding 1527 In Mode 3 (KIM=11), the presence or absence of the Key Source 1528 and Key Identifier depends on the Security Level (LVL) 1529 described below. If the Security Level indicates there is 1530 encryption, then the fields are present; if it indicates there 1531 is no encryption, then the fields are not present. 1533 Resvd: 3-bit unused field. The field MUST be initialized to zero by 1534 the sender and MUST be ignored by the receiver. 1536 Security Level (LVL): The Security Level is a 3-bit field that 1537 indicates the provided packet protection. This value can be 1538 adapted on a per-packet basis and allows for varying levels of 1539 data authenticity and, optionally, for data confidentiality. 1540 The KIM field indicates whether signatures are used and the 1541 meaning of the Level field. Note that the assigned values of 1542 Security Level are not necessarily ordered -- a higher value of 1543 LVL does not necessarily equate to increased security. The 1544 Security Level is set to one of the values in the tables below: 1546 +---------------------------+ 1547 | KIM=0,1,2 | 1548 +-------+--------------------+------+ 1549 | LVL | Attributes | MAC | 1550 | | | Len | 1551 +-------+--------------------+------+ 1552 | 0 | MAC-32 | 4 | 1553 | 1 | ENC-MAC-32 | 4 | 1554 | 2 | MAC-64 | 8 | 1555 | 3 | ENC-MAC-64 | 8 | 1556 | 4-7 | Unassigned | N/A | 1557 +-------+--------------------+------+ 1559 +---------------------+ 1560 | KIM=3 | 1561 +-------+---------------+-----+ 1562 | LVL | Attributes | Sig | 1563 | | | Len | 1564 +-------+---------------+-----+ 1565 | 0 | Sign-3072 | 384 | 1566 | 1 | ENC-Sign-3072 | 384 | 1567 | 2 | Sign-2048 | 256 | 1568 | 3 | ENC-Sign-2048 | 256 | 1569 | 4-7 | Unassigned | N/A | 1570 +-------+---------------+-----+ 1572 Figure 11: Security Level (LVL) Encoding 1574 The MAC attribute indicates that the message has a MAC of the 1575 specified length. The ENC attribute indicates that the message 1576 is encrypted. The Sign attribute indicates that the message 1577 has a signature of the specified length. 1579 Flags: 8-bit unused field reserved for flags. The field MUST be 1580 initialized to zero by the sender and MUST be ignored by the 1581 receiver. 1583 Counter: The Counter field indicates the non-repeating 4-octet value 1584 used to construct the cryptographic mechanism that implements 1585 packet protection and allows for the provision of semantic 1586 security. See Section 10.9.1. 1588 Key Identifier: The Key Identifier field indicates which key was 1589 used to protect the packet. This field provides various levels 1590 of granularity of packet protection, including peer-to-peer 1591 keys, group keys, and signature keys. This field is 1592 represented as indicated by the Key Identifier Mode field and 1593 is formatted as follows: 1595 0 1 2 3 1596 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1598 | | 1599 . Key Source . 1600 . . 1601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1602 | | 1603 . Key Index . 1604 . . 1605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1607 Figure 12: Key Identifier 1609 Key Source: The Key Source field, when present, indicates the 1610 logical identifier of the originator of a group key. When 1611 present, this field is 8 bytes in length. 1613 Key Index: The Key Index field, when present, allows unique 1614 identification of different keys with the same originator. It 1615 is the responsibility of each key originator to make sure that 1616 actively used keys that it issues have distinct key indices and 1617 that all key indices have a value unequal to 0x00. Value 0x00 1618 is reserved for a preinstalled, shared key. When present this 1619 field is 1 byte in length. 1621 Unassigned bits of the Security section are reserved. They MUST be 1622 set to zero on transmission and MUST be ignored on reception. 1624 6.2. DODAG Information Solicitation (DIS) 1626 The DODAG Information Solicitation (DIS) message may be used to 1627 solicit a DODAG Information Object from a RPL node. Its use is 1628 analogous to that of a Router Solicitation as specified in IPv6 1629 Neighbor Discovery; a node may use DIS to probe its neighborhood for 1630 nearby DODAGs. Section 8.3 describes how nodes respond to a DIS. 1632 6.2.1. Format of the DIS Base Object 1634 0 1 2 1635 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1637 | Flags | Reserved | Option(s)... 1638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1640 Figure 13: The DIS Base Object 1642 Flags: 8-bit unused field reserved for flags. The field MUST be 1643 initialized to zero by the sender and MUST be ignored by the 1644 receiver. 1646 Reserved: 8-bit unused field. The field MUST be initialized to zero 1647 by the sender and MUST be ignored by the receiver. 1649 Unassigned bits of the DIS Base are reserved. They MUST be set to 1650 zero on transmission and MUST be ignored on reception. 1652 6.2.2. Secure DIS 1654 A Secure DIS message follows the format in Figure 7, where the base 1655 format is the DIS message shown in Figure 13. 1657 6.2.3. DIS Options 1659 The DIS message MAY carry valid options. 1661 This specification allows for the DIS message to carry the following 1662 options: 1664 0x00 Pad1 1665 0x01 PadN 1666 0x07 Solicited Information 1668 6.3. DODAG Information Object (DIO) 1670 The DODAG Information Object carries information that allows a node 1671 to discover a RPL Instance, learn its configuration parameters, 1672 select a DODAG parent set, and maintain the DODAG. 1674 6.3.1. Format of the DIO Base Object 1675 0 1 2 3 1676 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1678 | RPLInstanceID |Version Number | Rank | 1679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1680 |G|0| MOP | Prf | DTSN | Flags | Reserved | 1681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1682 | | 1683 + + 1684 | | 1685 + DODAGID + 1686 | | 1687 + + 1688 | | 1689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1690 | Option(s)... 1691 +-+-+-+-+-+-+-+-+ 1693 Figure 14: The DIO Base Object 1695 Grounded (G): The Grounded 'G' flag indicates whether the DODAG 1696 advertised can satisfy the application-defined goal. If the 1697 flag is set, the DODAG is grounded. If the flag is cleared, 1698 the DODAG is floating. 1700 Mode of Operation (MOP): The Mode of Operation (MOP) field 1701 identifies the mode of operation of the RPL Instance as 1702 administratively provisioned at and distributed by the DODAG 1703 root. All nodes who join the DODAG must be able to honor the 1704 MOP in order to fully participate as a router, or else they 1705 must only join as a leaf. MOP is encoded as in the figure 1706 below: 1708 +-----+-----------------------------------------------------+ 1709 | MOP | Description | 1710 +-----+-----------------------------------------------------+ 1711 | 0 | No Downward routes maintained by RPL | 1712 | 1 | Non-Storing Mode of Operation | 1713 | 2 | Storing Mode of Operation with no multicast support | 1714 | 3 | Storing Mode of Operation with multicast support | 1715 | | | 1716 | | All other values are unassigned | 1717 +-----+-----------------------------------------------------+ 1719 A value of 0 indicates that destination advertisement messages are 1720 disabled and the DODAG maintains only Upward routes. 1722 Figure 15: Mode of Operation (MOP) Encoding 1724 DODAGPreference (Prf): A 3-bit unsigned integer that defines how 1725 preferable the root of this DODAG is compared to other DODAG 1726 roots within the instance. DAGPreference ranges from 0x00 1727 (least preferred) to 0x07 (most preferred). The default is 0 1728 (least preferred). Section 8.2 describes how DAGPreference 1729 affects DIO processing. 1731 Version Number: 8-bit unsigned integer set by the DODAG root to the 1732 DODAGVersionNumber. Section 8.2 describes the rules for 1733 DODAGVersionNumbers and how they affect DIO processing. 1735 Rank: 16-bit unsigned integer indicating the DODAG Rank of the node 1736 sending the DIO message. Section 8.2 describes how Rank is set 1737 and how it affects DIO processing. 1739 RPLInstanceID: 8-bit field set by the DODAG root that indicates of 1740 which RPL Instance the DODAG is a part. 1742 Destination Advertisement Trigger Sequence Number (DTSN): 8-bit 1743 unsigned integer set by the node issuing the DIO message. The 1744 Destination Advertisement Trigger Sequence Number (DTSN) flag 1745 is used as part of the procedure to maintain Downward routes. 1746 The details of this process are described in Section 9. 1748 Flags: 8-bit unused field reserved for flags. The field MUST be 1749 initialized to zero by the sender and MUST be ignored by the 1750 receiver. 1752 Reserved: 8-bit unused field. The field MUST be initialized to zero 1753 by the sender and MUST be ignored by the receiver. 1755 DODAGID: 128-bit IPv6 address set by a DODAG root that uniquely 1756 identifies a DODAG. The DODAGID MUST be a routable IPv6 1757 address belonging to the DODAG root. 1759 Unassigned bits of the DIO Base are reserved. They MUST be set to 1760 zero on transmission and MUST be ignored on reception. 1762 6.3.2. Secure DIO 1764 A Secure DIO message follows the format in Figure 7, where the base 1765 format is the DIO message shown in Figure 14. 1767 6.3.3. DIO Options 1769 The DIO message MAY carry valid options. 1771 This specification allows for the DIO message to carry the following 1772 options: 1774 0x00 Pad1 1775 0x01 PadN 1776 0x02 DAG Metric Container 1777 0x03 Routing Information 1778 0x04 DODAG Configuration 1779 0x08 Prefix Information 1781 6.4. Destination Advertisement Object (DAO) 1783 The Destination Advertisement Object (DAO) is used to propagate 1784 destination information Upward along the DODAG. In Storing mode, the 1785 DAO message is unicast by the child to the selected parent(s). In 1786 Non-Storing mode, the DAO message is unicast to the DODAG root. The 1787 DAO message may optionally, upon explicit request or error, be 1788 acknowledged by its destination with a Destination Advertisement 1789 Acknowledgement (DAO-ACK) message back to the sender of the DAO. 1791 6.4.1. Format of the DAO Base Object 1793 0 1 2 3 1794 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1796 | RPLInstanceID |K|D| Flags | Reserved | DAOSequence | 1797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1798 | | 1799 + + 1800 | | 1801 + DODAGID* + 1802 | | 1803 + + 1804 | | 1805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1806 | Option(s)... 1807 +-+-+-+-+-+-+-+-+ 1809 The '*' denotes that the DODAGID is not always present, as described 1810 below. 1812 Figure 16: The DAO Base Object 1814 RPLInstanceID: 8-bit field indicating the topology instance 1815 associated with the DODAG, as learned from the DIO. 1817 K: The 'K' flag indicates that the recipient is expected to send a 1818 DAO-ACK back. (See Section 9.3). 1820 D: The 'D' flag indicates that the DODAGID field is present. This 1821 flag MUST be set when a local RPLInstanceID is used. 1823 Flags: The 6 bits remaining unused in the Flags field are reserved 1824 for flags. The field MUST be initialized to zero by the sender 1825 and MUST be ignored by the receiver. 1827 Reserved: 8-bit unused field. The field MUST be initialized to zero 1828 by the sender and MUST be ignored by the receiver. 1830 DAOSequence: Incremented at each unique DAO message from a node and 1831 echoed in the DAO-ACK message. 1833 DODAGID (optional): 128-bit unsigned integer set by a DODAG root 1834 that uniquely identifies a DODAG. This field is only present 1835 when the 'D' flag is set. This field is typically only present 1836 when a local RPLInstanceID is in use, in order to identify the 1837 DODAGID that is associated with the RPLInstanceID. When a 1838 global RPLInstanceID is in use, this field need not be present. 1840 Unassigned bits of the DAO Base are reserved. They MUST be set to 1841 zero on transmission and MUST be ignored on reception. 1843 6.4.2. Secure DAO 1845 A Secure DAO message follows the format in Figure 7, where the base 1846 format is the DAO message shown in Figure 16. 1848 6.4.3. DAO Options 1850 The DAO message MAY carry valid options. 1852 This specification allows for the DAO message to carry the following 1853 options: 1855 0x00 Pad1 1856 0x01 PadN 1857 0x05 RPL Target 1858 0x06 Transit Information 1859 0x09 RPL Target Descriptor 1861 A special case of the DAO message, termed a No-Path, is used in 1862 Storing mode to clear Downward routing state that has been 1863 provisioned through DAO operation. The No-Path carries a Target 1864 option and an associated Transit Information option with a lifetime 1865 of 0x00000000 to indicate a loss of reachability to that Target. 1867 6.5. Destination Advertisement Object Acknowledgement (DAO-ACK) 1869 The DAO-ACK message is sent as a unicast packet by a DAO recipient (a 1870 DAO parent or DODAG root) in response to a unicast DAO message. 1872 6.5.1. Format of the DAO-ACK Base Object 1874 0 1 2 3 1875 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1877 | RPLInstanceID |D| Reserved | DAOSequence | Status | 1878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1879 | | 1880 + + 1881 | | 1882 + DODAGID* + 1883 | | 1884 + + 1885 | | 1886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1887 | Option(s)... 1888 +-+-+-+-+-+-+-+-+ 1890 The '*' denotes that the DODAGID is not always present, as described 1891 below. 1893 Figure 17: The DAO ACK Base Object 1895 RPLInstanceID: 8-bit field indicating the topology instance 1896 associated with the DODAG, as learned from the DIO. 1898 D: The 'D' flag indicates that the DODAGID field is present. This 1899 would typically only be set when a local RPLInstanceID is used. 1901 Reserved: The 7-bit field, reserved for flags. 1903 DAOSequence: Incremented at each DAO message from a node, and echoed 1904 in the DAO-ACK by the recipient. The DAOSequence is used to 1905 correlate a DAO message and a DAO ACK message and is not to be 1906 confused with the Transit Information option Path Sequence that 1907 is associated to a given Target Down the DODAG. 1909 Status: Indicates the completion. Status 0 is defined as 1910 unqualified acceptance in this specification. The remaining 1911 status values are reserved as rejection codes. No rejection 1912 status codes are defined in this specification, although status 1913 codes SHOULD be allocated according to the following guidelines 1914 in future specifications: 1916 0: Unqualified acceptance (i.e., the node receiving the DAO- 1917 ACK is not rejected). 1919 1-127: Not an outright rejection; the node sending the DAO-ACK 1920 is willing to act as a parent, but the receiving node is 1921 suggested to find and use an alternate parent instead. 1923 127-255: Rejection; the node sending the DAO-ACK is unwilling 1924 to act as a parent. 1926 DODAGID (optional): 128-bit unsigned integer set by a DODAG root 1927 that uniquely identifies a DODAG. This field is only present 1928 when the 'D' flag is set. Typically, this field is only 1929 present when a local RPLInstanceID is in use in order to 1930 identify the DODAGID that is associated with the RPLInstanceID. 1931 When a global RPLInstanceID is in use, this field need not be 1932 present. 1934 Unassigned bits of the DAO-ACK Base are reserved. They MUST be set 1935 to zero on transmission and MUST be ignored on reception. 1937 6.5.2. Secure DAO-ACK 1939 A Secure DAO-ACK message follows the format in Figure 7, where the 1940 base format is the DAO-ACK message shown in Figure 17. 1942 6.5.3. DAO-ACK Options 1944 This specification does not define any options to be carried by the 1945 DAO-ACK message. 1947 6.6. Consistency Check (CC) 1949 The CC message is used to check secure message counters and issue 1950 challenge-responses. A CC message MUST be sent as a secured RPL 1951 message. 1953 6.6.1. Format of the CC Base Object 1954 0 1 2 3 1955 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1957 | RPLInstanceID |R| Flags | CC Nonce | 1958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1959 | | 1960 + + 1961 | | 1962 + DODAGID + 1963 | | 1964 + + 1965 | | 1966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1967 | Destination Counter | 1968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1969 | Option(s)... 1970 +-+-+-+-+-+-+-+-+ 1972 Figure 18: The CC Base Object 1974 RPLInstanceID: 8-bit field indicating the topology instance 1975 associated with the DODAG, as learned from the DIO. 1977 R: The 'R' flag indicates whether the CC message is a response. A 1978 message with the 'R' flag cleared is a request; a message with 1979 the 'R' flag set is a response. 1981 Flags: The 7 bits remaining unused in the Flags field are reserved 1982 for flags. The field MUST be initialized to zero by the sender 1983 and MUST be ignored by the receiver. 1985 CC Nonce: 16-bit unsigned integer set by a CC request. The 1986 corresponding CC response includes the same CC nonce value as 1987 the request. 1989 DODAGID: 128-bit field, contains the identifier of the DODAG root. 1991 Destination Counter: 32-bit unsigned integer value indicating the 1992 sender's estimate of the destination's current security counter 1993 value. If the sender does not have an estimate, it SHOULD set 1994 the Destination Counter field to zero. 1996 Unassigned bits of the CC Base are reserved. They MUST be set to 1997 zero on transmission and MUST be ignored on reception. 1999 The Destination Counter value allows new or recovered nodes to 2000 resynchronize through CC message exchanges. This is important to 2001 ensure that a Counter value is not repeated for a given security key 2002 even in the event of devices recovering from a failure that created a 2003 loss of Counter state. For example, where a CC request or other RPL 2004 message is received with an initialized counter within the message 2005 Security section, the provision of the Incoming Counter within the CC 2006 response message allows the requesting node to reset its Outgoing 2007 Counter to a value greater than the last value received by the 2008 responding node; the Incoming Counter will also be updated from the 2009 received CC response. 2011 6.6.2. CC Options 2013 This specification allows for the CC message to carry the following 2014 options: 2016 0x00 Pad1 2017 0x01 PadN 2019 6.7. RPL Control Message Options 2021 6.7.1. RPL Control Message Option Generic Format 2023 RPL Control Message options all follow this format: 2025 0 1 2 2026 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - 2028 | Option Type | Option Length | Option Data 2029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - 2031 Figure 19: RPL Option Generic Format 2033 Option Type: 8-bit identifier of the type of option. The Option 2034 Type values are assigned by IANA (see Section 20.4). 2036 Option Length: 8-bit unsigned integer, representing the length in 2037 octets of the option, not including the Option Type and Length 2038 fields. 2040 Option Data: A variable length field that contains data specific to 2041 the option. 2043 When processing a RPL message containing an option for which the 2044 Option Type value is not recognized by the receiver, the receiver 2045 MUST silently ignore the unrecognized option and continue to process 2046 the following option, correctly handling any remaining options in the 2047 message. 2049 RPL message options may have alignment requirements. Following the 2050 convention in IPv6, options with alignment requirements are aligned 2051 in a packet such that multi-octet values within the Option Data field 2052 of each option fall on natural boundaries (i.e., fields of width n 2053 octets are placed at an integer multiple of n octets from the start 2054 of the header, for n = 1, 2, 4, or 8). 2056 6.7.2. Pad1 2058 The Pad1 option MAY be present in DIS, DIO, DAO, DAO-ACK, and CC 2059 messages, and its format is as follows: 2061 0 2062 0 1 2 3 4 5 6 7 2063 +-+-+-+-+-+-+-+-+ 2064 | Type = 0x00 | 2065 +-+-+-+-+-+-+-+-+ 2067 Figure 20: Format of the Pad1 Option 2069 The Pad1 option is used to insert a single octet of padding into the 2070 message to enable options alignment. If more than one octet of 2071 padding is required, the PadN option should be used rather than 2072 multiple Pad1 options. 2074 NOTE! The format of the Pad1 option is a special case -- it has 2075 neither Option Length nor Option Data fields. 2077 6.7.3. PadN 2079 The PadN option MAY be present in DIS, DIO, DAO, DAO-ACK, and CC 2080 messages, and its format is as follows: 2082 0 1 2 2083 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - 2085 | Type = 0x01 | Option Length | 0x00 Padding... 2086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - 2088 Figure 21: Format of the Pad N Option 2090 The PadN option is used to insert two or more octets of padding into 2091 the message to enable options alignment. PadN option data MUST be 2092 ignored by the receiver. 2094 Option Type: 0x01 2096 Option Length: For N octets of padding, where 2 <= N <= 7, the 2097 Option Length field contains the value N-2. An Option Length 2098 of 0 indicates a total padding of 2 octets. An Option Length 2099 of 5 indicates a total padding of 7 octets, which is the 2100 maximum padding size allowed with the PadN option. 2102 Option Data: For N (N > 1) octets of padding, the Option Data 2103 consists of N-2 zero-valued octets. 2105 6.7.4. DAG Metric Container 2107 The DAG Metric Container option MAY be present in DIO or DAO 2108 messages, and its format is as follows: 2110 0 1 2 2111 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - 2113 | Type = 0x02 | Option Length | Metric Data 2114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - 2116 Figure 22: Format of the DAG Metric Container Option 2118 The DAG Metric Container is used to report metrics along the DODAG. 2119 The DAG Metric Container may contain a number of discrete node, link, 2120 and aggregate path metrics and constraints specified in [RFC6551] as 2121 chosen by the implementer. 2123 The DAG Metric Container MAY appear more than once in the same RPL 2124 control message, for example, to accommodate a use case where the 2125 Metric Data is longer than 256 bytes. More information is in 2126 [RFC6551]. 2128 The processing and propagation of the DAG Metric Container is 2129 governed by implementation specific policy functions. 2131 Option Type: 0x02 2133 Option Length: The Option Length field contains the length in octets 2134 of the Metric Data. 2136 Metric Data: The order, content, and coding of the DAG Metric 2137 Container data is as specified in [RFC6551]. 2139 6.7.5. Route Information 2141 The Route Information Option (RIO) MAY be present in DIO messages, 2142 and it carries the same information as the IPv6 Neighbor Discovery 2143 (ND) RIO as defined in [RFC4191]. The root of a DODAG is 2144 authoritative for setting that information and the information is 2145 unchanged as propagated down the DODAG. A RPL router may trivially 2146 transform it back into an ND option to advertise in its own RAs so a 2147 node attached to the RPL router will end up using the DODAG for which 2148 the root has the best preference for the destination of a packet. In 2149 addition to the existing ND semantics, it is possible for an 2150 Objective Function to use this information to favor a DODAG whose 2151 root is most preferred for a specific destination. The format of the 2152 option is modified slightly (Type, Length, Prefix) in order to be 2153 carried as a RPL option as follows: 2155 0 1 2 3 2156 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2158 | Type = 0x03 | Option Length | Prefix Length |Resvd|Prf|Resvd| 2159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2160 | Route Lifetime | 2161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2162 | | 2163 . Prefix (Variable Length) . 2164 . . 2165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2167 Figure 23: Format of the Route Information Option 2169 The RIO is used to indicate that connectivity to the specified 2170 destination prefix is available from the DODAG root. 2172 In the event that a RPL control message may need to specify 2173 connectivity to more than one destination, the RIO may be repeated. 2175 [RFC4191] should be consulted as the authoritative reference with 2176 respect to the RIO. The field descriptions are transcribed here for 2177 convenience: 2179 Option Type: 0x03 2181 Option Length: Variable, length of the option in octets excluding 2182 the Type and Length fields. Note that this length is expressed 2183 in units of single octets, unlike in IPv6 ND. 2185 Prefix Length: 8-bit unsigned integer. The number of leading bits 2186 in the prefix that are valid. The value ranges from 0 to 128. 2187 The Prefix field has the number of bytes inferred from the 2188 Option Length field, that must be at least the Prefix Length. 2189 Note that in RPL, this means that the Prefix field may have 2190 lengths other than 0, 8, or 16. 2192 Prf: 2-bit signed integer. The Route Preference indicates whether 2193 to prefer the router associated with this prefix over others, 2194 when multiple identical prefixes (for different routers) have 2195 been received. If the Reserved (10) value is received, the RIO 2196 MUST be ignored. Per [RFC4191], the Reserved (10) value MUST 2197 NOT be sent. ([RFC4191] restricts the Preference to just three 2198 values to reinforce that it is not a metric.) 2200 Resvd: Two 3-bit unused fields. They MUST be initialized to zero by 2201 the sender and MUST be ignored by the receiver. 2203 Route Lifetime: 32-bit unsigned integer. The length of time in 2204 seconds (relative to the time the packet is sent) that the 2205 prefix is valid for route determination. A value of all one 2206 bits (0xFFFFFFFF) represents infinity. 2208 Prefix: Variable-length field containing an IP address or a prefix 2209 of an IPv6 address. The Prefix Length field contains the 2210 number of valid leading bits in the prefix. The bits in the 2211 prefix after the prefix length (if any) are reserved and MUST 2212 be initialized to zero by the sender and ignored by the 2213 receiver. Note that in RPL, this field may have lengths other 2214 than 0, 8, or 16. 2216 Unassigned bits of the RIO are reserved. They MUST be set to zero on 2217 transmission and MUST be ignored on reception. 2219 6.7.6. DODAG Configuration 2221 The DODAG Configuration option MAY be present in DIO messages, and 2222 its format is as follows: 2224 0 1 2 3 2225 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2227 | Type = 0x04 |Opt Length = 14| Flags |A| PCS | DIOIntDoubl. | 2228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2229 | DIOIntMin. | DIORedun. | MaxRankIncrease | 2230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2231 | MinHopRankIncrease | OCP | 2232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2233 | Reserved | Def. Lifetime | Lifetime Unit | 2234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2236 Figure 24: Format of the DODAG Configuration Option 2238 The DODAG Configuration option is used to distribute configuration 2239 information for DODAG Operation through the DODAG. 2241 The information communicated in this option is generally static and 2242 unchanging within the DODAG, therefore it is not necessary to include 2243 in every DIO. This information is configured at the DODAG root and 2244 distributed throughout the DODAG with the DODAG Configuration option. 2245 Nodes other than the DODAG root MUST NOT modify this information when 2246 propagating the DODAG Configuration option. This option MAY be 2247 included occasionally by the DODAG root (as determined by the DODAG 2248 root), and MUST be included in response to a unicast request, e.g. a 2249 unicast DODAG Information Solicitation (DIS) message. 2251 Option Type: 0x04 2253 Option Length: 14 2255 Flags: The 4-bits remaining unused in the Flags field are reserved 2256 for flags. The field MUST be initialized to zero by the sender 2257 and MUST be ignored by the receiver. 2259 Authentication Enabled (A): 1-bit flag describing the security mode 2260 of the network. The bit describes whether a node must 2261 authenticate with a key authority before joining the network as 2262 a router. If the DIO is not a secure DIO, the 'A' bit MUST be 2263 zero. 2265 Path Control Size (PCS): 3-bit unsigned integer used to configure 2266 the number of bits that may be allocated to the Path Control 2267 field (see Section 9.9). Note that when PCS is consulted to 2268 determine the width of the Path Control field, a value of 1 is 2269 added, i.e., a PCS value of 0 results in 1 active bit in the 2270 Path Control field. The default value of PCS is 2271 DEFAULT_PATH_CONTROL_SIZE. 2273 DIOIntervalDoublings: 8-bit unsigned integer used to configure Imax 2274 of the DIO Trickle timer (see Section 8.3.1). The default 2275 value of DIOIntervalDoublings is 2276 DEFAULT_DIO_INTERVAL_DOUBLINGS. 2278 DIOIntervalMin: 8-bit unsigned integer used to configure Imin of the 2279 DIO Trickle timer (see Section 8.3.1). The default value of 2280 DIOIntervalMin is DEFAULT_DIO_INTERVAL_MIN. 2282 DIORedundancyConstant: 8-bit unsigned integer used to configure k of 2283 the DIO Trickle timer (see Section 8.3.1). The default value 2284 of DIORedundancyConstant is DEFAULT_DIO_REDUNDANCY_CONSTANT. 2286 MaxRankIncrease: 16-bit unsigned integer used to configure 2287 DAGMaxRankIncrease, the allowable increase in Rank in support 2288 of local repair. If DAGMaxRankIncrease is 0, then this 2289 mechanism is disabled. 2291 MinHopRankIncrease: 16-bit unsigned integer used to configure 2292 MinHopRankIncrease as described in Section 3.5.1. The default 2293 value of MinHopRankInc is DEFAULT_MIN_HOP_RANK_INCREASE. 2295 Objective Code Point (OCP): 16-bit unsigned integer. The OCP field 2296 identifies the OF and is managed by the IANA. 2298 Reserved: 7-bit unused field. The field MUST be initialized to zero 2299 by the sender and MUST be ignored by the receiver. 2301 Default Lifetime: 8-bit unsigned integer. This is the lifetime that 2302 is used as default for all RPL routes. It is expressed in 2303 units of Lifetime Units, e.g., the default lifetime in seconds 2304 is (Default Lifetime) * (Lifetime Unit). 2306 Lifetime Unit: 16-bit unsigned integer. Provides the unit in 2307 seconds that is used to express route lifetimes in RPL. For 2308 very stable networks, it can be hours to days. 2310 6.7.7. RPL Target 2312 The RPL Target option MAY be present in DAO messages, and its format 2313 is as follows: 2315 0 1 2 3 2316 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2318 | Type = 0x05 | Option Length | Flags | Prefix Length | 2319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2320 | | 2321 + + 2322 | Target Prefix (Variable Length) | 2323 . . 2324 . . 2325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2327 Figure 25: Format of the RPL Target Option 2329 The RPL Target option is used to indicate a Target IPv6 address, 2330 prefix, or multicast group that is reachable or queried along the 2331 DODAG. In a DAO, the RPL Target option indicates reachability. 2333 A RPL Target option MAY optionally be paired with a RPL Target 2334 Descriptor option (Figure 30) that qualifies the target. 2336 A set of one or more Transit Information options (Section 6.7.8) MAY 2337 directly follow a set of one or more Target options in a DAO message 2338 (where each Target option MAY be paired with a RPL Target Descriptor 2339 option as above). The structure of the DAO message, detailing how 2340 Target options are used in conjunction with Transit Information 2341 options is further described in Section 9.4. 2343 The RPL Target option may be repeated as necessary to indicate 2344 multiple targets. 2346 Option Type: 0x05 2348 Option Length: Variable, length of the option in octets excluding 2349 the Type and Length fields. 2351 Flags: 8-bit unused field reserved for flags. The field MUST be 2352 initialized to zero by the sender and MUST be ignored by the 2353 receiver. 2355 Prefix Length: 8-bit unsigned integer. Number of valid leading bits 2356 in the IPv6 Prefix. 2358 Target Prefix: Variable-length field identifying an IPv6 destination 2359 address, prefix, or multicast group. The Prefix Length field 2360 contains the number of valid leading bits in the prefix. The 2361 bits in the prefix after the prefix length (if any) are 2362 reserved and MUST be set to zero on transmission and MUST be 2363 ignored on receipt. 2365 6.7.8. Transit Information 2367 The Transit Information option MAY be present in DAO messages, and 2368 its format is as follows: 2370 0 1 2 3 2371 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2373 | Type = 0x06 | Option Length |E| Flags | Path Control | 2374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2375 | Path Sequence | Path Lifetime | | 2376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 2377 | | 2378 + + 2379 | | 2380 + Parent Address* + 2381 | | 2382 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2383 | | 2384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2386 The '*' denotes that the DODAG Parent Address subfield is not always 2387 present, as described below. 2389 Figure 26: Format of the Transit Information Option 2391 The Transit Information option is used for a node to indicate 2392 attributes for a path to one or more destinations. The destinations 2393 are indicated by one or more Target options that immediately precede 2394 the Transit Information option(s). 2396 The Transit Information option can be used for a node to indicate its 2397 DODAG parents to an ancestor that is collecting DODAG routing 2398 information, typically, for the purpose of constructing source 2399 routes. In the Non-Storing mode of operation, this ancestor will be 2400 the DODAG root, and this option is carried by the DAO message. In 2401 the Storing mode of operation, the DODAG Parent Address subfield is 2402 not needed, since the DAO message is sent directly to the parent. 2403 The option length is used to determine whether or not the DODAG 2404 Parent Address subfield is present. 2406 A non-storing node that has more than one DAO parent MAY include a 2407 Transit Information option for each DAO parent as part of the non- 2408 storing destination advertisement operation. The node may distribute 2409 the bits in the Path Control field among different groups of DAO 2410 parents in order to signal a preference among parents. That 2411 preference may influence the decision of the DODAG root when 2412 selecting among the alternate parents/paths for constructing Downward 2413 routes. 2415 One or more Transit Information options MUST be preceded by one or 2416 more RPL Target options. In this manner, the RPL Target option 2417 indicates the child node, and the Transit Information option(s) 2418 enumerates the DODAG parents. The structure of the DAO message, 2419 further detailing how Target options are used in conjunction with 2420 Transit Information options, is further described in Section 9.4. 2422 A typical non-storing node will use multiple Transit Information 2423 options, and it will send the DAO message thus formed directly to the 2424 root. A typical storing node will use one Transit Information option 2425 with no parent field and will send the DAO message thus formed, with 2426 additional adjustments, to Path Control as detailed later, to one or 2427 multiple parents. 2429 For example, in a Non-Storing mode of operation let Tgt(T) denote a 2430 Target option for a Target T. Let Trnst(P) denote a Transit 2431 Information option that contains a parent address P. Consider the 2432 case of a non-storing Node N that advertises the self-owned targets 2433 N1 and N2 and has parents P1, P2, and P3. In that case, the DAO 2434 message would be expected to contain the sequence ((Tgt(N1), 2435 Tgt(N2)), (Trnst(P1), Trnst(P2), Trnst(P3))), such that the group of 2436 Target options {N1, N2} is described by the Transit Information 2437 options as having the parents {P1, P2, P3}. The non-storing node 2438 would then address that DAO message directly to the DODAG root and 2439 forward that DAO message through one of the DODAG parents: P1, P2, or 2440 P3. 2442 Option Type: 0x06 2444 Option Length: Variable, depending on whether or not the DODAG 2445 Parent Address subfield is present. 2447 External (E): 1-bit flag. The 'E' flag is set to indicate that the 2448 parent router redistributes external targets into the RPL 2449 network. An external Target is a Target that has been learned 2450 through an alternate protocol. The external targets are listed 2451 in the Target options that immediately precede the Transit 2452 Information option. An external Target is not expected to 2453 support RPL messages and options. 2455 Flags: The 7 bits remaining unused in the Flags field are reserved 2456 for flags. The field MUST be initialized to zero by the sender 2457 and MUST be ignored by the receiver. 2459 Path Control: 8-bit bit field. The Path Control field limits the 2460 number of DAO parents to which a DAO message advertising 2461 connectivity to a specific destination may be sent, as well as 2462 providing some indication of relative preference. The limit 2463 provides some bound on overall DAO message fan-out in the LLN. 2464 The assignment and ordering of the bits in the Path Control 2465 also serves to communicate preference. Not all of these bits 2466 may be enabled as according to the PCS in the DODAG 2467 Configuration. The Path Control field is divided into four 2468 subfields that contain two bits each: PC1, PC2, PC3, and PC4, 2469 as illustrated in Figure 27. The subfields are ordered by 2470 preference, with PC1 being the most preferred and PC4 being the 2471 least preferred. Within a subfield, there is no order of 2472 preference. By grouping the parents (as in ECMP) and ordering 2473 them, the parents may be associated with specific bits in the 2474 Path Control field in a way that communicates preference. 2476 0 1 2 3 4 5 6 7 2477 +-+-+-+-+-+-+-+-+ 2478 |PC1|PC2|PC3|PC4| 2479 +-+-+-+-+-+-+-+-+ 2481 Figure 27: Path Control Preference Subfield Encoding 2483 Path Sequence: 8-bit unsigned integer. When a RPL Target option is 2484 issued by the node that owns the Target prefix (i.e., in a DAO 2485 message), that node sets the Path Sequence and increments the 2486 Path Sequence each time it issues a RPL Target option with 2487 updated information. 2489 Path Lifetime: 8-bit unsigned integer. The length of time in 2490 Lifetime Units (obtained from the Configuration option) that 2491 the prefix is valid for route determination. The period starts 2492 when a new Path Sequence is seen. A value of all one bits 2493 (0xFF) represents infinity. A value of all zero bits (0x00) 2494 indicates a loss of reachability. A DAO message that contains 2495 a Transit Information option with a Path Lifetime of 0x00 for a 2496 Target is referred as a No-Path (for that Target) in this 2497 document. 2499 Parent Address (optional): IPv6 address of the DODAG parent of the 2500 node originally issuing the Transit Information option. This 2501 field may not be present, as according to the DODAG Mode of 2502 Operation (Storing or Non-Storing) and indicated by the Transit 2503 Information option length. 2505 Unassigned bits of the Transit Information option are reserved. They 2506 MUST be set to zero on transmission and MUST be ignored on reception. 2508 6.7.9. Solicited Information 2510 The Solicited Information option MAY be present in DIS messages, and 2511 its format is as follows: 2513 0 1 2 3 2514 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2516 | Type = 0x07 |Opt Length = 19| RPLInstanceID |V|I|D| Flags | 2517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2518 | | 2519 + + 2520 | | 2521 + DODAGID + 2522 | | 2523 + + 2524 | | 2525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2526 |Version Number | 2527 +-+-+-+-+-+-+-+-+ 2529 Figure 28: Format of the Solicited Information Option 2531 The Solicited Information option is used for a node to request DIO 2532 messages from a subset of neighboring nodes. The Solicited 2533 Information option may specify a number of predicate criteria to be 2534 matched by a receiving node. This is used by the requester to limit 2535 the number of replies from "non-interesting" nodes. These predicates 2536 affect whether a node resets its DIO Trickle timer, as described in 2537 Section 8.3. 2539 The Solicited Information option contains flags that indicate which 2540 predicates a node should check when deciding whether to reset its 2541 Trickle timer. A node resets its Trickle timer when all predicates 2542 are true. If a flag is set, then the RPL node MUST check the 2543 associated predicate. If a flag is cleared, then the RPL node MUST 2544 NOT check the associated predicate. (If a flag is cleared, the RPL 2545 node assumes that the associated predicate is true.) 2547 Option Type: 0x07 2548 Option Length: 19 2550 V: The 'V' flag is the Version predicate. The Version predicate 2551 is true if the receiver's DODAGVersionNumber matches the 2552 requested Version Number. If the 'V' flag is cleared, then the 2553 Version field is not valid and the Version field MUST be set to 2554 zero on transmission and ignored upon receipt. 2556 I: The 'I' flag is the InstanceID predicate. The InstanceID 2557 predicate is true when the RPL node's current RPLInstanceID 2558 matches the requested RPLInstanceID. If the 'I' flag is 2559 cleared, then the RPLInstanceID field is not valid and the 2560 RPLInstanceID field MUST be set to zero on transmission and 2561 ignored upon receipt. 2563 D: The 'D' flag is the DODAGID predicate. The DODAGID predicate 2564 is true if the RPL node's parent set has the same DODAGID as 2565 the DODAGID field. If the 'D' flag is cleared, then the 2566 DODAGID field is not valid and the DODAGID field MUST be set to 2567 zero on transmission and ignored upon receipt. 2569 Flags: The 5 bits remaining unused in the Flags field are reserved 2570 for flags. The field MUST be initialized to zero by the sender 2571 and MUST be ignored by the receiver. 2573 Version Number: 8-bit unsigned integer containing the value of 2574 DODAGVersionNumber that is being solicited when valid. 2576 RPLInstanceID: 8-bit unsigned integer containing the RPLInstanceID 2577 that is being solicited when valid. 2579 DODAGID: 128-bit unsigned integer containing the DODAGID that is 2580 being solicited when valid. 2582 Unassigned bits of the Solicited Information option are reserved. 2583 They MUST be set to zero on transmission and MUST be ignored on 2584 reception. 2586 6.7.10. Prefix Information 2588 The Prefix Information Option (PIO) MAY be present in DIO messages, 2589 and carries the information that is specified for the IPv6 ND Prefix 2590 Information option in [RFC4861], [RFC4862], and [RFC6275] for use by 2591 RPL nodes and IPv6 hosts. In particular, a RPL node may use this 2592 option for the purpose of Stateless Address Autoconfiguration (SLAAC) 2593 from a prefix advertised by a parent as specified in [RFC4862], and 2594 advertise its own address as specified in [RFC6275]. The root of a 2595 DODAG is authoritative for setting that information. The information 2596 is propagated down the DODAG unchanged, with the exception that a RPL 2597 router may overwrite the Interface ID if the 'R' flag is set to 2598 indicate its full address in the PIO. The format of the option is 2599 modified (Type, Length, Prefix) in order to be carried as a RPL 2600 option as follows: 2602 If the only desired effect of a received PIO in a DIO is to provide 2603 the global address of the parent node to the receiving node, then the 2604 sender resets the 'A' and 'L' bits and sets the 'R' bit. Upon 2605 receipt, the RPL will not autoconfigure an address or a connected 2606 route from the prefix [RFC4862]. As in all cases, when the 'L' bit 2607 is not set, the RPL node MAY include the prefix in PIOs it sends to 2608 its children. 2610 0 1 2 3 2611 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2613 | Type = 0x08 |Opt Length = 30| Prefix Length |L|A|R|Reserved1| 2614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2615 | Valid Lifetime | 2616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2617 | Preferred Lifetime | 2618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2619 | Reserved2 | 2620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2621 | | 2622 + + 2623 | | 2624 + Prefix + 2625 | | 2626 + + 2627 | | 2628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2630 Figure 29: Format of the Prefix Information Option 2632 The PIO may be used to distribute the prefix in use inside the DODAG, 2633 e.g., for address autoconfiguration. 2635 [RFC4861] and [RFC6275] should be consulted as the authoritative 2636 reference with respect to the PIO. The field descriptions are 2637 transcribed here for convenience: 2639 Option Type: 0x08 2641 Option Length: 30. Note that this length is expressed in units of 2642 single octets, unlike in IPv6 ND. 2644 Prefix Length: 8-bit unsigned integer. The number of leading bits 2645 in the Prefix field that are valid. The value ranges from 0 to 2646 128. The Prefix Length field provides necessary information 2647 for on-link determination (when combined with the 'L' flag in 2648 the PIO). It also assists with address autoconfiguration as 2649 specified in [RFC4862], for which there may be more 2650 restrictions on the prefix length. 2652 L: 1-bit on-link flag. When set, it indicates that this prefix 2653 can be used for on-link determination. When not set, the 2654 advertisement makes no statement about on-link or off-link 2655 properties of the prefix. In other words, if the 'L' flag is 2656 not set, a RPL node MUST NOT conclude that an address derived 2657 from the prefix is off-link. That is, it MUST NOT update a 2658 previous indication that the address is on-link. A RPL node 2659 acting as a router MUST NOT propagate a PIO with the 'L' flag 2660 set. A RPL node acting as a router MAY propagate a PIO with 2661 the 'L' flag not set. 2663 A: 1-bit autonomous address-configuration flag. When set, it 2664 indicates that this prefix can be used for stateless address 2665 configuration as specified in [RFC4862]. When both protocols 2666 (ND RAs and RPL DIOs) are used to carry PIOs on the same link, 2667 it is possible to use either one for SLAAC by a RPL node. It 2668 is also possible to make either protocol ineligible for SLAAC 2669 operation by forcing the 'A' flag to 0 for PIOs carried in that 2670 protocol. 2672 R: 1-bit router address flag. When set, it indicates that the 2673 Prefix field contains a complete IPv6 address assigned to the 2674 sending router that can be used as parent in a target option. 2675 The indicated prefix is the first prefix length bits of the 2676 Prefix field. The router IPv6 address has the same scope and 2677 conforms to the same lifetime values as the advertised prefix. 2678 This use of the Prefix field is compatible with its use in 2679 advertising the prefix itself, since Prefix Advertisement uses 2680 only the leading bits. Interpretation of this flag bit is thus 2681 independent of the processing required for the on-link (L) and 2682 autonomous address-configuration (A) flag bits. 2684 Reserved1: 5-bit unused field. It MUST be initialized to zero by 2685 the sender and MUST be ignored by the receiver. 2687 Valid Lifetime: 32-bit unsigned integer. The length of time in 2688 seconds (relative to the time the packet is sent) that the 2689 prefix is valid for the purpose of on-link determination. A 2690 value of all one bits (0xFFFFFFFF) represents infinity. The 2691 Valid Lifetime is also used by [RFC4862]. 2693 Preferred Lifetime: 32-bit unsigned integer. The length of time in 2694 seconds (relative to the time the packet is sent) that 2695 addresses generated from the prefix via stateless address 2696 autoconfiguration remain preferred [RFC4862]. A value of all 2697 one bits (0xFFFFFFFF) represents infinity. See [RFC4862]. 2698 Note that the value of this field MUST NOT exceed the Valid 2699 Lifetime field to avoid preferring addresses that are no longer 2700 valid. 2702 Reserved2: This field is unused. It MUST be initialized to zero by 2703 the sender and MUST be ignored by the receiver. 2705 Prefix: An IPv6 address or a prefix of an IPv6 address. The Prefix 2706 Length field contains the number of valid leading bits in the 2707 prefix. The bits in the prefix after the prefix length are 2708 reserved and MUST be initialized to zero by the sender and 2709 ignored by the receiver. A router SHOULD NOT send a prefix 2710 option for the link-local prefix, and a host SHOULD ignore such 2711 a prefix option. A non-storing node SHOULD refrain from 2712 advertising a prefix till it owns an address of that prefix, 2713 and then it SHOULD advertise its full address in this field, 2714 with the 'R' flag set. The children of a node that so 2715 advertises a full address with the 'R' flag set may then use 2716 that address to determine the content of the DODAG Parent 2717 Address subfield of the Transit Information option. 2719 Unassigned bits of the PIO are reserved. They MUST be set to zero on 2720 transmission and MUST be ignored on reception. 2722 6.7.11. RPL Target Descriptor 2724 The RPL Target option MAY be immediately followed by one opaque 2725 descriptor that qualifies that specific target. 2727 0 1 2 3 2728 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2730 | Type = 0x09 |Opt Length = 4 | Descriptor 2731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2732 Descriptor (cont.) | 2733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2735 Figure 30: Format of the RPL Target Descriptor Option 2737 The RPL Target Descriptor option is used to qualify a target, 2738 something that is sometimes called "tagging". 2740 At most, there can be one descriptor per target. The descriptor is 2741 set by the node that injects the Target in the RPL network. It MUST 2742 be copied but not modified by routers that propagate the Target Up 2743 the DODAG in DAO messages. 2745 Option Type: 0x09 2747 Option Length: 4 2749 Descriptor: 32-bit unsigned integer. Opaque. 2751 7. Sequence Counters 2753 This section describes the general scheme for bootstrap and operation 2754 of sequence counters in RPL, such as the DODAGVersionNumber in the 2755 DIO message, the DAOSequence in the DAO message, and the Path 2756 Sequence in the Transit Information option. 2758 7.1. Sequence Counter Overview 2760 This specification utilizes three different sequence numbers to 2761 validate the freshness and the synchronization of protocol 2762 information: 2764 DODAGVersionNumber: This sequence counter is present in the DIO Base 2765 to indicate the Version of the DODAG being formed. The 2766 DODAGVersionNumber is monotonically incremented by the root 2767 each time the root decides to form a new Version of the DODAG 2768 in order to revalidate the integrity and allow a global repair 2769 to occur. The DODAGVersionNumber is propagated unchanged Down 2770 the DODAG as routers join the new DODAG Version. The 2771 DODAGVersionNumber is globally significant in a DODAG and 2772 indicates the Version of the DODAG in which a router is 2773 operating. An older (lesser) value indicates that the 2774 originating router has not migrated to the new DODAG Version 2775 and cannot be used as a parent once the receiving node has 2776 migrated to the newer DODAG Version. 2778 DAOSequence: This sequence counter is present in the DAO Base to 2779 correlate a DAO message and a DAO ACK message. The DAOSequence 2780 number is locally significant to the node that issues a DAO 2781 message for its own consumption to detect the loss of a DAO 2782 message and enable retries. 2784 Path Sequence: This sequence counter is present in the Transit 2785 Information option in a DAO message. The purpose of this 2786 counter is to differentiate a movement where a newer route 2787 supersedes a stale one from a route redundancy scenario where 2788 multiple routes exist in parallel for the same target. The 2789 Path Sequence is globally significant in a DODAG and indicates 2790 the freshness of the route to the associated target. An older 2791 (lesser) value received from an originating router indicates 2792 that the originating router holds stale routing states and the 2793 originating router should not be considered anymore as a 2794 potential next hop for the target. The Path Sequence is 2795 computed by the node that advertises the target, that is the 2796 Target itself or a router that advertises a Target on behalf of 2797 a host, and is unchanged as the DAO content is propagated 2798 towards the root by parent routers. If a host does not pass a 2799 counter to its router, then the router is in charge of 2800 computing the Path Sequence on behalf of the host and the host 2801 can only register to one router for that purpose. If a DAO 2802 message containing the same Target is issued to multiple 2803 parents at a given point in time for the purpose of route 2804 redundancy, then the Path Sequence is the same in all the DAO 2805 messages for that same target. 2807 7.2. Sequence Counter Operation 2809 RPL sequence counters are subdivided in a 'lollipop' fashion 2810 [Perlman83], where the values from 128 and greater are used as a 2811 linear sequence to indicate a restart and bootstrap the counter, and 2812 the values less than or equal to 127 used as a circular sequence 2813 number space of size 128 as in [RFC1982]. Consideration is given to 2814 the mode of operation when transitioning from the linear region to 2815 the circular region. Finally, when operating in the circular region, 2816 if sequence numbers are detected to be too far apart, then they are 2817 not comparable, as detailed below. 2819 A window of comparison, SEQUENCE_WINDOW = 16, is configured based on 2820 a value of 2^N, where N is defined to be 4 in this specification. 2822 For a given sequence counter: 2824 1. The sequence counter SHOULD be initialized to an implementation 2825 defined value, which is 128 or greater prior to use. A 2826 recommended value is 240 (256 - SEQUENCE_WINDOW). 2828 2. When a sequence counter increment would cause the sequence 2829 counter to increment beyond its maximum value, the sequence 2830 counter MUST wrap back to zero. When incrementing a sequence 2831 counter greater than or equal to 128, the maximum value is 255. 2832 When incrementing a sequence counter less than 128, the maximum 2833 value is 127. 2835 3. When comparing two sequence counters, the following rules MUST be 2836 applied: 2838 1. When a first sequence counter A is in the interval [128..255] 2839 and a second sequence counter B is in [0..127]: 2841 1. If (256 + B - A) is less than or equal to 2842 SEQUENCE_WINDOW, then B is greater than A, A is less than 2843 B, and the two are not equal. 2845 2. If (256 + B - A) is greater than SEQUENCE_WINDOW, then A 2846 is greater than B, B is less than A, and the two are not 2847 equal. 2849 For example, if A is 240, and B is 5, then (256 + 5 - 240) is 2850 21. 21 is greater than SEQUENCE_WINDOW (16); thus, 240 is 2851 greater than 5. As another example, if A is 250 and B is 5, 2852 then (256 + 5 - 250) is 11. 11 is less than SEQUENCE_WINDOW 2853 (16); thus, 250 is less than 5. 2855 2. In the case where both sequence counters to be compared are 2856 less than or equal to 127, and in the case where both 2857 sequence counters to be compared are greater than or equal to 2858 128: 2860 1. If the absolute magnitude of difference between the two 2861 sequence counters is less than or equal to 2862 SEQUENCE_WINDOW, then a comparison as described in 2863 [RFC1982] is used to determine the relationships greater 2864 than, less than, and equal. 2866 2. If the absolute magnitude of difference of the two 2867 sequence counters is greater than SEQUENCE_WINDOW, then a 2868 desynchronization has occurred and the two sequence 2869 numbers are not comparable. 2871 4. If two sequence numbers are determined not to be comparable, 2872 i.e., the results of the comparison are not defined, then a node 2873 should consider the comparison as if it has evaluated in such a 2874 way so as to give precedence to the sequence number that has most 2875 recently been observed to increment. Failing this, the node 2876 should consider the comparison as if it has evaluated in such a 2877 way so as to minimize the resulting changes to its own state. 2879 8. Upward Routes 2881 This section describes how RPL discovers and maintains Upward routes. 2882 It describes the use of DODAG Information Objects (DIOs), the 2883 messages used to discover and maintain these routes. It specifies 2884 how RPL generates and responds to DIOs. It also describes DODAG 2885 Information Solicitation (DIS) messages, which are used to trigger 2886 DIO transmissions. 2888 As mentioned in Section 3.2.8, nodes that decide to join a DODAG MUST 2889 provision at least one DODAG parent as a default route for the 2890 associated instance. This default route enables a packet to be 2891 forwarded Upward until it eventually hits a common ancestor from 2892 which it will be routed Downward to the destination. If the 2893 destination is not in the DODAG, then the DODAG root may be able to 2894 forward the packet using connectivity to the outside of the DODAG; if 2895 it cannot forward the packet outside, then the DODAG root has to drop 2896 it. 2898 A DIO message can also transport explicit routing information: 2900 DODAGID: The DODAGID is a Global or Unique Local IPv6 address of the 2901 root. A node that joins a DODAG SHOULD provision a host route 2902 via a DODAG parent to the address used by the root as the 2903 DODAGID. 2905 RIO Prefix: The root MAY place one or more Route Information options 2906 in a DIO message. The RIO is used to advertise an external 2907 route that is reachable via the root, associated with a 2908 preference, as presented in Section 6.7.5, which incorporates 2909 the RIO from [RFC4191]. It is interpreted as a capability of 2910 the root as opposed to a routing advertisement, and it MUST NOT 2911 be redistributed in another routing protocol though it SHOULD 2912 be used by an ingress RPL router to select a DODAG when a 2913 packet is injected in a RPL domain from a node attached to that 2914 RPL router. An Objective Function MAY use the routes 2915 advertised in RIO or the preference for those routes in order 2916 to favor a DODAG versus another one for the same instance. 2918 8.1. DIO Base Rules 2920 1. For the following DIO Base fields, a node that is not a DODAG 2921 root MUST advertise the same values as its preferred DODAG parent 2922 (defined in Section 8.2.1). In this way, these values will 2923 propagate Down the DODAG unchanged and advertised by every node 2924 that has a route to that DODAG root. These fields are as 2925 follows: 2927 1. Grounded (G) 2928 2. Mode of Operation (MOP) 2929 3. DAGPreference (Prf) 2930 4. Version 2931 5. RPLInstanceID 2932 6. DODAGID 2934 2. A node MAY update the following fields at each hop: 2936 1. Rank 2937 2. DTSN 2939 3. The DODAGID field each root sets MUST be unique within the RPL 2940 Instance and MUST be a routable IPv6 address belonging to the 2941 root. 2943 8.2. Upward Route Discovery and Maintenance 2945 Upward route discovery allows a node to join a DODAG by discovering 2946 neighbors that are members of the DODAG of interest and identifying a 2947 set of parents. The exact policies for selecting neighbors and 2948 parents is implementation dependent and driven by the OF. This 2949 section specifies the set of rules those policies must follow for 2950 interoperability. 2952 8.2.1. Neighbors and Parents within a DODAG Version 2954 RPL's Upward route discovery algorithms and processing are in terms 2955 of three logical sets of link-local nodes. First, the candidate 2956 neighbor set is a subset of the nodes that can be reached via link- 2957 local multicast. The selection of this set is implementation and OF 2958 dependent. Second, the parent set is a restricted subset of the 2959 candidate neighbor set. Finally, the preferred parent is a member of 2960 the parent set that is the preferred next hop in Upward routes. 2961 Conceptually, the preferred parent is a single parent; although, it 2962 may be a set of multiple parents if those parents are equally 2963 preferred and have identical Rank. 2965 More precisely: 2967 1. The DODAG parent set MUST be a subset of the candidate neighbor 2968 set. 2970 2. A DODAG root MUST have a DODAG parent set of size zero. 2972 3. A node that is not a DODAG root MAY maintain a DODAG parent set 2973 of size greater than or equal to one. 2975 4. A node's preferred DODAG parent MUST be a member of its DODAG 2976 parent set. 2978 5. A node's Rank MUST be greater than all elements of its DODAG 2979 parent set. 2981 6. When Neighbor Unreachability Detection (NUD) [RFC4861], or an 2982 equivalent mechanism, determines that a neighbor is no longer 2983 reachable, a RPL node MUST NOT consider this node in the 2984 candidate neighbor set when calculating and advertising routes 2985 until it determines that it is again reachable. Routes through 2986 an unreachable neighbor MUST be removed from the routing table. 2988 These rules ensure that there is a consistent partial order on nodes 2989 within the DODAG. As long as node Ranks do not change, following the 2990 above rules ensures that every node's route to a DODAG root is loop- 2991 free, as Rank decreases on each hop to the root. 2993 The OF can guide candidate neighbor set and parent set selection, as 2994 discussed in [RFC6552]. 2996 8.2.2. Neighbors and Parents across DODAG Versions 2998 The above rules govern a single DODAG Version. The rules in this 2999 section define how RPL operates when there are multiple DODAG 3000 Versions. 3002 8.2.2.1. DODAG Version 3004 1. The tuple (RPLInstanceID, DODAGID, DODAGVersionNumber) uniquely 3005 defines a DODAG Version. Every element of a node's DODAG parent 3006 set, as conveyed by the last heard DIO message from each DODAG 3007 parent, MUST belong to the same DODAG Version. Elements of a 3008 node's candidate neighbor set MAY belong to different DODAG 3009 Versions. 3011 2. A node is a member of a DODAG Version if every element of its 3012 DODAG parent set belongs to that DODAG Version, or if that node 3013 is the root of the corresponding DODAG. 3015 3. A node MUST NOT send DIOs for DODAG Versions of which it is not a 3016 member. 3018 4. DODAG roots MAY increment the DODAGVersionNumber that they 3019 advertise and thus move to a new DODAG Version. When a DODAG 3020 root increments its DODAGVersionNumber, it MUST follow the 3021 conventions of Serial Number Arithmetic as described in 3022 Section 7. Events triggering the increment of the 3023 DODAGVersionNumber are described later in this section and in 3024 Section 18. 3026 5. Within a given DODAG, a node that is a not a root MUST NOT 3027 advertise a DODAGVersionNumber higher than the highest 3028 DODAGVersionNumber it has heard. Higher is defined as the 3029 greater-than operator in Section 7. 3031 6. Once a node has advertised a DODAG Version by sending a DIO, it 3032 MUST NOT be a member of a previous DODAG Version of the same 3033 DODAG (i.e., with the same RPLInstanceID, the same DODAGID, and a 3034 lower DODAGVersionNumber). Lower is defined as the less-than 3035 operator in Section 7. 3037 When the DODAG parent set becomes empty on a node that is not a root, 3038 (i.e., the last parent has been removed, causing the node no longer 3039 to be associated with that DODAG), then the DODAG information should 3040 not be suppressed until after the expiration of an implementation- 3041 specific local timer. During the interval prior to suppression of 3042 the "old" DODAG state, the node will be able to observe if the 3043 DODAGVersionNumber has been incremented should any new parents 3044 appear. This will help protect against the possibility of loops that 3045 may occur if that node were to inadvertently rejoin the old DODAG 3046 Version in its own prior sub-DODAG. 3048 As the DODAGVersionNumber is incremented, a new DODAG Version spreads 3049 outward from the DODAG root. A parent that advertises the new 3050 DODAGVersionNumber cannot belong to the sub-DODAG of a node 3051 advertising an older DODAGVersionNumber. Therefore, a node can 3052 safely add a parent of any Rank with a newer DODAGVersionNumber 3053 without forming a loop. 3055 For example, suppose that a node has left a DODAG with 3056 DODAGVersionNumber N. Suppose that a node had a sub-DODAG and did 3057 attempt to poison that sub-DODAG by advertising a Rank of 3058 INFINITE_RANK, but those advertisements may have become lost in the 3059 LLN. Then, if the node did observe a candidate neighbor advertising 3060 a position in that original DODAG at DODAGVersionNumber N, that 3061 candidate neighbor could possibly have been in the node's former sub- 3062 DODAG, and there is a possible case where adding that candidate 3063 neighbor as a parent could cause a loop. In this case, if that 3064 candidate neighbor is observed to advertise a DODAGVersionNumber N+1, 3065 then that candidate neighbor is certain to be safe, since it is 3066 certain not to be in that original node's sub-DODAG, as it has been 3067 able to increment the DODAGVersionNumber by hearing from the DODAG 3068 root while that original node was detached. For this reason, it is 3069 useful for the detached node to remember the original DODAG 3070 information, including the DODAGVersionNumber N. 3072 Exactly when a DODAG root increments the DODAGVersionNumber is 3073 implementation dependent and out of scope for this specification. 3074 Examples include incrementing the DODAGVersionNumber periodically, 3075 upon administrative intervention, or on application-level detection 3076 of lost connectivity or DODAG inefficiency. 3078 After a node transitions to and advertises a new DODAG Version, the 3079 rules above make it unable to advertise the previous DODAG Version 3080 (prior DODAGVersionNumber) once it has committed to advertising the 3081 new DODAG Version. 3083 8.2.2.2. DODAG Roots 3085 1. A DODAG root without possibility to satisfy the application- 3086 defined goal MUST NOT set the Grounded bit. 3088 2. A DODAG root MUST advertise a Rank of ROOT_RANK. 3090 3. A node whose DODAG parent set is empty MAY become the DODAG root 3091 of a floating DODAG. It MAY also set its DAGPreference such that 3092 it is less preferred. 3094 In a deployment that uses non-LLN links to federate a number of LLN 3095 roots, it is possible to run RPL over those non-RPL links and use one 3096 router as a "backbone root". The backbone root is the virtual root 3097 of the DODAG and exposes a Rank of BASE_RANK over the backbone. All 3098 the LLN roots that are parented to that backbone root, including the 3099 backbone root if it also serves as the LLN root itself, expose a Rank 3100 of ROOT_RANK to the LLN. These virtual roots are part of the same 3101 DODAG and advertise the same DODAGID. They coordinate 3102 DODAGVersionNumbers and other DODAG parameters with the virtual root 3103 over the backbone. The method of coordination is out of scope for 3104 this specification (to be defined in future companion 3105 specifications). 3107 8.2.2.3. DODAG Selection 3109 The Objective Function and the set of advertised routing metrics and 3110 constraints of a DAG determine how a node selects its neighbor set, 3111 parent set, and preferred parents. This selection implicitly also 3112 determines the DODAG within a DAG. Such selection can include 3113 administrative preference (Prf) as well as metrics or other 3114 considerations. 3116 If a node has the option to join a more preferred DODAG while still 3117 meeting other optimization objectives, then the node will generally 3118 seek to join the more preferred DODAG as determined by the OF. All 3119 else being equal, it is left to the implementation to determine which 3120 DODAG is most preferred (since, as a reminder, a node must only join 3121 one DODAG per RPL Instance). 3123 8.2.2.4. Rank and Movement within a DODAG Version 3125 1. A node MUST NOT advertise a Rank less than or equal to any member 3126 of its parent set within the DODAG Version. 3128 2. A node MAY advertise a Rank lower than its prior advertisement 3129 within the DODAG Version. 3131 3. Let L be the lowest Rank within a DODAG Version that a given node 3132 has advertised. Within the same DODAG Version, that node MUST 3133 NOT advertise an effective Rank higher than L + 3134 DAGMaxRankIncrease. INFINITE_RANK is an exception to this rule: 3135 a node MAY advertise an INFINITE_RANK within a DODAG Version 3136 without restriction. If a node's Rank were to be higher than 3137 allowed by L + DAGMaxRankIncrease, when it advertises Rank, it 3138 MUST advertise its Rank as INFINITE_RANK. 3140 4. A node MAY, at any time, choose to join a different DODAG within 3141 a RPL Instance. Such a join has no Rank restrictions, unless 3142 that different DODAG is a DODAG Version of which this node has 3143 previously been a member; in which case, the rule of the previous 3144 bullet (3) must be observed. Until a node transmits a DIO 3145 indicating its new DODAG membership, it MUST forward packets 3146 along the previous DODAG. 3148 5. A node MAY, at any time after hearing the next DODAGVersionNumber 3149 advertised from suitable DODAG parents, choose to migrate to the 3150 next DODAG Version within the DODAG. 3152 Conceptually, an implementation is maintaining a DODAG parent set 3153 within the DODAG Version. Movement entails changes to the DODAG 3154 parent set. Moving Up does not present the risk to create a loop but 3155 moving Down might, so that operation is subject to additional 3156 constraints. 3158 When a node migrates to the next DODAG Version, the DODAG parent set 3159 needs to be rebuilt for the new Version. An implementation could 3160 defer to migrate for some reasonable amount of time, to see if some 3161 other neighbors with potentially better metrics but higher Rank 3162 announce themselves. Similarly, when a node jumps into a new DODAG, 3163 it needs to construct a new DODAG parent set for this new DODAG. 3165 If a node needs to move Down a DODAG that it is attached to, 3166 increasing its Rank, then it MAY poison its routes and delay before 3167 moving as described in Section 8.2.2.5. 3169 A node is allowed to join any DODAG Version that it has never been a 3170 prior member of without any restrictions, but if the node has been a 3171 prior member of the DODAG Version, then it must continue to observe 3172 the rule that it may not advertise a Rank higher than 3173 L+DAGMaxRankIncrease at any point in the life of the DODAG Version. 3174 This rule must be observed so as not to create a loophole that would 3175 allow the node to effectively increment its Rank all the way to 3176 INFINITE_RANK, which may have impact on other nodes and create a 3177 resource-wasting count-to-infinity scenario. 3179 8.2.2.5. Poisoning 3181 1. A node poisons routes by advertising a Rank of INFINITE_RANK. 3183 2. A node MUST NOT have any nodes with a Rank of INFINITE_RANK in 3184 its parent set. 3186 Although an implementation may advertise INFINITE_RANK for the 3187 purposes of poisoning, doing so is not the same as setting Rank to 3188 INFINITE_RANK. For example, a node may continue to send data packets 3189 whose RPL Packet Information includes a Rank that is not 3190 INFINITE_RANK, yet still advertise INFINITE_RANK in its DIOs. 3192 When a (former) parent is observed to advertise a Rank of 3193 INFINITE_RANK, that (former) parent has detached from the DODAG and 3194 is no longer able to act as a parent, nor is there any way that 3195 another node may be considered to have a Rank greater-than 3196 INFINITE_RANK. Therefore, that (former) parent cannot act as a 3197 parent any longer and is removed from the parent set. 3199 8.2.2.6. Detaching 3201 1. A node unable to stay connected to a DODAG within a given DODAG 3202 Version, i.e., that cannot retain non-empty parent set without 3203 violating the rules of this specification, MAY detach from this 3204 DODAG Version. A node that detaches becomes the root of its own 3205 floating DODAG and SHOULD immediately advertise this new 3206 situation in a DIO as an alternate to poisoning. 3208 8.2.2.7. Following a Parent 3210 1. If a node receives a DIO from one of its DODAG parents, 3211 indicating that the parent has left the DODAG, that node SHOULD 3212 stay in its current DODAG through an alternative DODAG parent, if 3213 possible. It MAY follow the leaving parent. 3215 A DODAG parent may have moved, migrated to the next DODAG Version, or 3216 jumped to a different DODAG. A node ought to give some preference to 3217 remaining in the current DODAG, if possible via an alternate parent, 3218 but ought to follow the parent if there are no other options. 3220 8.2.3. DIO Message Communication 3222 When a DIO message is received, the receiving node must first 3223 determine whether or not the DIO message should be accepted for 3224 further processing, and subsequently present the DIO message for 3225 further processing if eligible. 3227 1. If the DIO message is malformed, then the DIO message is not 3228 eligible for further processing and a node MUST silently discard 3229 it. (See Section 18 for error logging). 3231 2. If the sender of the DIO message is a member of the candidate 3232 neighbor set and the DIO message is not malformed, the node MUST 3233 process the DIO. 3235 8.2.3.1. DIO Message Processing 3237 As DIO messages are received from candidate neighbors, the neighbors 3238 may be promoted to DODAG parents by following the rules of DODAG 3239 discovery as described in Section 8.2. When a node places a neighbor 3240 into the DODAG parent set, the node becomes attached to the DODAG 3241 through the new DODAG parent node. 3243 The most preferred parent should be used to restrict which other 3244 nodes may become DODAG parents. Some nodes in the DODAG parent set 3245 may be of a Rank less than or equal to the most preferred DODAG 3246 parent. (This case may occur, for example, if an energy-constrained 3247 device is at a lesser Rank but should be avoided per an optimization 3248 objective, resulting in a more preferred parent at a greater Rank.) 3250 8.3. DIO Transmission 3252 RPL nodes transmit DIOs using a Trickle timer [RFC6206]. A DIO from 3253 a sender with a lesser DAGRank that causes no changes to the 3254 recipient's parent set, preferred parent, or Rank SHOULD be 3255 considered consistent with respect to the Trickle timer. 3257 The following packets and events MUST be considered inconsistencies 3258 with respect to the Trickle timer, and cause the Trickle timer to 3259 reset: 3261 * When a node detects an inconsistency when forwarding a packet, as 3262 detailed in Section 11.2. 3264 * When a node receives a multicast DIS message without a Solicited 3265 Information option, unless a DIS flag restricts this behavior. 3267 * When a node receives a multicast DIS with a Solicited Information 3268 option and the node matches all of the predicates in the Solicited 3269 Information option, unless a DIS flag restricts this behavior. 3271 * When a node joins a new DODAG Version (e.g., by updating its 3272 DODAGVersionNumber, joining a new RPL Instance, etc.). 3274 Note that this list is not exhaustive, and an implementation MAY 3275 consider other messages or events to be inconsistencies. 3277 A node SHOULD NOT reset its DIO Trickle timer in response to unicast 3278 DIS messages. When a node receives a unicast DIS without a Solicited 3279 Information option, it MUST unicast a DIO to the sender in response. 3280 This DIO MUST include a DODAG Configuration option. When a node 3281 receives a unicast DIS message with a Solicited Information option 3282 and matches the predicates of that Solicited Information option, it 3283 MUST unicast a DIO to the sender in response. This unicast DIO MUST 3284 include a DODAG Configuration option. Thus, a node MAY transmit a 3285 unicast DIS message to a potential DODAG parent in order to probe for 3286 DODAG Configuration and other parameters. 3288 8.3.1. Trickle Parameters 3290 The configuration parameters of the Trickle timer are specified as 3291 follows: 3293 Imin: learned from the DIO message as (2^DIOIntervalMin) ms. The 3294 default value of DIOIntervalMin is DEFAULT_DIO_INTERVAL_MIN. 3296 Imax: learned from the DIO message as DIOIntervalDoublings. The 3297 default value of DIOIntervalDoublings is 3298 DEFAULT_DIO_INTERVAL_DOUBLINGS. 3300 k: learned from the DIO message as DIORedundancyConstant. The 3301 default value of DIORedundancyConstant is 3302 DEFAULT_DIO_REDUNDANCY_CONSTANT. In RPL, when k has the value 3303 of 0x00, this is to be treated as a redundancy constant of 3304 infinity in RPL, i.e., Trickle never suppresses messages. 3306 8.4. DODAG Selection 3308 The DODAG selection is implementation and OF dependent. In order to 3309 limit erratic movements, and all metrics being equal, nodes SHOULD 3310 keep their previous selection. Also, nodes SHOULD provide a means to 3311 filter out a parent whose availability is detected as fluctuating, at 3312 least when more stable choices are available. 3314 When connection to a grounded DODAG is not possible or preferable for 3315 security or other reasons, scattered DODAGs MAY aggregate as much as 3316 possible into larger DODAGs in order to allow connectivity within the 3317 LLN. 3319 A node SHOULD verify that bidirectional connectivity and adequate 3320 link quality is available with a candidate neighbor before it 3321 considers that candidate as a DODAG parent. 3323 8.5. Operation as a Leaf Node 3325 In some cases, a RPL node may attach to a DODAG as a leaf node only. 3326 One example of such a case is when a node does not understand or does 3327 not support (policy) the RPL Instance's OF or advertised metric/ 3328 constraint. As specified in Section 18.6, related to policy 3329 function, the node may either join the DODAG as a leaf node or may 3330 not join the DODAG. As mentioned in Section 18.5, it is then 3331 recommended to log a fault. 3333 A leaf node does not extend DODAG connectivity; however, in some 3334 cases, the leaf node may still need to transmit DIOs on occasion, in 3335 particular, when the leaf node may not have always been acting as a 3336 leaf node and an inconsistency is detected. 3338 A node operating as a leaf node must obey the following rules: 3340 1. It MUST NOT transmit DIOs containing the DAG Metric Container. 3342 2. Its DIOs MUST advertise a DAGRank of INFINITE_RANK. 3344 3. It MAY suppress DIO transmission, unless the DIO transmission has 3345 been triggered due to detection of inconsistency when a packet is 3346 being forwarded or in response to a unicast DIS message, in which 3347 case the DIO transmission MUST NOT be suppressed. 3349 4. It MAY transmit unicast DAOs as described in Section 9.2. 3351 5. It MAY transmit multicast DAOs to the '1 hop' neighborhood as 3352 described in Section 9.10. 3354 A particular case that requires a leaf node to send a DIO is if that 3355 leaf node was a prior member of another DODAG and another node 3356 forwards a message assuming the old topology, triggering an 3357 inconsistency. The leaf node needs to transmit a DIO in order to 3358 repair the inconsistency. Note that due to the lossy nature of LLNs, 3359 even though the leaf node may have optimistically poisoned its routes 3360 by advertising a Rank of INFINITE_RANK in the old DODAG prior to 3361 becoming a leaf node, that advertisement may have become lost and a 3362 leaf node must be capable to send a DIO later in order to repair the 3363 inconsistency. 3365 In the general case, the leaf node MUST NOT advertise itself as a 3366 router (i.e., send DIOs). 3368 8.6. Administrative Rank 3370 In some cases, it might be beneficial to adjust the Rank advertised 3371 by a node beyond that computed by the OF based on some 3372 implementation-specific policy and properties of the node. For 3373 example, a node that has a limited battery should be a leaf unless 3374 there is no other choice, and may then augment the Rank computation 3375 specified by the OF in order to expose an exaggerated Rank. 3377 9. Downward Routes 3379 This section describes how RPL discovers and maintains Downward 3380 routes. RPL constructs and maintains Downward routes with 3381 Destination Advertisement Object (DAO) messages. Downward routes 3382 support P2MP flows, from the DODAG roots toward the leaves. Downward 3383 routes also support P2P flows: P2P messages can flow toward a DODAG 3384 root (or a common ancestor) through an Upward route, then away from 3385 the DODAG root to a destination through a Downward route. 3387 This specification describes the two modes a RPL Instance may choose 3388 from for maintaining Downward routes. In the first mode, called 3389 "Storing", nodes store Downward routing tables for their sub-DODAG. 3390 Each hop on a Downward route in a storing network examines its 3391 routing table to decide on the next hop. In the second mode, called 3392 "Non-Storing", nodes do not store Downward routing tables. Downward 3393 packets are routed with source routes populated by a DODAG root 3394 [RFC6554]. 3396 RPL allows a simple one-hop P2P optimization for both storing and 3397 non-storing networks. A node may send a P2P packet destined to a 3398 one-hop neighbor directly to that node. 3400 9.1. Destination Advertisement Parents 3402 To establish Downward routes, RPL nodes send DAO messages Upward. 3403 The next-hop destinations of these DAO messages are called "DAO 3404 parents". The collection of a node's DAO parents is called the "DAO 3405 parent set". 3407 1. A node MAY send DAO messages using the all-RPL-nodes multicast 3408 address, which is an optimization to provision one-hop routing. 3409 The 'K' bit MUST be cleared on transmission of the multicast DAO. 3411 2. A node's DAO parent set MUST be a subset of its DODAG parent set. 3413 3. In Storing mode operation, a node MUST NOT address unicast DAO 3414 messages to nodes that are not DAO parents. 3416 4. In Storing mode operation, the IPv6 source and destination 3417 addresses of a DAO message MUST be link-local addresses. 3419 5. In Non-Storing mode operation, a node MUST NOT address unicast 3420 DAO messages to nodes that are not DODAG roots. 3422 6. In Non-Storing mode operation, the IPv6 source and destination 3423 addresses of a DAO message MUST be a unique-local or a global 3424 address. 3426 The selection of DAO parents is implementation and Objective Function 3427 specific. 3429 9.2. Downward Route Discovery and Maintenance 3431 Destination Advertisement may be configured to be entirely disabled, 3432 or operate in either a Storing or Non-Storing mode, as reported in 3433 the MOP in the DIO message. 3435 1. All nodes who join a DODAG MUST abide by the MOP setting from the 3436 root. Nodes that do not have the capability to fully participate 3437 as a router, e.g., that do not match the advertised MOP, MAY join 3438 the DODAG as a leaf. 3440 2. If the MOP is 0, indicating no Downward routing, nodes MUST NOT 3441 transmit DAO messages and MAY ignore DAO messages. 3443 3. In Non-Storing mode, the DODAG root SHOULD store source routing 3444 table entries for destinations learned from DAOs. The DODAG root 3445 MUST be able to generate source routes for those destinations 3446 learned from DAOs that were stored. 3448 4. In Storing mode, all non-root, non-leaf nodes MUST store routing 3449 table entries for destinations learned from DAOs. 3451 A DODAG can have one of several possible modes of operation, as 3452 defined by the MOP field. Either it does not support Downward 3453 routes, it supports Downward routes through source routing from DODAG 3454 roots, or it supports Downward routes through in-network routing 3455 tables. 3457 When Downward routes are supported through source routing from DODAG 3458 roots, it is generally expected that the DODAG root has stored the 3459 source routing information learned from DAOs in order to construct 3460 the source routes. If the DODAG root fails to store some 3461 information, then some destinations may be unreachable. 3463 When Downward routes are supported through in-network routing tables, 3464 the multicast operation defined in this specification may or may not 3465 be supported, also as indicated by the MOP field. 3467 When Downward routes are supported through in-network routing tables, 3468 as described in this specification, it is expected that nodes acting 3469 as routers have been provisioned sufficiently to hold the required 3470 routing table state. If a node acting as a router is unable to hold 3471 the full routing table state then the routing state is not complete, 3472 messages may be dropped as a consequence, and a fault may be logged 3473 (Section 18.5). Future extensions to RPL may elaborate on refined 3474 actions/behaviors to manage this case. 3476 As of the writing of this specification, RPL does not support mixed- 3477 mode operation, where some nodes source route and other store routing 3478 tables: future extensions to RPL may support this mode of operation. 3480 9.2.1. Maintenance of Path Sequence 3482 For each Target that is associated with (owned by) a node, that node 3483 is responsible to emit DAO messages in order to provision the 3484 Downward routes. The Target+Transit information contained in those 3485 DAO messages subsequently propagates Up the DODAG. The Path Sequence 3486 counter in the Transit information option is used to indicate 3487 freshness and update stale Downward routing information as described 3488 in Section 7. 3490 For a Target that is associated with (owned by) a node, that node 3491 MUST increment the Path Sequence counter, and generate a new DAO 3492 message, when: 3494 1. the Path Lifetime is to be updated (e.g., a refresh or a no- 3495 Path). 3497 2. the DODAG Parent Address subfield list is to be changed. 3499 For a Target that is associated with (owned by) a node, that node MAY 3500 increment the Path Sequence counter, and generate a new DAO message, 3501 on occasion in order to refresh the Downward routing information. In 3502 Storing mode, the node generates such a DAO to each of its DAO 3503 parents in order to enable multipath. All DAOs generated at the same 3504 time for the same Target MUST be sent with the same Path Sequence in 3505 the Transit Information. 3507 9.2.2. Generation of DAO Messages 3509 A node might send DAO messages when it receives DAO messages, as a 3510 result of changes in its DAO parent set, or in response to another 3511 event such as the expiry of a related prefix lifetime. In the case 3512 of receiving DAOs, it matters whether the DAO message is "new" or 3513 contains new information. In Non-Storing mode, every DAO message a 3514 node receives is "new". In Storing mode, a DAO message is "new" if 3515 it satisfies any of these criteria for a contained Target: 3517 1. it has a newer Path Sequence number, 3519 2. it has additional Path Control bits, or 3521 3. it is a No-Path DAO message that removes the last Downward route 3522 to a prefix. 3524 A node that receives a DAO message from its sub-DODAG MAY suppress 3525 scheduling a DAO message transmission if that DAO message is not new. 3527 9.3. DAO Base Rules 3529 1. If a node sends a DAO message with newer or different information 3530 than the prior DAO message transmission, it MUST increment the 3531 DAOSequence field by at least one. A DAO message transmission 3532 that is identical to the prior DAO message transmission MAY 3533 increment the DAOSequence field. 3535 2. The RPLInstanceID and DODAGID fields of a DAO message MUST be the 3536 same value as the members of the node's parent set and the DIOs 3537 it transmits. 3539 3. A node MAY set the 'K' flag in a unicast DAO message to solicit a 3540 unicast DAO-ACK in response in order to confirm the attempt. 3542 4. A node receiving a unicast DAO message with the 'K' flag set 3543 SHOULD respond with a DAO-ACK. A node receiving a DAO message 3544 without the 'K' flag set MAY respond with a DAO-ACK, especially 3545 to report an error condition. 3547 5. A node that sets the 'K' flag in a unicast DAO message but does 3548 not receive a DAO-ACK in response MAY reschedule the DAO message 3549 transmission for another attempt, up until an implementation- 3550 specific number of retries. 3552 6. Nodes SHOULD ignore DAOs without newer sequence numbers and MUST 3553 NOT process them further. 3555 Unlike the Version field of a DIO, which is incremented only by a 3556 DODAG root and repeated unchanged by other nodes, DAOSequence values 3557 are unique to each node. The sequence number space for unicast and 3558 multicast DAO messages can be either the same or distinct. It is 3559 RECOMMENDED to use the same sequence number space. 3561 9.4. Structure of DAO Messages 3563 DAOs follow a common structure in both storing and non-storing 3564 networks. In the most general form, a DAO message may include 3565 several groups of options, where each group consists of one or more 3566 Target options followed by one or more Transit Information options. 3568 The entire group of Transit Information options applies to the entire 3569 group of Target options. Later sections describe further details for 3570 each mode of operation. 3572 1. RPL nodes MUST include one or more RPL Target options in each DAO 3573 message they transmit. One RPL Target option MUST have a prefix 3574 that includes the node's IPv6 address if that node needs the 3575 DODAG to provision Downward routes to that node. The RPL Target 3576 option MAY be immediately followed by an opaque RPL Target 3577 Descriptor option that qualifies it. 3579 2. When a node updates the information in a Transit Information 3580 option for a Target option that covers one of its addresses, it 3581 MUST increment the Path Sequence number in that Transit 3582 Information option. The Path Sequence number MAY be incremented 3583 occasionally to cause a refresh to the Downward routes. 3585 3. One or more RPL Target options in a unicast DAO message MUST be 3586 followed by one or more Transit Information options. All the 3587 transit options apply to all the Target options that immediately 3588 precede them. 3590 4. Multicast DAOs MUST NOT include the DODAG Parent Address subfield 3591 in Transit Information options. 3593 5. A node that receives and processes a DAO message containing 3594 information for a specific Target, and that has prior information 3595 for that Target, MUST use the Path Sequence number in the Transit 3596 Information option associated with that Target in order to 3597 determine whether or not the DAO message contains updated 3598 information per Section 7. 3600 6. If a node receives a DAO message that does not follow the above 3601 rules, it MUST discard the DAO message without further 3602 processing. 3604 In Non-Storing mode, the root builds a strict source routing header, 3605 hop-by-hop, by recursively looking up one-hop information that ties a 3606 Target (address or prefix) and a transit address together. In some 3607 cases, when a child address is derived from a prefix that is owned 3608 and advertised by a parent, that parent-child relationship may be 3609 inferred by the root for the purpose of constructing the source 3610 routing header. In all other cases, it is necessary to inform the 3611 root of the transit-Target relationship from a reachable target, so 3612 as to later enable the recursive construction of the routing header. 3613 An address that is advertised as a Target in a DAO message MUST be 3614 collocated in the same router, or reachable on-link by the router 3615 that owns the address that is indicated in the associated Transit 3616 Information. The following additional rules apply to ensure the 3617 continuity of the end-to-end source route path: 3619 1. The address of a parent used in the transit option MUST be taken 3620 from a PIO from that parent with the 'R' flag set. The 'R' flag 3621 in a PIO indicates that the prefix field actually contains the 3622 full parent address but the child SHOULD NOT assume that the 3623 parent address is on-link. 3625 2. A PIO with an 'A' flag set indicates that the RPL child node may 3626 use the prefix to autoconfigure an address. A parent that 3627 advertises a prefix in a PIO with the 'A' flag set MUST ensure 3628 that the address or the whole prefix in the PIO is reachable from 3629 the root by advertising it as a DAO target. If the parent also 3630 sets the 'L' flag indicating that the prefix is on-link, then it 3631 MUST advertise the whole prefix as Target in a DAO message. If 3632 the 'L' flag is cleared and the 'R' flag is set, indicating that 3633 the parent provides its own address in the PIO, then the parent 3634 MUST advertise that address as a DAO target. 3636 3. An address that is advertised as Target in a DAO message MUST be 3637 collocated in the same router or reachable on-link by the router 3638 that owns the address that is indicated in the associated Transit 3639 Information. 3641 4. In order to enable an optimum compression of the routing header, 3642 the parent SHOULD set the 'R' flag in all PIOs with the 'A' flag 3643 set and the 'L' flag cleared, and the child SHOULD prefer to use 3644 as transit the address of the parent that is found in the PIO 3645 that is used to autoconfigure the address that is advertised as 3646 Target in the DAO message. 3648 5. A router might have targets that are not known to be on-link for 3649 a parent, either because they are addresses located on an 3650 alternate interface or because they belong to nodes that are 3651 external to RPL, for instance connected hosts. In order to 3652 inject such a Target in the RPL network, the router MUST 3653 advertise itself as the DODAG Parent Address subfield in the 3654 Transit Information option for that target, using an address that 3655 is on-link for that nodes DAO parent. If the Target belongs to 3656 an external node, then the router MUST set the External 'E' flag 3657 in the Transit Information. 3659 A child node that has autoconfigured an address from a parent PIO 3660 with the 'L' flag set does not need to advertise that address as a 3661 DAO Target since the parent ensures that the whole prefix is already 3662 reachable from the root. However, if the 'L' flag is not set, then 3663 it is necessary, in Non-Storing mode, for the child node to inform 3664 the root of the parent-child relationship, using a reachable address 3665 of the parent, so as to enable the recursive construction of the 3666 routing header. This is done by associating an address of the parent 3667 as transit with the address of the child as Target in a DAO message. 3669 9.5. DAO Transmission Scheduling 3671 Because DAOs flow Upward, receiving a unicast DAO can trigger sending 3672 a unicast DAO to a DAO parent. 3674 1. On receiving a unicast DAO message with updated information, such 3675 as containing a Transit Information option with a new Path 3676 Sequence, a node SHOULD send a DAO. It SHOULD NOT send this DAO 3677 message immediately. It SHOULD delay sending the DAO message in 3678 order to aggregate DAO information from other nodes for which it 3679 is a DAO parent. 3681 2. A node SHOULD delay sending a DAO message with a timer 3682 (DelayDAO). Receiving a DAO message starts the DelayDAO timer. 3683 DAO messages received while the DelayDAO timer is active do not 3684 reset the timer. When the DelayDAO timer expires, the node sends 3685 a DAO. 3687 3. When a node adds a node to its DAO parent set, it SHOULD schedule 3688 a DAO message transmission. 3690 DelayDAO's value and calculation is implementation dependent. A 3691 default value of DEFAULT_DAO_DELAY is defined in this specification. 3693 9.6. Triggering DAO Messages 3695 Nodes can trigger their sub-DODAG to send DAO messages. Each node 3696 maintains a DAO Trigger Sequence Number (DTSN), which it communicates 3697 through DIO messages. 3699 1. If a node hears one of its DAO parents increment its DTSN, the 3700 node MUST schedule a DAO message transmission using rules in 3701 Sections 9.3 and 9.5. 3703 2. In Non-Storing mode, if a node hears one of its DAO parents 3704 increment its DTSN, the node MUST increment its own DTSN. 3706 In a Storing mode of operation, as part of routine routing table 3707 updates and maintenance, a storing node MAY increment DTSN in order 3708 to reliably trigger a set of DAO updates from its immediate children. 3710 In a Storing mode of operation, it is not necessary to trigger DAO 3711 updates from the entire sub-DODAG, since that state information will 3712 propagate hop-by-hop Up the DODAG. 3714 In a Non-Storing mode of operation, a DTSN increment will also cause 3715 the immediate children of a node to increment their DTSN in turn, 3716 triggering a set of DAO updates from the entire sub-DODAG. 3717 Typically, in a Non-Storing mode of operation, only the root would 3718 independently increment the DTSN when a DAO refresh is needed but a 3719 global repair (such as by incrementing DODAGVersionNumber) is not 3720 desired. Typically, in a Non-Storing mode of operation, all non-root 3721 nodes would increment their DTSN only when their parent(s) are 3722 observed to do so. 3724 In general, a node may trigger DAO updates according to 3725 implementation-specific logic, such as based on the detection of a 3726 Downward route inconsistency or occasionally based upon an internal 3727 timer. 3729 In a storing network, selecting a proper DelayDAO for triggered DAOs 3730 can greatly reduce the number of DAOs transmitted. The trigger flows 3731 Down the DODAG; in the best case, the DAOs flow Up the DODAG such 3732 that leaves send DAOs first, with each node sending a DAO message 3733 only once. Such a scheduling could be approximated by setting 3734 DelayDAO inversely proportional to Rank. Note that this suggestion 3735 is intended as an optimization to allow efficient aggregation (it is 3736 not required for correct operation in the general case). 3738 9.7. Non-Storing Mode 3740 In Non-Storing mode, RPL routes messages Downward using IP source 3741 routing. The following rule applies to nodes that are in Non-Storing 3742 mode. Storing mode has a separate set of rules, described in 3743 Section 9.8. 3745 1. The DODAG Parent Address subfield of a Transit Information option 3746 MUST contain one or more addresses. All of these addresses MUST 3747 be addresses of DAO parents of the sender. 3749 2. DAOs are sent directly to the root along a default route 3750 installed as part of the parent selection. 3752 3. When a node removes a node from its DAO parent set, it MAY 3753 generate a new DAO message with an updated Transit Information 3754 option. 3756 In Non-Storing mode, a node uses DAOs to report its DAO parents to 3757 the DODAG root. The DODAG root can piece together a Downward route 3758 to a node by using DAO parent sets from each node in the route. The 3759 Path Sequence information may be used to detect stale DAO 3760 information. The purpose of this per-hop route calculation is to 3761 minimize traffic when DAO parents change. If nodes reported complete 3762 source routes, then on a DAO parent change, the entire sub-DODAG 3763 would have to send new DAOs to the DODAG root. Therefore, in Non- 3764 Storing mode, a node can send a single DAO, although it might choose 3765 to send more than one DAO message to each of multiple DAO parents. 3767 Nodes pack DAOs by sending a single DAO message with multiple RPL 3768 Target options. Each RPL Target option has its own, immediately 3769 following, Transit Information options. 3771 9.8. Storing Mode 3773 In Storing mode, RPL routes messages Downward by the IPv6 destination 3774 address. The following rules apply to nodes that are in Storing 3775 mode: 3777 1. The DODAG Parent Address subfield of a Transmit Information 3778 option MUST be empty. 3780 2. On receiving a unicast DAO, a node MUST compute if the DAO would 3781 change the set of prefixes that the node itself advertises. This 3782 computation SHOULD include consultation of the Path Sequence 3783 information in the Transit Information options associated with 3784 the DAO, to determine if the DAO message contains newer 3785 information that supersedes the information already stored at the 3786 node. If so, the node MUST generate a new DAO message and 3787 transmit it, following the rules in Section 9.5. Such a change 3788 includes receiving a No-Path DAO. 3790 3. When a node generates a new DAO, it SHOULD unicast it to each of 3791 its DAO parents. It MUST NOT unicast the DAO message to nodes 3792 that are not DAO parents. 3794 4. When a node removes a node from its DAO parent set, it SHOULD 3795 send a No-Path DAO message (Section 6.4.3) to that removed DAO 3796 parent to invalidate the existing route. 3798 5. If messages to an advertised Downward address suffer from a 3799 forwarding error, Neighbor Unreachable Detection (NUD), or 3800 similar failure, a node MAY mark the address as unreachable and 3801 generate an appropriate No-Path DAO. 3803 DAOs advertise to which destination addresses and prefixes a node has 3804 routes. Unlike in Non-Storing mode, these DAOs do not communicate 3805 information about the routes themselves: that information is stored 3806 within the network and is implicit from the IPv6 source address. 3807 When a storing node generates a DAO, it uses the stored state of DAOs 3808 it has received to produce a set of RPL Target options and their 3809 associated Transmit Information options. 3811 Because this information is stored within each node's routing tables, 3812 in Storing mode, DAOs are communicated directly to DAO parents, who 3813 store this information. 3815 9.9. Path Control 3817 A DAO message from a node contains one or more Target options. Each 3818 Target option specifies either a prefix advertised by the node, a 3819 prefix of addresses reachable outside the LLN, the address of a 3820 destination in the node's sub-DODAG, or a multicast group to which a 3821 node in the sub-DODAG is listening. The Path Control field of the 3822 Transit Information option allows nodes to request or allow for 3823 multiple Downward routes. A node constructs the Path Control field 3824 of a Transit Information option as follows: 3826 1. The bit width of the Path Control field MUST be equal to the 3827 value (PCS + 1), where PCS is specified in the control field of 3828 the DODAG Configuration option. Bits greater than or equal to 3829 the value (PCS + 1) MUST be cleared on transmission and MUST be 3830 ignored on reception. Bits below that value are considered 3831 "active" bits. 3833 2. The node MUST logically construct groupings of its DAO parents 3834 while populating the Path Control field, where each group 3835 consists of DAO parents of equal preference. Those groups MUST 3836 then be ordered according to preference, which allows for a 3837 logical mapping of DAO parents onto Path Control subfields (see 3838 Figure 27). Groups MAY be repeated in order to extend over the 3839 entire bit width of the patch control field, but the order, 3840 including repeated groups, MUST be retained so that preference is 3841 properly communicated. 3843 3. For a RPL Target option describing a node's own address or a 3844 prefix outside the LLN, at least one active bit of the Path 3845 Control field MUST be set. More active bits of the Path Control 3846 field MAY be set. 3848 4. If a node receives multiple DAOs with the same RPL Target option, 3849 it MUST bitwise-OR the Path Control fields it receives. This 3850 aggregated bitwise-OR represents the number of Downward routes 3851 the prefix requests. 3853 5. When a node sends a DAO message to one of its DAO parents, it 3854 MUST select one or more of the bits that are set active in the 3855 subfield that is mapped to the group containing that DAO parent 3856 from the aggregated Path Control field. A given bit can only be 3857 presented as active to one parent. The DAO message it transmits 3858 to its parent MUST have these active bits set and all other 3859 active bits cleared. 3861 6. For the RPL Target option and DAOSequence number, the DAOs a node 3862 sends to different DAO parents MUST have disjoint sets of active 3863 Path Control bits. A node MUST NOT set the same active bit on 3864 DAOs to two different DAO parents. 3866 7. Path Control bits SHOULD be allocated according to the preference 3867 mapping of DAO parents onto Path Control subfields, such that the 3868 active Path Control bits, or groupings of bits, that belong to a 3869 particular Path Control subfield are allocated to DAO parents 3870 within the group that was mapped to that subfield. 3872 8. In a Non-Storing mode of operation, a node MAY pass DAOs through 3873 without performing any further processing on the Path Control 3874 field. 3876 9. A node MUST NOT unicast a DAO message that has no active bits in 3877 the Path Control field set. It is possible that, for a given 3878 Target option, a node does not have enough aggregate Path Control 3879 bits to send a DAO message containing that Target to each of its 3880 DAO parents, in which case those least preferred DAO Parents may 3881 not get a DAO message for that Target. 3883 The Path Control field allows a node to bound how many Downward 3884 routes will be generated to it. It sets a number of bits in the Path 3885 Control field equal to the maximum number of Downward routes it 3886 prefers. At most, each bit is sent to one DAO parent; clusters of 3887 bits can be sent to a single DAO parent for it to divide among its 3888 own DAO parents. 3890 A node that provisions a DAO route for a Target that has an 3891 associated Path Control field SHOULD use the content of that Path 3892 Control field in order to determine an order of preference among 3893 multiple alternative DAO routes for that Target. The Path Control 3894 field assignment is derived from preference (of the DAO parents), as 3895 determined on the basis of this node's best knowledge of the "end-to- 3896 end" aggregated metrics in the Downward direction as per the 3897 Objective Function. In Non-Storing mode the root can determine the 3898 Downward route by aggregating the information from each received DAO, 3899 which includes the Path Control indications of preferred DAO parents. 3901 9.9.1. Path Control Example 3903 Suppose that there is an LLN operating in Storing mode that contains 3904 a Node N with four parents, P1, P2, P3, and P4. Let N have three 3905 children, C1, C2, and C3 in its sub-DODAG. Let PCS be 7, such that 3906 there will be 8 active bits in the Path Control field: 11111111b. 3907 Consider the following example: 3909 The Path Control field is split into four subfields, PC1 (11000000b), 3910 PC2 (00110000b), PC3 (00001100b), and PC4 (00000011b), such that 3911 those four subfields represent four different levels of preference 3912 per Figure 27. The implementation at Node N, in this example, groups 3913 {P1, P2} to be of equal preference to each other and the most 3914 preferred group overall. {P3} is less preferred to {P1, P2}, and more 3915 preferred to {P4}. Let Node N then perform its Path Control mapping 3916 such that: 3918 {P1, P2} -> PC1 (11000000b) in the Path Control field 3919 {P3} -> PC2 (00110000b) in the Path Control field 3920 {P4} -> PC3 (00001100b) in the Path Control field 3921 {P4} -> PC4 (00000011b) in the Path Control field 3923 Note that the implementation repeated {P4} in order to get complete 3924 coverage of the Path Control field. 3926 1. Let C1 send a DAO containing a Target T with a Path Control 3927 10000000b. Node N stores an entry associating 10000000b with 3928 the Path Control field for C1 and Target T. 3930 2. Let C2 send a DAO containing a Target T with a Path Control 3931 00010000b. Node N stores an entry associating 00010000b with 3932 the Path Control field for C1 and Target T. 3934 3. Let C3 send a DAO containing a Target T with a Path Control 3935 00001100b. Node N stores an entry associating 00001100b with 3936 the Path Control field for C1 and Target T. 3938 4. At some later time, Node N generates a DAO for Target T. Node N 3939 will construct an aggregate Path Control field by ORing together 3940 the contribution from each of its children that have given a DAO 3941 for Target T. Thus, the aggregate Path Control field has the 3942 active bits set as: 10011100b. 3944 5. Node N then distributes the aggregate Path Control bits among 3945 its parents P1, P2, P3, and P4 in order to prepare the DAO 3946 messages. 3948 6. P1 and P2 are eligible to receive active bits from the most 3949 preferred subfield (11000000b). Those bits are 10000000b in the 3950 aggregate Path Control field. Node N must set the bit to one of 3951 the two parents only. In this case, Node P1 is allocated the 3952 bit and gets the Path Control field 10000000b for its DAO. 3953 There are no bits left to allocate to Node P2; thus, Node P2 3954 would have a Path Control field of 00000000b and a DAO cannot be 3955 generated to Node P2 since there are no active bits. 3957 7. The second-most preferred subfield (00110000b) has the active 3958 bits 00010000b. Node N has mapped P3 to this subfield. Node N 3959 may allocates the active bit to P3, constructing a DAO for P3 3960 containing Target T with a Path Control of 00010000b. 3962 8. The third-most preferred subfield (00001100b) has the active 3963 bits 00001100b. Node N has mapped P4 to this subfield. Node N 3964 may allocate both bits to P4, constructing a DAO for P4 3965 containing Target T with a Path Control of 00001100b. 3967 9. The least preferred subfield (00000011b) has no active bits. 3968 Had there been active bits, those bits would have been added to 3969 the Path Control field of the DAO constructed for P4. 3971 10. The process of populating the DAO messages destined for P1, P2, 3972 P3, P4 with other targets (other than T) proceeds according to 3973 the aggregate Path Control fields collected for those targets. 3975 9.10. Multicast Destination Advertisement Messages 3977 A special case of DAO operation, distinct from unicast DAO operation, 3978 is multicast DAO operation that may be used to populate '1-hop' 3979 routing table entries. 3981 1. A node MAY multicast a DAO message to the link-local scope all- 3982 RPL-nodes multicast address. 3984 2. A multicast DAO message MUST be used only to advertise 3985 information about the node itself, i.e., prefixes directly 3986 connected to or owned by the node, such as a multicast group that 3987 the node is subscribed to or a global address owned by the node. 3989 3. A multicast DAO message MUST NOT be used to relay connectivity 3990 information learned (e.g., through unicast DAO) from another 3991 node. 3993 4. A node MUST NOT perform any other DAO-related processing on a 3994 received multicast DAO message; in particular, a node MUST NOT 3995 perform the actions of a DAO parent upon receipt of a multicast 3996 DAO. 3998 * The multicast DAO may be used to enable direct P2P communication, 3999 without needing the DODAG to relay the packets. 4001 10. Security Mechanisms 4003 This section describes the generation and processing of secure RPL 4004 messages. The high-order bit of the RPL message code identifies 4005 whether or not a RPL message is secure. In addition to secure 4006 versions of basic control messages (DIS, DIO, DAO, DAO-ACK), RPL has 4007 several messages that are relevant only in networks that are security 4008 enabled. 4010 Implementation complexity and size is a core concern for LLNs such 4011 that it may be economically or physically impossible to include 4012 sophisticated security provisions in a RPL implementation. 4013 Furthermore, many deployments can utilize link-layer or other 4014 security mechanisms to meet their security requirements without 4015 requiring the use of security in RPL. 4017 Therefore, the security features described in this document are 4018 OPTIONAL to implement. A given implementation MAY support a subset 4019 (including the empty set) of the described security features, for 4020 example, it could support integrity and confidentiality, but not 4021 signatures. An implementation SHOULD clearly specify which security 4022 mechanisms are supported, and it is RECOMMENDED that implementers 4023 carefully consider security requirements and the availability of 4024 security mechanisms in their network. 4026 10.1. Security Overview 4028 RPL supports three security modes: 4030 * Unsecured. In this security mode, RPL uses basic DIS, DIO, DAO, 4031 and DAO-ACK messages, which do not have Security sections. As a 4032 network could be using other security mechanisms, such as link- 4033 layer security, unsecured mode does not imply all messages are 4034 sent without any protection. 4036 * Preinstalled. In this security mode, RPL uses secure messages. 4037 To join a RPL Instance, a node must have a preinstalled key. 4038 Nodes use this to provide message confidentiality, integrity, and 4039 authenticity. A node may, using this preinstalled key, join the 4040 RPL network as either a host or a router. 4042 * Authenticated. In this security mode, RPL uses secure messages. 4043 To join a RPL Instance, a node must have a preinstalled key. 4044 Nodes use this key to provide message confidentiality, integrity, 4045 and authenticity. Using this preinstalled key, a node may join 4046 the network as a host only. To join the network as a router, a 4047 node must obtain a second key from a key authority. This key 4048 authority can authenticate that the requester is allowed to be a 4049 router before providing it with the second key. Authenticated 4050 mode cannot be supported by symmetric algorithms. As of the 4051 writing of this specification, RPL supports only symmetric 4052 algorithms: authenticated mode is included for the benefit of 4053 potential future cryptographic primitives. See Section 10.3. 4055 Whether or not the RPL Instance uses unsecured mode is signaled by 4056 whether it uses secure RPL messages. Whether a secured network uses 4057 the preinstalled or authenticated mode is signaled by the 'A' bit of 4058 the DAG Configuration option. 4060 This specification specifies CCM -- Counter with CBC-MAC (Cipher 4061 Block Chaining - Message Authentication Code) -- as the cryptographic 4062 basis for RPL security [RFC3610]. In this specification, CCM uses 4063 AES-128 as its underlying cryptographic algorithm. There are bits 4064 reserved in the Security section to specify other algorithms in the 4065 future. 4067 All secured RPL messages have either a MAC or a signature. 4068 Optionally, secured RPL messages also have encryption protection for 4069 confidentiality. Secured RPL message formats support both integrated 4070 encryption/authentication schemes (e.g., CCM) as well as schemes that 4071 separately encrypt and authenticate packets. 4073 10.2. Joining a Secure Network 4075 RPL security assumes that a node wishing to join a secured network 4076 has been pre-configured with a shared key for communicating with 4077 neighbors and the RPL root. To join a secure RPL network, a node 4078 either listens for secure DIOs or triggers secure DIOs by sending a 4079 secure DIS. In addition to the DIO/DIS rules in Section 8, secure 4080 DIO and DIS messages have these rules: 4082 1. If sent, this initial secure DIS MUST set the Key Identifier Mode 4083 field to 0 (00) and MUST set the Security Level field to 1 (001). 4084 The key used MUST be the pre-configured group key (Key Index 4085 0x00). 4087 2. When a node resets its Trickle timer in response to a secure DIS 4088 (Section 8.3), the next DIO it transmits MUST be a secure DIO 4089 with the same security configuration as the secure DIS. If a 4090 node receives multiple secure DIS messages before it transmits a 4091 DIO, the secure DIO MUST have the same security configuration as 4092 the last DIS to which it is responding. 4094 3. When a node sends a DIO in response to a unicast secure DIS 4095 (Section 8.3), the DIO MUST be a secure DIO. 4097 The above rules allow a node to join a secured RPL Instance using the 4098 pre-configured shared key. Once a node has joined the DODAG using 4099 the pre-configured shared key, the 'A' bit of the Configuration 4100 option determines its capabilities. If the 'A' bit of the 4101 Configuration option is cleared, then nodes can use this 4102 preinstalled, shared key to exchange messages normally: it can issue 4103 DIOs, DAOs, etc. 4105 If the 'A' bit of the Configuration option is set and the RPL 4106 Instance is operating in authenticated mode: 4108 1. A node MUST NOT advertise a Rank besides INFINITE_RANK in secure 4109 DIOs secured with Key Index 0x00. When processing DIO messages 4110 secured with Key Index 0x00, a processing node MUST consider the 4111 advertised Rank to be INFINITE_RANK. Any other value results in 4112 the message being discarded. 4114 2. Secure DAOs using a Key Index 0x00 MUST NOT have a RPL Target 4115 option with a prefix besides the node's address. If a node 4116 receives a secured DAO message using the preinstalled, shared key 4117 where the RPL Target option does not match the IPv6 source 4118 address, it MUST discard the secured DAO message without further 4119 processing. 4121 The above rules mean that in RPL Instances where the 'A' bit is set, 4122 using Key Index 0x00, a node can join the RPL Instance as a host but 4123 not a router. A node must communicate with a key authority to obtain 4124 a key that will enable it to act as a router. 4126 10.3. Installing Keys 4128 Authenticated mode requires a would-be router to dynamically install 4129 new keys once they have joined a network as a host. Having joined as 4130 a host, the node uses standard IP messaging to communicate with an 4131 authorization server, which can provide new keys. 4133 The protocol to obtain such keys is out of scope for this 4134 specification and to be elaborated in future specifications. That 4135 elaboration is required for RPL to securely operate in authenticated 4136 mode. 4138 10.4. Consistency Checks 4140 RPL nodes send Consistency Check (CC) messages to protect against 4141 replay attacks and synchronize counters. 4143 1. If a node receives a unicast CC message with the 'R' bit cleared, 4144 and it is a member of or is in the process of joining the 4145 associated DODAG, it SHOULD respond with a unicast CC message to 4146 the sender. This response MUST have the 'R' bit set, and it MUST 4147 have the same CC nonce, RPLInstanceID, and DODAGID fields as the 4148 message it received. 4150 2. If a node receives a multicast CC message, it MUST discard the 4151 message with no further processing. 4153 Consistency Check messages allow nodes to issue a challenge-response 4154 to validate a node's current counter value. Because the CC nonce is 4155 generated by the challenger, an adversary replaying messages is 4156 unlikely to be able to generate a correct response. The counter in 4157 the Consistency Check response allows the challenger to validate the 4158 counter values it hears. 4160 10.5. Counters 4162 In the simplest case, the counter value is an unsigned integer that a 4163 node increments by one or more on each secured RPL transmission. The 4164 counter MAY represent a timestamp that has the following properties: 4166 1. The timestamp MUST be at least six octets long. 4168 2. The timestamp MUST be in 1024 Hz (binary millisecond) 4169 granularity. 4171 3. The timestamp start time MUST be January 1, 1970, 12:00:00AM UTC. 4173 4. If the counter represents a timestamp, the counter value MUST be 4174 a value computed as follows. Let T be the timestamp, S be the 4175 start time of the key in use, and E be the end time of the key in 4176 use. Both S and E are represented using the same three rules as 4177 the timestamp described above. If E > T < S, then the counter is 4178 invalid and a node MUST NOT generate a packet. Otherwise, the 4179 counter value is equal to T-S. 4181 5. If the counter represents such a timestamp, a node MAY set the 4182 'T' flag of the Security section of secured RPL packets. 4184 6. If the Counter field does not present such a timestamp, then a 4185 node MUST NOT set the 'T' flag. 4187 7. If a node does not have a local timestamp that satisfies the 4188 above requirements, it MUST ignore the 'T' flag. 4190 If a node supports such timestamps and it receives a message with the 4191 'T' flag set, it MAY apply the temporal check on the received message 4192 described in Section 10.7.1. If a node receives a message without 4193 the 'T' flag set, it MUST NOT apply this temporal check. A node's 4194 security policy MAY, for application reasons, include rejecting all 4195 messages without the 'T' flag set. 4197 The 'T' flag is present because many LLNs today already maintain 4198 global time synchronization at sub-millisecond granularity for 4199 security, application, and other reasons. Allowing RPL to leverage 4200 this existing functionality when present greatly simplifies solutions 4201 to some security problems, such as delay protection. 4203 10.6. Transmission of Outgoing Packets 4205 Given an outgoing RPL control packet and the required security 4206 protection, this section describes how RPL generates the secured 4207 packet to transmit. It also describes the order of cryptographic 4208 operations to provide the required protection. 4210 The requirement for security protection and the level of security to 4211 be applied to an outgoing RPL packet shall be determined by the 4212 node's security policy database. The configuration of this security 4213 policy database for outgoing packet processing is implementation 4214 specific. 4216 Where secured RPL messages are to be transmitted, a RPL node MUST set 4217 the Security section (T, Sec, KIM, and LVL) in the outgoing RPL 4218 packet to describe the protection level and security settings that 4219 are applied (see Section 6.1). The Security subfield bit of the RPL 4220 Message Code field MUST be set to indicate the secure RPL message. 4222 The counter value used in constructing the AES-128 CCM nonce 4223 (Figure 31) to secure the outgoing packet MUST be an increment of the 4224 last counter transmitted to the particular destination address. 4226 Where security policy specifies the application of delay protection, 4227 the Timestamp counter used in constructing the CCM nonce to secure 4228 the outgoing packet MUST be incremented according to the rules in 4229 Section 10.5. Where a Timestamp counter is applied (indicated with 4230 the 'T' flag set), the locally maintained Timestamp counter MUST be 4231 included as part of the transmitted secured RPL message. 4233 The cryptographic algorithm used in securing the outgoing packet 4234 shall be specified by the node's security policy database and MUST be 4235 indicated in the value of the Sec field set within the outgoing 4236 message. 4238 The security policy for the outgoing packet shall determine the 4239 applicable KIM and Key Identifier specifying the security key to be 4240 used for the cryptographic packet processing, including the optional 4241 use of signature keys (see Section 6.1). The security policy will 4242 also specify the algorithm (Algorithm) and level of protection 4243 (Level) in the form of authentication or authentication and 4244 encryption, and potential use of signatures that shall apply to the 4245 outgoing packet. 4247 Where encryption is applied, a node MUST replace the original packet 4248 payload with that payload encrypted using the security protection, 4249 key, and CCM nonce specified in the Security section of the packet. 4251 All secured RPL messages include integrity protection. In 4252 conjunction with the security algorithm processing, a node derives 4253 either a MAC or signature that MUST be included as part of the 4254 outgoing secured RPL packet. 4256 10.7. Reception of Incoming Packets 4258 This section describes the reception and processing of a secured RPL 4259 packet. Given an incoming secured RPL packet, where the Security 4260 subfield bit of the RPL Message Code field is set, this section 4261 describes how RPL generates an unencrypted variant of the packet and 4262 validates its integrity. 4264 The receiver uses the RPL security control fields to determine the 4265 necessary packet security processing. If the described level of 4266 security for the message type and originator is unknown or does not 4267 meet locally maintained security policies, a node MUST discard the 4268 packet without further processing, MAY raise a management alert, and 4269 MUST NOT send any messages in response. These policies can include 4270 security levels, keys used, source identifiers, or the lack of 4271 timestamp-based counters (as indicated by the 'T' flag). The 4272 configuration of the security policy database for incoming packet 4273 processing is out of scope for this specification (it may, for 4274 example, be defined through DIO Configuration or through out-of-band 4275 administrative router configuration). 4277 Where the message Security Level (LVL) indicates an encrypted RPL 4278 message, the node uses the key information identified through the KIM 4279 field as well as the CCM nonce as input to the message payload 4280 decryption processing. The CCM nonce shall be derived from the 4281 message Counter field and other received and locally maintained 4282 information (see Section 10.9.1). The plaintext message contents 4283 shall be obtained by invoking the inverse cryptographic mode of 4284 operation specified by the Sec field of the received packet. 4286 The receiver shall use the CCM nonce and identified key information 4287 to check the integrity of the incoming packet. If the integrity 4288 check fails against the received MAC, a node MUST discard the packet. 4290 If the received message has an initialized (zero value) counter value 4291 and the receiver has an incoming counter currently maintained for the 4292 originator of the message, the receiver MUST initiate a counter 4293 resynchronization by sending a Consistency Check response message 4294 (see Section 6.6) to the message source. The Consistency Check 4295 response message shall be protected with the current full outgoing 4296 counter maintained for the particular node address. That outgoing 4297 counter will be included within the security section of the message 4298 while the incoming counter will be included within the Consistency 4299 Check message payload. 4301 Based on the specified security policy, a node MAY apply replay 4302 protection for a received RPL message. The replay check SHOULD be 4303 performed before the authentication of the received packet. The 4304 counter, as obtained from the incoming packet, shall be compared 4305 against the watermark of the incoming counter maintained for the 4306 given origination node address. If the received message counter 4307 value is non-zero and less than the maintained incoming counter 4308 watermark, a potential packet replay is indicated and the node MUST 4309 discard the incoming packet. 4311 If delay protection is specified as part of the incoming packet 4312 security policy checks, the Timestamp counter is used to validate the 4313 timeliness of the received RPL message. If the incoming message 4314 Timestamp counter value indicates a message transmission time prior 4315 to the locally maintained transmission time counter for the 4316 originator address, a replay violation is indicated and the node MUST 4317 discard the incoming packet. If the received Timestamp counter value 4318 indicates a message transmission time that is earlier than the 4319 Current time less the acceptable packet delay, a delay violation is 4320 indicated and the node MUST discard the incoming packet. 4322 Once a message has been decrypted, where applicable, and has 4323 successfully passed its integrity check, replay check, and optionally 4324 delay-protection checks, the node can update its local security 4325 information, such as the source's expected counter value for replay 4326 comparison. 4328 A node MUST NOT update its security information on receipt of a 4329 message that fails security policy checks or other applied integrity, 4330 replay, or delay checks. 4332 10.7.1. Timestamp Key Checks 4334 If the 'T' flag of a message is set and a node has a local timestamp 4335 that follows the requirements in Section 10.5, then a node MAY check 4336 the temporal consistency of the message. The node computes the 4337 transmit time of the message by adding the counter value to the start 4338 time of the associated key. If this transmit time is past the end 4339 time of the key, the node MAY discard the message without further 4340 processing. If the transmit time is too far in the past or future 4341 compared to the local time on the receiver, it MAY discard the 4342 message without further processing. 4344 10.8. Coverage of Integrity and Confidentiality 4346 For a RPL ICMPv6 message, the entire packet is within the scope of 4347 RPL security. 4349 MACs and signatures are calculated over the entire unsecured IPv6 4350 packet. When computing MACs and signatures, mutable IPv6 fields are 4351 considered to be filled with zeroes, following the rules in 4352 Section 3.3.3.1 of [RFC4302] (IPsec Authenticated Header). MAC and 4353 signature calculations are performed before any compression that 4354 lower layers may apply. 4356 When a RPL ICMPv6 message is encrypted, encryption starts at the 4357 first byte after the Security section and continues to the last byte 4358 of the packet. The IPv6 header, ICMPv6 header, and RPL message up to 4359 the end of the Security section are not encrypted, as they are needed 4360 to correctly decrypt the packet. 4362 For example, a node sending a message with LVL=1, KIM=0, and 4363 Algorithm=0 uses the CCM algorithm [RFC3610] to create a packet with 4364 attributes ENC-MAC-32: it encrypts the packet and appends a 32-bit 4365 MAC. The block cipher key is determined by the Key Index. The CCM 4366 nonce is computed as described in Section 10.9.1; the message to 4367 authenticate and encrypt is the RPL message starting at the first 4368 byte after the Security section and ends with the last byte of the 4369 packet. The additional authentication data starts with the beginning 4370 of the IPv6 header and ends with the last byte of the RPL Security 4371 section. 4373 10.9. Cryptographic Mode of Operation 4375 The cryptographic mode of operation described in this specification 4376 (Algorithm = 0) is based on CCM and the block-cipher AES-128 4377 [RFC3610]. This mode of operation is widely supported by existing 4378 implementations. CCM mode requires a nonce (CCM nonce). 4380 10.9.1. CCM Nonce 4382 A RPL node constructs a CCM nonce as follows: 4384 0 1 2 3 4385 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 4386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4387 | | 4388 + Source Identifier + 4389 | | 4390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4391 | Counter | 4392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4393 |KIM|Resvd| LVL | 4394 +-+-+-+-+-+-+-+-+ 4396 Figure 31: CCM Nonce 4398 Source Identifier: 8 bytes. Source Identifier is set to the logical 4399 identifier of the originator of the protected packet. 4401 Counter: 4 bytes. Counter is set to the (uncompressed) value of the 4402 corresponding field in the Security option of the RPL control 4403 message. 4405 Key Identifier Mode (KIM): 2 bits. KIM is set to the value of the 4406 corresponding field in the Security option of the RPL control 4407 message. 4409 Security Level (LVL): 3 bits. Security Level is set to the value of 4410 the corresponding field in the Security option of the RPL 4411 control message. 4413 Unassigned bits of the CCM nonce are reserved. They MUST be set to 4414 zero when constructing the CCM nonce. 4416 All fields of the CCM nonce are represented in most significant octet 4417 and most significant bit first order. 4419 10.9.2. Signatures 4421 If the KIM indicates the use of signatures (a value of 3), then a 4422 node appends a signature to the data payload of the packet. The 4423 Security Level (LVL) field describes the length of this signature. 4424 The signature scheme in RPL for Security Mode 3 is an instantiation 4425 of the RSA algorithm (RSASSA-PSS) as defined in Section 8.1 of 4426 [RFC3447]. As public key, it uses the pair (n,e), where n is a 4427 2048-bit or 3072-bit RSA modulus and where e=2^{16}+1. It uses CCM 4428 mode [RFC3610] as the encryption scheme with M=0 (as a stream- 4429 cipher). Note that although [RFC3610] disallows the CCM mode with 4430 M=0, RPL explicitly allows the CCM mode with M=0 when used in 4431 conjunction with a signature, because the signature provides 4432 sufficient data authentication. Here, the CCM mode with M=0 is 4433 specified as in [RFC3610], but where the M' field in Section 2.2 MUST 4434 be set to 0. It uses the SHA-256 hash function specified in 4435 Section 6.2 of [FIPS180]. It uses the message encoding rules of 4436 Section 8.1 of [RFC3447]. 4438 Let 'a' be a concatenation of a 6-byte representation of counter and 4439 the message header. The packet payload is the right-concatenation of 4440 packet data 'm' and the signature 's'. This signature scheme is 4441 invoked with the right-concatenation of the message parts a and m, 4442 whereas the signature verification is invoked with the right- 4443 concatenation of the message parts a and m and with signature s. 4445 RSA signatures of this form provide sufficient protection for RPL 4446 networks. If needed, alternative signature schemes that produce more 4447 concise signatures is out of scope for this specification and may be 4448 the subject of a future specification. 4450 An implementation that supports RSA signing with either 2048-bit or 4451 3072-bit signatures SHOULD support verification of both 2048-bit and 4452 3072-bit RSA signatures. This is in consideration of providing an 4453 upgrade path for a RPL deployment. 4455 11. Packet Forwarding and Loop Avoidance/Detection 4457 11.1. Suggestions for Packet Forwarding 4459 This document specifies a routing protocol. These non-normative 4460 suggestions are provided to aid in the design of a forwarding 4461 implementation by illustrating how such an implementation could work 4462 with RPL. 4464 When forwarding a packet to a destination, precedence is given to 4465 selection of a next-hop successor as follows: 4467 1. This specification only covers how a successor is selected from 4468 the DODAG Version that matches the RPLInstanceID marked in the 4469 IPv6 header of the packet being forwarded. Routing outside the 4470 instance can be done as long as additional rules are put in place 4471 such as strict ordering of instances and routing protocols to 4472 protect against loops. Such rules may be defined in a separate 4473 document. 4475 2. If a local administrative preference favors a route that has been 4476 learned from a different routing protocol than RPL, then use that 4477 successor. 4479 3. If the packet header specifies a source route by including an RH4 4480 header as specified in [RFC6554], then use that route. If the 4481 node fails to forward the packet with that specified source 4482 route, then that packet should be dropped. The node MAY log an 4483 error. The node may send an ICMPv6 error in Source Routing 4484 Header message to the source of the packet (see Section 20.18). 4486 4. If there is an entry in the routing table matching the 4487 destination that has been learned from a multicast destination 4488 advertisement (e.g., the destination is a one-hop neighbor), then 4489 use that successor. 4491 5. If there is an entry in the routing table matching the 4492 destination that has been learned from a unicast destination 4493 advertisement (e.g., the destination is located Down the sub- 4494 DODAG), then use that successor. If there are DAO Path Control 4495 bits associated with multiple successors, then consult the Path 4496 Control bits to order the successors by preference when choosing. 4497 If, for a given DAO Path Control bit, multiple successors are 4498 recorded as having asserted that bit, precedence should be given 4499 to the successor who most recently asserted that bit. 4501 6. If there is a DODAG Version offering a route to a prefix matching 4502 the destination, then select one of those DODAG parents as a 4503 successor according to the OF and routing metrics. 4505 7. Any other as-yet-unattempted DODAG parent may be chosen for the 4506 next attempt to forward a unicast packet when no better match 4507 exists. 4509 8. Finally, the packet is dropped. ICMP Destination Unreachable MAY 4510 be invoked (an inconsistency is detected). 4512 Hop Limit MUST be decremented when forwarding per [RFC2460]. 4514 Note that the chosen successor MUST NOT be the neighbor that was the 4515 predecessor of the packet (split horizon), except in the case where 4516 it is intended for the packet to change from an Upward to a Downward 4517 direction, as determined by the routing table of the node making the 4518 change, such as switching from DIO routes to DAO routes as the 4519 destination is neared in order to continue traveling toward the 4520 destination. 4522 11.2. Loop Avoidance and Detection 4524 RPL loop avoidance mechanisms are kept simple and designed to 4525 minimize churn and states. Loops may form for a number of reasons, 4526 e.g., control packet loss. RPL includes a reactive loop detection 4527 technique that protects from meltdown and triggers repair of broken 4528 paths. 4530 RPL loop detection uses RPL Packet Information that is transported 4531 within the data packets, relying on an external mechanism such as 4532 [RFC6553] that places in the RPL Packet Information in an IPv6 Hop- 4533 by-Hop option header. 4535 The content of RPL Packet Information is defined as follows: 4537 Down 'O': 1-bit flag indicating whether the packet is expected to 4538 progress Up or Down. A router sets the 'O' flag when the 4539 packet is expected to progress Down (using DAO routes), and 4540 clears it when forwarding toward the DODAG root (to a node with 4541 a lower Rank). A host or RPL leaf node MUST set the 'O' flag 4542 to 0. 4544 Rank-Error 'R': 1-bit flag indicating whether a Rank error was 4545 detected. A Rank error is detected when there is a mismatch in 4546 the relative Ranks and the direction as indicated in the 'O' 4547 bit. A host or RPL leaf node MUST set the 'R' bit to 0. 4549 Forwarding-Error 'F': 1-bit flag indicating that this node cannot 4550 forward the packet further towards the destination. The 'F' 4551 bit might be set by a child node that does not have a route to 4552 destination for a packet with the Down 'O' bit set. A host or 4553 RPL leaf node MUST set the 'F' bit to 0. 4555 RPLInstanceID: 8-bit field indicating the DODAG instance along which 4556 the packet is sent. 4558 SenderRank: 16-bit field set to zero by the source and to 4559 DAGRank(rank) by a router that forwards inside the RPL network. 4561 11.2.1. Source Node Operation 4563 If the source is aware of the RPLInstanceID that is preferred for the 4564 packet, then it MUST set the RPLInstanceID field associated with the 4565 packet accordingly; otherwise, it MUST set it to the 4566 RPL_DEFAULT_INSTANCE. 4568 11.2.2. Router Operation 4570 11.2.2.1. Instance Forwarding 4572 The RPLInstanceID is associated by the source with the packet. This 4573 RPLInstanceID MUST match the RPL Instance onto which the packet is 4574 placed by any node, be it a host or router. The RPLInstanceID is 4575 part of the RPL Packet Information. 4577 A RPL router that forwards a packet in the RPL network MUST check if 4578 the packet includes the RPL Packet Information. If not, then the RPL 4579 router MUST insert the RPL Packet Information. If the router is an 4580 ingress router that injects the packet into the RPL network, the 4581 router MUST set the RPLInstanceID field in the RPL Packet 4582 Information. The details of how that router determines the mapping 4583 to a RPLInstanceID are out of scope for this specification and left 4584 to future specification. 4586 A router that forwards a packet outside the RPL network MUST remove 4587 the RPL Packet Information. 4589 When a router receives a packet that specifies a given RPLInstanceID 4590 and the node can forward the packet along the DODAG associated to 4591 that instance, then the router MUST do so and leave the RPLInstanceID 4592 value unchanged. 4594 If any node cannot forward a packet along the DODAG associated with 4595 the RPLInstanceID, then the node SHOULD discard the packet and send 4596 an ICMP error message. 4598 11.2.2.2. DAG Inconsistency Loop Detection 4600 The DODAG is inconsistent if the direction of a packet does not match 4601 the Rank relationship. A receiver detects an inconsistency if it 4602 receives a packet with either: 4604 * the 'O' bit set (to Down) from a node of a higher Rank. 4606 * the 'O' bit cleared (for Up) from a node of a lower Rank. 4608 When the DODAG root increments the DODAGVersionNumber, a temporary 4609 Rank discontinuity may form between the next DODAG Version and the 4610 prior DODAG Version, in particular, if nodes are adjusting their Rank 4611 in the next DODAG Version and deferring their migration into the next 4612 DODAG Version. A router that is still a member of the prior DODAG 4613 Version may choose to forward a packet to a (future) parent that is 4614 in the next DODAG Version. In some cases, this could cause the 4615 parent to detect an inconsistency because the Rank-ordering in the 4616 prior DODAG Version is not necessarily the same as in the next DODAG 4617 Version, and the packet may be judged not to be making forward 4618 progress. If the sending router is aware that the chosen successor 4619 has already joined the next DODAG Version, then the sending router 4620 MUST update the SenderRank to INFINITE_RANK as it forwards the 4621 packets across the discontinuity into the next DODAG Version in order 4622 to avoid a false detection of Rank inconsistency. 4624 One inconsistency along the path is not considered a critical error 4625 and the packet may continue. However, a second detection along the 4626 path of the same packet should not occur and the packet MUST be 4627 dropped. 4629 This process is controlled by the Rank-Error bit associated with the 4630 packet. When an inconsistency is detected on a packet, if the Rank- 4631 Error bit was not set, then the Rank-Error bit is set. If it was set 4632 the packet MUST be discarded and the Trickle timer MUST be reset. 4634 11.2.2.3. DAO Inconsistency Detection and Recovery 4636 DAO inconsistency loop recovery is a mechanism that applies to 4637 Storing mode of operation only. 4639 In Non-Storing mode, the packets are source routed to the 4640 destination, and DAO inconsistencies are not corrected locally. 4641 Instead, an ICMP error with a new code "Error in Source Routing 4642 Header" is sent back to the root. The "Error in Source Routing 4643 Header" message has the same format as the "Destination Unreachable 4644 Message", as specified in [RFC4443]. The portion of the invoking 4645 packet that is sent back in the ICMP message should record at least 4646 up to the routing header, and the routing header should be consumed 4647 by this node so that the destination in the IPv6 header is the next 4648 hop that this node could not reach. 4650 A DAO inconsistency happens when a router has a Downward route that 4651 was previously learned from a DAO message via a child, but that 4652 Downward route is not longer valid in the child, e.g., because that 4653 related state in the child has been cleaned up. With DAO 4654 inconsistency loop recovery, a packet can be used to recursively 4655 explore and clean up the obsolete DAO states along a sub-DODAG. 4657 In a general manner, a packet that goes Down should never go Up 4658 again. If DAO inconsistency loop recovery is applied, then the 4659 router SHOULD send the packet back to the parent that passed it with 4660 the Forwarding-Error 'F' bit set and the 'O' bit left untouched. 4661 Otherwise, the router MUST silently discard the packet. 4663 Upon receiving a packet with a Forwarding-Error bit set, the node 4664 MUST remove the routing states that caused forwarding to that 4665 neighbor, clear the Forwarding-Error bit, and attempt to send the 4666 packet again. The packet may be sent to an alternate neighbor, after 4667 the expiration of a user-configurable implementation-specific timer. 4668 If that alternate neighbor still has an inconsistent DAO state via 4669 this node, the process will recurse, this node will set the 4670 Forwarding-Error 'F' bit, and the routing state in the alternate 4671 neighbor will be cleaned up as well. 4673 12. Multicast Operation 4675 This section describes a multicast routing operation over an IPv6 RPL 4676 network and, specifically, how unicast DAOs can be used to relay 4677 group registrations. The same DODAG construct can be used to forward 4678 unicast and multicast traffic. This section is limited to a 4679 description of how group registrations may be exchanged and how the 4680 forwarding infrastructure operates. It does not provide a full 4681 description of multicast within an LLN and, in particular, does not 4682 describe the generation of DODAGs specifically targeted at multicast 4683 or the details of operating RPL for multicast -- that will be the 4684 subject of further specifications. 4686 The multicast group registration uses DAO messages that are identical 4687 to unicast except for the type of address that is transported. The 4688 main difference is that the multicast traffic going down is copied to 4689 all the children that have registered with the multicast group, 4690 whereas unicast traffic is passed to one child only. 4692 Nodes that support the RPL Storing mode of operation SHOULD also 4693 support multicast DAO operations as described below. Nodes that only 4694 support the Non-Storing mode of operation are not expected to support 4695 this section. 4697 The multicast operation is controlled by the MOP field in the DIO. 4699 * If the MOP field requires multicast support, then a node that 4700 joins the RPL network as a router must operate as described in 4701 this section for multicast signaling and forwarding within the RPL 4702 network. A node that does not support the multicast operation 4703 required by the MOP field can only join as a leaf. 4705 * If the MOP field does not require multicast support, then 4706 multicast is handled by some other way that is out of scope for 4707 this specification. (Examples may include a series of unicast 4708 copies or limited-scope flooding). 4710 A router might select to pass a listener registration DAO message to 4711 its preferred parent only; in which case, multicast packets coming 4712 back might be lost for all of its sub-DODAGs if the transmission 4713 fails over that link. Alternatively, the router might select copying 4714 additional parents as it would do for DAO messages advertising 4715 unicast destinations; in which case, there might be duplicates that 4716 the router will need to prune. 4718 As a result, multicast routing states are installed in each router on 4719 the way from the listeners to the DODAG root, enabling the root to 4720 copy a multicast packet to all its children routers that had issued a 4721 DAO message including a Target option for that multicast group. 4723 For a multicast packet sourced from inside the DODAG, the packet is 4724 passed to the preferred parents, and if that fails, then to the 4725 alternates in the DODAG. The packet is also copied to all the 4726 registered children, except for the one that passed the packet. 4727 Finally, if there is a listener in the external infrastructure, then 4728 the DODAG root has to further propagate the packet into the external 4729 infrastructure. 4731 As a result, the DODAG root acts as an automatic proxy Rendezvous 4732 Point for the RPL network and as source towards the non-RPL domain 4733 for all multicast flows started in the RPL domain. So, regardless of 4734 whether the root is actually attached to a non-RPL domain, and 4735 regardless of whether the DODAG is grounded or floating, the root can 4736 serve inner multicast streams at all times. 4738 13. Maintenance of Routing Adjacency 4740 The selection of successors, along the default paths Up along the 4741 DODAG, or along the paths learned from destination advertisements 4742 Down along the DODAG, leads to the formation of routing adjacencies 4743 that require maintenance. 4745 In IGPs, such as OSPF [RFC4915] or IS-IS [RFC5120], the maintenance 4746 of a routing adjacency involves the use of keepalive mechanisms 4747 (Hellos) or other protocols such as the Bidirectional Forwarding 4748 Detection (BFD) [RFC5881] and the MANET Neighborhood Discovery 4749 Protocol (NHDP) [RFC6130]. Unfortunately, such a proactive approach 4750 is often not desirable in constrained environments where it would 4751 lead to excessive control traffic in light of the data traffic with a 4752 negative impact on both link loads and nodes resources. 4754 By contrast with those routing protocols, RPL does not define any 4755 keepalive mechanisms to detect routing adjacency failures: this is 4756 because in many cases, such a mechanism would be too expensive in 4757 terms of bandwidth and, even more importantly, energy (a battery- 4758 operated device could not afford to send periodic keepalives). Still 4759 RPL requires an external mechanisms to detect that a neighbor is no 4760 longer reachable. Such a mechanism should preferably be reactive to 4761 traffic in order to minimize the overhead to maintain the routing 4762 adjacency and focus on links that are actually being used. 4764 Example reactive mechanisms that can be used include: 4766 * The Neighbor Unreachability Detection [RFC4861] mechanism. 4768 * Layer 2 triggers [RFC5184] derived from events such as association 4769 states and L2 acknowledgements. 4771 14. Guidelines for Objective Functions 4773 An Objective Function (OF), in conjunction with routing metrics and 4774 constraints, allows for the selection of a DODAG to join, and a 4775 number of peers in that DODAG as parents. The OF is used to compute 4776 an ordered list of parents. The OF is also responsible to compute 4777 the Rank of the device within the DODAG Version. 4779 The Objective Function is indicated in the DIO message using an 4780 Objective Code Point (OCP), and it indicates the method that must be 4781 used to construct the DODAG. The Objective Code Points are specified 4782 in [RFC6552] and related companion specifications. 4784 14.1. Objective Function Behavior 4786 Most Objective Functions are expected to follow the same abstract 4787 behavior at a node: 4789 * The parent selection is triggered each time an event indicates 4790 that a potential next-hop information is updated. This might 4791 happen upon the reception of a DIO message, a timer elapse, all 4792 DODAG parents are unavailable, or a trigger indicating that the 4793 state of a candidate neighbor has changed. 4795 * An OF scans all the interfaces on the node. Although, there may 4796 typically be only one interface in most application scenarios, 4797 there might be multiple of them and an interface might be 4798 configured to be usable or not for RPL operation. An interface 4799 can also be configured with a preference or dynamically learned to 4800 be better than another by some heuristics that might be link-layer 4801 dependent and are out of scope for this specification. Finally, 4802 an interface might or might not match a required criterion for an 4803 Objective Function, for instance, a degree of security. As a 4804 result, some interfaces might be completely excluded from the 4805 computation, for example, if those interfaces cannot satisfy some 4806 advertised constraints, while others might be more or less 4807 preferred. 4809 * An OF scans all the candidate neighbors on the possible interfaces 4810 to check whether they can act as a router for a DODAG. There 4811 might be many of them and a candidate neighbor might need to pass 4812 some validation tests before it can be used. In particular, some 4813 link layers require experience on the activity with a router to 4814 enable the router as a next hop. 4816 * An OF computes Rank of a node for comparison by adding to the Rank 4817 of the candidate a value representing the relative locations of 4818 the node and the candidate in the DODAG Version. 4820 - The increase in Rank must be at least MinHopRankIncrease. 4822 - To keep loop avoidance and metric optimization in alignment, 4823 the increase in Rank should reflect any increase in the metric 4824 value. For example, with a purely additive metric, such as 4825 ETX, the increase in Rank can be made proportional to the 4826 increase in the metric. 4828 - Candidate neighbors that would cause the Rank of the node to 4829 increase are not considered for parent selection. 4831 * Candidate neighbors that advertise an OF incompatible with the set 4832 of OFs specified by the policy functions are ignored. 4834 * As it scans all the candidate neighbors, the OF keeps the current 4835 best parent and compares its capabilities with the current 4836 candidate neighbor. The OF defines a number of tests that are 4837 critical to reach the objective. A test between the routers 4838 determines an order relation. 4840 - If the routers are equal for that relation, then the next test 4841 is attempted between the routers, 4843 - Else the best of the two routers becomes the current best 4844 parent, and the scan continues with the next candidate 4845 neighbor. 4847 - Some OFs may include a test to compare the Ranks that would 4848 result if the node joined either router. 4850 * When the scan is complete, the preferred parent is elected and the 4851 node's Rank is computed as the preferred parent Rank plus the step 4852 in Rank with that parent. 4854 * Other rounds of scans might be necessary to elect alternate 4855 parents. In the next rounds: 4857 - Candidate neighbors that are not in the same DODAG are ignored. 4859 - Candidate neighbors that are of greater Rank than the node are 4860 ignored. 4862 - Candidate neighbors of an equal Rank to the node are ignored 4863 for parent selection. 4865 - Candidate neighbors of a lesser Rank than the node are 4866 preferred. 4868 15. Suggestions for Interoperation with Neighbor Discovery 4870 This specification directly borrows the Prefix Information Option 4871 (PIO) and the Route Information Option (RIO) from IPv6 ND. It is 4872 envisioned that, as future specifications build on this base, there 4873 may be additional cause to leverage parts of IPv6 ND. This section 4874 provides some suggestions for future specifications. 4876 First and foremost, RPL is a routing protocol. One should take great 4877 care to preserve architecture when mapping functionalities between 4878 RPL and ND. RPL is for routing only. That said, there may be 4879 persuading technical reasons to allow for sharing options between RPL 4880 and IPv6 ND in a particular implementation/deployment. 4882 In general, the following guidelines apply: 4884 * RPL Type codes must be allocated from the RPL Control Message 4885 Options registry. 4887 * RPL Length fields must be expressed in units of single octets, as 4888 opposed to ND Length fields, which are expressed in units of 8 4889 octets. 4891 * RPL options are generally not required to be aligned to 8-octet 4892 boundaries. 4894 * When mapping/transposing an IPv6 ND option for redistribution as a 4895 RPL option, any padding octets should be removed when possible. 4896 For example, the Prefix Length field in the PIO is sufficient to 4897 describe the length of the Prefix field. When mapping/transposing 4898 a RPL option for redistribution as an IPv6 ND option, any such 4899 padding octets should be restored. This procedure must be 4900 unambiguous. 4902 16. Summary of Requirements for Interoperable Implementations 4904 This section summarizes basic interoperability and references 4905 normative text for RPL implementations operating in one of three 4906 major modes. Implementations are expected to support either no 4907 Downward routes, Non-Storing mode only, or Storing mode only. A 4908 fourth mode, operation as a leaf, is also possible. 4910 Implementations conforming to this specification may contain 4911 different subsets of capabilities as appropriate to the application 4912 scenario. It is important for the implementer to support a level of 4913 interoperability consistent with that required by the application 4914 scenario. To this end, further guidance may be provided beyond this 4915 specification (e.g., as applicability statements), and it is 4916 understood that in some cases such further guidance may override 4917 portions of this specification. 4919 16.1. Common Requirements 4921 In a general case, the greatest level of interoperability may be 4922 achieved when all of the nodes in a RPL LLN are cooperating to use 4923 the same MOP, OF, metrics, and constraints, and are thus able to act 4924 as RPL routers. When a node is not capable of being a RPL router, it 4925 may be possible to interoperate in a more limited manner as a RPL 4926 leaf. 4928 All RPL implementations need to support the use of RPL Packet 4929 Information transported within data packets (Section 11.2). One such 4930 mechanism is described in [RFC6553]. 4932 RPL implementations will need to support the use of Neighbor 4933 Unreachability Detection (NUD), or an equivalent mechanism, to 4934 maintain the reachability of neighboring RPL nodes (Section 8.2.1). 4935 Alternate mechanisms may be optimized to the constrained capabilities 4936 of the implementation, such as hints from the link layer. 4938 This specification provides means to obtain a PIO and thus form an 4939 IPv6 address. When that mechanism is used, it may be necessary to 4940 perform address resolution and duplicate address detection through an 4941 external process, such as IPv6 ND [RFC4861] or 6LoWPAN ND 4942 [6LOWPAN-ND]. 4944 16.2. Operation as a RPL Leaf Node (Only) 4946 * An implementation of a leaf node (only) does not ever participate 4947 as a RPL router. Interoperable implementations of leaf nodes 4948 behave as summarized in Section 8.5. 4950 * Support of a particular MOP encoding is not required, although if 4951 the leaf node sends DAO messages to set up Downward routes, the 4952 leaf node should do so in a manner consistent with the mode of 4953 operation indicated by the MOP. 4955 * Support of a particular OF is not required. 4957 * In summary, a leaf node does not generally issue DIO messages, it 4958 may issue DAO and DIS messages. A leaf node accepts DIO messages 4959 though it generally ignores DAO and DIS messages. 4961 16.3. Operation as a RPL Router 4963 If further guidance is not available then a RPL router implementation 4964 MUST at least support the metric-less OF0 [RFC6552]. 4966 For consistent operation a RPL router implementation needs to support 4967 the MOP in use by the DODAG. 4969 All RPL routers will need to implement Trickle [RFC6206]. 4971 16.3.1. Support for Upward Routes (Only) 4973 An implementation of a RPL router that supports only Upward routes 4974 supports the following: 4976 * Upward routes (Section 8) 4978 * MOP encoding 0 (Section 20.3) 4980 * In summary, DIO and DIS messages are issued, and DAO messages are 4981 not issued. DIO and DIS messages are accepted, and DAO messages 4982 are ignored. 4984 16.3.2. Support for Upward Routes and Downward Routes in Non-Storing 4986 An implementation of a RPL router that supports Upward routes and 4987 Downward routes in Non-Storing mode supports the following: 4989 * Upward routes (Section 8) 4991 * Downward routes (Non-Storing) (Section 9) 4993 * MOP encoding 1 (Section 20.3) 4995 * Source-routed Downward traffic ([RFC6554]) 4997 * In summary, DIO and DIS messages are issued, and DAO messages are 4998 issued to the DODAG root. DIO and DIS messages are accepted, and 4999 DAO messages are ignored by nodes other than DODAG roots. 5000 Multicast is not supported through the means described in this 5001 specification, though it may be supported through some alternate 5002 means. 5004 16.3.3. Support for Upward Routes and Downward Routes in Storing Mode 5006 An implementation of a RPL router that supports Upward routes and 5007 Downward routes in Storing mode supports the following: 5009 * Upward routes (Section 8) 5011 * Downward routes (Non-Storing) (Section 9) 5013 * MOP encoding 2 (Section 20.3) 5014 * In summary, DIO, DIS, and DAO messages are issued. DIO, DIS, and 5015 DAO messages are accepted. Multicast is not supported through the 5016 means described in this specification, though it may be supported 5017 through some alternate means. 5019 16.3.3.1. Optional Support for Basic Multicast Scheme 5021 A Storing mode implementation may be enhanced with basic multicast 5022 support through the following additions: 5024 * Basic Multicast Support (Section 12) 5026 * MOP encoding 3 (Section 20.3) 5028 16.4. Items for Future Specification 5030 A number of items are left to future specification, including but not 5031 limited to the following: 5033 * How to attach a non-RPL node such as an IPv6 host, e.g., to 5034 consistently distribute at least PIO material to the attached 5035 node. 5037 * How to obtain authentication material in support if authenticated 5038 mode is used (Section 10.3). 5040 * Details of operation over multiple simultaneous instances. 5042 * Advanced configuration mechanisms, such as the provisioning of 5043 RPLInstanceIDs, parameterization of Objective Functions, and 5044 parameters to control security. (It is expected that such 5045 mechanisms might extend the DIO as a means to disseminate 5046 information across the DODAG). 5048 17. RPL Constants and Variables 5050 The following is a summary of RPL constants and variables: 5052 BASE_RANK: This is the Rank for a virtual root that might be used to 5053 coordinate multiple roots. BASE_RANK has a value of 0. 5055 ROOT_RANK: This is the Rank for a DODAG root. ROOT_RANK has a value 5056 of MinHopRankIncrease (as advertised by the DODAG root), such 5057 that DAGRank(ROOT_RANK) is 1. 5059 INFINITE_RANK: This is the constant maximum for the Rank. 5060 INFINITE_RANK has a value of 0xFFFF. 5062 RPL_DEFAULT_INSTANCE: This is the RPLInstanceID that is used by this 5063 protocol by a node without any overriding policy. 5064 RPL_DEFAULT_INSTANCE has a value of 0. 5066 DEFAULT_PATH_CONTROL_SIZE: This is the default value used to 5067 configure PCS in the DODAG Configuration option, which dictates 5068 the number of significant bits in the Path Control field of the 5069 Transit Information option. DEFAULT_PATH_CONTROL_SIZE has a 5070 value of 0. This configures the simplest case limiting the 5071 fan-out to 1 and limiting a node to send a DAO message to only 5072 one parent. 5074 DEFAULT_DIO_INTERVAL_MIN: This is the default value used to 5075 configure Imin for the DIO Trickle timer. 5076 DEFAULT_DIO_INTERVAL_MIN has a value of 3. This configuration 5077 results in Imin of 8 ms. 5079 DEFAULT_DIO_INTERVAL_DOUBLINGS: This is the default value used to 5080 configure Imax for the DIO Trickle timer. 5081 DEFAULT_DIO_INTERVAL_DOUBLINGS has a value of 20. This 5082 configuration results in a maximum interval of 2.3 hours. 5084 DEFAULT_DIO_REDUNDANCY_CONSTANT: This is the default value used to 5085 configure k for the DIO Trickle timer. 5086 DEFAULT_DIO_REDUNDANCY_CONSTANT has a value of 10. This 5087 configuration is a conservative value for Trickle suppression 5088 mechanism. 5090 DEFAULT_MIN_HOP_RANK_INCREASE: This is the default value of 5091 MinHopRankIncrease. DEFAULT_MIN_HOP_RANK_INCREASE has a value 5092 of 256. This configuration results in an 8-bit wide integer 5093 part of Rank. 5095 DEFAULT_DAO_DELAY: This is the default value for the DelayDAO Timer. 5096 DEFAULT_DAO_DELAY has a value of 1 second. See Section 9.5. 5098 DIO Timer: One instance per DODAG of which a node is a member. 5099 Expiry triggers DIO message transmission. A Trickle timer with 5100 variable interval in [0, 5101 DIOIntervalMin..2^DIOIntervalDoublings]. See Section 8.3.1. 5103 DAG Version Increment Timer: Up to one instance per DODAG of which 5104 the node is acting as DODAG root. May not be supported in all 5105 implementations. Expiry triggers increment of 5106 DODAGVersionNumber, causing a new series of updated DIO message 5107 to be sent. Interval should be chosen appropriate to 5108 propagation time of DODAG and as appropriate to application 5109 requirements (e.g., response time versus overhead). 5111 DelayDAO Timer: Up to one timer per DAO parent (the subset of DODAG 5112 parents chosen to receive destination advertisements) per 5113 DODAG. Expiry triggers sending of DAO message to the DAO 5114 parent. See Section 9.5. 5116 RemoveTimer: Up to one timer per DAO entry per neighbor (i.e., those 5117 neighbors that have given DAO messages to this node as a DODAG 5118 parent). Expiry may trigger No-Path advertisements or 5119 immediately deallocate the DAO entry if there are no DAO 5120 parents. 5122 18. Manageability Considerations 5124 The aim of this section is to give consideration to the manageability 5125 of RPL, and how RPL will be operated in an LLN. The scope of this 5126 section is to consider the following aspects of manageability: 5127 configuration, monitoring, fault management, accounting, and 5128 performance of the protocol in light of the recommendations set forth 5129 in [RFC5706]. 5131 18.1. Introduction 5133 Most of the existing IETF management standards are MIB modules (data 5134 models based on the Structure of Management Information (SMI)) to 5135 monitor and manage networking devices. 5137 For a number of protocols, the IETF community has used the IETF 5138 Standard Management Framework, including the Simple Network 5139 Management Protocol [RFC3410], the Structure of Management 5140 Information [RFC2578], and MIB data models for managing new 5141 protocols. 5143 As pointed out in [RFC5706], the common policy in terms of operation 5144 and management has been expanded to a policy that is more open to a 5145 set of tools and management protocols rather than strictly relying on 5146 a single protocol such as SNMP. 5148 In 2003, the Internet Architecture Board (IAB) held a workshop on 5149 Network Management [RFC3535] that discussed the strengths and 5150 weaknesses of some IETF network management protocols and compared 5151 them to operational needs, especially configuration. 5153 One issue discussed was the user-unfriendliness of the binary format 5154 of SNMP [RFC3410]. In the case of LLNs, it must be noted that at the 5155 time of writing, the CoRE working group is actively working on 5156 resource management of devices in LLNs. Still, it is felt that this 5157 section provides important guidance on how RPL should be deployed, 5158 operated, and managed. 5160 As stated in [RFC5706]: 5162 | A management information model should include a discussion of what 5163 | is manageable, which aspects of the protocol need to be 5164 | configured, what types of operations are allowed, what protocol- 5165 | specific events might occur, which events can be counted, and for 5166 | which events an operator should be notified. 5168 These aspects are discussed in detail in the following sections. 5170 RPL will be used on a variety of devices that may have resources such 5171 as memory varying from a few kilobytes to several hundreds of 5172 kilobytes and even megabytes. When memory is highly constrained, it 5173 may not be possible to satisfy all the requirements listed in this 5174 section. Still it is worth listing all of these in an exhaustive 5175 fashion, and implementers will then determine which of these 5176 requirements could be satisfied according to the available resources 5177 on the device. 5179 18.2. Configuration Management 5181 This section discusses the configuration management, listing the 5182 protocol parameters for which configuration management is relevant. 5184 Some of the RPL parameters are optional. The requirements for 5185 configuration are only applicable for the options that are used. 5187 18.2.1. Initialization Mode 5189 "Architectural Principles of the Internet" [RFC1958], Section 3.8, 5190 states: "Avoid options and parameters whenever possible. Any options 5191 and parameters should be configured or negotiated dynamically rather 5192 than manually". This is especially true in LLNs where the number of 5193 devices may be large and manual configuration is infeasible. This 5194 has been taken into account in the design of RPL whereby the DODAG 5195 root provides a number of parameters to the devices joining the 5196 DODAG, thus avoiding cumbersome configuration on the routers and 5197 potential sources of misconfiguration (e.g., values of Trickle 5198 timers, etc.). Still, there are additional RPL parameters that a RPL 5199 implementation should allow to be configured, which are discussed in 5200 this section. 5202 18.2.1.1. DIS Mode of Operation upon Boot-Up 5204 When a node is first powered up: 5206 1. The node may decide to stay silent, waiting to receive DIO 5207 messages from DODAG of interest (advertising a supported OF and 5208 metrics/constraints) and not send any multicast DIO messages 5209 until it has joined a DODAG. 5211 2. The node may decide to send one or more DIS messages (optionally, 5212 requesting DIO for a specific DODAG) as an initial probe for 5213 nearby DODAGs, and in the absence of DIO messages in reply after 5214 some configurable period of time, the node may decide to root a 5215 floating DODAG and start sending multicast DIO messages. 5217 A RPL implementation SHOULD allow configuring the preferred mode of 5218 operation listed above along with the required parameters (in the 5219 second mode: the number of DIS messages and related timer). 5221 18.2.2. DIO and DAO Base Message and Options Configuration 5223 RPL specifies a number of protocol parameters considering the large 5224 spectrum of applications where it will be used. That said, 5225 particular attention has been given to limiting the number of these 5226 parameters that must be configured on each RPL router. Instead, a 5227 number of the default values can be used, and when required these 5228 parameters can be provided by the DODAG root thus allowing for 5229 dynamic parameter setting. 5231 A RPL implementation SHOULD allow configuring the following routing 5232 protocol parameters. As pointed out above, note that a large set of 5233 parameters is configured on the DODAG root. 5235 18.2.3. Protocol Parameters to Be Configured on Every Router in the LLN 5237 A RPL implementation MUST allow configuring the following RPL 5238 parameters: 5240 * RPLInstanceID [DIO message, in DIO Base message]. Although the 5241 RPLInstanceID must be configured on the DODAG root, it must also 5242 be configured as a policy on every node in order to determine 5243 whether or not the node should join a particular DODAG. Note that 5244 a second RPLInstanceID can be configured on the node, should it 5245 become root of a floating DODAG. 5247 * List of supported Objective Code Points (OCPs) 5248 * List of supported metrics: [RFC6551] specifies a number of metrics 5249 and constraints used for the DODAG formation. Thus, a RPL 5250 implementation should allow configuring the list of metrics that a 5251 node can accept and understand. If a DIO is received with a 5252 metric and/or constraint that is not understood or supported, as 5253 specified in Section 8.5, the node would join as a leaf node. 5255 * Prefix Information, along with valid and preferred lifetime and 5256 the 'L' and 'A' flags. [DIO message, Prefix Information Option]. 5257 A RPL implementation SHOULD allow configuring if the Prefix 5258 Information option must be carried with the DIO message to 5259 distribute the Prefix Information for autoconfiguration. In that 5260 case, the RPL implementation MUST allow the list of prefixes to be 5261 advertised in the PIO along with the corresponding flags. 5263 * Solicited Information [DIS message, in Solicited Information 5264 option]. Note that a RPL implementation SHOULD allow configuring 5265 when such messages should be sent and under which circumstances, 5266 along with the value of the RPLInstance ID, 'V'/'I'/'D' flags. 5268 * 'K' flag: when a node should set the 'K' flag in a DAO message 5269 [DAO message, in DAO Base message]. 5271 * MOP (Mode of Operation) [DIO message, in DIO Base message]. 5273 * Route Information (and preference) [DIO message, in Route 5274 Information option] 5276 18.2.4. Protocol Parameters to Be Configured on Every Non-DODAG-Root 5277 Router in the LLN 5279 A RPL implementation MUST allow configuring the Target prefix [DAO 5280 message, in RPL Target option]. 5282 Furthermore, there are circumstances where a node may want to 5283 designate a Target to allow for specific processing of the Target 5284 (prioritization, etc.). Such processing rules are out of scope for 5285 this specification. When used, a RPL implementation SHOULD allow 5286 configuring the Target Descriptor on a per-Target basis (for example, 5287 using access lists). 5289 A node whose DODAG parent set is empty may become the DODAG root of a 5290 floating DODAG. It may also set its DAGPreference such that it is 5291 less preferred. Thus, a RPL implementation MUST allow configuring 5292 the set of actions that the node should initiate in this case: 5294 * Start its own (floating) DODAG: the new DODAGID must be configured 5295 in addition to its DAGPreference. 5297 * Poison the broken path (see procedure in Section 8.2.2.5). 5299 * Trigger a local repair. 5301 18.2.5. Parameters to Be Configured on the DODAG Root 5303 In addition, several other parameters are configured only on the 5304 DODAG root and advertised in options carried in DIO messages. 5306 As specified in Section 8.3, a RPL implementation makes use of 5307 Trickle timers to govern the sending of DIO messages. The operation 5308 of the Trickle algorithm is determined by a set of configurable 5309 parameters, which MUST be configurable and that are then advertised 5310 by the DODAG root along the DODAG in DIO messages. 5312 * DIOIntervalDoublings [DIO message, in DODAG Configuration option] 5314 * DIOIntervalMin [DIO message, in DODAG Configuration option] 5316 * DIORedundancyConstant [DIO message, in DODAG Configuration option] 5318 In addition, a RPL implementation SHOULD allow for configuring the 5319 following set of RPL parameters: 5321 * Path Control Size [DIO message, in DODAG Configuration option] 5323 * MinHopRankIncrease [DIO message, in DODAG Configuration option] 5325 * The DODAGPreference field [DIO message, DIO Base object] 5327 * DODAGID [DIO message, in DIO Base option] and [DAO message, when 5328 the 'D' flag of the DAO message is set] 5330 DAG root behavior: in some cases, a node may not want to permanently 5331 act as a floating DODAG root if it cannot join a grounded DODAG. For 5332 example, a battery-operated node may not want to act as a floating 5333 DODAG root for a long period of time. Thus, a RPL implementation MAY 5334 support the ability to configure whether or not a node could act as a 5335 floating DODAG root for a configured period of time. 5337 DAG Version Number Increment: a RPL implementation may allow, by 5338 configuration at the DODAG root, refreshing the DODAG states by 5339 updating the DODAGVersionNumber. A RPL implementation SHOULD allow 5340 configuring whether or not periodic or event triggered mechanisms are 5341 used by the DODAG root to control DODAGVersionNumber change (which 5342 triggers a global repair as specified in Section 3.2.2). 5344 18.2.6. Configuration of RPL Parameters Related to DAO-Based Mechanisms 5346 DAO messages are optional and used in DODAGs that require Downward 5347 routing operation. This section deals with the set of parameters 5348 related to DAO messages and provides recommendations on their 5349 configuration. 5351 As stated in Section 9.5, it is recommended to delay the sending of 5352 DAO message to DAO parents in order to maximize the chances to 5353 perform route aggregation. Upon receiving a DAO message, the node 5354 should thus start a DelayDAO timer. The default value is 5355 DEFAULT_DAO_DELAY. A RPL implementation MAY allow for configuring 5356 the DelayDAO timer. 5358 In a Storing mode of operation, a storing node may increment DTSN in 5359 order to reliably trigger a set of DAO updates from its immediate 5360 children, as part of routine routing table updates and maintenance. 5361 A RPL implementation MAY allow for configuring a set of rules 5362 specifying the triggers for DTSN increment (manual or event-based). 5364 When a DAO entry times out or is invalidated, a node SHOULD make a 5365 reasonable attempt to report a No-Path to each of the DAO parents. 5366 That number of attempts MAY be configurable. 5368 An implementation should support rate-limiting the sending of DAO 5369 messages. The related parameters MAY be configurable. 5371 18.2.7. Configuration of RPL Parameters Related to Security Mechanisms 5373 As described in Section 10, the security features described in this 5374 document are optional to implement and a given implementation may 5375 support a subset (including the empty set) of the described security 5376 features. 5378 To this end, an implementation supporting described security features 5379 may conceptually implement a security policy database. In support of 5380 the security mechanisms, a RPL implementation SHOULD allow for 5381 configuring a subset of the following parameters: 5383 * Security Modes accepted [Unsecured mode, Preinstalled mode, 5384 Authenticated mode] 5386 * KIM values accepted [Secure RPL control messages, in Security 5387 section] 5389 * Level values accepted [Secure RPL control messages, in Security 5390 section] 5392 * Algorithm values accepted [Secure RPL control messages, in 5393 Security section] 5395 * Key material in support of Authenticated or Preinstalled key 5396 modes. 5398 In addition, a RPL implementation SHOULD allow for configuring a 5399 DODAG root with a subset of the following parameters: 5401 * Level values advertised [Secure DIO message, in Security section] 5403 * KIM value advertised [Secure DIO message, in Security section] 5405 * Algorithm value advertised [Secure DIO message, in Security 5406 section] 5408 18.2.8. Default Values 5410 This document specifies default values for the following set of RPL 5411 variables: 5413 DEFAULT_PATH_CONTROL_SIZE 5414 DEFAULT_DIO_INTERVAL_MIN 5415 DEFAULT_DIO_INTERVAL_DOUBLINGS 5416 DEFAULT_DIO_REDUNDANCY_CONSTANT 5417 DEFAULT_MIN_HOP_RANK_INCREASE 5418 DEFAULT_DAO_DELAY 5420 It is recommended to specify default values in protocols; that being 5421 said, as discussed in [RFC5706], default values may make less and 5422 less sense. RPL is a routing protocol that is expected to be used in 5423 a number of contexts where network characteristics such as the number 5424 of nodes and link and node types are expected to vary significantly. 5425 Thus, these default values are likely to change with the context and 5426 as the technology evolves. Indeed, LLNs' related technology (e.g., 5427 hardware, link layers) have been evolving dramatically over the past 5428 few years and such technologies are expected to change and evolve 5429 considerably in the coming years. 5431 The proposed values are not based on extensive best current practices 5432 and are considered to be conservative. 5434 18.3. Monitoring of RPL Operation 5436 Several RPL parameters should be monitored to verify the correct 5437 operation of the routing protocol and the network itself. This 5438 section lists the set of monitoring parameters of interest. 5440 18.3.1. Monitoring a DODAG Parameters 5442 A RPL implementation SHOULD provide information about the following 5443 parameters: 5445 * DODAG Version number [DIO message, in DIO Base message] 5447 * Status of the 'G' flag [DIO message, in DIO Base message] 5449 * Status of the MOP field [DIO message, in DIO Base message] 5451 * Value of the DTSN [DIO message, in DIO Base message] 5453 * Value of the Rank [DIO message, in DIO Base message] 5455 * DAOSequence: Incremented at each unique DAO message, echoed in the 5456 DAO-ACK message [DAO and DAO-ACK messages] 5458 * Route Information [DIO message, Route Information Option] (list of 5459 IPv6 prefixes per parent along with lifetime and preference] 5461 * Trickle parameters: 5463 - DIOIntervalDoublings [DIO message, in DODAG Configuration 5464 option] 5466 - DIOIntervalMin [DIO message, in DODAG Configuration option] 5468 - DIORedundancyConstant [DIO message, in DODAG Configuration 5469 option] 5471 * Path Control Size [DIO message, in DODAG Configuration option] 5473 * MinHopRankIncrease [DIO message, in DODAG Configuration option] 5475 Values that may be monitored only on the DODAG root: 5477 * Transit Information [DAO, Transit Information option]: A RPL 5478 implementation SHOULD allow configuring whether the set of 5479 received Transit Information options should be displayed on the 5480 DODAG root. In this case, the RPL database of received Transit 5481 Information should also contain the Path Sequence, Path Control, 5482 Path Lifetime, and Parent Address. 5484 18.3.2. Monitoring a DODAG Inconsistencies and Loop Detection 5486 Detection of DODAG inconsistencies is particularly critical in RPL 5487 networks. Thus, it is recommended for a RPL implementation to 5488 provide appropriate monitoring tools. A RPL implementation SHOULD 5489 provide a counter reporting the number of a times the node has 5490 detected an inconsistency with respect to a DODAG parent, e.g., if 5491 the DODAGID has changed. 5493 When possible more granular information about inconsistency detection 5494 should be provided. A RPL implementation MAY provide counters 5495 reporting the number of following inconsistencies: 5497 * Packets received with 'O' bit set (to Down) from a node with a 5498 higher Rank 5500 * Packets received with 'O' bit cleared (to Up) from a node with a 5501 lower Rank 5503 * Number of packets with the 'F' bit set 5505 * Number of packets with the 'R' bit set 5507 18.4. Monitoring of the RPL Data Structures 5509 18.4.1. Candidate Neighbor Data Structure 5511 A node in the candidate neighbor list is a node discovered by the 5512 same means and qualified to potentially become a parent (with high 5513 enough local confidence). A RPL implementation SHOULD provide a way 5514 to allow for the candidate neighbor list to be monitored with some 5515 metric reflecting local confidence (the degree of stability of the 5516 neighbors) as measured by some metrics. 5518 A RPL implementation MAY provide a counter reporting the number of 5519 times a candidate neighbor has been ignored, should the number of 5520 candidate neighbors exceed the maximum authorized value. 5522 18.4.2. Destination-Oriented Directed Acyclic Graph (DODAG) Table 5524 For each DODAG, a RPL implementation is expected to keep track of the 5525 following DODAG table values: 5527 * RPLInstanceID 5529 * DODAGID 5531 * DODAGVersionNumber 5532 * Rank 5534 * Objective Code Point 5536 * A set of DODAG parents 5538 * A set of prefixes offered Upward along the DODAG 5540 * Trickle timers used to govern the sending of DIO messages for the 5541 DODAG 5543 * List of DAO parents 5545 * DTSN 5547 * Node status (router versus leaf) 5549 A RPL implementation SHOULD allow for monitoring the set of 5550 parameters listed above. 5552 18.4.3. Routing Table and DAO Routing Entries 5554 A RPL implementation maintains several information elements related 5555 to the DODAG and the DAO entries (for storing nodes). In the case of 5556 a non-storing node, a limited amount of information is maintained 5557 (the routing table is mostly reduced to a set of DODAG parents along 5558 with characteristics of the DODAG as mentioned above); whereas in the 5559 case of storing nodes, this information is augmented with routing 5560 entries. 5562 A RPL implementation SHOULD allow for the following parameters to be 5563 monitored: 5565 * Next Hop (DODAG parent) 5567 * Next Hop Interface 5569 * Path metrics value for each DODAG parent 5571 A DAO Routing Table entry conceptually contains the following 5572 elements (for storing nodes only): 5574 * Advertising Neighbor Information 5576 * IPv6 address 5578 * Interface ID to which DAO parents has this entry been reported 5579 * Retry counter 5581 * Logical equivalent of DAO Content: 5583 - DAO-Sequence 5585 - Path Sequence 5587 - DAO Lifetime 5589 - DAO Path Control 5591 * Destination Prefix (or address or Mcast Group) 5593 A RPL implementation SHOULD provide information about the state of 5594 each DAO Routing Table entry states. 5596 18.5. Fault Management 5598 Fault management is a critical component used for troubleshooting, 5599 verification of the correct mode of operation of the protocol, and 5600 network design; also, it is a key component of network performance 5601 monitoring. A RPL implementation SHOULD allow the provision of the 5602 following information related to fault managements: 5604 * Memory overflow along with the cause (e.g., routing tables 5605 overflow, etc.) 5607 * Number of times a packet could not be sent to a DODAG parent 5608 flagged as valid 5610 * Number of times a packet has been received for which the router 5611 did not have a corresponding RPLInstanceID 5613 * Number of times a local repair procedure was triggered 5615 * Number of times a global repair was triggered by the DODAG root 5617 * Number of received malformed messages 5619 * Number of seconds with packets to forward and no next hop (DODAG 5620 parent) 5622 * Number of seconds without next hop (DODAG parent) 5623 * Number of times a node has joined a DODAG as a leaf because it 5624 received a DIO with a metric/constraint that was not understood 5625 and it was configured to join as a leaf node in this case (see 5626 Section 18.6) 5628 It is RECOMMENDED to report faults via at least error log messages. 5629 Other protocols may be used to report such faults. 5631 18.6. Policy 5633 Policy rules can be used by a RPL implementation to determine whether 5634 or not the node is allowed to join a particular DODAG advertised by a 5635 neighbor by means of DIO messages. 5637 This document specifies operation within a single DODAG. A DODAG is 5638 characterized by the following tuple (RPLInstanceID, DODAGID). 5639 Furthermore, as pointed out above, DIO messages are used to advertise 5640 other DODAG characteristics such as the routing metrics and 5641 constraints used to build to the DODAG and the Objective Function in 5642 use (specified by OCP). 5644 The first policy rules consist of specifying the following conditions 5645 that a RPL node must satisfy to join a DODAG: 5647 * RPLInstanceID 5649 * List of supported routing metrics and constraints 5651 * Objective Function (OCP values) 5653 A RPL implementation MUST allow configuring these parameters and 5654 SHOULD specify whether the node must simply ignore the DIO if the 5655 advertised DODAG is not compliant with the local policy or whether 5656 the node should join as the leaf node if only the list of supported 5657 routing metrics and constraints, and the OF is not supported. 5658 Additionally, a RPL implementation SHOULD allow for the addition of 5659 the DODAGID as part of the policy. 5661 A RPL implementation SHOULD allow configuring the set of acceptable 5662 or preferred Objective Functions (OFs) referenced by their Objective 5663 Code Points (OCPs) for a node to join a DODAG, and what action should 5664 be taken if none of a node's candidate neighbors advertise one of the 5665 configured allowable Objective Functions, or if the advertised 5666 metrics/constraint is not understood/supported. Two actions can be 5667 taken in this case: 5669 * The node joins the DODAG as a leaf node as specified in 5670 Section 8.5. 5672 * The node does not join the DODAG. 5674 A node in an LLN may learn routing information from different routing 5675 protocols including RPL. In this case, it is desirable to control, 5676 via administrative preference, which route should be favored. An 5677 implementation SHOULD allow for the specification of an 5678 administrative preference for the routing protocol from which the 5679 route was learned. 5681 Internal Data Structures: some RPL implementations may limit the size 5682 of the candidate neighbor list in order to bound the memory usage; in 5683 which case, some otherwise viable candidate neighbors may not be 5684 considered and simply dropped from the candidate neighbor list. 5686 A RPL implementation MAY provide an indicator on the size of the 5687 candidate neighbor list. 5689 18.7. Fault Isolation 5691 It is RECOMMENDED to quarantine neighbors that start emitting 5692 malformed messages at unacceptable rates. 5694 18.8. Impact on Other Protocols 5696 RPL has very limited impact on other protocols. Where more than one 5697 routing protocol is required on a router, such as an LBR, it is 5698 expected for the device to support routing redistribution functions 5699 between the routing protocols to allow for reachability between the 5700 two routing domains. Such redistribution SHOULD be governed by the 5701 use of user configurable policy. 5703 With regard to the impact in terms of traffic on the network, RPL has 5704 been designed to limit the control traffic thanks to mechanisms such 5705 as Trickle timers (Section 8.3). Thus, the impact of RPL on other 5706 protocols should be extremely limited. 5708 18.9. Performance Management 5710 Performance management is always an important aspect of a protocol, 5711 and RPL is not an exception. Several metrics of interest have been 5712 specified by the IP Performance Monitoring (IPPM) working group: that 5713 being said, they will be hardly applicable to LLN considering the 5714 cost of monitoring these metrics in terms of resources on the devices 5715 and required bandwidth. Still, RPL implementations MAY support some 5716 of these, and other parameters of interest are listed below: 5718 * Number of repairs and time to repair in seconds (average, 5719 variance) 5721 * Number of times and time period during which a devices could not 5722 forward a packet because of a lack of a reachable neighbor in its 5723 routing table 5725 * Monitoring of resources consumption by RPL in terms of bandwidth 5726 and required memory 5728 * Number of RPL control messages sent and received 5730 18.10. Diagnostics 5732 There may be situations where a node should be placed in "verbose" 5733 mode to improve diagnostics. Thus, a RPL implementation SHOULD 5734 provide the ability to place a node in and out of verbose mode in 5735 order to get additional diagnostic information. 5737 19. Security Considerations 5739 19.1. Overview 5741 From a security perspective, RPL networks are no different from any 5742 other network. They are vulnerable to passive eavesdropping attacks 5743 and, potentially, even active tampering when physical access to a 5744 wire is not required to participate in communications. The very 5745 nature of ad hoc networks and their cost objectives impose additional 5746 security constraints, which perhaps make these networks the most 5747 difficult environments to secure. Devices are low-cost and have 5748 limited capabilities in terms of computing power, available storage, 5749 and power drain; it cannot always be assumed they have a trusted 5750 computing base or a high-quality random number generator aboard. 5752 Communications cannot rely on the online availability of a fixed 5753 infrastructure and might involve short-term relationships between 5754 devices that may never have communicated before. These constraints 5755 might severely limit the choice of cryptographic algorithms and 5756 protocols and influence the design of the security architecture 5757 because the establishment and maintenance of trust relationships 5758 between devices need to be addressed with care. In addition, battery 5759 lifetime and cost constraints put severe limits on the security 5760 overhead these networks can tolerate, something that is of far less 5761 concern with higher bandwidth networks. Most of these security 5762 architectural elements can be implemented at higher layers and may, 5763 therefore, be considered to be out of scope for this specification. 5764 Special care, however, needs to be exercised with respect to 5765 interfaces to these higher layers. 5767 The security mechanisms in this standard are based on symmetric-key 5768 and public-key cryptography and use keys that are to be provided by 5769 higher-layer processes. The establishment and maintenance of these 5770 keys are out of scope for this specification. The mechanisms assume 5771 a secure implementation of cryptographic operations and secure and 5772 authentic storage of keying material. 5774 The security mechanisms specified provide particular combinations of 5775 the following security services: 5777 Data confidentiality: Assurance that transmitted information is only 5778 disclosed to parties for which it is intended. 5780 Data authenticity: Assurance of the source of transmitted 5781 information (and, hereby, that information was not modified in 5782 transit). 5784 Replay protection: Assurance that a duplicate of transmitted 5785 information is detected. 5787 Timeliness (delay protection): Assurance that transmitted 5788 information was received in a timely manner. 5790 The actual protection provided can be adapted on a per-packet basis 5791 and allows for varying levels of data authenticity (to minimize 5792 security overhead in transmitted packets where required) and for 5793 optional data confidentiality. When nontrivial protection is 5794 required, replay protection is always provided. 5796 Replay protection is provided via the use of a non-repeating value 5797 (CCM nonce) in the packet protection process and storage of some 5798 status information (originating device and the CCM nonce counter last 5799 received from that device), which allows detection of whether this 5800 particular CCM nonce value was used previously by the originating 5801 device. In addition, so-called delay protection is provided amongst 5802 those devices that have a loosely synchronized clock on board. The 5803 acceptable time delay can be adapted on a per-packet basis and allows 5804 for varying latencies (to facilitate longer latencies in packets 5805 transmitted over a multi-hop communication path). 5807 Cryptographic protection may use a key shared between two peer 5808 devices (link key) or a key shared among a group of devices (group 5809 key), thus allowing some flexibility and application-specific trade- 5810 offs between key storage and key maintenance costs versus the 5811 cryptographic protection provided. If a group key is used for peer- 5812 to-peer communication, protection is provided only against outsider 5813 devices and not against potential malicious devices in the key- 5814 sharing group. 5816 Data authenticity may be provided using symmetric-key-based or 5817 public-key-based techniques. With public-key-based techniques (via 5818 signatures), one corroborates evidence as to the unique originator of 5819 transmitted information, whereas with symmetric-key-based techniques, 5820 data authenticity is only provided relative to devices in a key- 5821 sharing group. Thus, public-key-based authentication may be useful 5822 in scenarios that require a more fine-grained authentication than can 5823 be provided with symmetric-key-based authentication techniques alone, 5824 such as with group communications (broadcast, multicast) or in 5825 scenarios that require non-repudiation. 5827 20. IANA Considerations 5829 20.1. RPL Control Message 5831 The RPL control message is an ICMP information message type that is 5832 to be used carry DODAG Information Objects, DODAG Information 5833 Solicitations, and Destination Advertisement Objects in support of 5834 RPL operation. 5836 IANA has defined an ICMPv6 Type Number Registry. The type value for 5837 the RPL control message is 155. 5839 20.2. New Registry for RPL Control Codes> 5841 IANA has created a registry, RPL Control Codes, for the Code field of 5842 the ICMPv6 RPL control message. 5844 New codes may be allocated only by an IETF Review. Each code is 5845 tracked with the following qualities: 5847 * Code 5849 * Description 5851 * Defining RFC 5853 The following codes are currently defined: 5855 +======+==================================+===========+ 5856 | Code | Description | Reference | 5857 +======+==================================+===========+ 5858 | 0x00 | DODAG Information Solicitation | RFC 6550 | 5859 +------+----------------------------------+-----------+ 5860 | 0x01 | DODAG Information Object | RFC 6550 | 5861 +------+----------------------------------+-----------+ 5862 | 0x02 | Destination Advertisement Object | RFC 6550 | 5863 +------+----------------------------------+-----------+ 5864 | 0x03 | Destination Advertisement Object | RFC 6550 | 5865 | | Acknowledgment | | 5866 +------+----------------------------------+-----------+ 5867 | 0x80 | Secure DODAG Information | RFC 6550 | 5868 | | Solicitation | | 5869 +------+----------------------------------+-----------+ 5870 | 0x81 | Secure DODAG Information Object | RFC 6550 | 5871 +------+----------------------------------+-----------+ 5872 | 0x82 | Secure Destination Advertisement | RFC 6550 | 5873 | | Object | | 5874 +------+----------------------------------+-----------+ 5875 | 0x83 | Secure Destination Advertisement | RFC 6550 | 5876 | | Object Acknowledgment | | 5877 +------+----------------------------------+-----------+ 5878 | 0x8A | Consistency Check | RFC 6550 | 5879 +------+----------------------------------+-----------+ 5881 Table 1: RPL Control Codes 5883 20.3. New Registry for the Mode of Operation (MOP) 5885 IANA has created a registry for the 3-bit Mode of Operation (MOP), 5886 which is contained in the DIO Base. 5888 New values may be allocated only by an IETF Review. Each value is 5889 tracked with the following qualities: 5891 * Mode of Operation Value 5893 * Capability description 5895 * Defining RFC 5897 Four values are currently defined: 5899 +===========+======================================+===========+ 5900 | MOP value | Description | Reference | 5901 +===========+======================================+===========+ 5902 | 0 | No Downward routes maintained by RPL | RFC 6550 | 5903 +-----------+--------------------------------------+-----------+ 5904 | 1 | Non-Storing Mode of Operation | RFC 6550 | 5905 +-----------+--------------------------------------+-----------+ 5906 | 2 | Storing Mode of Operation with no | RFC 6550 | 5907 | | multicast support | | 5908 +-----------+--------------------------------------+-----------+ 5909 | 3 | Storing Mode of Operation with | RFC 6550 | 5910 | | multicast support | | 5911 +-----------+--------------------------------------+-----------+ 5913 Table 2: DIO Mode of Operation 5915 The rest of the range, decimal 4 to 7, is currently unassigned. 5917 20.4. RPL Control Message Options 5919 IANA has created a registry for the RPL Control Message Options. 5921 New values may be allocated only by an IETF Review. Each value is 5922 tracked with the following qualities: 5924 * Value 5926 * Meaning 5928 * Defining RFC 5929 +=======+=======================+===========+ 5930 | Value | Meaning | Reference | 5931 +=======+=======================+===========+ 5932 | 0x00 | Pad1 | RFC 6550 | 5933 +-------+-----------------------+-----------+ 5934 | 0x01 | PadN | RFC 6550 | 5935 +-------+-----------------------+-----------+ 5936 | 0x02 | DAG Metric Container | RFC 6550 | 5937 +-------+-----------------------+-----------+ 5938 | 0x03 | Routing Information | RFC 6550 | 5939 +-------+-----------------------+-----------+ 5940 | 0x04 | DODAG Configuration | RFC 6550 | 5941 +-------+-----------------------+-----------+ 5942 | 0x05 | RPL Target | RFC 6550 | 5943 +-------+-----------------------+-----------+ 5944 | 0x06 | Transit Information | RFC 6550 | 5945 +-------+-----------------------+-----------+ 5946 | 0x07 | Solicited Information | RFC 6550 | 5947 +-------+-----------------------+-----------+ 5948 | 0x08 | Prefix Information | RFC 6550 | 5949 +-------+-----------------------+-----------+ 5950 | 0x09 | Target Descriptor | RFC 6550 | 5951 +-------+-----------------------+-----------+ 5953 Table 3: RPL Control Message Options 5955 20.5. Objective Code Point (OCP) Registry 5957 IANA has created a registry to manage the codespace of the Objective 5958 Code Point (OCP) field. 5960 No OCPs are defined in this specification. 5962 New codes may be allocated only by an IETF Review. Each code is 5963 tracked with the following qualities: 5965 * Code 5967 * Description 5969 * Defining RFC 5971 20.6. New Registry for the Security Section Algorithm 5973 IANA has created a registry for the values of the 8-bit Algorithm 5974 field in the Security section. 5976 New values may be allocated only by an IETF Review. Each value is 5977 tracked with the following qualities: 5979 * Value 5981 * Encryption/MAC 5983 * Signature 5985 * Defining RFC 5987 The following value is currently defined: 5989 +=======+==================+==================+===========+ 5990 | Value | Encryption/MAC | Signature | Reference | 5991 +=======+==================+==================+===========+ 5992 | 0 | CCM with AES-128 | RSA with SHA-256 | RFC 6550 | 5993 +-------+------------------+------------------+-----------+ 5995 Table 4: Security Section Algorithm 5997 20.7. New Registry for the Security Section Flags 5999 IANA has created a registry for the 8-bit Security Section Flags 6000 field. 6002 New bit numbers may be allocated only by an IETF Review. Each bit is 6003 tracked with the following qualities: 6005 * Bit number (counting from bit 0 as the most significant bit) 6007 * Capability description 6009 * Defining RFC 6011 No bit is currently defined for the Security Section Flags field. 6013 20.8. New Registry for Per-KIM Security Levels 6015 IANA has created one registry for the 3-bit Security Level (LVL) 6016 field per allocated KIM value. 6018 For a given KIM value, new levels may be allocated only by an IETF 6019 Review. Each level is tracked with the following qualities: 6021 * Level 6023 * KIM value 6024 * Description 6026 * Defining RFC 6028 The following levels per KIM value are currently defined: 6030 +=======+===========+===============+===========+ 6031 | Level | KIM value | Description | Reference | 6032 +=======+===========+===============+===========+ 6033 | 0 | 0 | See Figure 11 | RFC 6550 | 6034 +-------+-----------+---------------+-----------+ 6035 | 1 | 0 | See Figure 11 | RFC 6550 | 6036 +-------+-----------+---------------+-----------+ 6037 | 2 | 0 | See Figure 11 | RFC 6550 | 6038 +-------+-----------+---------------+-----------+ 6039 | 3 | 0 | See Figure 11 | RFC 6550 | 6040 +-------+-----------+---------------+-----------+ 6041 | 0 | 1 | See Figure 11 | RFC 6550 | 6042 +-------+-----------+---------------+-----------+ 6043 | 1 | 1 | See Figure 11 | RFC 6550 | 6044 +-------+-----------+---------------+-----------+ 6045 | 2 | 1 | See Figure 11 | RFC 6550 | 6046 +-------+-----------+---------------+-----------+ 6047 | 3 | 1 | See Figure 11 | RFC 6550 | 6048 +-------+-----------+---------------+-----------+ 6049 | 0 | 2 | See Figure 11 | RFC 6550 | 6050 +-------+-----------+---------------+-----------+ 6051 | 1 | 2 | See Figure 11 | RFC 6550 | 6052 +-------+-----------+---------------+-----------+ 6053 | 2 | 2 | See Figure 11 | RFC 6550 | 6054 +-------+-----------+---------------+-----------+ 6055 | 3 | 2 | See Figure 11 | RFC 6550 | 6056 +-------+-----------+---------------+-----------+ 6057 | 0 | 3 | See Figure 11 | RFC 6550 | 6058 +-------+-----------+---------------+-----------+ 6059 | 1 | 3 | See Figure 11 | RFC 6550 | 6060 +-------+-----------+---------------+-----------+ 6061 | 2 | 3 | See Figure 11 | RFC 6550 | 6062 +-------+-----------+---------------+-----------+ 6063 | 3 | 3 | See Figure 11 | RFC 6550 | 6064 +-------+-----------+---------------+-----------+ 6066 Table 5: Per-KIM Security Levels 6068 20.9. New Registry for DODAG Informational Solicitation (DIS) Flags 6070 IANA has created a registry for the DIS (DODAG Informational 6071 Solicitation) Flags field. 6073 New bit numbers may be allocated only by an IETF Review. Each bit is 6074 tracked with the following qualities: 6076 * Bit number (counting from bit 0 as the most significant bit) 6078 * Capability description 6080 * Defining RFC 6082 No bit is currently defined for the DIS (DODAG Informational 6083 Solicitation) Flags field. 6085 20.10. New Registry for the DODAG Information Object (DIO) Flags 6087 IANA has created a registry for the 8-bit DODAG Information Object 6088 (DIO) Flags field. 6090 New bit numbers may be allocated only by an IETF Review. Each bit is 6091 tracked with the following qualities: 6093 * Bit number (counting from bit 0 as the most significant bit) 6095 * Capability description 6097 * Defining RFC 6099 No bit is currently defined for the DIS (DODAG Informational 6100 Solicitation) Flags. 6102 20.11. New Registry for the Destination Advertisement Object (DAO) 6103 Flags 6105 IANA has created a registry for the 8-bit Destination Advertisement 6106 Object (DAO) Flags field. 6108 New bit numbers may be allocated only by an IETF Review. Each bit is 6109 tracked with the following qualities: 6111 * Bit number (counting from bit 0 as the most significant bit) 6113 * Capability description 6115 * Defining RFC 6117 The following bits are currently defined: 6119 +============+==============================+===========+ 6120 | Bit number | Description | Reference | 6121 +============+==============================+===========+ 6122 | 0 | DAO-ACK request (K) | RFC 6550 | 6123 +------------+------------------------------+-----------+ 6124 | 1 | DODAGID field is present (D) | RFC 6550 | 6125 +------------+------------------------------+-----------+ 6127 Table 6: DAO Base Flags 6129 20.12. New Registry for the Destination Advertisement Object (DAO) 6130 Acknowledgement Flags 6132 IANA has created a registry for the 8-bit Destination Advertisement 6133 Object (DAO) Acknowledgement Flags field. 6135 New bit numbers may be allocated only by an IETF Review. Each bit is 6136 tracked with the following qualities: 6138 * Bit number (counting from bit 0 as the most significant bit) 6140 * Capability description 6142 * Defining RFC 6144 The following bit is currently defined: 6146 +============+==============================+===========+ 6147 | Bit number | Description | Reference | 6148 +============+==============================+===========+ 6149 | 0 | DODAGID field is present (D) | RFC 6550 | 6150 +------------+------------------------------+-----------+ 6152 Table 7: DAO-ACK Base Flags 6154 20.13. New Registry for the Consistency Check (CC) Flags 6156 IANA has created a registry for the 8-bit Consistency Check (CC) 6157 Flags field. 6159 New bit numbers may be allocated only by an IETF Review. Each bit is 6160 tracked with the following qualities: 6162 * Bit number (counting from bit 0 as the most significant bit) 6164 * Capability description 6166 * Defining RFC 6167 The following bit is currently defined: 6169 +============+=================+===========+ 6170 | Bit number | Description | Reference | 6171 +============+=================+===========+ 6172 | 0 | CC Response (R) | RFC 6550 | 6173 +------------+-----------------+-----------+ 6175 Table 8: Consistency Check Base Flags 6177 20.14. New Registry for the DODAG Configuration Option Flags 6179 IANA has created a registry for the 8-bit DODAG Configuration Option 6180 Flags field. 6182 New bit numbers may be allocated only by an IETF Review. Each bit is 6183 tracked with the following qualities: 6185 * Bit number (counting from bit 0 as the most significant bit) 6187 * Capability description 6189 * Defining RFC 6191 The following bits are currently defined: 6193 +============+============================+===========+ 6194 | Bit number | Description | Reference | 6195 +============+============================+===========+ 6196 | 4 | Authentication Enabled (A) | RFC 6550 | 6197 +------------+----------------------------+-----------+ 6198 | 5-7 | Path Control Size (PCS) | RFC 6550 | 6199 +------------+----------------------------+-----------+ 6201 Table 9: DODAG Configuration Option Flags 6203 20.15. New Registry for the RPL Target Option Flags 6205 IANA has created a registry for the 8-bit RPL Target Option Flags 6206 field. 6208 New bit numbers may be allocated only by an IETF Review. Each bit is 6209 tracked with the following qualities: 6211 * Bit number (counting from bit 0 as the most significant bit) 6213 * Capability description 6214 * Defining RFC 6216 No bit is currently defined for the RPL Target Option Flags. 6218 20.16. New Registry for the Transit Information Option Flags 6220 IANA has created a registry for the 8-bit Transit Information Option 6221 (TIO) Flags field. 6223 New bit numbers may be allocated only by an IETF Review. Each bit is 6224 tracked with the following qualities: 6226 * Bit number (counting from bit 0 as the most significant bit) 6228 * Capability description 6230 * Defining RFC 6232 The following bits are currently defined: 6234 +============+==============+===========+ 6235 | Bit number | Description | Reference | 6236 +============+==============+===========+ 6237 | 0 | External (E) | RFC 6550 | 6238 +------------+--------------+-----------+ 6240 Table 10: Transit Information Option 6241 Flags 6243 20.17. New Registry for the Solicited Information Option Flags 6245 IANA has created a registry for the 8-bit Solicited Information 6246 Option (SIO) Flags field. 6248 New bit numbers may be allocated only by an IETF Review. Each bit is 6249 tracked with the following qualities: 6251 * Bit number (counting from bit 0 as the most significant bit) 6253 * Capability description 6255 * Defining RFC 6257 The following bits are currently defined: 6259 +============+================================+===========+ 6260 | Bit number | Description | Reference | 6261 +============+================================+===========+ 6262 | 0 | Version Predicate match (V) | RFC 6550 | 6263 +------------+--------------------------------+-----------+ 6264 | 1 | InstanceID Predicate match (I) | RFC 6550 | 6265 +------------+--------------------------------+-----------+ 6266 | 2 | DODAGID Predicate match (D) | RFC 6550 | 6267 +------------+--------------------------------+-----------+ 6269 Table 11: Solicited Information Option Flags 6271 20.18. ICMPv6: Error in Source Routing Header 6273 In some cases RPL will return an ICMPv6 error message when a message 6274 cannot be delivered as specified by its source routing header. This 6275 ICMPv6 error message is "Error in Source Routing Header". 6277 IANA has defined an ICMPv6 "Code" Fields Registry for ICMPv6 Message 6278 Types. ICMPv6 Message Type 1 describes "Destination Unreachable" 6279 codes. The "Error in Source Routing Header" code is has been 6280 allocated from the ICMPv6 Code Fields Registry for ICMPv6 Message 6281 Type 1, with a code value of 7. 6283 20.19. Link-Local Scope Multicast Address 6285 The rules for assigning new IPv6 multicast addresses are defined in 6286 [RFC3307]. This specification requires the allocation of a new 6287 permanent multicast address with a link-local scope for RPL nodes 6288 called all-RPL-nodes, with a value of ff02::1a. 6290 21. Acknowledgements 6292 The authors would like to acknowledge the review, feedback, and 6293 comments from Emmanuel Baccelli, Dominique Barthel, Yusuf Bashir, 6294 Yoav Ben-Yehezkel, Phoebus Chen, Quynh Dang, Mischa Dohler, Mathilde 6295 Durvy, Joakim Eriksson, Omprakash Gnawali, Manhar Goindi, Mukul 6296 Goyal, Ulrich Herberg, Anders Jagd, JeongGil (John) Ko, Ajay Kumar, 6297 Quentin Lampin, Jerry Martocci, Matteo Paris, Alexandru Petrescu, 6298 Joseph Reddy, Michael Richardson, Don Sturek, Joydeep Tripathi, and 6299 Nicolas Tsiftes. 6301 The authors would like to acknowledge the guidance and input provided 6302 by the ROLL Chairs, David Culler and JP. Vasseur, and the Area 6303 Director, Adrian Farrel. 6305 The authors would like to acknowledge prior contributions of Robert 6306 Assimiti, Mischa Dohler, Julien Abeille, Ryuji Wakikawa, Teco Boot, 6307 Patrick Wetterwald, Bryan Mclaughlin, Carlos J. Bernardos, Thomas 6308 Watteyne, Zach Shelby, Caroline Bontoux, Marco Molteni, Billy Moon, 6309 Jim Bound, Yanick Pouffary, Henning Rogge, and Arsalan Tavakoli, who 6310 have provided useful design considerations to RPL. 6312 RPL Security Design, found in Section 10, Section 19, and elsewhere 6313 throughout the document, is primarily the contribution of the 6314 Security Design Team: Tzeta Tsao, Roger Alexander, Dave Ward, Philip 6315 Levis, Kris Pister, Rene Struik, and Adrian Farrel. 6317 Thanks also to Jari Arkko and Ralph Droms for their attentive 6318 reviews, especially with respect to interoperability considerations 6319 and integration with other IETF specifications. 6321 22. Contributors 6323 Roger K. Alexander 6324 Cooper Power Systems 6325 20201 Century Blvd., Suite 250 6326 Germantown, MD 20874 6327 USA 6329 Phone: +1 240 454 9817 6330 EMail: roger.alexander@cooperindustries.com 6332 Anders Brandt 6333 Sigma Designs 6334 Emdrupvej 26A, 1. 6335 Copenhagen DK-2100 6336 Denmark 6338 EMail: abr@sdesigns.dk 6340 Stephen Dawson-Haggerty 6341 UC Berkeley 6342 Soda Hall 6343 Berkeley, CA 94720 6344 USA 6346 EMail: stevedh@cs.berkeley.edu 6347 Jonathan W. Hui 6348 Arch Rock Corporation 6349 501 2nd St., Suite 410 6350 San Francisco, CA 94107 6351 USA 6353 EMail: jhui@archrock.com 6355 Richard Kelsey 6356 Ember Corporation 6357 Boston, MA 6358 USA 6360 Phone: +1 617 951 1225 6361 EMail: kelsey@ember.com 6363 Philip Levis 6364 Stanford University 6365 358 Gates Hall, Stanford University 6366 Stanford, CA 94305-9030 6367 USA 6369 EMail: pal@cs.stanford.edu 6371 Kris Pister 6372 Dust Networks 6373 30695 Huntwood Ave. 6374 Hayward, CA 94544 6375 USA 6377 EMail: kpister@dustnetworks.com 6379 Rene Struik 6380 Struik Security Consultancy 6382 EMail: rstruik.ext@gmail.com 6384 JP. Vasseur 6385 Cisco Systems 6386 11, Rue Camille Desmoulins 6387 Issy Les Moulineaux 92782 6388 France 6390 EMail: jpv@cisco.com 6392 23. References 6394 23.1. Normative References 6396 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 6397 Requirement Levels", BCP 14, RFC 2119, 6398 DOI 10.17487/RFC2119, March 1997, 6399 . 6401 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 6402 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 6403 December 1998, . 6405 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 6406 Standards (PKCS) #1: RSA Cryptography Specifications 6407 Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February 6408 2003, . 6410 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 6411 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 6412 November 2005, . 6414 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 6415 DOI 10.17487/RFC4302, December 2005, 6416 . 6418 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 6419 Control Message Protocol (ICMPv6) for the Internet 6420 Protocol Version 6 (IPv6) Specification", STD 89, 6421 RFC 4443, DOI 10.17487/RFC4443, March 2006, 6422 . 6424 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 6425 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 6426 DOI 10.17487/RFC4861, September 2007, 6427 . 6429 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 6430 Address Autoconfiguration", RFC 4862, 6431 DOI 10.17487/RFC4862, September 2007, 6432 . 6434 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 6435 "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, 6436 March 2011, . 6438 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 6439 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 6440 2011, . 6442 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 6443 and D. Barthel, "Routing Metrics Used for Path Calculation 6444 in Low-Power and Lossy Networks", RFC 6551, 6445 DOI 10.17487/RFC6551, March 2012, 6446 . 6448 [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing 6449 Protocol for Low-Power and Lossy Networks (RPL)", 6450 RFC 6552, DOI 10.17487/RFC6552, March 2012, 6451 . 6453 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 6454 Power and Lossy Networks (RPL) Option for Carrying RPL 6455 Information in Data-Plane Datagrams", RFC 6553, 6456 DOI 10.17487/RFC6553, March 2012, 6457 . 6459 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 6460 Routing Header for Source Routes with the Routing Protocol 6461 for Low-Power and Lossy Networks (RPL)", RFC 6554, 6462 DOI 10.17487/RFC6554, March 2012, 6463 . 6465 23.2. Informative References 6467 [RFC1958] Carpenter, B., Ed., "Architectural Principles of the 6468 Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996, 6469 . 6471 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 6472 DOI 10.17487/RFC1982, August 1996, 6473 . 6475 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 6476 Schoenwaelder, Ed., "Structure of Management Information 6477 Version 2 (SMIv2)", STD 58, RFC 2578, 6478 DOI 10.17487/RFC2578, April 1999, 6479 . 6481 [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast 6482 Addresses", RFC 3307, DOI 10.17487/RFC3307, August 2002, 6483 . 6485 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 6486 "Introduction and Applicability Statements for Internet- 6487 Standard Management Framework", RFC 3410, 6488 DOI 10.17487/RFC3410, December 2002, 6489 . 6491 [RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network 6492 Management Workshop", RFC 3535, DOI 10.17487/RFC3535, May 6493 2003, . 6495 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 6496 CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September 6497 2003, . 6499 [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., 6500 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 6501 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 6502 RFC 3819, DOI 10.17487/RFC3819, July 2004, 6503 . 6505 [RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, 6506 DOI 10.17487/RFC4101, June 2005, 6507 . 6509 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 6510 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 6511 RFC 4915, DOI 10.17487/RFC4915, June 2007, 6512 . 6514 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 6515 Topology (MT) Routing in Intermediate System to 6516 Intermediate Systems (IS-ISs)", RFC 5120, 6517 DOI 10.17487/RFC5120, February 2008, 6518 . 6520 [RFC5184] Teraoka, F., Gogo, K., Mitsuya, K., Shibui, R., and K. 6521 Mitani, "Unified Layer 2 (L2) Abstractions for Layer 3 6522 (L3)-Driven Fast Handover", RFC 5184, 6523 DOI 10.17487/RFC5184, May 2008, 6524 . 6526 [RFC5548] Dohler, M., Ed., Watteyne, T., Ed., Winter, T., Ed., and 6527 D. Barthel, Ed., "Routing Requirements for Urban Low-Power 6528 and Lossy Networks", RFC 5548, DOI 10.17487/RFC5548, May 6529 2009, . 6531 [RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T. 6532 Phinney, "Industrial Routing Requirements in Low-Power and 6533 Lossy Networks", RFC 5673, DOI 10.17487/RFC5673, October 6534 2009, . 6536 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 6537 Management of New Protocols and Protocol Extensions", 6538 RFC 5706, DOI 10.17487/RFC5706, November 2009, 6539 . 6541 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 6542 Routing Requirements in Low-Power and Lossy Networks", 6543 RFC 5826, DOI 10.17487/RFC5826, April 2010, 6544 . 6546 [RFC5867] Martocci, J., Ed., De Mil, P., Riou, N., and W. Vermeylen, 6547 "Building Automation Routing Requirements in Low-Power and 6548 Lossy Networks", RFC 5867, DOI 10.17487/RFC5867, June 6549 2010, . 6551 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 6552 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 6553 DOI 10.17487/RFC5881, June 2010, 6554 . 6556 [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc 6557 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 6558 RFC 6130, DOI 10.17487/RFC6130, April 2011, 6559 . 6561 [6LOWPAN-ND] 6562 Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 6563 Bormann, "Neighbor Discovery Optimization for IPv6 over 6564 Low-Power Wireless Personal Area Networks (6LoWPANs)", 6565 RFC 6775, DOI 10.17487/RFC6775, November 2012, 6566 . 6568 [ROLL-TERMS] 6569 Vasseur, JP., "Terms Used in Routing for Low-Power and 6570 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 6571 2014, . 6573 [Perlman83] 6574 Perlman, R., "Fault-Tolerant Broadcast of Routing 6575 Information", North-Holland Computer Networks, Vol.7: p. 6576 395-405, December 1983. 6578 [FIPS180] National Institute of Standards and Technology, "FIPS Pub 6579 180-3, Secure Hash Standard (SHS)", US Department of 6580 Commerce , February 2008, 6581 . 6583 Appendix A. Example Operation 6585 This appendix provides some examples to illustrate the dissemination 6586 of addressing information and prefixes with RPL. The examples depict 6587 information being distributed with PIOs and RIOs and the use of DIO 6588 and DAO messages. Note that this appendix is not normative, and that 6589 the specific details of a RPL addressing plan and autoconfiguration 6590 may vary according to specific implementations. RPL merely provides 6591 a vehicle for disseminating information that may be built upon and 6592 used by other mechanisms. 6594 Note that these examples illustrate use of address autoconfiguration 6595 schemes supported by information distributed within RPL. However, if 6596 an implementation includes another address autoconfiguration scheme, 6597 RPL nodes might be configured not to set the 'A' flag in PIO options, 6598 though the PIO can still be used to distribute prefix and addressing 6599 information. 6601 A.1. Example Operation in Storing Mode with Node-Owned Prefixes 6603 Figure 32 illustrates the logical addressing architecture of a simple 6604 RPL network operating in Storing mode. In this example, each Node, 6605 A, B, C, and D, owns its own prefix and makes that prefix available 6606 for address autoconfiguration by on-link devices. (This is conveyed 6607 by setting the 'A' flag and the 'L' flag in the PIO of the DIO 6608 messages). Node A owns the prefix A::/64, Node B owns B::/64, and so 6609 on. Node B autoconfigures an on-link address with respect to Node A, 6610 A::B. Nodes C and D similarly autoconfigure on-link addresses from 6611 Node B's prefix, B::C and B::D, respectively. Nodes have the option 6612 of setting the 'R' flag and publishing their address within the 6613 Prefix field of the PIO. 6615 +-------------+ 6616 | Root | 6617 | | 6618 | Node A | 6619 | | 6620 | A::A | 6621 +------+------+ 6622 | 6623 | 6624 | 6625 +------+------+ 6626 | A::B | 6627 | | 6628 | Node B | 6629 | | 6630 | B::B | 6631 +------+------+ 6632 | 6633 | 6634 .--------------+--------------. 6635 / \ 6636 / \ 6637 +------+------+ +------+------+ 6638 | B::C | | B::D | 6639 | | | | 6640 | Node C | | Node D | 6641 | | | | 6642 | C::C | | D::D | 6643 +-------------+ +-------------+ 6645 Figure 32: Storing Mode with Node-Owned Prefixes 6647 A.1.1. DIO Messages and PIO 6649 Node A, for example, will send DIO messages with a PIO as follows: 6650 'A' flag: Set 6651 'L' flag: Set 6652 'R' flag: Clear 6653 Prefix Length: 64 6654 Prefix: A:: 6656 Node B, for example, will send DIO messages with a PIO as follows: 6657 'A' flag: Set 6658 'L' flag: Set 6659 'R' flag: Set 6660 Prefix Length: 64 6661 Prefix: B::B 6662 Node C, for example, will send DIO messages with a PIO as follows: 6663 'A' flag: Set 6664 'L' flag: Set 6665 'R' flag: Clear 6666 Prefix Length: 64 6667 Prefix: C:: 6669 Node D, for example, will send DIO messages with a PIO as follows: 6670 'A' flag: Set 6671 'L' flag: Set 6672 'R' flag: Set 6673 Prefix Length: 64 6674 Prefix: D::D 6676 A.1.2. DAO Messages 6678 Node B will send DAO messages to Node A with the following 6679 information: 6680 * Target B::/64 6681 * Target C::/64 6682 * Target D::/64 6684 Node C will send DAO messages to Node B with the following 6685 information: 6686 * Target C::/64 6688 Node D will send DAO messages to Node B with the following 6689 information: 6690 * Target D::/64 6692 A.1.3. Routing Information Base 6694 Node A will conceptually collect the following information into 6695 its Routing Information Base (RIB): 6696 * A::/64 connected 6697 * B::/64 via B's link local 6698 * C::/64 via B's link local 6699 * D::/64 via B's link local 6701 Node B will conceptually collect the following information into 6702 its RIB: 6703 * ::/0 via A's link local 6704 * B::/64 connected 6705 * C::/64 via C's link local 6706 * D::/64 via D's link local 6708 Node C will conceptually collect the following information into 6709 its RIB: 6710 * ::/0 via B's link local 6711 * C::/64 connected 6713 Node D will conceptually collect the following information into 6714 its RIB: 6715 * ::/0 via B's link local 6716 * D::/64 connected 6718 A.2. Example Operation in Storing Mode with Subnet-Wide Prefix 6720 Figure 33 illustrates the logical addressing architecture of a simple 6721 RPL network operating in Storing mode. In this example, the root 6722 Node A sources a prefix that is used for address autoconfiguration 6723 over the entire RPL subnet. (This is conveyed by setting the 'A' 6724 flag and clearing the 'L' flag in the PIO of the DIO messages.) 6725 Nodes A, B, C, and D all autoconfigure to the prefix A::/64. Nodes 6726 have the option of setting the 'R' flag and publishing their address 6727 within the Prefix field of the PIO. 6729 +-------------+ 6730 | Root | 6731 | | 6732 | Node A | 6733 | A::A | 6734 | | 6735 +------+------+ 6736 | 6737 | 6738 | 6739 +------+------+ 6740 | | 6741 | Node B | 6742 | A::B | 6743 | | 6744 +------+------+ 6745 | 6746 | 6747 .--------------+--------------. 6748 / \ 6749 / \ 6750 +------+------+ +------+------+ 6751 | | | | 6752 | Node C | | Node D | 6753 | A::C | | A::D | 6754 | | | | 6755 +-------------+ +-------------+ 6756 Figure 33: Storing Mode with Subnet-Wide Prefix 6758 A.2.1. DIO Messages and PIO 6760 Node A, for example, will send DIO messages with a PIO as follows: 6761 'A' flag: Set 6762 'L' flag: Clear 6763 'R' flag: Clear 6764 Prefix Length: 64 6765 Prefix: A:: 6767 Node B, for example, will send DIO messages with a PIO as follows: 6768 'A' flag: Set 6769 'L' flag: Clear 6770 'R' flag: Set 6771 Prefix Length: 64 6772 Prefix: A::B 6774 Node C, for example, will send DIO messages with a PIO as follows: 6775 'A' flag: Set 6776 'L' flag: Clear 6777 'R' flag: Clear 6778 Prefix Length: 64 6779 Prefix: A:: 6781 Node D, for example, will send DIO messages with a PIO as follows: 6782 'A' flag: Set 6783 'L' flag: Clear 6784 'R' flag: Set 6785 Prefix Length: 64 6786 Prefix: A::D 6788 A.2.2. DAO Messages 6790 Node B will send DAO messages to Node A with the following 6791 information: 6792 * Target A::B/128 6793 * Target A::C/128 6794 * Target A::D/128 6796 Node C will send DAO messages to Node B with the following 6797 information: 6798 * Target A::C/128 6800 Node D will send DAO messages to Node B with the following 6801 information: 6802 * Target A::D/128 6804 A.2.3. Routing Information Base 6806 Node A will conceptually collect the following information into 6807 its RIB: 6808 * A::A/128 connected 6809 * A::B/128 via B's link local 6810 * A::C/128 via B's link local 6811 * A::D/128 via B's link local 6813 Node B will conceptually collect the following information into 6814 its RIB: 6815 * ::/0 via A's link local 6816 * A::B/128 connected 6817 * A::C/128 via C's link local 6818 * A::D/128 via D's link local 6820 Node C will conceptually collect the following information into 6821 its RIB: 6822 * ::/0 via B's link local 6823 * A::C/128 connected 6825 Node D will conceptually collect the following information into 6826 its RIB: 6827 * ::/0 via B's link local 6828 * A::D/128 connected 6830 A.3. Example Operation in Non-Storing Mode with Node-Owned Prefixes 6832 Figure 34 illustrates the logical addressing architecture of a simple 6833 RPL network operating in Non-Storing mode. In this example, each 6834 Node, A, B, C, and D, owns its own prefix, and makes that prefix 6835 available for address autoconfiguration by on-link devices. (This is 6836 conveyed by setting the 'A' flag and the 'L' flag in the PIO of the 6837 DIO messages.) Node A owns the prefix A::/64, Node B owns B::/64, 6838 and so on. Node B autoconfigures an on-link address with respect to 6839 Node A, A::B. Nodes C and D similarly autoconfigure on-link 6840 addresses from Node B's prefix, B::C and B::D, respectively. Nodes 6841 have the option of setting the 'R' flag and publishing their address 6842 within the Prefix field of the PIO. 6844 +-------------+ 6845 | Root | 6846 | | 6847 | Node A | 6848 | | 6849 | A::A | 6850 +------+------+ 6851 | 6852 | 6853 | 6854 +------+------+ 6855 | A::B | 6856 | | 6857 | Node B | 6858 | | 6859 | B::B | 6860 +------+------+ 6861 | 6862 | 6863 .--------------+--------------. 6864 / \ 6865 / \ 6866 +------+------+ +------+------+ 6867 | B::C | | B::D | 6868 | | | | 6869 | Node C | | Node D | 6870 | | | | 6871 | C::C | | D::D | 6872 +-------------+ +-------------+ 6874 Figure 34: Non-Storing Mode with Node-Owned Prefixes 6876 A.3.1. DIO Messages and PIO 6878 The PIO contained in the DIO messages in the Non-Storing mode with 6879 node-owned prefixes can be considered to be identical to those in the 6880 Storing mode with node-owned prefixes case (Appendix A.1.1). 6882 A.3.2. DAO Messages 6884 Node B will send DAO messages to Node A with the following 6885 information: 6886 * Target B::/64, Transit A::B 6888 Node C will send DAO messages to Node A with the following 6889 information: 6890 * Target C::/64, Transit B::C 6892 Node D will send DAO messages to Node A with the following 6893 information: 6894 * Target D::/64, Transit B::D 6896 A.3.3. Routing Information Base 6898 Node A will conceptually collect the following information into 6899 its RIB. Note that Node A has enough information to construct 6900 source routes by doing recursive lookups into the RIB: 6901 * A::/64 connected 6902 * B::/64 via A::B 6903 * C::/64 via B::C 6904 * D::/64 via B::D 6906 Node B will conceptually collect the following information into 6907 its RIB: 6908 * ::/0 via A's link local 6909 * B::/64 connected 6911 Node C will conceptually collect the following information into 6912 its RIB: 6913 * ::/0 via B's link local 6914 * C::/64 connected 6916 Node D will conceptually collect the following information into 6917 its RIB: 6918 * ::/0 via B's link local 6919 * D::/64 connected 6921 A.4. Example Operation in Non-Storing Mode with Subnet-Wide Prefix 6923 Figure 35 illustrates the logical addressing architecture of a simple 6924 RPL network operating in Non-Storing mode. In this example, the root 6925 Node A sources a prefix that is used for address autoconfiguration 6926 over the entire RPL subnet. (This is conveyed by setting the 'A' 6927 flag and clearing the 'L' flag in the PIO of the DIO messages.) 6928 Nodes A, B, C, and D all autoconfigure to the prefix A::/64. Nodes 6929 must set the 'R' flag and publish their address within the Prefix 6930 field of the PIO, in order to inform their children which address to 6931 use in the transit option. 6933 +-------------+ 6934 | Root | 6935 | | 6936 | Node A | 6937 | A::A | 6938 | | 6939 +------+------+ 6940 | 6941 | 6942 | 6943 +------+------+ 6944 | | 6945 | Node B | 6946 | A::B | 6947 | | 6948 +------+------+ 6949 | 6950 | 6951 .--------------+--------------. 6952 / \ 6953 / \ 6954 +------+------+ +------+------+ 6955 | | | | 6956 | Node C | | Node D | 6957 | A::C | | A::D | 6958 | | | | 6959 +-------------+ +-------------+ 6961 Figure 35: Non-Storing Mode with Subnet-Wide Prefix 6963 A.4.1. DIO Messages and PIO 6965 Node A, for example, will send DIO messages with a PIO as follows: 6966 'A' flag: Set 6967 'L' flag: Clear 6968 'R' flag: Set 6969 Prefix Length: 64 6970 Prefix: A::A 6972 Node B, for example, will send DIO messages with a PIO as follows: 6973 'A' flag: Set 6974 'L' flag: Clear 6975 'R' flag: Set 6976 Prefix Length: 64 6977 Prefix: A::B 6979 Node C, for example, will send DIO messages with a PIO as follows: 6980 'A' flag: Set 6981 'L' flag: Clear 6982 'R' flag: Set 6983 Prefix Length: 64 6984 Prefix: A::C 6986 Node D, for example, will send DIO messages with a PIO as follows: 6987 'A' flag: Set 6988 'L' flag: Clear 6989 'R' flag: Set 6990 Prefix Length: 64 6991 Prefix: A::D 6993 A.4.2. DAO Messages 6995 Node B will send DAO messages to Node A with the following 6996 information: 6997 * Target A::B/128, Transit A::A 6999 Node C will send DAO messages to Node A with the following 7000 information: 7001 * Target A::C/128, Transit A::B 7003 Node D will send DAO messages to Node A with the following 7004 information: 7005 * Target A::D/128, Transit A::B 7007 A.4.3. Routing Information Base 7009 Node A will conceptually collect the following information into 7010 its RIB. Note that Node A has enough information to construct 7011 source routes by doing recursive lookups into the RIB: 7012 * A::A/128 connected 7013 * A::B/128 via A::A 7014 * A::C/128 via A::B 7015 * A::D/128 via A::B 7017 Node B will conceptually collect the following information into 7018 its RIB: 7019 * ::/0 via A's link local 7020 * A::B/128 connected 7022 Node C will conceptually collect the following information into 7023 its RIB:: 7024 * ::/0 via B's link local 7025 * A::C/128 connected 7027 Node D will conceptually collect the following information into 7028 its RIB: 7029 * ::/0 via B's link local 7030 * A::D/128 connected 7032 A.5. Example with External Prefixes 7034 Consider the simple network illustrated in Figure 36. In this 7035 example, there are a group of routers participating in a RPL network: 7036 a DODAG root, Nodes A, Y, and Z. The DODAG root and Node Z also have 7037 connectivity to different external network domains (i.e., external to 7038 the RPL network). Note that those external networks could be RPL 7039 networks or another type of network altogether. 7041 RPL Network +-------------------+ 7042 RPL::/64 | | 7043 | External | 7044 [RPL::Root] (Root)----------+ Prefix | 7045 | | EXT_1::/64 | 7046 | | | 7047 | +-------------------+ 7048 [RPL::A] (A) 7049 : 7050 : 7051 : 7052 [RPL::Y] (Y) 7053 | +-------------------+ 7054 | | | 7055 | | External | 7056 [RPL::Z] (Z)------------+ Prefix | 7057 : | EXT_2::/64 | 7058 : | | 7059 : +-------------------+ 7061 Figure 36: Simple Network Example 7063 In this example, the DODAG root makes a prefix available to the RPL 7064 subnet for address autoconfiguration. Here, the entire RPL subnet 7065 uses that same prefix, RPL::/64, for address autoconfiguration, 7066 though in other implementations more complex/hybrid schemes could be 7067 employed. 7069 The DODAG root has connectivity to an external (with respect to that 7070 RPL network) prefix EXT_1::/64. The DODAG root may have learned of 7071 connectivity to this prefix, for example, via explicit configuration 7072 or IPv6 ND on a non-RPL interface. The DODAG root is configured to 7073 announce information on the connectivity to this prefix. 7075 Similarly, Node Z has connectivity to an external prefix EXT_2::/64. 7076 Node Z also has a sub-DODAG underneath of it. 7078 1. The DODAG root adds a RIO to its DIO messages. The RIO contains 7079 the external prefix EXT_1::/64. This information may be repeated 7080 in the DIO messages emitted by the other nodes within the DODAG. 7081 Thus, the reachability to the prefix EXT_1::/64 is disseminated 7082 down the DODAG. 7084 2. Node Z may advertise reachability to the Target network 7085 EXT_2::/64 by sending DAO messages using EXT_2::/64 as a Target 7086 in the Target option and itself (Node Z) as a parent in the 7087 Transit Information option. (In Storing mode, that Transit 7088 Information option does not need to contain the address of Node 7089 Z). A non-storing root then becomes aware of the 1-hop link 7090 (Node Z -- EXT_2::/64) for use in constructing source routes. 7091 Node Z may additionally advertise its reachability to EXT_2::/64 7092 to nodes in its sub-DODAG by sending DIO messages with a PIO, 7093 with the 'A' flag cleared. 7095 Authors' Addresses 7097 Pascal Thubert (editor) 7098 Cisco Systems, Inc 7099 Building D 7100 45 Allee des Ormes - BP1200 7101 06254 MOUGINS - Sophia Antipolis 7102 France 7104 Phone: +33 497 23 26 34 7105 Email: pthubert@cisco.com 7107 Tim Winter (editor) 7109 Email: wintert@acm.org