idnits 2.17.00 (12 Aug 2021) /tmp/idnits36647/draft-ietf-roll-rpl-16.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 8, 2010) is 4182 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) == Unused Reference: 'I-D.ietf-manet-nhdp' is defined on line 6215, but no explicit reference was found in the text == Outdated reference: draft-ietf-6man-rpl-option has been published as RFC 6553 == Outdated reference: draft-ietf-6man-rpl-routing-header has been published as RFC 6554 == Outdated reference: draft-ietf-roll-routing-metrics has been published as RFC 6551 == Outdated reference: draft-ietf-roll-trickle has been published as RFC 6206 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: draft-ietf-manet-nhdp has been published as RFC 6130 == Outdated reference: draft-ietf-roll-of0 has been published as RFC 6552 == Outdated reference: draft-ietf-roll-terminology has been published as RFC 7102 Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROLL T. Winter, Ed. 3 Internet-Draft 4 Intended status: Standards Track P. Thubert, Ed. 5 Expires: June 11, 2011 Cisco Systems 6 A. Brandt 7 Sigma Designs 8 T. Clausen 9 LIX, Ecole Polytechnique 10 J. Hui 11 Arch Rock Corporation 12 R. Kelsey 13 Ember Corporation 14 P. Levis 15 Stanford University 16 K. Pister 17 Dust Networks 18 R. Struik 20 JP. Vasseur 21 Cisco Systems 22 December 8, 2010 24 RPL: IPv6 Routing Protocol for Low power and Lossy Networks 25 draft-ietf-roll-rpl-16 27 Abstract 29 Low power and Lossy Networks (LLNs) are a class of network in which 30 both the routers and their interconnect are constrained. LLN routers 31 typically operate with constraints on processing power, memory, and 32 energy (battery power). Their interconnects are characterized by 33 high loss rates, low data rates, and instability. LLNs are comprised 34 of anything from a few dozen and up to thousands of routers. 35 Supported traffic flows include point-to-point (between devices 36 inside the LLN), point-to-multipoint (from a central control point to 37 a subset of devices inside the LLN), and multipoint-to-point (from 38 devices inside the LLN towards a central control point). This 39 document specifies the IPv6 Routing Protocol for LLNs (RPL), which 40 provides a mechanism whereby multipoint-to-point traffic from devices 41 inside the LLN towards a central control point, as well as point-to- 42 multipoint traffic from the central control point to the devices 43 inside the LLN, is supported. Support for point-to-point traffic is 44 also available. 46 Status of this Memo 48 This Internet-Draft is submitted in full conformance with the 49 provisions of BCP 78 and BCP 79. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF). Note that other groups may also distribute 53 working documents as Internet-Drafts. The list of current Internet- 54 Drafts is at http://datatracker.ietf.org/drafts/current/. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 This Internet-Draft will expire on June 11, 2011. 63 Copyright Notice 65 Copyright (c) 2010 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (http://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the Simplified BSD License. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8 81 1.1. Design Principles . . . . . . . . . . . . . . . . . . . 8 82 1.2. Expectations of Link Layer Type . . . . . . . . . . . . 10 83 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 14 85 3.1. Topology . . . . . . . . . . . . . . . . . . . . . . . . 14 86 3.1.1. Constructing Topologies . . . . . . . . . . . . . . . 14 87 3.1.2. RPL Identifiers . . . . . . . . . . . . . . . . . . . 14 88 3.1.3. Instances, DODAGs, and DODAG Versions . . . . . . . . 15 89 3.2. Upward Routes and DODAG Construction . . . . . . . . . . 17 90 3.2.1. Objective Function (OF) . . . . . . . . . . . . . . . 17 91 3.2.2. DODAG Repair . . . . . . . . . . . . . . . . . . . . 17 92 3.2.3. Security . . . . . . . . . . . . . . . . . . . . . . 18 93 3.2.4. Grounded and Floating DODAGs . . . . . . . . . . . . 18 94 3.2.5. Local DODAGs . . . . . . . . . . . . . . . . . . . . 18 95 3.2.6. Administrative Preference . . . . . . . . . . . . . . 19 96 3.2.7. Datapath Validation and Loop Detection . . . . . . . 19 97 3.2.8. Distributed Algorithm Operation . . . . . . . . . . . 19 98 3.3. Downward Routes and Destination Advertisement . . . . . 20 99 3.4. Local DODAGs Route Discovery . . . . . . . . . . . . . . 20 100 3.5. Rank Properties . . . . . . . . . . . . . . . . . . . . 20 101 3.5.1. Rank Comparison (DAGRank()) . . . . . . . . . . . . . 21 102 3.5.2. Rank Relationships . . . . . . . . . . . . . . . . . 22 103 3.6. Routing Metrics and Constraints Used By RPL . . . . . . 23 104 3.7. Loop Avoidance . . . . . . . . . . . . . . . . . . . . . 24 105 3.7.1. Greediness and Instability . . . . . . . . . . . . . 24 106 3.7.2. DODAG Loops . . . . . . . . . . . . . . . . . . . . . 26 107 3.7.3. DAO Loops . . . . . . . . . . . . . . . . . . . . . . 27 108 4. Traffic Flows Supported by RPL . . . . . . . . . . . . . . . 28 109 4.1. Multipoint-to-Point Traffic . . . . . . . . . . . . . . 28 110 4.2. Point-to-Multipoint Traffic . . . . . . . . . . . . . . 28 111 4.3. Point-to-Point Traffic . . . . . . . . . . . . . . . . . 28 112 5. RPL Instance . . . . . . . . . . . . . . . . . . . . . . . . 29 113 5.1. RPL Instance ID . . . . . . . . . . . . . . . . . . . . 29 114 6. ICMPv6 RPL Control Message . . . . . . . . . . . . . . . . . 31 115 6.1. RPL Security Fields . . . . . . . . . . . . . . . . . . 33 116 6.2. DODAG Information Solicitation (DIS) . . . . . . . . . . 38 117 6.2.1. Format of the DIS Base Object . . . . . . . . . . . . 38 118 6.2.2. Secure DIS . . . . . . . . . . . . . . . . . . . . . 38 119 6.2.3. DIS Options . . . . . . . . . . . . . . . . . . . . . 38 120 6.3. DODAG Information Object (DIO) . . . . . . . . . . . . . 38 121 6.3.1. Format of the DIO Base Object . . . . . . . . . . . . 39 122 6.3.2. Secure DIO . . . . . . . . . . . . . . . . . . . . . 41 123 6.3.3. DIO Options . . . . . . . . . . . . . . . . . . . . . 41 124 6.4. Destination Advertisement Object (DAO) . . . . . . . . . 41 125 6.4.1. Format of the DAO Base Object . . . . . . . . . . . . 41 126 6.4.2. Secure DAO . . . . . . . . . . . . . . . . . . . . . 43 127 6.4.3. DAO Options . . . . . . . . . . . . . . . . . . . . . 43 128 6.5. Destination Advertisement Object Acknowledgement 129 (DAO-ACK) . . . . . . . . . . . . . . . . . . . . . . . 43 130 6.5.1. Format of the DAO-ACK Base Object . . . . . . . . . . 43 131 6.5.2. Secure DAO-ACK . . . . . . . . . . . . . . . . . . . 45 132 6.5.3. DAO-ACK Options . . . . . . . . . . . . . . . . . . . 45 133 6.6. Consistency Check (CC) . . . . . . . . . . . . . . . . . 45 134 6.6.1. Format of the CC Base Object . . . . . . . . . . . . 45 135 6.6.2. CC Options . . . . . . . . . . . . . . . . . . . . . 46 136 6.7. RPL Control Message Options . . . . . . . . . . . . . . 46 137 6.7.1. RPL Control Message Option Generic Format . . . . . . 46 138 6.7.2. Pad1 . . . . . . . . . . . . . . . . . . . . . . . . 47 139 6.7.3. PadN . . . . . . . . . . . . . . . . . . . . . . . . 48 140 6.7.4. Metric Container . . . . . . . . . . . . . . . . . . 48 141 6.7.5. Route Information . . . . . . . . . . . . . . . . . . 49 142 6.7.6. DODAG Configuration . . . . . . . . . . . . . . . . . 51 143 6.7.7. RPL Target . . . . . . . . . . . . . . . . . . . . . 53 144 6.7.8. Transit Information . . . . . . . . . . . . . . . . . 54 145 6.7.9. Solicited Information . . . . . . . . . . . . . . . . 57 146 6.7.10. Prefix Information . . . . . . . . . . . . . . . . . 59 147 6.7.11. RPL Target Descriptor . . . . . . . . . . . . . . . . 61 148 7. Sequence Counters . . . . . . . . . . . . . . . . . . . . . . 63 149 7.1. Sequence Counter Overview . . . . . . . . . . . . . . . 63 150 7.2. Sequence Counter Operation . . . . . . . . . . . . . . . 64 151 8. Upward Routes . . . . . . . . . . . . . . . . . . . . . . . . 66 152 8.1. DIO Base Rules . . . . . . . . . . . . . . . . . . . . . 66 153 8.2. Upward Route Discovery and Maintenance . . . . . . . . . 67 154 8.2.1. Neighbors and Parents within a DODAG Version . . . . 67 155 8.2.2. Neighbors and Parents across DODAG Versions . . . . . 68 156 8.2.3. DIO Message Communication . . . . . . . . . . . . . . 73 157 8.3. DIO Transmission . . . . . . . . . . . . . . . . . . . . 73 158 8.3.1. Trickle Parameters . . . . . . . . . . . . . . . . . 74 159 8.4. DODAG Selection . . . . . . . . . . . . . . . . . . . . 74 160 8.5. Operation as a Leaf Node . . . . . . . . . . . . . . . . 75 161 8.6. Administrative Rank . . . . . . . . . . . . . . . . . . 76 162 9. Downward Routes . . . . . . . . . . . . . . . . . . . . . . . 77 163 9.1. Destination Advertisement Parents . . . . . . . . . . . 77 164 9.2. Downward Route Discovery and Maintenance . . . . . . . . 78 165 9.2.1. Maintenance of Path Sequence . . . . . . . . . . . . 79 166 9.2.2. Generation of DAO Messages . . . . . . . . . . . . . 79 167 9.3. DAO Base Rules . . . . . . . . . . . . . . . . . . . . . 80 168 9.4. Structure of DAO Messages . . . . . . . . . . . . . . . 80 169 9.5. DAO Transmission Scheduling . . . . . . . . . . . . . . 82 170 9.6. Triggering DAO Messages . . . . . . . . . . . . . . . . 83 171 9.7. Non-storing Mode . . . . . . . . . . . . . . . . . . . . 84 172 9.8. Storing Mode . . . . . . . . . . . . . . . . . . . . . . 85 173 9.9. Path Control . . . . . . . . . . . . . . . . . . . . . . 85 174 9.9.1. Path Control Example . . . . . . . . . . . . . . . . 87 175 9.10. Multicast Destination Advertisement Messages . . . . . . 89 176 10. Security Mechanisms . . . . . . . . . . . . . . . . . . . . . 90 177 10.1. Security Overview . . . . . . . . . . . . . . . . . . . 90 178 10.2. Joining a Secure Network . . . . . . . . . . . . . . . . 91 179 10.3. Installing Keys . . . . . . . . . . . . . . . . . . . . 92 180 10.4. Consistency Checks . . . . . . . . . . . . . . . . . . . 92 181 10.5. Counters . . . . . . . . . . . . . . . . . . . . . . . . 93 182 10.6. Transmission of Outgoing Packets . . . . . . . . . . . . 94 183 10.7. Reception of Incoming Packets . . . . . . . . . . . . . 95 184 10.7.1. Timestamp Key Checks . . . . . . . . . . . . . . . . 96 185 10.8. Coverage of Integrity and Confidentiality . . . . . . . 97 186 10.9. Cryptographic Mode of Operation . . . . . . . . . . . . 97 187 10.9.1. Nonce . . . . . . . . . . . . . . . . . . . . . . . . 97 188 10.9.2. Signatures . . . . . . . . . . . . . . . . . . . . . 98 189 11. Packet Forwarding and Loop Avoidance/Detection . . . . . . . 100 190 11.1. Suggestions for Packet Forwarding . . . . . . . . . . . 100 191 11.2. Loop Avoidance and Detection . . . . . . . . . . . . . . 101 192 11.2.1. Source Node Operation . . . . . . . . . . . . . . . . 102 193 11.2.2. Router Operation . . . . . . . . . . . . . . . . . . 102 194 12. Multicast Operation . . . . . . . . . . . . . . . . . . . . . 105 195 13. Maintenance of Routing Adjacency . . . . . . . . . . . . . . 107 196 14. Guidelines for Objective Functions . . . . . . . . . . . . . 108 197 14.1. Objective Function Behavior . . . . . . . . . . . . . . 108 198 15. Suggestions for Interoperation with Neighbor Discovery . . . 110 199 16. RPL Constants and Variables . . . . . . . . . . . . . . . . . 111 200 17. Manageability Considerations . . . . . . . . . . . . . . . . 113 201 17.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 113 202 17.2. Configuration Management . . . . . . . . . . . . . . . . 114 203 17.2.1. Initialization Mode . . . . . . . . . . . . . . . . . 114 204 17.2.2. DIO and DAO Base Message and Options Configuration . 115 205 17.2.3. Protocol Parameters to be configured on every 206 router in the LLN . . . . . . . . . . . . . . . . . . 115 207 17.2.4. Protocol Parameters to be configured on every 208 non-DODAG-root router in the LLN . . . . . . . . . . 116 209 17.2.5. Parameters to be configured on the DODAG root . . . . 116 210 17.2.6. Configuration of RPL Parameters related to 211 DAO-based mechanisms . . . . . . . . . . . . . . . . 117 212 17.2.7. Configuration of RPL Parameters related to 213 Security mechanisms . . . . . . . . . . . . . . . . . 118 214 17.2.8. Default Values . . . . . . . . . . . . . . . . . . . 119 215 17.3. Monitoring of RPL Operation . . . . . . . . . . . . . . 119 216 17.3.1. Monitoring a DODAG parameters . . . . . . . . . . . . 119 217 17.3.2. Monitoring a DODAG inconsistencies and loop 218 detection . . . . . . . . . . . . . . . . . . . . . . 120 219 17.4. Monitoring of the RPL data structures . . . . . . . . . 121 220 17.4.1. Candidate Neighbor Data Structure . . . . . . . . . . 121 221 17.4.2. Destination Oriented Directed Acyclic Graph (DAG) 222 Table . . . . . . . . . . . . . . . . . . . . . . . . 121 223 17.4.3. Routing Table and DAO Routing Entries . . . . . . . . 122 224 17.5. Fault Management . . . . . . . . . . . . . . . . . . . . 123 225 17.6. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 123 226 17.7. Fault Isolation . . . . . . . . . . . . . . . . . . . . 124 227 17.8. Impact on Other Protocols . . . . . . . . . . . . . . . 125 228 17.9. Performance Management . . . . . . . . . . . . . . . . . 125 229 17.10. Diagnostics . . . . . . . . . . . . . . . . . . . . . . 125 230 18. Security Considerations . . . . . . . . . . . . . . . . . . . 126 231 18.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 126 232 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 128 233 19.1. RPL Control Message . . . . . . . . . . . . . . . . . . 128 234 19.2. New Registry for RPL Control Codes . . . . . . . . . . . 128 235 19.3. New Registry for the Mode of Operation (MOP) . . . . . . 129 236 19.4. RPL Control Message Option . . . . . . . . . . . . . . . 130 237 19.5. Objective Code Point (OCP) Registry . . . . . . . . . . 130 238 19.6. New Registry for the Security Section Algorithm . . . . 131 239 19.7. New Registry for the Security Section Flags . . . . . . 131 240 19.8. New Registry for Per-KIM Security Levels . . . . . . . . 132 241 19.9. New Registry for the DIS (DODAG Informational 242 Solicitation) Flags . . . . . . . . . . . . . . . . . . 133 243 19.10. New Registry for the DODAG Information Object (DIO) 244 Flags . . . . . . . . . . . . . . . . . . . . . . . . . 134 245 19.11. New Registry for the Destination Advertisement Object 246 (DAO) Flags . . . . . . . . . . . . . . . . . . . . . . 134 247 19.12. New Registry for the Destination Advertisement Object 248 (DAO) Acknowledgement Flags . . . . . . . . . . . . . . 135 249 19.13. New Registry for the Consistency Check (CC) Flags . . . 135 250 19.14. New Registry for the DODAG Configuration Option Flags . 136 251 19.15. New Registry for the RPL Target Option Flags . . . . . . 136 252 19.16. New Registry for the Transit Information Option Flags . 137 253 19.17. New Registry for the Solicited Information Option 254 Flags . . . . . . . . . . . . . . . . . . . . . . . . . 137 255 19.18. ICMPv6: Error in Source Routing Header . . . . . . . . . 138 256 19.19. Link-Local Scope multicast address . . . . . . . . . . . 138 257 20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 139 258 21. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 140 259 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 141 260 22.1. Normative References . . . . . . . . . . . . . . . . . . 141 261 22.2. Informative References . . . . . . . . . . . . . . . . . 142 262 Appendix A. Example Operation . . . . . . . . . . . . . . . . . 145 263 A.1. Example with External Prefixes . . . . . . . . . . . . . 145 264 A.2. Example Operation in Storing Mode With Node-owned 265 Prefixes . . . . . . . . . . . . . . . . . . . . . . . . 147 266 A.2.1. DIO messages and PIO . . . . . . . . . . . . . . . . 148 267 A.2.2. DAO messages . . . . . . . . . . . . . . . . . . . . 148 268 A.2.3. Routing Information Base . . . . . . . . . . . . . . 149 269 A.3. Example Operation in Storing Mode With Subnet-wide 270 Prefix . . . . . . . . . . . . . . . . . . . . . . . . . 149 271 A.3.1. DIO messages and PIO . . . . . . . . . . . . . . . . 150 272 A.3.2. DAO messages . . . . . . . . . . . . . . . . . . . . 151 273 A.3.3. Routing Information Base . . . . . . . . . . . . . . 151 274 A.4. Example Operation in Non-Storing Mode With Node-owned 275 Prefixes . . . . . . . . . . . . . . . . . . . . . . . . 152 276 A.4.1. DIO messages and PIO . . . . . . . . . . . . . . . . 153 277 A.4.2. DAO messages . . . . . . . . . . . . . . . . . . . . 153 278 A.4.3. Routing Information Base . . . . . . . . . . . . . . 154 279 A.5. Example Operation in Non-Storing Mode With 280 Subnet-wide Prefix . . . . . . . . . . . . . . . . . . . 154 281 A.5.1. DIO messages and PIO . . . . . . . . . . . . . . . . 155 282 A.5.2. DAO messages . . . . . . . . . . . . . . . . . . . . 156 283 A.5.3. Routing Information Base . . . . . . . . . . . . . . 156 284 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 158 286 1. Introduction 288 Low power and Lossy Networks (LLNs) consist of largely of constrained 289 nodes (with limited processing power, memory, and sometimes energy 290 when they are battery operated or energy scavenging). These routers 291 are interconnected by lossy links, typically supporting only low data 292 rates, that are usually unstable with relatively low packet delivery 293 rates. Another characteristic of such networks is that the traffic 294 patterns are not simply point-to-point, but in many cases point-to- 295 multipoint or multipoint-to-point. Furthermore such networks may 296 potentially comprise up to thousands of nodes. These characteristics 297 offer unique challenges to a routing solution: the IETF ROLL Working 298 Group has defined application-specific routing requirements for a Low 299 power and Lossy Network (LLN) routing protocol, specified in 300 [RFC5867], [RFC5826], [RFC5673], and [RFC5548]. 302 This document specifies the IPv6 Routing Protocol for Low power and 303 lossy networks (RPL). Note that although RPL was specified according 304 to the requirements set forth in the aforementioned requirement 305 documents, its use is in no way limited to these applications. 307 1.1. Design Principles 309 RPL was designed with the objective to meet the requirements spelled 310 out in [RFC5867], [RFC5826], [RFC5673], and [RFC5548]. 312 A network may run multiple instances of RPL concurrently. Each such 313 instance may serve different and potentially antagonistic constraints 314 or performance criteria. This document defines how a single instance 315 operates. 317 In order to be useful in a wide range of LLN application domains, RPL 318 separates packet processing and forwarding from the routing 319 optimization objective. Examples of such objectives include 320 minimizing energy, minimizing latency, or satisfying constraints. 321 This document describes the mode of operation of RPL. Other 322 companion documents specify routing objective functions. A RPL 323 implementation, in support of a particular LLN application, will 324 include the necessary objective function(s) as required by the 325 application. 327 RPL operations require bidirectional links. It is required that the 328 reachability of a router is verified before the router can be used as 329 a parent. RPL expects an external mechanism to be triggered during 330 the parent selection phase in order to verify link properties and 331 neighbor reachability. Neighbor Unreachability Detection (NUD) is 332 such a mechanism, but alternates are possible, including 333 Bidirectional Forwarding Detection [RFC5881] and hints from lower 334 layers via L2 triggers like [RFC5184]. In a general fashion, a 335 detection mechanism that is reactive to traffic is favored in order 336 to minimize the cost of monitoring links that are not being used. 338 RPL also expects an external mechanism to access and transport some 339 control information, referred to as the "RPL Packet Information", in 340 data packets. The RPL Packet Information is defined in Section 11.2 341 and enables the association of a data packet with a RPL instance and 342 the validation of RPL routing states. The IPv6 Hop-by-Hop RPL Option 343 [I-D.ietf-6man-rpl-option] is an example of such mechanism. The 344 mechanism is required for all packets except when strict source 345 routing is used (that is for packets going downward in non-storing 346 mode as detailed further in Section 9), which by nature prevents 347 endless loops and alleviates the need for the RPL Packet Information. 348 Future companion specifications may propose alternate ways to carry 349 the RPL Packet Information in the IPv6 packets and may extend the RPL 350 Packet Information to support additional features. 352 RPL provides a mechanism to disseminate information over the 353 dynamically-formed network topology. The dissemination enables 354 minimal configuration in the nodes, allowing nodes to operate mostly 355 autonomously. This mechanism uses trickle [I-D.ietf-roll-trickle] to 356 optimize the dissemination as described in Section 8.3. 358 In some applications, RPL assembles topologies of routers that own 359 independent prefixes. Those prefixes may or may not be aggregatable 360 depending on the origin of the routers. A prefix that is owned by a 361 router is advertised as on-link. 363 RPL also introduces the capability to bind a subnet together with a 364 common prefix and to route within that subnet. A source can inject 365 information about the subnet to be disseminated by RPL, and that 366 source is authoritative for that subnet. Because many LLN links have 367 non-transitive properties, a common prefix that RPL disseminates over 368 the subnet must not be advertised as on-link. 370 RPL may in particular disseminate IPv6 Neighbor Discovery (ND) 371 information such as the [RFC4861] Prefix Information Option (PIO) and 372 the [RFC4191] Route Information Option (RIO). ND information that is 373 disseminated by RPL conserves all its original semantics for router 374 to host, with limited extensions for router to router, though it is 375 not to be confused with routing advertisements and it is never to be 376 directly redistributed in another routing protocol. A RPL node often 377 combines host and router behaviors. As a host, it will process the 378 options as specified in [RFC4191], [RFC4861], [RFC4862] and 379 [RFC3775]. As a router, the RPL node may advertise the information 380 from the options as required for the specific link, for instance in a 381 ND RA message, though the exact operation 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 410 [I-D.ietf-roll-terminology], and introduces the following 411 terminology: 413 DAG: Directed Acyclic Graph. A directed graph having the property 414 that all edges are oriented in such a way that no cycles exist. 415 All edges are contained in paths oriented toward and 416 terminating at one or more root nodes. 418 DAG root: A DAG root is a node within the DAG that has no outgoing 419 edge. Because the graph is acyclic, by definition all DAGs 420 must have at least one DAG root and all paths terminate at a 421 DAG root. 423 Destination Oriented DAG (DODAG): A DAG rooted at a single 424 destination, i.e. at a single DAG root (the DODAG root) with no 425 outgoing edges. 427 DODAG root: A DODAG root is the DAG root of a DODAG. The DODAG root 428 may act as a border router for the DODAG, and in particular it 429 may aggregate routes in the DODAG, and may redistribute DODAG 430 routes into other routing protocols. 432 Virtual DODAG root: A Virtual DODAG root is the result of two or 433 more RPL routers, for instance 6LoWPAN Border Routers (6LBRs), 434 coordinating to synchronize DODAG state and act in concert as 435 if they are a single DODAG root (with multiple interfaces), 436 with respect to the LLN. The coordination most likely occurs 437 between powered devices over a reliable transit link, and the 438 details of that scheme are out of scope for this specification 439 (to be defined in future companion specifications). 441 Up: Up refers to the direction from leaf nodes towards DODAG roots, 442 following DODAG edges. This follows the common terminology 443 used in graphs and depth-first-search, where vertices further 444 from the root are "deeper," or "down," and vertices closer to 445 the root are "shallower," or "up". 447 Down: Down refers to the direction from DODAG roots towards leaf 448 nodes, in the reverse direction of DODAG edges. This follows 449 the common terminology used in graphs and depth-first-search, 450 where vertices further from the root are "deeper," or "down," 451 and vertices closer to the root are "shallower," or "up". 453 Rank: A node's Rank defines the node's individual position relative 454 to other nodes with respect to a DODAG root. Rank strictly 455 increases in the Down direction and strictly decreases in the 456 Up direction. The exact way Rank is computed depends on the 457 DAG's Objective Function (OF). The Rank may analogously track 458 a simple topological distance, may be calculated as a function 459 of link metrics, and may consider other properties such as 460 constraints. 462 Objective Function (OF): Defines how routing metrics, optimization 463 objectives, and related functions are used to compute Rank. 464 Furthermore, the OF dictates how parents in the DODAG are 465 selected and thus the DODAG formation. 467 Objective Code Point (OCP): An identifier that indicates which 468 Objective Function the DODAG uses. 470 RPLInstanceID: A unique identifier within a network. DODAGs with 471 the same RPLInstanceID share the same Objective Function. 473 RPL Instance: A set of one or more DODAGs that share a 474 RPLInstanceID. A RPL node can belong to at most one DODAG in a 475 RPL Instance. Each RPL Instance operates independently of 476 other RPL Instances. This document describes operation within 477 a single RPL Instance. 479 DODAGID: The identifier of a DODAG root. The DODAGID is unique 480 within the scope of a RPL Instance in the LLN. The tuple 481 (RPLInstanceID, DODAGID) uniquely identifies a DODAG. 483 DODAG Version: A specific iteration ("Version") of a DODAG with a 484 given DODAGID. 486 DODAGVersionNumber: A sequential counter that is incremented by the 487 root to form a new Version of a DODAG. A DODAG Version is 488 identified uniquely by the (RPLInstanceID, DODAGID, 489 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 if the Goal can be 494 satisfied or not. 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 to be connected to a 498 specific 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 allows that single root node to allocate and manage a RPL 520 Instance, identified by a local RPLInstanceID, without 521 coordination with other nodes. This is typically done in order 522 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. Topology 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 a predefined 557 topologies, for example those imposed by point to point wires, so RPL 558 has to discover links and then select peers sparingly. 560 Because in many cases layer 2 ranges overlap only partially, RPL 561 forms non-transitive/NBMA network topologies upon which it computes 562 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 o 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 o 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 o 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 o 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 may coordinate over a network that is not 604 necessarily as constrained as a LLN. 606 A RPL Instance may comprise: 608 o 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 o 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 o 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 a 6LowPAN application, that 628 are capable to act as logically equivalent interfaces to the 629 sink of the same DODAG. 631 o a combination of the above as suited to some application scenario. 633 Each RPL packet is associated with a particular RPLInstanceID (see 634 Section 11.2) and therefore RPL Instance (Section 5). The 635 provisioning or automated discovery of a mapping between a 636 RPLInstanceID and a type or service of application traffic is out of 637 scope for this specification (to be defined in future companion 638 specifications). 640 Figure 1 depicts an example of a RPL Instance comprising three DODAGs 641 with DODAG Roots R1, R2, and R3. Each of these DODAG Roots 642 advertises the same RPLInstanceID. The lines depict connectivity 643 between parents and children. 645 Figure 2 depicts how a DODAG Version number increment leads to a new 646 DODAG Version. This depiction illustrates a DODAG Version number 647 increment that results in a different DODAG topology. Note that a 648 new DODAG Version does not always imply a different DODAG topology. 649 To accommodate certain topology changes requires a new DODAG Version, 650 as described later in this specification. 652 Please note that in the following examples tree-like structures are 653 depicted for simplicity, although the DODAG structure allows for each 654 node to have multiple parents when the connectivity supports it. 656 +----------------------------------------------------------------+ 657 | | 658 | +--------------+ | 659 | | | | 660 | | (R1) | (R2) (R3) | 661 | | / \ | /| \ / | \ | 662 | | / \ | / | \ / | \ | 663 | | (A) (B) | (C) | (D) ... (F) (G) (H) | 664 | | /|\ |\ | / | / |\ |\ | | | 665 | | : : : : : | : (E) : : : `: : | 666 | | | / \ | 667 | +--------------+ : : | 668 | DODAG | 669 | | 670 +----------------------------------------------------------------+ 671 RPL Instance 673 Figure 1: RPL Instance 675 +----------------+ +----------------+ 676 | | | | 677 | (R1) | | (R1) | 678 | / \ | | / | 679 | / \ | | / | 680 | (A) (B) | \ | (A) | 681 | /|\ / |\ | ------\ | /|\ | 682 | : : (C) : : | \ | : : (C) | 683 | | / | \ | 684 | | ------/ | \ | 685 | | / | (B) | 686 | | | |\ | 687 | | | : : | 688 | | | | 689 +----------------+ +----------------+ 690 Version N Version N+1 692 Figure 2: DODAG Version 694 3.2. Upward Routes and DODAG Construction 696 RPL provisions routes Up towards DODAG roots, forming a DODAG 697 optimized according to an Objective Function (OF). RPL nodes 698 construct and maintain these DODAGs through DODAG Information Object 699 (DIO) messages. 701 3.2.1. Objective Function (OF) 703 The Objective Function (OF) defines how RPL nodes select and optimize 704 routes within a RPL Instance. The OF is identified by an Objective 705 Code Point (OCP) within the DIO Configuration option. An OF defines 706 how nodes translate one or more metrics and constraints, which are 707 themselves defined in [I-D.ietf-roll-routing-metrics], into a value 708 called Rank, which approximates the node's distance from a DODAG 709 root. An OF also defines how nodes select parents. Further details 710 may be found in Section 14, [I-D.ietf-roll-routing-metrics], 711 [I-D.ietf-roll-of0], and related companion specifications. 713 3.2.2. DODAG Repair 715 A DODAG Root institutes a global repair operation by incrementing the 716 DODAG Version Number. This initiates a new DODAG Version. Nodes in 717 the new DODAG Version can choose a new position whose Rank is not 718 constrained by their Rank within the old DODAG Version. 720 RPL also supports mechanisms which may be used for local repair 721 within the DODAG Version. The DIO message specifies the necessary 722 parameters as configured from and controlled by policy at the DODAG 723 root. 725 3.2.3. Security 727 RPL supports message confidentiality and integrity. It is designed 728 such that link-layer mechanisms can be used when available and 729 appropriate, yet in their absence RPL can use its own mechanisms. 730 RPL has three basic security modes. 732 In the first, called "unsecured," RPL control messages are sent 733 without any additional security mechanisms. Unsecured mode does not 734 imply that the RPL network is unsecure: it could be using other 735 present security primitives (e.g. link-layer security) to meet 736 application security requirements. 738 In the second, called "pre-installed," nodes joining a RPL Instance 739 have pre-installed keys that enable them to process and generate 740 secured RPL messages. 742 The third mode is called "authenticated." In authenticated mode, 743 nodes have pre-installed keys as in pre-installed mode, but the pre- 744 installed key may only be used to join a RPL Instance as a leaf. 745 Joining an authenticated RPL Instance as a router requires obtaining 746 a key from an authentication authority. The process by which this 747 key is obtained is out of scope for this specification. Note that 748 this specification alone does not provide sufficient detail for a RPL 749 implementation to securely operate in authenticated mode. For a RPL 750 implementation to operate securely in authenticated mode it is 751 necessary for a future companion specification to detail the 752 mechanisms by which a node obtains/requests the authentication 753 material (e.g. key, certificate), and to determine from where that 754 material should be obtained. See also Section 10.3. 756 3.2.4. Grounded and Floating DODAGs 758 DODAGs can be grounded or floating: the DODAG root advertises which 759 is the case. A grounded DODAG offers connectivity to hosts that are 760 required for satisfying the application-defined goal. A floating 761 DODAG is not expected to satisfy the goal and in most cases only 762 provides routes to nodes within the DODAG. Floating DODAGs may be 763 used, for example, to preserve inner connectivity during repair. 765 3.2.5. Local DODAGs 767 RPL nodes can optimize routes to a destination within an LLN by 768 forming a local DODAG whose DODAG Root is the desired destination. 769 Unlike global DAGs, which can consist of multiple DODAGs, local DAGs 770 have one and only one DODAG and therefore one DODAG Root. Local 771 DODAGs can be constructed on-demand. 773 3.2.6. Administrative Preference 775 An implementation/deployment may specify that some DODAG roots should 776 be used over others through an administrative preference. 777 Administrative preference offers a way to control traffic and 778 engineer DODAG formation in order to better support application 779 requirements or needs. 781 3.2.7. Datapath Validation and Loop Detection 783 The low-power and lossy nature of LLNs motivates RPL's use of on- 784 demand loop detection using data packets. Because data traffic can 785 be infrequent, maintaining a routing topology that is constantly up 786 to date with the physical topology can waste energy. Typical LLNs 787 exhibit variations in physical connectivity that are transient and 788 innocuous to traffic, but that would be costly to track closely from 789 the control plane. Transient and infrequent changes in connectivity 790 need not be addressed by RPL until there is data to send. This 791 aspect of RPL's design draws from existing, highly used LLN protocols 792 as well as extensive experimental and deployment evidence on its 793 efficacy. 795 The RPL Packet Information that is transported with data packets 796 includes the Rank of the transmitter. An inconsistency between the 797 routing decision for a packet (upward or downward) and the Rank 798 relationship between the two nodes indicates a possible loop. On 799 receiving such a packet, a node institutes a local repair operation. 801 For example, if a node receives a packet flagged as moving in the 802 upward direction, and if that packet records that the transmitter is 803 of a lower (lesser) Rank than the receiving node, then the receiving 804 node is able to conclude that the packet has not progressed in the 805 upward direction and that the DODAG is inconsistent. 807 3.2.8. Distributed Algorithm Operation 809 A high level overview of the distributed algorithm, which constructs 810 the DODAG, is as follows: 812 o Some nodes are configured to be DODAG roots, with associated DODAG 813 configurations. 815 o Nodes advertise their presence, affiliation with a DODAG, routing 816 cost, and related metrics by sending link-local multicast DIO 817 messages to all-RPL-nodes. 819 o Nodes listen for DIOs and use their information to join a new 820 DODAG (thus selecting DODAG parents), or to maintain an existing 821 DODAG, according to the specified Objective Function and Rank of 822 their neighbors. 824 o Nodes provision routing table entries, for the destinations 825 specified by the DIO message, via their DODAG parents in the DODAG 826 Version. Nodes that decide to join a DODAG can provision one or 827 more DODAG parents as the next-hop for the default route and a 828 number of other external routes for the associated instance. 830 3.3. Downward Routes and Destination Advertisement 832 RPL uses Destination Advertisement Object (DAO) messages to establish 833 downward routes. DAO messages are an optional feature for 834 applications that require P2MP or P2P traffic. RPL supports two 835 modes of downward traffic: storing (fully stateful) or non-storing 836 (fully source routed). Any given RPL Instance is either storing or 837 non-storing. In both cases, P2P packets travel Up toward a DODAG 838 Root then Down to the final destination (unless the destination is on 839 the upward route). In the non-storing case the packet will travel 840 all the way to a DODAG root before traveling Down. In the storing 841 case the packet may be directed Down towards the destination by a 842 common ancestor of the source and the destination prior to reaching a 843 DODAG Root. 845 This specification describes a basic mode of operation in support of 846 P2P traffic. Note that more optimized P2P solutions may be described 847 in companion specifications. 849 3.4. Local DODAGs Route Discovery 851 A RPL network can optionally support on-demand discovery of DODAGs to 852 specific destinations within an LLN. Such local DODAGs behave 853 slightly differently than global DODAGs: they are uniquely defined by 854 the combination of DODAGID and RPLInstanceID. The RPLInstanceID 855 denotes whether a DODAG is a local DODAG. 857 3.5. Rank Properties 859 The rank of a node is a scalar representation of the location of that 860 node within a DODAG Version. The rank is used to avoid and detect 861 loops, and as such must demonstrate certain properties. The exact 862 calculation of the rank is left to the Objective Function. Even 863 though the specific computation of the rank is left to the Objective 864 Function, the rank must implement generic properties regardless of 865 the Objective Function. 867 In particular, the rank of the nodes must monotonically decrease as 868 the DODAG version is followed towards the DODAG destination. In that 869 regard, the rank can be regarded as a scalar representation of the 870 location or radius of a node within a DODAG Version. 872 The details of how the Objective Function computes rank are out of 873 scope for this specification, although that computation may depend, 874 for example, on parents, link metrics, node metrics, and the node 875 configuration and policies. See Section 14 for more information. 877 The rank is not a path cost, although its value can be derived from 878 and influenced by path metrics. The rank has properties of its own 879 that are not necessarily those of all metrics: 881 Type: The rank is an abstract numeric value. 883 Function: The rank is the expression of a relative position within a 884 DODAG Version with regard to neighbors and is not necessarily 885 a good indication or a proper expression of a distance or a 886 path cost to the root. 888 Stability: The stability of the rank determines the stability of the 889 routing topology. Some dampening or filtering is RECOMMENDED 890 to keep the topology stable, and thus the rank does not 891 necessarily change as fast as some link or node metrics 892 would. A new DODAG Version would be a good opportunity to 893 reconcile the discrepancies that might form over time between 894 metrics and ranks within a DODAG Version. 896 Properties: The rank is incremented in a strictly monotonic fashion, 897 and can be used to validate a progression from or towards the 898 root. A metric, like bandwidth or jitter, does not 899 necessarily exhibit this property. 901 Abstract: The rank does not have a physical unit, but rather a range 902 of increment per hop, where the assignment of each increment 903 is to be determined by the Objective Function. 905 The rank value feeds into DODAG parent selection, according to the 906 RPL loop-avoidance strategy. Once a parent has been added, and a 907 rank value for the node within the DODAG has been advertised, the 908 node's further options with regard to DODAG parent selection and 909 movement within the DODAG are restricted in favor of loop avoidance. 911 3.5.1. Rank Comparison (DAGRank()) 913 Rank may be thought of as a fixed point number, where the position of 914 the radix point between the integer part and the fractional part is 915 determined by MinHopRankIncrease. MinHopRankIncrease is the minimum 916 increase in rank between a node and any of its DODAG parents. A 917 DODAG Root provisions MinHopRankIncrease. MinHopRankIncrease creates 918 a tradeoff between hop cost precision and the maximum number of hops 919 a network can support. A very large MinHopRankIncrease, for example, 920 allows precise characterization of a given hop's affect on Rank but 921 cannot support many hops. 923 When an objective function computes rank, the objective function 924 operates on the entire (i.e. 16-bit) rank quantity. When rank is 925 compared, e.g. for determination of parent relationships or loop 926 detection, the integer portion of the rank is to be used. The 927 integer portion of the Rank is computed by the DAGRank() macro as 928 follows, where floor(x) is the function that evaluates to the 929 greatest integer less than or equal to x: 931 DAGRank(rank) = floor(rank/MinHopRankIncrease) 933 For example, if a 16-bit rank quantity is decimal 27, and the 934 MinHopRankIncrease is decimal 16, then DAGRank(27) = floor(1.6875) = 935 1. The integer part of the rank is 1 and the fractional part is 936 11/16. 938 By convention in this document, using the macro DAGRank(node) may be 939 interpreted as DAGRank(node.rank), where node.rank is the rank value 940 as maintained by the node. 942 A node A has a rank less than the rank of a node B if DAGRank(A) is 943 less than DAGRank(B). 945 A node A has a rank equal to the rank of a node B if DAGRank(A) is 946 equal to DAGRank(B). 948 A node A has a rank greater than the rank of a node B if DAGRank(A) 949 is greater than DAGRank(B). 951 3.5.2. Rank Relationships 953 Rank computations maintain the following properties for any nodes M 954 and N that are neighbors in the LLN: 956 DAGRank(M) is less than DAGRank(N): In this case, the position of M 957 is closer to the DODAG root than the position of N. Node M 958 may safely be a DODAG parent for Node N without risk of 959 creating a loop. Further, for a node N, all parents in the 960 DODAG parent set must be of rank less than DAGRank(N). In 961 other words, the rank presented by a node N MUST be greater 962 than that presented by any of its parents. 964 DAGRank(M) equals DAGRank(N): In this case the positions of M and N 965 within the DODAG and with respect to the DODAG root are 966 similar (identical). Routing through a node with equal Rank 967 may cause a routing loop (i.e., if that node chooses to route 968 through a node with equal Rank as well). 970 DAGRank(M) is greater than DAGRank(N): In this case, the position of 971 M is farther from the DODAG root than the position of N. 972 Further, Node M may in fact be in the sub-DODAG of Node N. If 973 node N selects node M as DODAG parent there is a risk to 974 create a loop. 976 As an example, the rank could be computed in such a way so as to 977 closely track ETX (Expected Transmission Count, a fairly common 978 routing metric used in LLN and defined in 979 [I-D.ietf-roll-routing-metrics]) when the metric that an objective 980 function minimizes is ETX, or latency, or in a more complicated way 981 as appropriate to the objective function being used within the DODAG. 983 3.6. Routing Metrics and Constraints Used By RPL 985 Routing metrics are used by routing protocols to compute shortest 986 paths. Interior Gateway Protocols (IGPs) such as IS-IS ([RFC5120]) 987 and OSPF ([RFC4915]) use static link metrics. Such link metrics can 988 simply reflect the bandwidth or can also be computed according to a 989 polynomial function of several metrics defining different link 990 characteristics. Some routing protocols support more than one 991 metric: in the vast majority of the cases, one metric is used per 992 (sub)topology. Less often, a second metric may be used as a tie- 993 breaker in the presence of Equal Cost Multiple Paths (ECMP). The 994 optimization of multiple metrics is known as an NP complete problem 995 and is sometimes supported by some centralized path computation 996 engine. 998 In contrast, LLNs do require the support of both static and dynamic 999 metrics. Furthermore, both link and node metrics are required. In 1000 the case of RPL, it is virtually impossible to define one metric, or 1001 even a composite metric, that will satisfy all use cases. 1003 In addition, RPL supports constrained-based routing where constraints 1004 may be applied to both link and nodes. If a link or a node does not 1005 satisfy a required constraint, it is 'pruned' from the candidate 1006 neighbor set, thus leading to a constrained shortest path. 1008 An Objective Function specifies the objectives used to compute the 1009 (constrained) path. Furthermore, nodes are configured to support a 1010 set of metrics and constraints, and select their parents in the DODAG 1011 according to the metrics and constraints advertised in the DIO 1012 messages. Upstream and Downstream metrics may be merged or 1013 advertised separately depending on the OF and the metrics. When they 1014 are advertised separately, it may happen that the set of DIO parents 1015 is different from the set of DAO parents (a DAO parent is a node to 1016 which unicast DAO messages are sent). Yet, all are DODAG parents 1017 with regards to the rules for Rank computation. 1019 The Objective Function is decoupled from the routing metrics and 1020 constraints used by RPL. Indeed, whereas the OF dictates rules such 1021 as DODAG parents selection, load balancing and so on, the set of 1022 metrics and/or constraints used, and thus determine the preferred 1023 path, are based on the information carried within the DAG container 1024 option in DIO messages. 1026 The set of supported link/node constraints and metrics is specified 1027 in [I-D.ietf-roll-routing-metrics]. 1029 Example 1: Shortest path: path offering the shortest end-to-end 1030 delay. 1032 Example 2: Shortest Constrained path: the path that does not traverse 1033 any battery-operated node and that optimizes the path 1034 reliability. 1036 3.7. Loop Avoidance 1038 RPL tries to avoid creating loops when undergoing topology changes 1039 and includes rank-based datapath validation mechanisms for detecting 1040 loops when they do occur (see Section 11 for more details). In 1041 practice, this means that RPL guarantees neither loop free path 1042 selection nor tight delay convergence times, but can detect and 1043 repair a loop as soon as it is used. RPL uses this loop detection to 1044 ensure that packets make forward progress within the DODAG Version 1045 and trigger repairs when necessary. 1047 3.7.1. Greediness and Instability 1049 A node is greedy if it attempts to move deeper (increase Rank) in the 1050 DODAG Version in order to increase the size of the parent set or 1051 improve some other metric. Once a node has joined a DODAG Version, 1052 RPL disallows certain behaviors, including greediness, in order to 1053 prevent resulting instabilities in the DODAG Version. 1055 Suppose a node is willing to receive and process a DIO message from a 1056 node in its own sub-DODAG, and in general a node deeper than itself. 1058 In this case, a possibility exists that a feedback loop is created, 1059 wherein two or more nodes continue to try and move in the DODAG 1060 Version while attempting to optimize against each other. In some 1061 cases, this will result in instability. It is for this reason that 1062 RPL limits the cases where a node may process DIO messages from 1063 deeper nodes to some forms of local repair. This approach creates an 1064 'event horizon', whereby a node cannot be influenced beyond some 1065 limit into an instability by the action of nodes that may be in its 1066 own sub-DODAG. 1068 3.7.1.1. Example: Greedy Parent Selection and Instability 1070 (A) (A) (A) 1071 |\ |\ |\ 1072 | `-----. | `-----. | `-----. 1073 | \ | \ | \ 1074 (B) (C) (B) \ | (C) 1075 \ | | / 1076 `-----. | | .-----' 1077 \| |/ 1078 (C) (B) 1080 -1- -2- -3- 1082 Figure 3: Greedy DODAG Parent Selection 1084 Figure 3 depicts a DODAG in 3 different configurations. A usable 1085 link between (B) and (C) exists in all 3 configurations. In 1086 Figure 3-1, Node (A) is a DODAG parent for Nodes (B) and (C). In 1087 Figure 3-2, Node (A) is a DODAG parent for Nodes (B) and (C), and 1088 Node (B) is also a DODAG parent for Node (C). In Figure 3-3, Node 1089 (A) is a DODAG parent for Nodes (B) and (C), and Node (C) is also a 1090 DODAG parent for Node (B). 1092 If a RPL node is too greedy, in that it attempts to optimize for an 1093 additional number of parents beyond its most preferred parents, then 1094 an instability can result. Consider the DODAG illustrated in 1095 Figure 3-1. In this example, Nodes (B) and (C) may most prefer Node 1096 (A) as a DODAG parent, but we will consider the case when they are 1097 operating under the greedy condition that will try to optimize for 2 1098 parents. 1100 o Let Figure 3-1 be the initial condition. 1102 o Suppose Node (C) first is able to leave the DODAG and rejoin at a 1103 lower rank, taking both Nodes (A) and (B) as DODAG parents as 1104 depicted in Figure 3-2. Now Node (C) is deeper than both Nodes 1105 (A) and (B), and Node (C) is satisfied to have 2 DODAG parents. 1107 o Suppose Node (B), in its greediness, is willing to receive and 1108 process a DIO message from Node (C) (against the rules of RPL), 1109 and then Node (B) leaves the DODAG and rejoins at a lower rank, 1110 taking both Nodes (A) and (C) as DODAG parents. Now Node (B) is 1111 deeper than both Nodes (A) and (C) and is satisfied with 2 DAG 1112 parents. 1114 o Then Node (C), because it is also greedy, will leave and rejoin 1115 deeper, to again get 2 parents and have a lower rank then both of 1116 them. 1118 o Next Node (B) will again leave and rejoin deeper, to again get 2 1119 parents 1121 o And again Node (C) leaves and rejoins deeper... 1123 o The process will repeat, and the DODAG will oscillate between 1124 Figure 3-2 and Figure 3-3 until the nodes count to infinity and 1125 restart the cycle again. 1127 o This cycle can be averted through mechanisms in RPL: 1129 * Nodes (B) and (C) stay at a rank sufficient to attach to their 1130 most preferred parent (A) and don't go for any deeper (worse) 1131 alternate parents (Nodes are not greedy) 1133 * Nodes (B) and (C) do not process DIO messages from nodes deeper 1134 than themselves (because such nodes are possibly in their own 1135 sub-DODAGs) 1137 These mechanisms are further described in Section 8.2.2.4 1139 3.7.2. DODAG Loops 1141 A DODAG loop may occur when a node detaches from the DODAG and 1142 reattaches to a device in its prior sub-DODAG. This may happen in 1143 particular when DIO messages are missed. Strict use of the DODAG 1144 Version Number can eliminate this type of loop, but this type of loop 1145 may possibly be encountered when using some local repair mechanisms. 1147 For example, consider the local repair mechanism that allows a node 1148 to detach from the DODAG, advertise a rank of INFINITE_RANK (in order 1149 to poison its routes / inform its sub-DODAG), and then to re-attach 1150 to the DODAG. In that case the node may in some cases re-attach to 1151 its own prior-sub-DODAG, causing a DODAG loop, because the poisoning 1152 may fail if the INFINITE_RANK advertisements are lost in the LLN 1153 environment. (In this case the rank-based datapath validation 1154 mechanisms would eventually detect and trigger correction of the 1155 loop). 1157 3.7.3. DAO Loops 1159 A DAO loop may occur when the parent has a route installed upon 1160 receiving and processing a DAO message from a child, but the child 1161 has subsequently cleaned up the related DAO state. This loop happens 1162 when a No-Path (a DAO message that invalidates a previously announced 1163 prefix) was missed and persists until all state has been cleaned up. 1164 RPL includes an optional mechanism to acknowledge DAO messages, which 1165 may mitigate the impact of a single DAO message being missed. RPL 1166 includes loop detection mechanisms that mitigate the impact of DAO 1167 loops and trigger their repair. (See Section 11.2.2.3). 1169 4. Traffic Flows Supported by RPL 1171 RPL supports three basic traffic flows: Multipoint-to-Point (MP2P), 1172 Point-to-Multipoint (P2MP), and Point-to-Point (P2P). 1174 4.1. Multipoint-to-Point Traffic 1176 Multipoint-to-Point (MP2P) is a dominant traffic flow in many LLN 1177 applications ([RFC5867], [RFC5826], [RFC5673], [RFC5548]). The 1178 destinations of MP2P flows are designated nodes that have some 1179 application significance, such as providing connectivity to the 1180 larger Internet or core private IP network. RPL supports MP2P 1181 traffic by allowing MP2P destinations to be reached via DODAG roots. 1183 4.2. Point-to-Multipoint Traffic 1185 Point-to-multipoint (P2MP) is a traffic pattern required by several 1186 LLN applications ([RFC5867], [RFC5826], [RFC5673], [RFC5548]). RPL 1187 supports P2MP traffic by using a destination advertisement mechanism 1188 that provisions Down routes toward destinations (prefixes, addresses, 1189 or multicast groups), and away from roots. Destination 1190 advertisements can update routing tables as the underlying DODAG 1191 topology changes. 1193 4.3. Point-to-Point Traffic 1195 RPL DODAGs provide a basic structure for point-to-point (P2P) 1196 traffic. For a RPL network to support P2P traffic, a root must be 1197 able to route packets to a destination. Nodes within the network may 1198 also have routing tables to destinations. A packet flows towards a 1199 root until it reaches an ancestor that has a known route to the 1200 destination. As pointed out later in this document, in the most 1201 constrained case (when nodes cannot store routes), that common 1202 ancestor may be the DODAG root. In other cases it may be a node 1203 closer to both the source and destination. 1205 RPL also supports the case where a P2P destination is a 'one-hop' 1206 neighbor. 1208 RPL neither specifies nor precludes additional mechanisms for 1209 computing and installing potentially more optimal routes to support 1210 arbitrary P2P traffic. 1212 5. RPL Instance 1214 Within a given LLN, there may be multiple, logically independent RPL 1215 instances. A RPL node may belong to multiple RPL instances, and may 1216 act as a router in some and as a leaf in others. This document 1217 describes how a single instance behaves. 1219 There are two types of RPL Instances: local and global. RPL divides 1220 the RPLInstanceID space between Global and Local instances to allow 1221 for both coordinated and unilateral allocation of RPLInstanceIDs. 1222 Global RPL Instances are coordinated, have one or more DODAGs, and 1223 are typically long-lived. Local RPL Instances are always a single 1224 DODAG whose singular root owns the corresponding DODAGID and 1225 allocates the Local RPLInstanceID in a unilateral manner. Local RPL 1226 Instances can be used, for example, for constructing DODAGs in 1227 support of a future on-demand routing solution. The mode of 1228 operation of Local RPL Instances is out of scope for this 1229 specification and may be described in other companion specifications. 1231 The definition and provisioning of RPL instances are out of scope for 1232 this specification. Guidelines may be application and implementation 1233 specific, and are expected to be elaborated in future companion 1234 specifications. Those operations are expected to be such that data 1235 packets coming from the outside of the RPL network can unambiguously 1236 be associated to at least one RPL instance, and be safely routed over 1237 any instance that would match the packet. 1239 Control and data packets within RPL network are tagged to 1240 unambiguously identify what RPL Instance they are part of. 1242 Every RPL control message has a RPLInstanceID field. Some RPL 1243 control messages, when referring to a local RPLInstanceID as defined 1244 below, may also include a DODAGID. 1246 Data packets that flow within the RPL network expose the 1247 RPLInstanceID as part of the RPL Packet Information that RPL 1248 requires, as further described in Section 11.2. For data packets 1249 coming from outside the RPL network, the ingress router determines 1250 the RPLInstanceID and places it into the resulting packet that it 1251 injects into the RPL network. 1253 5.1. RPL Instance ID 1255 A global RPLInstanceID MUST be unique to the whole LLN. Mechanisms 1256 for allocating and provisioning global RPLInstanceID are out of scope 1257 for this specification. There can be up to 128 global instance in 1258 the whole network. Local instances are always used in conjunction 1259 with a DODAGID (which is either given explicitly or implicitly in 1260 some cases), and up 64 local instances per DODAGID can be supported. 1261 Local instances are allocated and managed by the node that owns the 1262 DODAGID, without any explicit coordination with other nodes, as 1263 further detailed below. 1265 A global RPLinstanceID is encoded in a RPLinstanceID field as 1266 follows: 1268 0 1 2 3 4 5 6 7 1269 +-+-+-+-+-+-+-+-+ 1270 |0| ID | Global RPLinstanceID in 0..127 1271 +-+-+-+-+-+-+-+-+ 1273 Figure 4: RPL Instance ID field format for global instances 1275 A local RPLInstanceID is autoconfigured by the node that owns the 1276 DODAGID and it MUST be unique for that DODAGID. The DODAGID used to 1277 configure the local RPLInstanceID MUST be a reachable IPv6 address of 1278 the node, and MUST be used as an endpoint of all communications 1279 within that local instance. 1281 A local RPLinstanceID is encoded in a RPLinstanceID field as follows: 1283 0 1 2 3 4 5 6 7 1284 +-+-+-+-+-+-+-+-+ 1285 |1|D| ID | Local RPLInstanceID in 0..63 1286 +-+-+-+-+-+-+-+-+ 1288 Figure 5: RPL Instance ID field format for local instances 1290 The D flag in a Local RPLInstanceID is always set to 0 in RPL control 1291 messages. It is used in data packets to indicate whether the DODAGID 1292 is the source or the destination of the packet. If the D flag is set 1293 to 1 then the destination address of the IPv6 packet MUST be the 1294 DODAGID. If the D flag is cleared then the source address of the 1295 IPv6 packet MUST be the DODAGID. 1297 For example, consider a node A that is the DODAG Root of a local RPL 1298 Instance, and has allocated a local RPLInstanceID. By definition, 1299 all traffic traversing that local RPL Instance will either originate 1300 or terminate at node A. The DODAGID in this case will be the 1301 reachable IPv6 address of node A, and all traffic will contain the 1302 address of node A, thus the DODAGID, in either the source or 1303 destination address. Thus the Local RPLInstanceID may indicate that 1304 the DODAGID is equivalent to either the source address or the 1305 destination address by setting the D flag appropriately. 1307 6. ICMPv6 RPL Control Message 1309 This document defines the RPL Control Message, a new ICMPv6 [RFC4443] 1310 message. A RPL Control Message is identified by a code, and composed 1311 of a base that depends on the code, and a series of options. 1313 Most RPL Control Message have the scope of a link. The only 1314 exception is for the DAO / DAO-ACK messages in non-storing mode, 1315 which are exchanged using a unicast address over multiple hops and 1316 thus uses global or unique-local addresses for both the source and 1317 destination addresses. For all other RPL Control messages, the 1318 source address is a link-local address, and the destination address 1319 is either the all-RPL-nodes multicast address or a link-local unicast 1320 address of the destination. The all-RPL-nodes multicast address is a 1321 new address with a requested value of FF02::1A (to be confirmed by 1322 IANA). 1324 In accordance with [RFC4443], the RPL Control Message consists of an 1325 ICMPv6 header followed by a message body. The message body is 1326 comprised of a message base and possibly a number of options as 1327 illustrated in Figure 6. 1329 0 1 2 3 1330 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 1331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1332 | Type | Code | Checksum | 1333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1334 | | 1335 . Base . 1336 . . 1337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1338 | | 1339 . Option(s) . 1340 . . 1341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1343 Figure 6: RPL Control Message 1345 The RPL Control message is an ICMPv6 information message with a 1346 requested Type of 155 (to be confirmed by IANA). 1348 The Code field identifies the type of RPL Control Message. This 1349 document defines codes for the following RPL Control Message types 1350 (all codes are to be confirmed by IANA Section 19.2): 1352 o 0x00: DODAG Information Solicitation (Section 6.2) 1354 o 0x01: DODAG Information Object (Section 6.3) 1356 o 0x02: Destination Advertisement Object (Section 6.4) 1358 o 0x03: Destination Advertisement Object Acknowledgment 1359 (Section 6.5) 1361 o 0x80: Secure DODAG Information Solicitation (Section 6.2.2) 1363 o 0x81: Secure DODAG Information Object (Section 6.3.2) 1365 o 0x82: Secure Destination Advertisement Object (Section 6.4.2) 1367 o 0x83: Secure Destination Advertisement Object Acknowledgment 1368 (Section 6.5.2) 1370 o 0x8A: Consistency Check (Section 6.6) 1372 If a node receives a RPL control message with an unknown Code field, 1373 the node MUST discard the message without any further processing, MAY 1374 raise a management alert, and MUST NOT send any messages in response. 1376 The checksum is computed as specified in [RFC4443]. It is set to 1377 zero for the RPL security operations specified below, and computed 1378 once the rest of the content of the RPL message including the 1379 security fields is all set. 1381 The high order bit (0x80) of the code denotes whether the RPL message 1382 has security enabled. Secure RPL messages have a format to support 1383 confidentiality and integrity, illustrated in Figure 7. 1385 0 1 2 3 1386 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 1387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1388 | Type | Code | Checksum | 1389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1390 | | 1391 . Security . 1392 . . 1393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1394 | | 1395 . Base . 1396 . . 1397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1398 | | 1399 . Option(s) . 1400 . . 1401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1403 Figure 7: Secure RPL Control Message 1405 The remainder of this section describes the currently defined RPL 1406 Control Message Base formats followed by the currently defined RPL 1407 Control Message Options. 1409 6.1. RPL Security Fields 1411 Each RPL message has a secure variant. The secure variants provide 1412 integrity and replay protection as well as optional confidentiality 1413 and delay protection. Because security covers the base message as 1414 well as options, in secured messages the security information lies 1415 between the checksum and base, as shown in Figure 7. 1417 The level of security and the algorithms in use are indicated in the 1418 protocol messages as described below: 1420 0 1 2 3 1421 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 1422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1423 |T| Reserved | Algorithm |KIM|Resvd| LVL | Flags | 1424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1425 | Counter | 1426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1427 | | 1428 . Key Identifier . 1429 . . 1430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1431 Figure 8: Security Section 1433 Message authentication codes (MACs) and signatures provide 1434 authentication over the entire unsecured ICMPv6 RPL control message, 1435 including the Security section with all fields defined, but with the 1436 ICMPv6 checksum temporarily set to zero. Encryption provides 1437 confidentiality of the secured RPL ICMPv6 message starting at the 1438 first byte after the Security section and continuing to the last byte 1439 of the packet. The security transformation yields a secured ICMPv6 1440 RPL message with the inclusion of the cryptographic fields (MAC, 1441 signature, etc.). In other words, the security transformation itself 1442 (e.g. the Signature and/or Algorithm in use) will detail how to 1443 incorporate the cryptographic fields into the secured packet. The 1444 Security section itself does not explicitly carry those cryptographic 1445 fields. Use of the Security section is further detailed in 1446 Section 18 and Section 10. 1448 Counter is Time (T): If the Counter is Time flag is set then the 1449 Counter field is a timestamp. If the flag is cleared then the 1450 Counter is an incrementing counter. Section 10.5 describes the 1451 details of the 'T' flag and Counter field. 1453 Reserved: 7-bit unused field. The field MUST be initialized to zero 1454 by the sender and MUST be ignored by the receiver. 1456 Security Algorithm (Algorithm): The Security Algorithm field 1457 specifies the encryption, MAC, and signature scheme the network 1458 uses. Supported values of this field are as follows: 1460 +-----------+-------------------+------------------------+ 1461 | Algorithm | Encryption/MAC | Signature | 1462 +-----------+-------------------+------------------------+ 1463 | 0 | CCM with AES-128 | RSA with SHA-256 | 1464 | 1-255 | Unassigned | Unassigned | 1465 +-----------+-------------------+------------------------+ 1467 Figure 9: Security Algorithm (Algorithm) Encoding 1469 Section 10.9 describes the algorithms in greater detail. 1471 Key Identifier Mode (KIM): The Key Identifier Mode is a 2-bit field 1472 that indicates whether the key used for packet protection is 1473 determined implicitly or explicitly and indicates the 1474 particular representation of the Key Identifier field. The Key 1475 Identifier Mode is set one of the values from the table below: 1477 +------+-----+-----------------------------+------------+ 1478 | Mode | KIM | Meaning | Key | 1479 | | | | Identifier | 1480 | | | | Length | 1481 | | | | (octets) | 1482 +------+-----+-----------------------------+------------+ 1483 | 0 | 00 | Group key used. | 1 | 1484 | | | Key determined by Key Index | | 1485 | | | field. | | 1486 | | | | | 1487 | | | Key Source is not present. | | 1488 | | | Key Index is present. | | 1489 +------+-----+-----------------------------+------------+ 1490 | 1 | 01 | Per-pair key used. | 0 | 1491 | | | Key determined by source | | 1492 | | | and destination of packet. | | 1493 | | | | | 1494 | | | Key Source is not present. | | 1495 | | | Key Index is not present. | | 1496 +------+-----+-----------------------------+------------+ 1497 | 2 | 10 | Group key used. | 9 | 1498 | | | Key determined by Key Index | | 1499 | | | and Key Source Identifier. | | 1500 | | | | | 1501 | | | Key Source is present. | | 1502 | | | Key Index is present. | | 1503 +------+-----+-----------------------------+------------+ 1504 | 3 | 11 | Node's signature key used. | 0/9 | 1505 | | | If packet is encrypted, | 1506 | | | it uses a group key, Key | | 1507 | | | Index and Key Source | | 1508 | | | specify key. | | 1509 | | | | | 1510 | | | Key Source may be present. | | 1511 | | | Key Index may be present. | | 1512 +------+-----+-----------------------------+------------+ 1514 Figure 10: Key Identifier Mode (KIM) Encoding 1516 In Mode 3 (KIM=11), the presence or absence of the Key Source 1517 and Key Identifier depends on the Security Level (LVL) 1518 described below. If the Security Level indicates there is 1519 encryption, then the fields are present; if it indicates there 1520 is no encryption, then the fields are not present. 1522 Resvd: 3-bit unused field. The field MUST be initialized to zero by 1523 the sender and MUST be ignored by the receiver. 1525 Security Level (LVL): The Security Level is a 3-bit field that 1526 indicates the provided packet protection. This value can be 1527 adapted on a per-packet basis and allows for varying levels of 1528 data authenticity and, optionally, for data confidentiality. 1529 The KIM field indicates whether signatures are used and the 1530 meaning of the Level field. Note that the assigned values of 1531 Security Level are not necessarily ordered-- a higher value of 1532 LVL does not necessarily equate to increased security. The 1533 Security Level is set to one of the values in the tables below: 1535 +---------------------------+ 1536 | KIM=0,1,2 | 1537 +-------+--------------------+------+ 1538 | LVL | Attributes | MAC | 1539 | | | Len | 1540 +-------+--------------------+------+ 1541 | 0 | MAC-32 | 4 | 1542 | 1 | ENC-MAC-32 | 4 | 1543 | 2 | MAC-64 | 8 | 1544 | 3 | ENC-MAC-64 | 8 | 1545 | 4-7 | Unassigned | N/A | 1546 +-------+--------------------+------+ 1548 +---------------------+ 1549 | KIM=3 | 1550 +-------+---------------+-----+ 1551 | LVL | Attributes | Sig | 1552 | | | Len | 1553 +-------+---------------+-----+ 1554 | 0 | Sign-3072 | 384 | 1555 | 1 | ENC-Sign-3072 | 384 | 1556 | 2 | Sign-2048 | 256 | 1557 | 3 | ENC-Sign-2048 | 256 | 1558 | 4-7 | Unassigned | N/A | 1559 +-------+---------------+-----+ 1561 Figure 11: Security Level (LVL) Encoding 1563 The MAC attribute indicates that the message has a Message 1564 Authentication Code of the specified length. The ENC attribute 1565 indicates that the message is encrypted. The Sign attribute 1566 indicates that the message has a signature of the specified 1567 length. 1569 Flags: 8-bit unused field reserved for flags. The field MUST be 1570 initialized to zero by the sender and MUST be ignored by the 1571 receiver. 1573 Counter: The Counter field indicates the non-repeating 4-octet value 1574 (nonce) used with the cryptographic mechanism that implements 1575 packet protection and allows for the provision of semantic 1576 security. 1578 Key Identifier: The Key Identifier field indicates which key was 1579 used to protect the packet. This field provides various levels 1580 of granularity of packet protection, including peer-to-peer 1581 keys, group keys, and signature keys. This field is 1582 represented as indicated by the Key Identifier Mode field and 1583 is formatted as follows: 1585 0 1 2 3 1586 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 1587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1588 | | 1589 . Key Source . 1590 . . 1591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1592 | | 1593 . Key Index . 1594 . . 1595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1597 Figure 12: Key Identifier 1599 Key Source: The Key Source field, when present, indicates the 1600 logical identifier of the originator of a group key. 1601 When present this field is 8 bytes in length. 1603 Key Index: The Key Index field, when present, allows unique 1604 identification of different keys with the same 1605 originator. It is the responsibility of each key 1606 originator to make sure that actively used keys that it 1607 issues have distinct key indices and that all key indices 1608 have a value unequal to 0x00. Value 0x00 is reserved for 1609 a pre-installed, shared key. When present this field is 1610 1 byte in length. 1612 Unassigned bits of the Security section are reserved. They MUST be 1613 set to zero on transmission and MUST be ignored on reception. 1615 6.2. DODAG Information Solicitation (DIS) 1617 The DODAG Information Solicitation (DIS) message may be used to 1618 solicit a DODAG Information Object from a RPL node. Its use is 1619 analogous to that of a Router Solicitation as specified in IPv6 1620 Neighbor Discovery; a node may use DIS to probe its neighborhood for 1621 nearby DODAGs. Section 8.3 describes how nodes respond to a DIS. 1623 6.2.1. Format of the DIS Base Object 1625 0 1 2 1626 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1628 | Flags | Reserved | Option(s)... 1629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1631 Figure 13: The DIS Base Object 1633 Flags: 8-bit unused field reserved for flags. The field MUST be 1634 initialized to zero by the sender and MUST be ignored by the 1635 receiver. 1637 Reserved: 8-bit unused field. The field MUST be initialized to zero 1638 by the sender and MUST be ignored by the receiver. 1640 Unassigned bits of the DIS Base are reserved. They MUST be set to 1641 zero on transmission and MUST be ignored on reception. 1643 6.2.2. Secure DIS 1645 A Secure DIS message follows the format in Figure 7, where the base 1646 format is the DIS message shown in Figure 13. 1648 6.2.3. DIS Options 1650 The DIS message MAY carry valid options. 1652 This specification allows for the DIS message to carry the following 1653 options: 1654 0x00 Pad1 1655 0x01 PadN 1656 0x07 Solicited Information 1658 6.3. DODAG Information Object (DIO) 1660 The DODAG Information Object carries information that allows a node 1661 to discover a RPL Instance, learn its configuration parameters, 1662 select a DODAG parent set, and maintain the DODAG. 1664 6.3.1. Format of the DIO Base Object 1666 0 1 2 3 1667 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 1668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1669 | RPLInstanceID |Version Number | Rank | 1670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1671 |G|0| MOP | Prf | DTSN | Flags | Reserved | 1672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1673 | | 1674 + + 1675 | | 1676 + DODAGID + 1677 | | 1678 + + 1679 | | 1680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1681 | Option(s)... 1682 +-+-+-+-+-+-+-+-+ 1684 Figure 14: The DIO Base Object 1686 Grounded (G): The Grounded (G) flag indicates whether the DODAG 1687 advertised can satisfy the application-defined goal. If the 1688 flag is set, the DODAG is grounded. If the flag is cleared, 1689 the DODAG is floating. 1691 Mode of Operation (MOP): The Mode of Operation (MOP) field 1692 identifies the mode of operation of the RPL Instance as 1693 administratively provisioned at and distributed by the DODAG 1694 Root. All nodes who join the DODAG must be able to honor the 1695 MOP in order to fully participate as a router, or else they 1696 must only join as a leaf. MOP is encoded as in the figure 1697 below: 1699 +-----+-------------------------------------------------+ 1700 | MOP | Meaning | 1701 +-----+-------------------------------------------------+ 1702 | 0 | No downward routes maintained by RPL | 1703 | 1 | Non storing mode | 1704 | 2 | Storing without multicast support | 1705 | 3 | Storing with multicast support | 1706 | | | 1707 | | All other values are unassigned | 1708 +-----+-------------------------------------------------+ 1710 A value of 0 indicates that destination advertisement messages 1711 are disabled and the DODAG maintains only upward routes 1713 Figure 15: Mode of Operation (MOP) Encoding 1715 DODAGPreference (Prf): A 3-bit unsigned integer that defines how 1716 preferable the root of this DODAG is compared to other DODAG 1717 roots within the instance. DAGPreference ranges from 0x00 1718 (least preferred) to 0x07 (most preferred). The default is 0 1719 (least preferred). Section 8.2 describes how DAGPreference 1720 affects DIO processing. 1722 Version Number: 8-bit unsigned integer set by the DODAG root to the 1723 DODAGVersionNumber. Section 8.2 describes the rules for DODAG 1724 Version numbers and how they affect DIO processing. 1726 Rank: 16-bit unsigned integer indicating the DODAG rank of the node 1727 sending the DIO message. Section 8.2 describes how Rank is set 1728 and how it affects DIO processing. 1730 RPLInstanceID: 8-bit field set by the DODAG root that indicates 1731 which RPL Instance the DODAG is part of. 1733 Destination Advertisement Trigger Sequence Number (DTSN): 8-bit 1734 unsigned integer set by the node issuing the DIO message. The 1735 Destination Advertisement Trigger Sequence Number (DTSN) flag 1736 is used as part of the procedure to maintain downward routes. 1737 The details of this process are described in Section 9. 1739 Flags: 8-bit unused field reserved for flags. The field MUST be 1740 initialized to zero by the sender and MUST be ignored by the 1741 receiver. 1743 Reserved: 8-bit unused field. The field MUST be initialized to zero 1744 by the sender and MUST be ignored by the receiver. 1746 DODAGID: 128-bit IPv6 address set by a DODAG root which uniquely 1747 identifies a DODAG. The DODAGID MUST be a routable IPv6 1748 address belonging to the DODAG root. 1750 Unassigned bits of the DIO Base are reserved. They MUST be set to 1751 zero on transmission and MUST be ignored on reception. 1753 6.3.2. Secure DIO 1755 A Secure DIO message follows the format in Figure 7, where the base 1756 format is the DIO message shown in Figure 14. 1758 6.3.3. DIO Options 1760 The DIO message MAY carry valid options. 1762 This specification allows for the DIO message to carry the following 1763 options: 1764 0x00 Pad1 1765 0x01 PadN 1766 0x02 Metric Container 1767 0x03 Routing Information 1768 0x04 DODAG Configuration 1769 0x08 Prefix Information 1771 6.4. Destination Advertisement Object (DAO) 1773 The Destination Advertisement Object (DAO) is used to propagate 1774 destination information upwards along the DODAG. In storing mode the 1775 DAO message is unicast by the child to the selected parent(s). In 1776 non-storing mode the DAO message is unicast to the DODAG root. The 1777 DAO message may optionally, upon explicit request or error, be 1778 acknowledged by its destination with a Destination Advertisement 1779 Acknowledgement (DAO-ACK) message back to the sender of the DAO. 1781 6.4.1. Format of the DAO Base Object 1782 0 1 2 3 1783 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 1784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1785 | RPLInstanceID |K|D| Flags | Reserved | DAOSequence | 1786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1787 | | 1788 + + 1789 | | 1790 + DODAGID* + 1791 | | 1792 + + 1793 | | 1794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1795 | Option(s)... 1796 +-+-+-+-+-+-+-+-+ 1798 The '*' denotes that the DODAGID is not always present, as described 1799 below. 1801 Figure 16: The DAO Base Object 1803 RPLInstanceID: 8-bit field indicating the topology instance 1804 associated with the DODAG, as learned from the DIO. 1806 K: The 'K' flag indicates that the recipient is expected to send a 1807 DAO-ACK back. (See Section 9.3 1809 D: The 'D' flag indicates that the DODAGID field is present. This 1810 flag MUST be set when a local RPLInstanceID is used. 1812 Flags: 6-bit unused field reserved for flags. The field MUST be 1813 initialized to zero by the sender and MUST be ignored by the 1814 receiver. 1816 Reserved: 8-bit unused field. The field MUST be initialized to zero 1817 by the sender and MUST be ignored by the receiver. 1819 DAOSequence: Incremented at each unique DAO message from a node and 1820 echoed in the DAO-ACK message. 1822 DODAGID (optional): 128-bit unsigned integer set by a DODAG root 1823 which uniquely identifies a DODAG. This field is only present 1824 when the 'D' flag is set. This field is typically only present 1825 when a local RPLInstanceID is in use, in order to identify the 1826 DODAGID that is associated with the RPLInstanceID. When a 1827 global RPLInstanceID is in use this field need not be present. 1829 Unassigned bits of the DAO Base are reserved. They MUST be set to 1830 zero on transmission and MUST be ignored on reception. 1832 6.4.2. Secure DAO 1834 A Secure DAO message follows the format in Figure 7, where the base 1835 format is the DAO message shown in Figure 16. 1837 6.4.3. DAO Options 1839 The DAO message MAY carry valid options. 1841 This specification allows for the DAO message to carry the following 1842 options: 1843 0x00 Pad1 1844 0x01 PadN 1845 0x05 RPL Target 1846 0x06 Transit Information 1847 0x09 RPL Target Descriptor 1849 A special case of the DAO message, termed a No-Path, is used in 1850 storing mode to clear downward routing state that has been 1851 provisioned through DAO operation. The No-Path carries a Target 1852 option and an associated Transit Information option with a lifetime 1853 of 0x00000000 to indicate a loss of reachability to that Target. 1855 6.5. Destination Advertisement Object Acknowledgement (DAO-ACK) 1857 The DAO-ACK message is sent as a unicast packet by a DAO recipient (a 1858 DAO parent or DODAG root) in response to a unicast DAO message. 1860 6.5.1. Format of the DAO-ACK Base Object 1861 0 1 2 3 1862 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 1863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1864 | RPLInstanceID |D| Reserved | DAOSequence | Status | 1865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1866 | | 1867 + + 1868 | | 1869 + DODAGID* + 1870 | | 1871 + + 1872 | | 1873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1874 | Option(s)... 1875 +-+-+-+-+-+-+-+-+ 1877 The '*' denotes that the DODAGID is not always present, as described 1878 below. 1880 Figure 17: The DAO ACK Base Object 1882 RPLInstanceID: 8-bit field indicating the topology instance 1883 associated with the DODAG, as learned from the DIO. 1885 D: The 'D' flag indicates that the DODAGID field is present. This 1886 would typically only be set when a local RPLInstanceID is used. 1888 Flags: 7-bit unused field reserved for flags. The field MUST be 1889 initialized to zero by the sender and MUST be ignored by the 1890 receiver. 1892 DAOSequence: Incremented at each DAO message from a node, and echoed 1893 in the DAO-ACK by the recipient. The DAOSequence is used to 1894 correlate a DAO message and a DAO ACK message and is not to be 1895 confused with the Transit Information option Path Sequence that 1896 is associated to a given target Down the DODAG. 1898 Status: Indicates the completion. Status 0 is unqualified 1899 acceptance, 1 to 127 are unassigned and undetermined, and 128 1900 and greater are rejection codes used to indicate that the node 1901 should select an alternate parent. This specification does not 1902 define any rejection codes. 1904 DODAGID (optional): 128-bit unsigned integer set by a DODAG root 1905 which uniquely identifies a DODAG. This field is only present 1906 when the 'D' flag is set. This field is typically only present 1907 when a local RPLInstanceID is in use, in order to identify the 1908 DODAGID that is associated with the RPLInstanceID. When a 1909 global RPLInstanceID is in use this field need not be present. 1911 Unassigned bits of the DAO-ACK Base are reserved. They MUST be set 1912 to zero on transmission and MUST be ignored on reception. 1914 6.5.2. Secure DAO-ACK 1916 A Secure DAO-ACK message follows the format in Figure 7, where the 1917 base format is the DAO-ACK message shown in Figure 17. 1919 6.5.3. DAO-ACK Options 1921 This specification does not define any options to be carried by the 1922 DAO-ACK message. 1924 6.6. Consistency Check (CC) 1926 The CC message is used to check secure message counters and issue 1927 challenge/responses. A CC message MUST be sent as a secured RPL 1928 message. 1930 6.6.1. Format of the CC Base Object 1932 0 1 2 3 1933 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 1934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1935 | RPLInstanceID |R| Flags | Nonce | 1936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1937 | | 1938 + + 1939 | | 1940 + DODAGID + 1941 | | 1942 + + 1943 | | 1944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1945 | Destination Counter | 1946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1947 | Option(s)... 1948 +-+-+-+-+-+-+-+-+ 1950 Figure 18: The CC Base Object 1952 RPLInstanceID: 8-bit field indicating the topology instance 1953 associated with the DODAG, as learned from the DIO. 1955 R: The 'R' flag indicates whether the CC message is a response. A 1956 message with the 'R' flag cleared is a request; a message with 1957 the 'R' flag set is a response. 1959 Flags: 7-bit unused field reserved for flags. The field MUST be 1960 initialized to zero by the sender and MUST be ignored by the 1961 receiver. 1963 Nonce: 16-bit unsigned integer set by a CC request. The 1964 corresponding CC response includes the same nonce value as the 1965 request. 1967 Destination Counter: 32-bit unsigned integer value indicating the 1968 sender's estimate of the destination's current security Counter 1969 value. If the sender does not have an estimate, it SHOULD set 1970 the Destination Counter field to zero. 1972 Unassigned bits of the CC Base are reserved. They MUST be set to 1973 zero on transmission and MUST be ignored on reception. 1975 The Destination Counter value allows new or recovered nodes to 1976 resynchronize through CC message exchanges. This is important to 1977 ensure that a Counter value is not repeated for a given security key 1978 even in the event of devices recovering from a failure that created a 1979 loss of Counter state. For example, where a CC request or other RPL 1980 message is received with an initialized Counter within the message 1981 security section, the provision of the Incoming Counter within the CC 1982 response message allows the requesting node to reset its Outgoing 1983 Counter to a value greater than the last value received by the 1984 responding node; the Incoming Counter will also be updated from the 1985 received CC response. 1987 6.6.2. CC Options 1989 This specification allows for the CC message to carry the following 1990 options: 1991 0x00 Pad1 1992 0x01 PadN 1994 6.7. RPL Control Message Options 1996 6.7.1. RPL Control Message Option Generic Format 1998 RPL Control Message Options all follow this format: 2000 0 1 2 2001 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - 2003 | Option Type | Option Length | Option Data 2004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - 2006 Figure 19: RPL Option Generic Format 2008 Option Type: 8-bit identifier of the type of option. The Option 2009 Type values are to be confirmed by IANA Section 19.4. 2011 Option Length: 8-bit unsigned integer, representing the length in 2012 octets of the option, not including the Option Type and Length 2013 fields. 2015 Option Data: A variable length field that contains data specific to 2016 the option. 2018 When processing a RPL message containing an option for which the 2019 Option Type value is not recognized by the receiver, the receiver 2020 MUST silently ignore the unrecognized option and continue to process 2021 the following option, correctly handling any remaining options in the 2022 message. 2024 RPL message options may have alignment requirements. Following the 2025 convention in IPv6, options with alignment requirements are aligned 2026 in a packet such that multi-octet values within the Option Data field 2027 of each option fall on natural boundaries (i.e., fields of width n 2028 octets are placed at an integer multiple of n octets from the start 2029 of the header, for n = 1, 2, 4, or 8). 2031 6.7.2. Pad1 2033 The Pad1 option MAY be present in DIS, DIO, DAO, DAO-ACK, and CC 2034 messages, and its format is as follows: 2036 0 2037 0 1 2 3 4 5 6 7 2038 +-+-+-+-+-+-+-+-+ 2039 | Type = 0 | 2040 +-+-+-+-+-+-+-+-+ 2042 Figure 20: Format of the Pad 1 Option 2044 The Pad1 option is used to insert a single octet of padding into the 2045 message to enable options alignment. If more than one octet of 2046 padding is required, the PadN option should be used rather than 2047 multiple Pad1 options. 2049 NOTE! the format of the Pad1 option is a special case - it has 2050 neither Option Length nor Option Data fields. 2052 6.7.3. PadN 2054 The PadN option MAY be present in DIS, DIO, DAO, DAO-ACK, and CC 2055 messages, and its format is as follows: 2057 0 1 2 2058 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - 2060 | Type = 1 | Option Length | 0x00 Padding... 2061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - 2063 Figure 21: Format of the Pad N Option 2065 The PadN option is used to insert two or more octets of padding into 2066 the message to enable options alignment. PadN Option data MUST be 2067 ignored by the receiver. 2069 Option Type: 0x01 (to be confirmed by IANA) 2071 Option Length: For N octets of padding, where 2 <= N <= 7, the 2072 Option Length field contains the value N-2. An Option Length 2073 of 0 indicates a total padding of 2 octets. An Option Length 2074 of 5 indicates a total padding of 7 octets, which is the 2075 maximum padding size allowed with the PadN option. 2077 Option Data: For N (N > 1) octets of padding, the Option Data 2078 consists of N-2 zero-valued octets. 2080 6.7.4. Metric Container 2082 The Metric Container option MAY be present in DIO or DAO messages, 2083 and its format is as follows: 2085 0 1 2 2086 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - 2088 | Type = 2 | Option Length | Metric Data 2089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - 2091 Figure 22: Format of the Metric Container Option 2093 The Metric Container is used to report metrics along the DODAG. The 2094 Metric Container may contain a number of discrete node, link, and 2095 aggregate path metrics and constraints specified in 2096 [I-D.ietf-roll-routing-metrics] as chosen by the implementer. 2098 The Metric Container MAY appear more than once in the same RPL 2099 control message, for example to accommodate a use case where the 2100 Metric Data is longer than 256 bytes. More information is in 2101 [I-D.ietf-roll-routing-metrics]. 2103 The processing and propagation of the Metric Container is governed by 2104 implementation specific policy functions. 2106 Option Type: 0x02 (to be confirmed by IANA) 2108 Option Length: The Option Length field contains the length in octets 2109 of the Metric Data. 2111 Metric Data: The order, content, and coding of the Metric Container 2112 data is as specified in [I-D.ietf-roll-routing-metrics]. 2114 6.7.5. Route Information 2116 The Route Information option MAY be present in DIO messages, and 2117 carries the same information as the IPv6 Neighbor Discovery (ND) 2118 Route Information option as defined in [RFC4191]. The root of a 2119 DODAG is authoritative for setting that information and the 2120 information is unchanged as propagated down the DODAG. A RPL router 2121 may trivially transform it back into a ND option to advertise in its 2122 own RAs so a node attached to the RPL router will end up using the 2123 DODAG for which the root has the best preference for the destination 2124 of a packet. In addition to the existing ND semantics, it is 2125 possible for an Objective function to use this information to favor a 2126 DODAG which root is most preferred for a specific destination. The 2127 format of the option is modified slightly (Type, Length, Prefix) in 2128 order to be carried as a RPL option as follows: 2130 0 1 2 3 2131 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 2132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2133 | Type = 3 | Option Length | Prefix Length |Resvd|Prf|Resvd| 2134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2135 | Route Lifetime | 2136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2137 | | 2138 . Prefix (Variable Length) . 2139 . . 2140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2142 Figure 23: Format of the Route Information Option 2144 The Route Information option is used to indicate that connectivity to 2145 the specified destination prefix is available from the DODAG root. 2147 In the event that a RPL Control Message may need to specify 2148 connectivity to more than one destination, the Route Information 2149 option may be repeated. 2151 [RFC4191] should be consulted as the authoritative reference with 2152 respect to the Route Information option. The field descriptions are 2153 transcribed here for convenience: 2155 Option Type: 0x03 (to be confirmed by IANA) 2157 Option Length: Variable, length of the option in octets excluding 2158 the Type and Length fields. Note that this length is expressed 2159 in units of single-octets, unlike in IPv6 ND. 2161 Prefix Length 8-bit unsigned integer. The number of leading bits in 2162 the Prefix that are valid. The value ranges from 0 to 128. 2163 The Prefix field has the number of bytes inferred from the 2164 Option Length field, that must be at least the Prefix Length. 2165 Note that in RPL this means that the Prefix field may have 2166 lengths other than 0, 8, or 16. 2168 Prf: 2-bit signed integer. The Route Preference indicates whether 2169 to prefer the router associated with this prefix over others, 2170 when multiple identical prefixes (for different routers) have 2171 been received. If the Reserved (10) value is received, the 2172 Route Information Option MUST be ignored. As per [RFC4191], 2173 the Reserved (10) value MUST NOT be sent. ([RFC4191] restricts 2174 the Preference to just three values to reinforce that it is not 2175 a metric). 2177 Resvd: Two 3-bit unused fields. They MUST be initialized to zero by 2178 the sender and MUST be ignored by the receiver. 2180 Route Lifetime 32-bit unsigned integer. The length of time in 2181 seconds (relative to the time the packet is sent) that the 2182 prefix is valid for route determination. A value of all one 2183 bits (0xffffffff) represents infinity. 2185 Prefix Variable-length field containing an IP address or a prefix of 2186 an IPv6 address. The Prefix Length field contains the number 2187 of valid leading bits in the prefix. The bits in the prefix 2188 after the prefix length (if any) are reserved and MUST be 2189 initialized to zero by the sender and ignored by the receiver. 2190 Note that in RPL this field may have lengths other than 0, 8, 2191 or 16. 2193 Unassigned bits of the Route Information option are reserved. They 2194 MUST be set to zero on transmission and MUST be ignored on reception. 2196 6.7.6. DODAG Configuration 2198 The DODAG Configuration option MAY be present in DIO messages, and 2199 its format is as follows: 2201 0 1 2 3 2202 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 2203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2204 | Type = 4 |Opt Length = 14| Flags |A| PCS | DIOIntDoubl. | 2205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2206 | DIOIntMin. | DIORedun. | MaxRankIncrease | 2207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2208 | MinHopRankIncrease | OCP | 2209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2210 | Reserved | Def. Lifetime | Lifetime Unit | 2211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2213 Figure 24: Format of the DODAG Configuration Option 2215 The DODAG Configuration option is used to distribute configuration 2216 information for DODAG Operation through the DODAG. 2218 The information communicated in this option is generally static and 2219 unchanging within the DODAG, therefore it is not necessary to include 2220 in every DIO. This information is configured at the DODAG Root and 2221 distributed throughout the DODAG with the DODAG Configuration Option. 2222 Nodes other than the DODAG Root MUST NOT modify this information when 2223 propagating the DODAG Configuration option. This option MAY be 2224 included occasionally by the DODAG Root (as determined by the DODAG 2225 Root), and MUST be included in response to a unicast request, e.g. a 2226 unicast DODAG Information Solicitation (DIS) message. 2228 Option Type: 0x04 (to be confirmed by IANA) 2230 Option Length: 14 2232 Flags: 4-bit unused field reserved for flags. The field MUST be 2233 initialized to zero by the sender and MUST be ignored by the 2234 receiver. 2236 Authentication Enabled (A): One bit flag describing the security 2237 mode of the network. The bit describe whether a node must 2238 authenticate with a key authority before joining the network as 2239 a router. If the DIO is not a secure DIO, the 'A' bit MUST be 2240 zero. 2242 Path Control Size (PCS): 3-bit unsigned integer used to configure 2243 the number of bits that may be allocated to the Path Control 2244 field (see Section 9.9). Note that when PCS is consulted to 2245 determine the width of the Path Control field a value of 1 is 2246 added, i.e. a PCS value of 0 results in 1 active bit in the 2247 Path Control field. The default value of PCS is 2248 DEFAULT_PATH_CONTROL_SIZE. 2250 DIOIntervalDoublings: 8-bit unsigned integer used to configure Imax 2251 of the DIO trickle timer (see Section 8.3.1). The default 2252 value of DIOIntervalDoublings is 2253 DEFAULT_DIO_INTERVAL_DOUBLINGS. 2255 DIOIntervalMin: 8-bit unsigned integer used to configure Imin of the 2256 DIO trickle timer (see Section 8.3.1). The default value of 2257 DIOIntervalMin is DEFAULT_DIO_INTERVAL_MIN. 2259 DIORedundancyConstant: 8-bit unsigned integer used to configure k of 2260 the DIO trickle timer (see Section 8.3.1). The default value 2261 of DIORedundancyConstant is DEFAULT_DIO_REDUNDANCY_CONSTANT. 2263 MaxRankIncrease: 16-bit unsigned integer used to configure 2264 DAGMaxRankIncrease, the allowable increase in rank in support 2265 of local repair. If DAGMaxRankIncrease is 0 then this 2266 mechanism is disabled. 2268 MinHopRankInc 16-bit unsigned integer used to configure 2269 MinHopRankIncrease as described in Section 3.5.1. The default 2270 value of MinHopRankInc is DEFAULT_MIN_HOP_RANK_INCREASE. 2272 Default Lifetime: 8-bit unsigned integer. This is the lifetime that 2273 is used as default for all RPL routes. It is expressed in 2274 units of Lifetime Units, e.g. the default lifetime in seconds 2275 is (Default Lifetime) * (Lifetime Unit). 2277 Lifetime Unit: 16-bit unsigned integer. Provides the unit in 2278 seconds that is used to express route lifetimes in RPL. For 2279 very stable networks, it can be hours to days. 2281 Objective Code Point (OCP) 16-bit unsigned integer. The OCP field 2282 identifies the OF and is managed by the IANA. 2284 6.7.7. RPL Target 2286 The RPL Target option MAY be present in DAO messages, and its format 2287 is as follows: 2289 0 1 2 3 2290 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 2291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2292 | Type = 5 | Option Length | Flags | Prefix Length | 2293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2294 | | 2295 + + 2296 | Target Prefix (Variable Length) | 2297 . . 2298 . . 2299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2301 Figure 25: Format of the RPL Target Option 2303 The RPL Target Option is used to indicate a target IPv6 address, 2304 prefix, or multicast group that is reachable or queried along the 2305 DODAG. In a DAO, the RPL Target option indicates reachability. 2307 A RPL Target Option May optionally be paired with a RPL Target 2308 Descriptor Option (Figure 30) that qualifies the target. 2310 A set of one or more Transit Information options (Section 6.7.8) MAY 2311 directly follow a set of one or more Target option in a DAO message 2312 (where each Target Option MAY be paired with a RPL Target Descriptor 2313 Option as above). The structure of the DAO message, detailing how 2314 Target options are used in conjunction with Transit Information 2315 options, is further described in Section 9.4. 2317 The RPL Target option may be repeated as necessary to indicate 2318 multiple targets. 2320 Option Type: 0x05 (to be confirmed by IANA) 2322 Option Length: Variable, length of the option in octets excluding 2323 the Type and Length fields. 2325 Flags: 8-bit unused field reserved for flags. The field MUST be 2326 initialized to zero by the sender and MUST be ignored by the 2327 receiver. 2329 Prefix Length: 8-bit unsigned integer. Number of valid leading bits 2330 in the IPv6 Prefix. 2332 Target Prefix: Variable-length field identifying an IPv6 destination 2333 address, prefix, or multicast group. The Prefix Length field 2334 contains the number of valid leading bits in the prefix. The 2335 bits in the prefix after the prefix length (if any) are 2336 reserved and MUST be set to zero on transmission and MUST be 2337 ignored on receipt. 2339 6.7.8. Transit Information 2341 The Transit Information option MAY be present in DAO messages, and 2342 its format is as follows: 2344 0 1 2 3 2345 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 2346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2347 | Type = 6 | Option Length |E| Flags | Path Control | 2348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2349 | Path Sequence | Path Lifetime | | 2350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 2351 | | 2352 + + 2353 | | 2354 + Parent Address* + 2355 | | 2356 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2357 | | 2358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2360 The '*' denotes that the Parent Address is not always present, as 2361 described below. 2363 Figure 26: Format of the Transit Information option 2365 The Transit Information option is used for a node to indicate 2366 attributes for a path to one or more destinations. The destinations 2367 are indicated by one or more Target options that immediately precede 2368 the Transit Information option(s). 2370 The Transit Information option can be used for a node to indicate its 2371 DODAG parents to an ancestor that is collecting DODAG routing 2372 information, typically for the purpose of constructing source routes. 2373 In the non-storing mode of operation this ancestor will be the DODAG 2374 Root, and this option is carried by the DAO message. In the storing 2375 mode of operation the Parent Address is not needed, since the DAO 2376 message is sent directly to the parent. The option length is used to 2377 determine whether the Parent Address is present or not. 2379 A non-storing node that has more than one DAO parent MAY include a 2380 Transit Information option for each DAO parent as part of the non- 2381 storing destination advertisement operation. The node may distribute 2382 the bits in the Path Control field among different groups of DAO 2383 parents in order to signal a preference among parents. That 2384 preference may influence the decision of the DODAG root when 2385 selecting among the alternate parents/paths for constructing downward 2386 routes. 2388 One or more Transit Information options MUST be preceded by one or 2389 more RPL Target options. In this manner the RPL Target option 2390 indicates the child node, and the Transit Information option(s) 2391 enumerate the DODAG parents. The structure of the DAO message, 2392 further detailing how Target options are used in conjunction with 2393 Transit Information options, is further described in Section 9.4. 2395 A typical non-storing node will use multiple Transit Information 2396 options, and it will send the DAO message thus formed directly to the 2397 root. A typical storing node will use one Transit Information option 2398 with no parent field, and will send the DAO message thus formed, with 2399 additional adjustments to Path Control as detailed later, to one or 2400 multiple parents. 2402 For example, in a non-storing mode of operation let Tgt(T) denote a 2403 Target option for a target T. Let Trnst(P) denote a Transit 2404 Information option that contains a parent address P. Consider the 2405 case of a non-storing node N that advertises the self-owned targets 2406 N1 and N2 and has parents P1, P2, and P3. In that case the DAO 2407 message would be expected to contain the sequence ( (Tgt(N1), 2408 Tgt(N2)), (Trnst(P1), Trnst(P2), Trnst(P3)) ), such that the group of 2409 Target options {N1, N2} are described by the Transit Information 2410 options as having the parents {P1, P2, P3}. The non-storing node 2411 would then address that DAO message directly to the DODAG root, and 2412 forward that DAO message through one of the DODAG parents P1, P2, or 2413 P3. 2415 Option Type: 0x06 (to be confirmed by IANA) 2417 Option Length: Variable, depending on whether or not Parent Address 2418 is present. 2420 External (E): 1-bit flag. The 'E' flag is set to indicate that the 2421 parent router redistributes external targets into the RPL 2422 network. An external target is a target that has been learned 2423 through an alternate protocol. The external targets are listed 2424 in the target options that immediately precede the Transit 2425 Information option. An external target is not expected to 2426 support RPL messages and options. 2428 Flags: 7-bit unused field reserved for flags. The field MUST be 2429 initialized to zero by the sender and MUST be ignored by the 2430 receiver. 2432 Path Control: 8-bit bitfield. The Path Control field limits the 2433 number of DAO-Parents to which a DAO message advertising 2434 connectivity to a specific destination may be sent, as well as 2435 providing some indication of relative preference. The limit 2436 provides some bound on overall DAO message fan-out in the LLN. 2437 The assignment and ordering of the bits in the path control 2438 also serves to communicate preference. Not all of these bits 2439 may be enabled as according to the PCS in the DODAG 2440 Configuration. The Path Control field is divided into four 2441 subfields which contain two bits each: PC1, PC2, PC3, and PC4, 2442 as illustrated in Figure 27. The subfields are ordered by 2443 preference, with PC1 being the most preferred and PC4 being the 2444 least preferred. Within a subfield there is no order of 2445 preference. By grouping the parents (as in ECMP) and ordering 2446 them, the parents may be associated with specific bits in the 2447 Path Control field in a way that communicates preference. 2449 0 1 2 3 4 5 6 7 2450 +-+-+-+-+-+-+-+-+ 2451 |PC1|PC2|PC3|PC4| 2452 +-+-+-+-+-+-+-+-+ 2454 Figure 27: Path Control Preference Sub-field Encoding 2456 Path Sequence: 8-bit unsigned integer. When a RPL Target option is 2457 issued by the node that owns the Target Prefix (i.e. in a DAO 2458 message), that node sets the Path Sequence and increments the 2459 Path Sequence each time it issues a RPL Target option with 2460 updated information. 2462 Path Lifetime: 8-bit unsigned integer. The length of time in 2463 Lifetime Units (obtained from the Configuration option) that 2464 the prefix is valid for route determination. The period starts 2465 when a new Path Sequence is seen. A value of all one bits 2466 (0xFF) represents infinity. A value of all zero bits (0x00) 2467 indicates a loss of reachability. A DAO message that contains 2468 a Transit Information option with a Path Lifetime of 0x00 for a 2469 Target is referred as a No-Path (for that Target) in this 2470 document. 2472 Parent Address (optional): IPv6 Address of the DODAG Parent of the 2473 node originally issuing the Transit Information Option. This 2474 field may not be present, as according to the DODAG Mode of 2475 Operation (storing or non-storing) and indicated by the Transit 2476 Information option length. 2478 Unassigned bits of the Transit Information option are reserved. They 2479 MUST be set to zero on transmission and MUST be ignored on reception. 2481 6.7.9. Solicited Information 2483 The Solicited Information option MAY be present in DIS messages, and 2484 its format is as follows: 2486 0 1 2 3 2487 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 2488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2489 | Type = 7 |Opt Length = 19| RPLInstanceID |V|I|D| Flags | 2490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2491 | | 2492 + + 2493 | | 2494 + DODAGID + 2495 | | 2496 + + 2497 | | 2498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2499 |Version Number | 2500 +-+-+-+-+-+-+-+-+ 2502 Figure 28: Format of the Solicited Information Option 2504 The Solicited Information option is used for a node to request DIO 2505 messages from a subset of neighboring nodes. The Solicited 2506 Information option may specify a number of predicate criteria to be 2507 matched by a receiving node. This is used by the requester to limit 2508 the number of replies from "non-interesting" nodes. These predicates 2509 affect whether a node resets its DIO trickle timer, as described in 2510 Section 8.3. 2512 The Solicited Information option contains flags that indicate which 2513 predicates a node should check when deciding whether to reset its 2514 Trickle timer. A node resets its Trickle timer when all predicates 2515 are true. If a flag is set, then the RPL node MUST check the 2516 associated predicate. If a flag is cleared, then the RPL node MUST 2517 NOT check the associated predicate. (If a flag is cleared, the RPL 2518 node assumes that the associated predicate is true). 2520 Option Type: 0x07 (to be confirmed by IANA) 2522 Option Length: 19 2524 V: The V flag is the Version predicate. The Version predicate is 2525 true if the receiver's DODAGVersionNumber matches the requested 2526 Version Number. If the V flag is cleared then the Version 2527 field is not valid and the Version field MUST be set to zero on 2528 transmission and ignored upon receipt. 2530 I: The I flag is the InstanceID predicate. The InstanceID 2531 predicate is true when the RPL node's current RPLInstanceID 2532 matches the requested RPLInstanceID. If the I flag is cleared 2533 then the RPLInstanceID field is not valid and the RPLInstanceID 2534 field MUST be set to zero on transmission and ignored upon 2535 receipt. 2537 D: The D flag is the DODAGID predicate. The DODAGID predicate is 2538 true if the RPL node's parent set has the same DODAGID as the 2539 DODAGID field. If the D flag is cleared then the DODAGID field 2540 is not valid and the DODAGID field MUST be set to zero on 2541 transmission and ignored upon receipt. 2543 Flags: 5-bit unused field reserved for flags. The field MUST be 2544 initialized to zero by the sender and MUST be ignored by the 2545 receiver. 2547 Version Number: 8-bit unsigned integer containing the value of 2548 DODAGVersionNumber that is being solicited when valid. 2550 RPLInstanceID: 8-bit unsigned integer containing the RPLInstanceID 2551 that is being solicited when valid. 2553 DODAGID: 128-bit unsigned integer containing the DODAGID that is 2554 being solicited when valid. 2556 Unassigned bits of the Solicited Information option are reserved. 2557 They MUST be set to zero on transmission and MUST be ignored on 2558 reception. 2560 6.7.10. Prefix Information 2562 The Prefix Information option MAY be present in DIO messages, and 2563 carries the information that is specified for the IPv6 ND Prefix 2564 Information Option in [RFC4861], [RFC4862] and [RFC3775] for use by 2565 RPL nodes and IPv6 hosts. In particular, a RPL node may use this 2566 option for the purpose of State-Less Address Auto-Configuration 2567 (SLAAC) from a prefix advertised by a parent as specified in 2568 [RFC4862], and advertise its own address as specified in [RFC3775]. 2569 The root of a DODAG is authoritative for setting that information. 2570 The information is propagated down the DODAG unchanged, with the 2571 exception that a RPL router may update (extend) the prefix by 2572 appending it's own suffix. The format of the option is modified 2573 (Type, Length, Prefix) in order to be carried as a RPL option as 2574 follows: 2576 0 1 2 3 2577 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 2578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2579 | Type = 8 |Opt Length = 30| Prefix Length |L|A|R|Reserved1| 2580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2581 | Valid Lifetime | 2582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2583 | Preferred Lifetime | 2584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2585 | Reserved2 | 2586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2587 | | 2588 + + 2589 | | 2590 + Prefix + 2591 | | 2592 + + 2593 | | 2594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2596 Figure 29: Format of the Prefix Information Option 2598 The Prefix Information option may be used to distribute the prefix in 2599 use inside the DODAG, e.g. for address autoconfiguration. 2601 [RFC4861] and [RFC3775] should be consulted as the authoritative 2602 reference with respect to the Prefix Information option. The field 2603 descriptions are transcribed here for convenience: 2605 Option Type: 0x08 (to be confirmed by IANA) 2607 Option Length: 30. Note that this length is expressed in units of 2608 single-octets, unlike in IPv6 ND. 2610 Prefix Length 8-bit unsigned integer. The number of leading bits in 2611 the Prefix that are valid. The value ranges from 0 to 128. 2612 The prefix length field provides necessary information for on- 2613 link determination (when combined with the L flag in the prefix 2614 information option). It also assists with address 2615 autoconfiguration as specified in [RFC4862], for which there 2616 may be more restrictions on the prefix length. 2618 L 1-bit on-link flag. When set, indicates that this prefix can 2619 be used for on-link determination. When not set the 2620 advertisement makes no statement about on-link or off-link 2621 properties of the prefix. In other words, if the L flag is not 2622 set a RPL node MUST NOT conclude that an address derived from 2623 the prefix is off-link. That is, it MUST NOT update a previous 2624 indication that the address is on-link. A RPL node acting as a 2625 router MUST NOT propagate a PIO with the L flag set. A RPL 2626 node acting as a router MAY propagate a PIO with the L flag not 2627 set. 2629 A 1-bit autonomous address-configuration flag. When set 2630 indicates that this prefix can be used for stateless address 2631 configuration as specified in [RFC4862]. When both protocols 2632 (ND RAs and RPL DIOs) are used to carry PIOs on the same link, 2633 it is possible to use either one for SLAAC by a RPL node. It 2634 is also possible to make either protocol ineligible for SLAAC 2635 operation by forcing the A flag to 0 for PIOs carried in that 2636 protocol. 2638 R 1-bit Router address flag. When set, indicates that the Prefix 2639 field contains a complete IPv6 address assigned to the sending 2640 router that can be used as parent in a target option. The 2641 indicated prefix is the first Prefix Length bits of the Prefix 2642 field. The router IPv6 address has the same scope and conforms 2643 to the same lifetime values as the advertised prefix. This use 2644 of the Prefix field is compatible with its use in advertising 2645 the prefix itself, since Prefix Advertisement uses only the 2646 leading bits. Interpretation of this flag bit is thus 2647 independent of the processing required for the On-Link (L) and 2648 Autonomous Address-Configuration (A) flag bits. 2650 Reserved1 5-bit unused field. It MUST be initialized to zero by the 2651 sender and MUST be ignored by the receiver. 2653 Valid Lifetime 32-bit unsigned integer. The length of time in 2654 seconds (relative to the time the packet is sent) that the 2655 prefix is valid for the purpose of on-link determination. A 2656 value of all one bits (0xffffffff) represents infinity. The 2657 Valid Lifetime is also used by [RFC4862]. 2659 Preferred Lifetime 32-bit unsigned integer. The length of time in 2660 seconds (relative to the time the packet is sent) that 2661 addresses generated from the prefix via stateless address 2662 autoconfiguration remain preferred [RFC4862]. A value of all 2663 one bits (0xffffffff) represents infinity. See [RFC4862]. 2664 Note that the value of this field MUST NOT exceed the Valid 2665 Lifetime field to avoid preferring addresses that are no longer 2666 valid. 2668 Reserved2 This field is unused. It MUST be initialized to zero by 2669 the sender and MUST be ignored by the receiver. 2671 Prefix An IPv6 address or a prefix of an IPv6 address. The Prefix 2672 Length field contains the number of valid leading bits in the 2673 prefix. The bits in the prefix after the prefix length are 2674 reserved and MUST be initialized to zero by the sender and 2675 ignored by the receiver. A router SHOULD NOT send a prefix 2676 option for the link-local prefix and a host SHOULD ignore such 2677 a prefix option. A non-storing node SHOULD refrain from 2678 advertising a prefix till it owns an address of that prefix, 2679 and then it SHOULD advertise its full address in this field, 2680 with the 'R' flag set. The children of a node that so 2681 advertises a full address with the 'R' flag set may then use 2682 that address to determine the content of the Parent Address 2683 field of the Transit Information Option. 2685 Unassigned bits of the Prefix Information option are reserved. They 2686 MUST be set to zero on transmission and MUST be ignored on reception. 2688 6.7.11. RPL Target Descriptor 2690 The RPL Target option MAY be immediately followed by one opaque 2691 descriptor that qualifies that specific target. 2693 0 1 2 3 2694 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 2695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2696 | Type = 9 |Opt Length = 4 | Descriptor 2697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2698 Descriptor (cont.) | 2699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2701 Figure 30: Format of the RPL Target Descriptor Option 2703 The RPL Target Descriptor Option is used to qualify a target, 2704 something that is sometimes called tagging. 2706 There can be at most one descriptor per target. The descriptor is 2707 set by the node that injects the target in the RPL network. It MUST 2708 be copied but not modified by routers that propagate the target Up 2709 the DODAG in DAO messages. 2711 Option Type: 0x09 (to be confirmed by IANA) 2713 Option Length: 4 2715 Descriptor: 32-bit unsigned integer. Opaque. 2717 7. Sequence Counters 2719 This section describes the general scheme for bootstrap and operation 2720 of sequence counters in RPL, such as the DODAGVersionNumber in the 2721 DIO message, the DAOSequence in the DAO message, and the Path 2722 Sequence in the Transit Information option. 2724 7.1. Sequence Counter Overview 2726 This specification utilizes three different sequence numbers to 2727 validate the freshness and the synchronization of protocol 2728 information: 2730 DODAGVersionNumber: This sequence counter is present in the DIO 2731 base to indicate the Version of the DODAG being formed. The 2732 DODAGVersionNumber is monotonically incremented by the root 2733 each time the root decides to form a new Version of the DODAG 2734 in order to revalidate the integrity and allow a global repairs 2735 to occur. The DODAGVersionNumber is propagated unchanged Down 2736 the DODAG as routers join the new DODAG Version. The 2737 DODAGVersionNumber is globally significant in a DODAG and 2738 indicates the Version of the DODAG that a router is operating 2739 in. An older (lesser) value indicates that the originating 2740 router has not migrated to the new DODAG Version and can not be 2741 used as a parent once the receiving node has migrated to the 2742 newer DODAG Version. 2744 DAOSequence: This sequence counter is present in the DAO base to 2745 correlate a DAO message and a DAO ACK message. The DAOSequence 2746 number is locally significant to the node that issues a DAO 2747 message for its own consumption to detect the loss of a DAO 2748 message and enable retries. 2750 Path Sequence: This sequence counter is present in the Transit 2751 Information option in a DAO message. The purpose of this 2752 counter is to differentiate a movement where a newer route 2753 supersedes a stale one from a route redundancy scenario where 2754 multiple routes exist in parallel for a same target. The Path 2755 Sequence is globally significant in a DODAG and indicates the 2756 freshness of the route to the associated target. An older 2757 (lesser) value received from an originating router indicates 2758 that the originating router holds stale routing states and the 2759 originating router should not be considered anymore as a 2760 potential next-hop for the target. The Path Sequence is 2761 computed by the node that advertises the target, that is the 2762 target itself or a router that advertises a target on behalf of 2763 a host, and is unchanged as the DAO content is propagated 2764 towards the root by parent routers. If a host does not pass a 2765 counter to its router, then the router is in charge of 2766 computing the Path Sequence on behalf of the host and the host 2767 can only register to one router for that purpose. If a DAO 2768 message containing a same target is issued to multiple parents 2769 at a given point of time for the purpose of route redundancy, 2770 then the Path Sequence is the same in all the DAO messages for 2771 that same target. 2773 7.2. Sequence Counter Operation 2775 RPL sequence counters are subdivided in a 'lollipop' fashion 2776 ([Perlman83]), where the values from 128 and greater are used as a 2777 linear sequence to indicate a restart and bootstrap the counter, and 2778 the values less than or equal to 127 used as a circular sequence 2779 number space of size 128 as in [RFC1982]. Consideration is given to 2780 the mode of operation when transitioning from the linear region to 2781 the circular region. Finally, when operating in the circular region, 2782 if sequence numbers are detected to be too far apart then they are 2783 not comparable, as detailed below. 2785 A window of comparison, SEQUENCE_WINDOW = 16, is configured based on 2786 a value of 2^N, where N is defined to be 4 in this specification. 2788 For a given sequence counter, 2790 1. The sequence counter SHOULD be initialized to an implementation 2791 defined value which is 128 or greater prior to use. A 2792 recommended value is 240 (256 - SEQUENCE_WINDOW). 2794 2. When a sequence counter increment would cause the sequence 2795 counter to increment beyond its maximum value, the sequence 2796 counter MUST wrap back to zero. When incrementing a sequence 2797 counter greater than or equal to 128, the maximum value is 255. 2798 When incrementing a sequence counter less than 128, the maximum 2799 value is 127. 2801 3. When comparing two sequence counters, the following rules MUST be 2802 applied: 2804 1. When a first sequence counter A is in the interval [128..255] 2805 and a second sequence counter B is in [0..127]: 2807 1. If (256 + B - A) is less than or equal to 2808 SEQUENCE_WINDOW, then B is greater than A, A is less than 2809 B, and the two are not equal. 2811 2. If (256 + B - A) is greater than SEQUENCE_WINDOW, then A 2812 is greater than B, B is less than A, and the two are not 2813 equal. 2815 For example, if A is 240, and B is 5, then (256 + 5 - 240) is 2816 21. 21 is greater than SEQUENCE_WINDOW (16), thus 240 is 2817 greater than 5. As another example, if A is 250 and B is 5, 2818 then (256 + 5 - 250) is 11. 11 is less than SEQUENCE_WINDOW 2819 (16), thus 250 is less than 5. 2821 2. In the case where both sequence counters to be compared are 2822 less than or equal to 127, and in the case where both 2823 sequence counters to be compared are greater than or equal to 2824 128: 2826 1. If the absolute magnitude of difference between the two 2827 sequence counters is less than or equal to 2828 SEQUENCE_WINDOW, then a comparison as described in 2829 [RFC1982] is used to determine the relationships greater 2830 than, less than, and equal. 2832 2. If the absolute magnitude of difference of the two 2833 sequence counters is greater than SEQUENCE_WINDOW, then a 2834 desynchronization has occurred and the two sequence 2835 numbers are not comparable. 2837 4. If two sequence numbers are determined to be not comparable, i.e. 2838 the results of the comparison are not defined, then a node should 2839 consider the comparison as if it has evaluated in such a way so 2840 as to give precedence to the sequence number that has most 2841 recently been observed to increment. Failing this, the node 2842 should consider the comparison as if it has evaluated in such a 2843 way so as to minimize the resulting changes to its own state. 2845 8. Upward Routes 2847 This section describes how RPL discovers and maintains upward routes. 2848 It describes the use of DODAG Information Objects (DIOs), the 2849 messages used to discover and maintain these routes. It specifies 2850 how RPL generates and responds to DIOs. It also describes DODAG 2851 Information Solicitation (DIS) messages, which are used to trigger 2852 DIO transmissions. 2854 As mentioned in Section 3.2.8, nodes that decide to join a DODAG MUST 2855 provision at least one DODAG parent as a default route for the 2856 associated instance. This default route enables a packet to be 2857 forwarded upwards until it eventually hits a common ancestor from 2858 which it will be routed downwards to the destination. If the 2859 destination is not in the DODAG, then the DODAG root may be able to 2860 forward the packet using connectivity to the outside of the DODAG; if 2861 it can not forward the packet outside then the DODAG root has to drop 2862 it. 2864 A DIO message can also transport explicit routing information: 2866 DODAGID The DODAGID is a Global or Unique Local IPv6 Address of the 2867 root. A node that joins a DODAG SHOULD provision a host route 2868 via a DODAG parent to the address used by the root as DODAGID. 2870 RIO Prefix The root MAY place one or more Route Information options 2871 in a DIO message. The RIO is used to advertise an external 2872 route that is reachable via the root, associated with a 2873 preference, as presented in Section 6.7.5, which incorporates 2874 the RIO from [RFC4191]. It is interpreted as a capability of 2875 the root as opposed to a routing advertisement and it MUST NOT 2876 be redistributed in another routing protocol though it SHOULD 2877 be used by an ingress RPL router to select a DODAG when a 2878 packet is injected in a RPL domain from a node attached to that 2879 RPL router. An Objective Function MAY use the routes 2880 advertised in RIO or the preference for those routes in order 2881 to favor a DODAG versus another one for a same instance. 2883 8.1. DIO Base Rules 2885 1. For the following DIO Base fields, a node that is not a DODAG 2886 root MUST advertise the same values as its preferred DODAG parent 2887 (defined in Section 8.2.1). In this way these values will 2888 propagate Down the DODAG unchanged and advertised by every node 2889 that has a route to that DODAG root. These fields are: 2890 1. Grounded (G) 2891 2. Mode of Operation (MOP) 2892 3. DAGPreference (Prf) 2893 4. Version 2894 5. RPLInstanceID 2895 6. DODAGID 2897 2. A node MAY update the following fields at each hop: 2898 1. Rank 2899 2. DTSN 2901 3. The DODAGID field each root sets MUST be unique within the RPL 2902 Instance and MUST be a routable IPv6 address belonging to the 2903 root. 2905 8.2. Upward Route Discovery and Maintenance 2907 Upward route discovery allows a node to join a DODAG by discovering 2908 neighbors that are members of the DODAG of interest and identifying a 2909 set of parents. The exact policies for selecting neighbors and 2910 parents is implementation-dependent and driven by the OF. This 2911 section specifies the set of rules those policies must follow for 2912 interoperability. 2914 8.2.1. Neighbors and Parents within a DODAG Version 2916 RPL's upward route discovery algorithms and processing are in terms 2917 of three logical sets of link-local nodes. First, the candidate 2918 neighbor set is a subset of the nodes that can be reached via link- 2919 local multicast. The selection of this set is implementation- 2920 dependent and OF-dependent. Second, the parent set is a restricted 2921 subset of the candidate neighbor set. Finally, the preferred parent 2922 is a member of the parent set that is the preferred next hop in 2923 upward routes. The preferred parent is conceptually a single parent 2924 although it may be a set of multiple parents if those parents are 2925 equally preferred and have identical rank. 2927 More precisely: 2929 1. The DODAG parent set MUST be a subset of the candidate neighbor 2930 set. 2932 2. A DODAG root MUST have a DODAG parent set of size zero. 2934 3. A node that is not a DODAG root MAY maintain a DODAG parent set 2935 of size greater than or equal to one. 2937 4. A node's preferred DODAG parent MUST be a member of its DODAG 2938 parent set. 2940 5. A node's rank MUST be greater than all elements of its DODAG 2941 parent set. 2943 6. When Neighbor Unreachability Detection (NUD) [RFC4861], or an 2944 equivalent mechanism, determines that a neighbor is no longer 2945 reachable, a RPL node MUST NOT consider this node in the 2946 candidate neighbor set when calculating and advertising routes 2947 until it determines that it is again reachable. Routes through 2948 an unreachable neighbor MUST be removed from the routing table. 2950 These rules ensure that there is a consistent partial order on nodes 2951 within the DODAG. As long as node ranks do not change, following the 2952 above rules ensures that every node's route to a DODAG root is loop- 2953 free, as rank decreases on each hop to the root. 2955 The OF can guide candidate neighbor set and parent set selection, as 2956 discussed in [I-D.ietf-roll-of0]. 2958 8.2.2. Neighbors and Parents across DODAG Versions 2960 The above rules govern a single DODAG Version. The rules in this 2961 section define how RPL operates when there are multiple DODAG 2962 Versions: 2964 8.2.2.1. DODAG Version 2966 1. The tuple (RPLInstanceID, DODAGID, DODAGVersionNumber) uniquely 2967 defines a DODAG Version. Every element of a node's DODAG parent 2968 set, as conveyed by the last heard DIO message from each DODAG 2969 parent, MUST belong to the same DODAG Version. Elements of a 2970 node's candidate neighbor set MAY belong to different DODAG 2971 Versions. 2973 2. A node is a member of a DODAG Version if every element of its 2974 DODAG parent set belongs to that DODAG Version, or if that node 2975 is the root of the corresponding DODAG. 2977 3. A node MUST NOT send DIOs for DODAG Versions of which it is not a 2978 member. 2980 4. DODAG roots MAY increment the DODAGVersionNumber that they 2981 advertise and thus move to a new DODAG Version. When a DODAG 2982 root increments its DODAGVersionNumber, it MUST follow the 2983 conventions of Serial Number Arithmetic as described in 2984 Section 7. Events triggering the increment of the 2985 DODAGVersionNumber are described later in this section and in 2986 Section 17. 2988 5. Within a given DODAG, a node that is a not a root MUST NOT 2989 advertise a DODAGVersionNumber higher than the highest 2990 DODAGVersionNumber it has heard. Higher is defined as the 2991 greater-than operator in Section 7. 2993 6. Once a node has advertised a DODAG Version by sending a DIO, it 2994 MUST NOT be a member of a previous DODAG Version of the same 2995 DODAG (i.e. with the same RPLInstanceID, the same DODAGID, and a 2996 lower DODAGVersionNumber). Lower is defined as the less-than 2997 operator in Section 7. 2999 When the DODAG parent set becomes empty on a node that is not a root, 3000 (i.e. the last parent has been removed, causing the node to no longer 3001 be associated with that DODAG), then the DODAG information should not 3002 be suppressed until after the expiration of an implementation- 3003 specific local timer in order to observe if the DODAGVersionNumber 3004 has been incremented, should any new parents appear for the DODAG. 3005 This will help protect against the possibility of loops that may 3006 occur if that node were to inadvertently rejoin the old DODAG Version 3007 in its own prior sub-DODAG. 3009 As the DODAGVersionNumber is incremented, a new DODAG Version spreads 3010 outward from the DODAG root. A parent that advertises the new 3011 DODAGVersionNumber cannot belong to the sub-DODAG of a node 3012 advertising an older DODAGVersionNumber. Therefore a node can safely 3013 add a parent of any Rank with a newer DODAGVersionNumber without 3014 forming a loop. 3016 For example, suppose that a node has left a DODAG with 3017 DODAGVersionNumber N. Suppose that node had a sub-DODAG, and did 3018 attempt to poison that sub-DODAG by advertising a rank of 3019 INFINITE_RANK, but those advertisements may have become lost in the 3020 LLN. Then, if the node did observe a candidate neighbor advertising 3021 a position in that original DODAG at DODAGVersionNumber N, that 3022 candidate neighbor could possibly have been in the node's former sub- 3023 DODAG and there is a possible case where to add that candidate 3024 neighbor as a parent could cause a loop. If that candidate neighbor 3025 in this case is observed to advertise a DODAGVersionNumber N+1, then 3026 that candidate neighbor is certain to be safe, since it is certain 3027 not to be in that original node's sub-DODAG as it has been able to 3028 increment the DODAGVersionNumber by hearing from the DODAG root while 3029 that original node was detached. It is for this reason that it is 3030 useful for the detached node to remember the original DODAG 3031 information, including the DODAGVersionNumber N. 3033 Exactly when a DODAG Root increments the DODAGVersionNumber is 3034 implementation dependent and out of scope for this specification. 3035 Examples include incrementing the DODAGVersionNumber periodically, 3036 upon administrative intervention, or on application-level detection 3037 of lost connectivity or DODAG inefficiency. 3039 After a node transitions to and advertises a new DODAG Version, the 3040 rules above make it unable to advertise the previous DODAG Version 3041 (prior DODAGVersionNumber) once it has committed to advertising the 3042 new DODAG Version. 3044 8.2.2.2. DODAG Roots 3046 1. A DODAG root without possibility to satisfy the application- 3047 defined goal MUST NOT set the Grounded bit. 3049 2. A DODAG root MUST advertise a rank of ROOT_RANK. 3051 3. A node whose DODAG parent set is empty MAY become the DODAG Root 3052 of a floating DODAG. It MAY also set its DAGPreference such that 3053 it is less preferred. 3055 In a deployment that uses non-RPL links to federate a number of LLN 3056 roots, it is possible to run RPL over those non-RPL links and use one 3057 router as a "backbone root". The backbone root is the virtual root 3058 of the DODAG, and exposes a rank of BASE_RANK over the backbone. All 3059 the LLN roots that are parented to that backbone root, including the 3060 backbone root if it also serves as LLN root itself, expose a rank of 3061 ROOT_RANK to the LLN. These virtual roots are part of the same DODAG 3062 and advertise the same DODAGID. They coordinate DODAGVersionNumbers 3063 and other DODAG parameters with the virtual root over the backbone. 3064 The method of coordination is out of scope for this specification (to 3065 be defined in future companion specifications). 3067 8.2.2.3. DODAG Selection 3069 The objective function and the set of advertised routing metrics and 3070 constraints of a DAG determines how a node selects its neighbor set, 3071 parent set, and preferred parents. This selection implicitly also 3072 determines the DODAG within a DAG. Such selection can include 3073 administrative preference (Prf) as well as metrics or other 3074 considerations. 3076 If a node has the option to join a more preferred DODAG while still 3077 meeting other optimization objectives, then the node will generally 3078 seek to join the more preferred DODAG as determined by the OF. All 3079 else being equal, it is left to the implementation to determine which 3080 DODAG is most preferred (since, as a reminder, a node must only join 3081 one DODAG per RPL Instance). 3083 8.2.2.4. Rank and Movement within a DODAG Version 3085 1. A node MUST NOT advertise a Rank less than or equal to any member 3086 of its parent set within the DODAG Version. 3088 2. A node MAY advertise a Rank lower than its prior advertisement 3089 within the DODAG Version. 3091 3. Let L be the lowest rank within a DODAG Version that a given node 3092 has advertised. Within the same DODAG Version, that node MUST 3093 NOT advertise an effective rank higher than L + 3094 DAGMaxRankIncrease. INFINITE_RANK is an exception to this rule: 3095 a node MAY advertise an INFINITE_RANK within a DODAG version 3096 without restriction. If a node's Rank were to be higher than 3097 allowed by L + DAGMaxRankIncrease, when it advertises Rank it 3098 MUST advertise its Rank as INFINITE_RANK. 3100 4. A node MAY, at any time, choose to join a different DODAG within 3101 a RPL Instance. Such a join has no rank restrictions, unless 3102 that different DODAG is a DODAG Version of which this node has 3103 previously been a member, in which case the rule of the previous 3104 bullet (3) must be observed. Until a node transmits a DIO 3105 indicating its new DODAG membership, it MUST forward packets 3106 along the previous DODAG. 3108 5. A node MAY, at any time after hearing the next DODAGVersionNumber 3109 advertised from suitable DODAG parents, choose to migrate to the 3110 next DODAG Version within the DODAG. 3112 Conceptually, an implementation is maintaining a DODAG parent set 3113 within the DODAG Version. Movement entails changes to the DODAG 3114 parent set. Moving Up does not present the risk to create a loop but 3115 moving Down might, so that operation is subject to additional 3116 constraints. 3118 When a node migrates to the next DODAG Version, the DODAG parent set 3119 needs to be rebuilt for the new Version. An implementation could 3120 defer to migrate for some reasonable amount of time, to see if some 3121 other neighbors with potentially better metrics but higher rank 3122 announce themselves. Similarly, when a node jumps into a new DODAG 3123 it needs to construct a new DODAG parent set for this new DODAG. 3125 If a node needs to move Down a DODAG that it is attached to, 3126 increasing its Rank, then it MAY poison its routes and delay before 3127 moving as described in Section 8.2.2.5. 3129 A node is allowed to join any DODAG Version that it has never been a 3130 prior member of without any restrictions, but if the node has been a 3131 prior member of the DODAG Version then it must continue to observe 3132 the rule that it may not advertise a rank higher than 3133 L+DAGMaxRankIncrease at any point in the life of the DODAG Version. 3134 This rule must be observed so as not to create a loophole that would 3135 allow the node to effectively increment its rank all the way to 3136 INFINITE_RANK, which may have impact on other nodes and create a 3137 resource-wasting count-to-infinity scenario. 3139 8.2.2.5. Poisoning 3141 1. A node poisons routes by advertising a Rank of INFINITE_RANK. 3143 2. A node MUST NOT have any nodes with a Rank of INFINITE_RANK in 3144 its parent set. 3146 Although an implementation may advertise INFINITE_RANK for the 3147 purposes of poisoning, doing so is not the same as setting Rank to 3148 INFINITE_RANK. For example, a node may continue to send data packets 3149 whose RPL Packet Information includes a Rank that is not 3150 INFINITE_RANK, yet still advertise INFINITE_RANK in its DIOs. 3152 When a (former) parent is observed to advertise a Rank of 3153 INFINITE_RANK, that (former) parent has detached from the DODAG and 3154 is no longer able to act as a parent, nor is there any why that 3155 another node may be considered to have a Rank greater-than 3156 INFINITE_RANK. Therefore that (former) parent cannot act as a parent 3157 any longer and is removed from the parent set. 3159 8.2.2.6. Detaching 3161 1. A node unable to stay connected to a DODAG within a given DODAG 3162 Version, i.e. that cannot retain non-empty parent set without 3163 violating the rules of this specification, MAY detach from this 3164 DODAG Version. A node that detaches becomes root of its own 3165 floating DODAG and SHOULD immediately advertise this new 3166 situation in a DIO as an alternate to poisoning. 3168 8.2.2.7. Following a Parent 3170 1. If a node receives a DIO from one of its DODAG parents, 3171 indicating that the parent has left the DODAG, that node SHOULD 3172 stay in its current DODAG through an alternative DODAG parent, if 3173 possible. It MAY follow the leaving parent. 3175 A DODAG parent may have moved, migrated to the next DODAG Version, or 3176 jumped to a different DODAG. A node ought to give some preference to 3177 remaining in the current DODAG, if possible via an alternate parent, 3178 but ought to follow the parent if there are no other options. 3180 8.2.3. DIO Message Communication 3182 When an DIO message is received, the receiving node must first 3183 determine whether or not the DIO message should be accepted for 3184 further processing, and subsequently present the DIO message for 3185 further processing if eligible. 3187 1. If the DIO message is malformed, then the DIO message is not 3188 eligible for further processing and a node MUST silently discard 3189 it. (See Section 17 for error logging). 3191 2. If the sender of the DIO message is a member of the candidate 3192 neighbor set and the DIO message is not malformed, the node MUST 3193 process the DIO. 3195 8.2.3.1. DIO Message Processing 3197 As DIO messages are received from candidate neighbors, the neighbors 3198 may be promoted to DODAG parents by following the rules of DODAG 3199 discovery as described in Section 8.2. When a node places a neighbor 3200 into the DODAG parent set, the node becomes attached to the DODAG 3201 through the new DODAG parent node. 3203 The most preferred parent should be used to restrict which other 3204 nodes may become DODAG parents. Some nodes in the DODAG parent set 3205 may be of a rank less than or equal to the most preferred DODAG 3206 parent. (This case may occur, for example, if an energy constrained 3207 device is at a lesser rank but should be avoided as per an 3208 optimization objective, resulting in a more preferred parent at a 3209 greater rank). 3211 8.3. DIO Transmission 3213 RPL nodes transmit DIOs using a Trickle timer 3214 ([I-D.ietf-roll-trickle]). A DIO from a sender with a lesser DAGRank 3215 that causes no changes to the recipient's parent set, preferred 3216 parent, or Rank SHOULD be considered consistent with respect to the 3217 Trickle timer. 3219 The following packets and events MUST be considered inconsistencies 3220 with respect to the Trickle timer, and cause the Trickle timer to 3221 reset: 3223 o When a node detects an inconsistency when forwarding a packet, as 3224 detailed in Section 11.2. 3226 o When a node receives a multicast DIS message without a Solicited 3227 Information option, unless a DIS flag restricts this behavior. 3229 o When a node receives a multicast DIS with a Solicited Information 3230 option and the node matches all of the predicates in the Solicited 3231 Information option, unless a DIS flag restricts this behavior. 3233 o When a node joins a new DODAG Version (e.g. by updating its 3234 DODAGVersionNumber, joining a new RPL Instance, etc.). 3236 Note that this list is not exhaustive, and an implementation MAY 3237 consider other messages or events to be inconsistencies. 3239 A node SHOULD NOT reset its DIO trickle timer in response to unicast 3240 DIS messages. When a node receives a unicast DIS without a Solicited 3241 Information option, it MUST unicast a DIO to the sender in response. 3242 This DIO MUST include a DODAG Configuration option. When a node 3243 receives a unicast DIS message with a Solicited Information option 3244 and matches the predicates of that Solicited Information option, it 3245 MUST unicast a DIO to the sender in response. This unicast DIO MUST 3246 include a DODAG Configuration Option. Thus a node MAY transmit a 3247 unicast DIS message to a potential DODAG parent in order to probe for 3248 DODAG Configuration and other parameters. 3250 8.3.1. Trickle Parameters 3252 The configuration parameters of the trickle timer are specified as 3253 follows: 3255 Imin: learned from the DIO message as (2^DIOIntervalMin)ms. The 3256 default value of DIOIntervalMin is DEFAULT_DIO_INTERVAL_MIN. 3258 Imax: learned from the DIO message as DIOIntervalDoublings. The 3259 default value of DIOIntervalDoublings is 3260 DEFAULT_DIO_INTERVAL_DOUBLINGS. 3262 k: learned from the DIO message as DIORedundancyConstant. The 3263 default value of DIORedundancyConstant is 3264 DEFAULT_DIO_REDUNDANCY_CONSTANT. In RPL, when k has the value 3265 of 0x00 this is to be treated as a redundancy constant of 3266 infinity in RPL, i.e. Trickle never suppresses messages. 3268 8.4. DODAG Selection 3270 The DODAG selection is implementation and OF dependent. In order to 3271 limit erratic movements, and all metrics being equal, nodes SHOULD 3272 keep their previous selection. Also, nodes SHOULD provide a means to 3273 filter out a parent whose availability is detected as fluctuating, at 3274 least when more stable choices are available. 3276 When connection to a grounded DODAG is not possible or preferable for 3277 security or other reasons, scattered DODAGs MAY aggregate as much as 3278 possible into larger DODAGs in order to allow connectivity within the 3279 LLN. 3281 A node SHOULD verify that bidirectional connectivity and adequate 3282 link quality is available with a candidate neighbor before it 3283 considers that candidate as a DODAG parent. 3285 8.5. Operation as a Leaf Node 3287 In some cases a RPL node may attach to a DODAG as a leaf node only. 3288 One example of such a case is when a node does not understand or does 3289 not support (policy) the RPL Instance's OF or advertised metric/ 3290 constraint. As specified in Section 17.6 related to policy function, 3291 the node may either join the DODAG as a leaf node or may not join the 3292 DODAG. As mentioned in Section 17.5, it is then recommended to log a 3293 fault. 3295 A leaf node does not extend DODAG connectivity but in some cases the 3296 leaf node may still need to transmit DIOs on occasion, in particular 3297 when the leaf node may not have always been acting as a leaf node and 3298 an inconsistency is detected. 3300 A node operating as a leaf node must obey the following rules: 3302 1. It MUST NOT transmit DIOs containing the DAG Metric Container. 3304 2. Its DIOs MUST advertise a DAGRank of INFINITE_RANK. 3306 3. It MAY suppress DIO transmission, unless the DIO transmission has 3307 been triggered due to detection of inconsistency when a packet is 3308 being forwarded or in response to a unicast DIS message, in which 3309 case the DIO transmission MUST NOT be suppressed. 3311 4. It MAY transmit unicast DAOs as described in Section 9.2. 3313 5. It MAY transmit multicast DAOs to the '1 hop' neighborhood as 3314 described in Section 9.10. 3316 A particular case that requires a leaf node to send a DIO is if that 3317 leaf node was a prior member of another DODAG and another node 3318 forwards a message assuming the old topology, triggering an 3319 inconsistency. The leaf node needs to transmit a DIO in order to 3320 repair the inconsistency. Note that due to the lossy nature of LLNs, 3321 even though the leaf node may have optimistically poisoned its routes 3322 by advertising a rank of INFINITE_RANK in the old DODAG prior to 3323 becoming a leaf node, that advertisement may have become lost and a 3324 leaf node must be capable to send a DIO later in order to repair the 3325 inconsistency. 3327 In the general case, the leaf node MUST NOT advertise itself as a 3328 router (i.e. send DIOs). 3330 8.6. Administrative Rank 3332 In some cases it might be beneficial to adjust the rank advertised by 3333 a node beyond that computed by the OF based on some implementation 3334 specific policy and properties of the node. For example, a node that 3335 has limited battery should be a leaf unless there is no other choice, 3336 and may then augment the rank computation specified by the OF in 3337 order to expose an exaggerated rank. 3339 9. Downward Routes 3341 This section describes how RPL discovers and maintains downward 3342 routes. RPL constructs and maintains downward routes with 3343 Destination Advertisement Object (DAO) messages. Downward routes 3344 support P2MP flows, from the DODAG roots toward the leaves. Downward 3345 routes also support P2P flows: P2P messages can flow toward a DODAG 3346 Root (or a common ancestor) through an upward route, then away from 3347 the DODAG Root to a destination through a downward route. 3349 This specification describes the two modes a RPL Instance may choose 3350 from for maintaining downward routes. In the first mode, called 3351 "storing", nodes store downward routing tables for their sub-DODAG. 3352 Each hop on a downward route in a storing network examines its 3353 routing table to decide on the next hop. In the second mode, called 3354 "non-storing", nodes do not store downward routing tables. Downward 3355 packets are routed with source routes populated by a DODAG Root 3356 [I-D.ietf-6man-rpl-routing-header]. 3358 RPL allows a simple one-hop P2P optimization for both storing and 3359 non-storing networks. A node may send a P2P packet destined to a 3360 one-hop neighbor directly to that node. 3362 9.1. Destination Advertisement Parents 3364 To establish downward routes, RPL nodes send DAO messages upwards. 3365 The next hop destinations of these DAO messages are called DAO 3366 parents. The collection of a node's DAO parents is called the DAO 3367 parent set. 3369 1. A node MAY send DAO messages using the all-RPL-nodes multicast 3370 address, which is an optimization to provision one-hop routing. 3371 The 'K' bit MUST be cleared on transmission of the multicast DAO. 3373 2. A node's DAO parent set MUST be a subset of its DODAG parent set. 3375 3. In storing mode operation, a node MUST NOT address unicast DAO 3376 messages to nodes that are not DAO parents. 3378 4. In storing mode operation, the IPv6 source and destination 3379 addresses of a DAO message MUST be link-local addresses. 3381 5. In non-storing mode operation, a node MUST NOT address unicast 3382 DAO messages to nodes that are not DODAG roots. 3384 6. In non-storing mode operation, the IPv6 source and destination 3385 addresses of a DAO message MUST be a unique-local or a global 3386 addresses. 3388 The selection of DAO parents is implementation and objective function 3389 specific. 3391 9.2. Downward Route Discovery and Maintenance 3393 Destination Advertisement may be configured to be entirely disabled, 3394 or operate in either a storing or non-storing mode, as reported in 3395 the MOP in the DIO message. 3397 1. All nodes who join a DODAG MUST abide by the MOP setting from the 3398 root. Nodes that do not have the capability to fully participate 3399 as a router, e.g. that does not match the advertised MOP, MAY 3400 join the DODAG as a leaf. 3402 2. If the MOP is 0, indicating no downward routing, nodes MUST NOT 3403 transmit DAO messages, and MAY ignore DAO messages. 3405 3. In non-storing mode, the DODAG Root SHOULD store source routing 3406 table entries for destinations learned from DAOs. If the Root 3407 fails to store some information, then some destination may be 3408 unreachable. 3410 4. In storing mode, all non-root, non-leaf nodes MUST store routing 3411 table entries for destinations learned from DAOs. 3413 A DODAG can have one of several possible modes of operation, as 3414 defined by the MOP field. Either it does not support downward 3415 routes, it supports downward routes through source routing from DODAG 3416 Roots, or it supports downward routes through in-network routing 3417 tables. 3419 When downward routes are supported through in-network routing tables, 3420 the multicast operation defined in this specification may or may not 3421 be supported, also as indicated by the MOP field. 3423 When downward routes are supported through in-network routing tables 3424 as described in this specification, it is expected that nodes acting 3425 as routers have been provisioned sufficiently to hold the required 3426 routing table state. If a node acting as a router is unable to hold 3427 the full routing table state then the routing state is not complete, 3428 messages may be dropped as a consequence, and a fault may be logged 3429 (Section 17.5). Future extensions to RPL may elaborate on refined 3430 actions/behaviors to manage this case. 3432 As of this specification RPL does not support mixed-mode operation, 3433 where some nodes source route and other store routing tables: future 3434 extensions to RPL may support this mode of operation. 3436 9.2.1. Maintenance of Path Sequence 3438 For each Target that is associated with (owned by) a node, that node 3439 is responsible to emit DAO messages in order to provision the 3440 downward routes. The Target+Transit information contained in those 3441 DAO messages subsequently propagates Up the DODAG. The Path Sequence 3442 counter in the Transit information option is used to indicate 3443 freshness and update stale downward routing information as described 3444 in Section 7. 3446 For a Target that is associated with (owned by) a node, that node 3447 MUST increment the Path Sequence counter, and generate a new DAO 3448 message, when: 3450 1. The Path Lifetime is to be updated (e.g. a refresh or a no-Path) 3452 2. The Parent Address list is to be changed 3454 For a Target that is associated with (owned by) a node, that node MAY 3455 increment the Path Sequence counter, and generate a new DAO message, 3456 on occasion in order to refresh the downward routing information. In 3457 storing mode, the node generates such DAO to each of its DAO parents 3458 in order to enable multipath. All DAOs generated at the same time 3459 for a same target MUST be sent with the same path sequence in the 3460 transit information. 3462 9.2.2. Generation of DAO Messages 3464 A node might send DAO messages when it receives DAO messages, as a 3465 result of changes in its DAO parent set, or in response to another 3466 event such as the expiry of a related prefix lifetime. In the case 3467 of receiving DAOs, it matters whether the DAO message is "new," or 3468 contains new information. In non-storing mode, every DAO message a 3469 node receives is "new." In storing mode, a DAO message is "new" if 3470 it satisfies any of these criteria for a contained Target: 3472 1. it has a newer Path Sequence number, 3474 2. it has additional Path Control bits, or 3476 3. is a No-Path DAO message that removes the last downward route to 3477 a prefix. 3479 A node that receives a DAO message from its sub-DODAG MAY suppress 3480 scheduling a DAO message transmission if that DAO message is not new. 3482 9.3. DAO Base Rules 3484 1. If a node sends a DAO message with newer or different information 3485 than the prior DAO message transmission, it MUST increment the 3486 DAOSequence field by at least one. A DAO message transmission 3487 that is identical to the prior DAO message transmission MAY 3488 increment the DAOSequence field. 3490 2. The RPLInstanceID and DODAGID fields of a DAO message MUST be the 3491 same value as the members of the node's parent set and the DIOs 3492 it transmits. 3494 3. A node MAY set the 'K' flag in a unicast DAO message to solicit a 3495 unicast DAO-ACK in response in order to confirm the attempt. 3497 4. A node receiving a unicast DAO message with the 'K' flag set 3498 SHOULD respond with a DAO-ACK. A node receiving a DAO message 3499 without the 'K' flag set MAY respond with a DAO-ACK, especially 3500 to report an error condition. 3502 5. A node that sets the 'K' flag in a unicast DAO message but does 3503 not receive a DAO-ACK in response MAY reschedule the DAO message 3504 transmission for another attempt, up until an implementation- 3505 specific number of retries. 3507 6. Nodes SHOULD ignore DAOs without newer sequence numbers and MUST 3508 NOT process them further. 3510 Unlike the Version field of a DIO, which is incremented only by a 3511 DODAG Root and repeated unchanged by other nodes, DAOSequence values 3512 are unique to each node. The sequence number space for unicast and 3513 multicast DAO messages can be either the same or distinct. It is 3514 RECOMMENDED to use the same sequence number space. 3516 9.4. Structure of DAO Messages 3518 DAOs follow a common structure in both storing and non-storing 3519 networks. In the most general form, a DAO message may include 3520 several groups of options, where each group consists of one or more 3521 Target options followed by one or more Transit Information options. 3522 The entire group of Transit Information options applies to the entire 3523 group of Target options. Later sections describe further details for 3524 each mode of operation. 3526 1. RPL nodes MUST include one or more RPL Target Options in each DAO 3527 message they transmit. One RPL Target Option MUST have a prefix 3528 that includes the node's IPv6 address if that node needs the 3529 DODAG to provision downward routes to that node. The RPL Target 3530 Option MAY be immediately followed by an opaque RPL Target 3531 Descriptor Option that qualifies it. 3533 2. When a node updates the information in a Transit Information 3534 option for a Target option that covers one of its addresses, it 3535 MUST increment the Path Sequence number in that Transit 3536 Information option. The Path Sequence number MAY be incremented 3537 occasionally to cause a refresh to the downward routes. 3539 3. One or more RPL Target Option in a unicast DAO message MUST be 3540 followed by one or more Transit Information Option. All the 3541 transit options apply to all the target options that immediately 3542 precede them. 3544 4. Multicast DAOs MUST NOT include the Parent Address in Transit 3545 Information options. 3547 5. A node that receives and processes a DAO message containing 3548 information for a specific Target, and that has prior information 3549 for that Target, MUST use the Path Sequence number in the Transit 3550 Information option associated with that Target in order to 3551 determine whether or not the DAO message contains updated 3552 information as per Section 7. 3554 6. If a node receives a DAO message that does not follow the above 3555 rules, it MUST discard the DAO message without further 3556 processing. 3558 In non-storing mode, the root builds a strict source routing header, 3559 hop-by-hop, by recursively looking up one-hop information that ties a 3560 target (address or prefix) and a transit address together. In some 3561 cases, when a child address is derived from a prefix that is owned 3562 and advertised by a parent, that parent-child relationship may be 3563 inferred by the root for the purpose of constructing the source 3564 routing header. In all other cases it is necessary to inform the 3565 root of the transit-target relationship from a reachable target, so 3566 as to later enable the recursive construction of the routing header. 3567 An address that is advertised as target in a DAO message MUST be 3568 collocated in the same router, or reachable onlink by the router that 3569 owns the address that is indicated in the associated transit 3570 information. The following additional rules apply to ensure the 3571 continuity of the end-to-end source route path: 3573 1. The address of a parent used in the transit option MUST be taken 3574 from a PIO from that parent with the 'R' flag set. The 'R' flag 3575 in a PIO indicates that the prefix field actually contains the 3576 full parent address but the child SHOULD NOT assume that the 3577 parent address is onlink. 3579 2. A PIO with a 'A' flag set indicates that the RPL child node may 3580 use the prefix to autoconfigure an address. A parent that 3581 advertises a prefix in a PIO with the 'A' flag set MUST ensure 3582 that the address or the whole prefix in the PIO is reachable from 3583 the root by advertising it as a DAO target. If the parent sets 3584 also the 'L' flag indicating that the prefix is onlink, then it 3585 MUST advertise the whole prefix as target in a DAO message. 3587 3. An address that is advertised as target in a DAO message MUST be 3588 collocated in the same router or reachable onlink by the router 3589 that owns the address that is indicated in the associated transit 3590 information. 3592 4. In order to enable an optimum compression of the routing header, 3593 the parent SHOULD set the 'R' flag in all PIOs with the 'A' flag 3594 set and the 'L' flag cleared, and the child SHOULD prefer to use 3595 as transit the address of the parent that is found in the PIO 3596 that is used to autoconfigure the address that is advertised as 3597 target in the DAO message. 3599 5. A router might have targets that are not known to be on-link for 3600 a parent, either because they are addresses located on an 3601 alternate interface or because they belong to nodes that are 3602 external to RPL, for instance connected hosts. In order to 3603 inject such a target in the RPL network, the router MUST 3604 advertise itself as the Parent Address in the Transit Information 3605 option for that target, using an address that is on-link for that 3606 nodes DAO parent. If the target belongs to an external node then 3607 the router MUST set the External 'E' flag in the transit 3608 information. 3610 A child node that has autoconfigured an address from a parent PIO 3611 with the 'L' flag set does not need to advertise that address as a 3612 DAO target since the parent insures that the whole prefix is already 3613 reachable from the root. But if the 'L' flag is not set then it is 3614 necessary in non-storing mode for the child node to inform the root 3615 of the parent-child relationship, using a reachable address of the 3616 parent, so as to enable the recursive construction of the routing 3617 header. This is done by associating an address of the parent as 3618 transit with the address of the child as target in a DAO message. 3620 9.5. DAO Transmission Scheduling 3622 Because DAOs flow upwards, receiving a unicast DAO can trigger 3623 sending a unicast DAO to a DAO parent. 3625 1. On receiving a unicast DAO message with updated information, such 3626 as containing a Transit Information option with a new Path 3627 Sequence, a node SHOULD send a DAO. It SHOULD NOT send this DAO 3628 message immediately. It SHOULD delay sending the DAO message in 3629 order to aggregate DAO information from other nodes for which it 3630 is a DAO parent. 3632 2. A node SHOULD delay sending a DAO message with a timer 3633 (DelayDAO). Receiving a DAO message starts the DelayDAO timer. 3634 DAO messages received while the DelayDAO timer is active do not 3635 reset the timer. When the DelayDAO timer expires, the node sends 3636 a DAO. 3638 3. When a node adds a node to its DAO parent set, it SHOULD schedule 3639 a DAO message transmission. 3641 DelayDAO's value and calculation is implementation-dependent. A 3642 default value of DEFAULT_DAO_DELAY is defined in this specification. 3644 9.6. Triggering DAO Messages 3646 Nodes can trigger their sub-DODAG to send DAO messages. Each node 3647 maintains a DAO Trigger Sequence Number (DTSN), which it communicates 3648 through DIO messages. 3650 1. If a node hears one of its DAO parents increment its DTSN, the 3651 node MUST schedule a DAO message transmission using rules in 3652 Section 9.3 and Section 9.5. 3654 2. In non-storing mode, if a node hears one of its DAO parents 3655 increment its DTSN, the node MUST increment its own DTSN. 3657 In a storing mode of operation, as part of routine routing table 3658 updates and maintenance, a storing node MAY increment DTSN in order 3659 to reliably trigger a set of DAO updates from its immediate children. 3660 In a storing mode of operation it is not necessary to trigger DAO 3661 updates from the entire sub-DODAG, since that state information will 3662 propagate hop-by-hop Up the DODAG. 3664 In a non-storing mode of operation, a DTSN increment will also cause 3665 the immediate children of a node to increment their DTSN in turn, 3666 triggering a set of DAO updates from the entire sub-DODAG. In a non- 3667 storing mode of operation typically only the root would independently 3668 increment the DTSN when a DAO refresh is needed but a global repair 3669 (such as by incrementing DODAGVersionNumber) is not desired. In a 3670 non-storing mode of operation typically all non-root nodes would 3671 increment their DTSN only when their parent(s) are observed to do so. 3673 In the general, a node may trigger DAO updates according to 3674 implementation specific logic, such as based on the detection of a 3675 downward route inconsistency or occasionally based upon an internal 3676 timer. 3678 In the case of triggered DAOs, selecting a proper DAODelay can 3679 greatly reduce the number of DAOs transmitted. The trigger flows 3680 Down the DODAG; in the best case the DAOs flow Up the DODAG such that 3681 leaves send DAOs first, with each node sending a DAO message only 3682 once. Such a scheduling could be approximated by setting DAODelay 3683 inversely proportional to Rank. Note that this suggestion is 3684 intended as an optimization to allow efficient aggregation (it is not 3685 required for correct operation in the general case). 3687 9.7. Non-storing Mode 3689 In non-storing mode, RPL routes messages downward using IP source 3690 routing. The following rule applies to nodes that are in non-storing 3691 mode. Storing mode has a separate set of rules, described in 3692 Section 9.8. 3694 1. The Parent Address field of a Transit Information Option MUST 3695 contain one or more addresses. All of these addresses MUST be 3696 addresses of DAO parents of the sender. 3698 2. DAOs are sent directly to the root along a default route 3699 installed as part of the parent selection. 3701 3. When a node removes a node from its DAO parent set, it MAY 3702 generate a new DAO message with an updated Transit Information 3703 option. 3705 In non-storing mode, a node uses DAOs to report its DAO parents to 3706 the DODAG Root. The DODAG Root can piece together a downward route 3707 to a node by using DAO parent sets from each node in the route. The 3708 Path Sequence information may be used to detect stale DAO 3709 information. The purpose of this per-hop route calculation is to 3710 minimize traffic when DAO parents change. If nodes reported complete 3711 source routes, then on a DAO parent change the entire sub-DODAG would 3712 have to send new DAOs to the DODAG Root. Therefore, in non-storing 3713 mode, a node can send a single DAO, although it might choose to send 3714 more than one DAO message to each of multiple DAO parents. 3716 Nodes pack DAOs by sending a single DAO message with multiple RPL 3717 Target Options. Each RPL Target Option has its own, immediately 3718 following, Transit Information options. 3720 9.8. Storing Mode 3722 In storing mode, RPL routes messages downward by the IPv6 destination 3723 address. The following rule apply to nodes that are in storing mode: 3725 1. The Parent Address field of a Transmit Information option MUST be 3726 empty. 3728 2. On receiving a unicast DAO, a node MUST compute if the DAO would 3729 change the set of prefixes that the node itself advertises. This 3730 computation SHOULD include consultation of the Path Sequence 3731 information in the Transit Information options associated with 3732 the DAO, to determine if the DAO message contains newer 3733 information that supersedes the information already stored at the 3734 node. If so, the node MUST generate a new DAO message and 3735 transmit it, following the rules in Section 9.5. Such a change 3736 includes receiving a No-Path DAO. 3738 3. When a node generates a new DAO, it SHOULD unicast it to each of 3739 its DAO parents. It MUST NOT unicast the DAO message to nodes 3740 that are not DAO parents. 3742 4. When a node removes a node from its DAO parent set, it SHOULD 3743 send a No-Path DAO message (Section 6.4.3) to that removed DAO 3744 parent to invalidate the existing route. 3746 5. If messages to an advertised downwards address suffer from a 3747 forwarding error, neighbor unreachable detected (NUD), or similar 3748 failure, a node MAY mark the address as unreachable and generate 3749 an appropriate No-Path DAO. 3751 DAOs advertise what destination addresses and prefixes a node has 3752 routes to. Unlike in non-storing mode, these DAOs do not communicate 3753 information about the routes themselves: that information is stored 3754 within the network and is implicit from the IPv6 source address. 3755 When a storing node generates a DAO, it uses the stored state of DAOs 3756 it has received to produce a set of RPL Target options and their 3757 associated Transmit Information options. 3759 Because this information is stored within each node's routing tables, 3760 in storing mode DAOs are communicated directly to DAO parents, who 3761 store this information. 3763 9.9. Path Control 3765 A DAO message from a node contains one or more Target Options. Each 3766 Target Option specifies either a prefix advertised by the node, a 3767 prefix of addresses reachable outside the LLN, the address of 3768 destination in the node's sub-DODAG, or a multicast group that a node 3769 in the sub-DODAG is listening to. The Path Control field of the 3770 Transit Information option allows nodes to request or allow for 3771 multiple downward routes. A node constructs the Path Control field 3772 of a Transit Information option as follows: 3774 1. The bit width of the path control field MUST be equal to the 3775 value (PCS + 1), where PCS is specified in the control field of 3776 the DODAG Configuration Option. Bits greater than or equal to 3777 the value (PCS + 1) MUST be cleared on transmission and MUST be 3778 ignored on reception. Bits below that value are considered 3779 "active" bits. 3781 2. The node MUST logically construct groupings of its DAO parents 3782 while populating the Path Control field, where each group 3783 consists of DAO parents of equal preference. Those groups MUST 3784 then be ordered according to preference, which allows for a 3785 logical mapping of DAO parents onto Path Control subfields (See 3786 Figure 27). Groups MAY be repeated in order to extend over the 3787 entire bit width of the patch control field, but the order, 3788 including repeated groups, MUST be retained so that preference is 3789 properly communicated. 3791 3. For a RPL Target option describing a node's own address or a 3792 prefix outside the LLN, at least one active bit of the Path 3793 Control field MUST be set. More active bits of the Path Control 3794 field MAY be set. 3796 4. If a node receives multiple DAOs with the same RPL Target option, 3797 it MUST bitwise-OR the Path Control fields it receives. This 3798 aggregated bitwise-OR represents the number of downward routes 3799 the prefix requests. 3801 5. When a node sends a DAO message to one of its DAO parents, it 3802 MUST select one or more of the bits that are set active in the 3803 subfield that is mapped to the group containing that DAO parent 3804 from the aggregated Path Control field. A given bit can only be 3805 presented as active to one parent. The DAO message it transmits 3806 to its parent MUST have these active bits set and all other 3807 active bits cleared. 3809 6. For the RPL Target option and DAOSequence number, the DAOs a node 3810 sends to different DAO parents MUST have disjoint sets of active 3811 Path Control bits. A node MUST NOT set the same active bit on 3812 DAOs to two different DAO parents. 3814 7. Path control bits SHOULD be allocated according to the preference 3815 mapping of DAO parents onto Path Control subfields, such that the 3816 active Path Control bits, or groupings of bits, that belong to a 3817 particular Path Control subfield are allocated to DAO parents 3818 within the group that was mapped to that subfield. 3820 8. In a non-storing mode of operation, a node MAY pass DAOs through 3821 without performing any further processing on the Path Control 3822 field. 3824 9. A node MUST NOT unicast a DAO message that has no active bits in 3825 the Path Control field set. It is possible that, for a given 3826 Target option, that a node does not have enough aggregate Path 3827 Control bits to send a DAO message containing that Target to each 3828 of its DAO Parents, in which case those least preferred DAO 3829 Parents may not get a DAO message for that Target. 3831 The Path Control field allows a node to bound how many downward 3832 routes will be generated to it. It sets a number of bits in the Path 3833 Control field equal to the maximum number of downward routes it 3834 prefers. Each bit is sent to at most one DAO parent; clusters of 3835 bits can be sent to a single DAO parent for it to divide among its 3836 own DAO parents. 3838 A node that provisions a DAO route for a Target that has an 3839 associated Path Control field SHOULD use the content of that Path 3840 Control field in order to determine an order of preference among 3841 multiple alternative DAO routes for that Target. The Path Control 3842 field assignment is derived from preference (of the DAO parents), as 3843 determined on the basis of this node's best knowledge of the "end-to- 3844 end" aggregated metrics in the "downward" direction as per the 3845 objective function. In non storing mode the root can determine the 3846 downward route by aggregating the information from each received DAO, 3847 which includes the Path Control indications of preferred DAO parents. 3849 9.9.1. Path Control Example 3851 Suppose that there is an LLN operating in storing mode that contains 3852 a Node N with four parents, P1, P2, P3, and P4. Let N have three 3853 children, C1, C2, and C3 in its sub-DODAG. Let PCS be 7, such that 3854 there will be 8 active bits in the Path Control field: 11111111b. 3855 Consider the following example: 3857 The Path Control field is split into 4 subfields, PC1 (11000000b), 3858 PC2 (00110000b), PC3 (00001100b), and PC4 (00000011b), such that 3859 those 4 subfields represent 4 different levels of preference as per 3860 Figure 27. The implementation at Node N, in this example, groups 3861 {P1, P2} to be of equal preference to each other, and the most 3862 preferred group overall. {P3} is less preferred to {P1, P2}, and more 3863 preferred to {P4}. Let Node N then perform its path control mapping 3864 such that: 3866 {P1, P2} -> PC1 (11000000b) in the Path Control field 3867 {P3} -> PC2 (00110000b) in the Path Control field 3868 {P4} -> PC3 (00001100b) in the Path Control field 3869 {P4} -> PC4 (00000011b) in the Path Control field 3871 Note that the implementation repeated {P4} in order to get complete 3872 coverage of the Path Control field. 3874 1. Let C1 send a DAO containing a Target T with a Path Control 3875 10000000b. Node N stores an entry associating 10000000b with 3876 the Path Control field for C1 and Target T. 3878 2. Let C2 send a DAO containing a Target T with a Path Control 3879 00010000b. Node N stores an entry associating 00010000b with 3880 the Path Control field for C1 and Target T. 3882 3. Let C3 send a DAO containing a Target T with a Path Control 3883 00001100b. Node N stores an entry associating 00001100b with 3884 the Path Control field for C1 and Target T. 3886 4. At some later time, Node N generates a DAO for Target T. Node N 3887 will construct an aggregate Path Control field by ORing together 3888 the contribution from each of its children that have given a DAO 3889 for Target T. The aggregate Path Control field thus has the 3890 active bits set as: 10011100b. 3892 5. Node N then distributes the aggregate Path Control bits among 3893 its parents P1, P2, P3, and P4 in order to prepare the DAO 3894 messages. 3896 6. P1 and P2 are eligible to receive active bits from the most 3897 preferred subfield (11000000b). Those bits are 10000000b in the 3898 aggregate Path Control field. Node N must the bit to one of the 3899 two parents only. In this case, Node P1 is allocated the bit, 3900 and gets the Path Control field 10000000b for its DAO. There 3901 are no bits left to allocate to Node P2, thus Node P2 would have 3902 a Path Control field of 00000000b and a DAO cannot be generated 3903 to Node P2 since there are no active bits. 3905 7. The second-most preferred subfield (00110000b) has the active 3906 bits 00010000b. Node N has mapped P3 to this subfield. Node N 3907 may allocates the active bit to P3, constructing a DAO for P3 3908 containing Target T with a Path Control of 00010000b. 3910 8. The third-most preferred subfield (00001100b) has the active 3911 bits 00001100b. Node N has mapped P4 to this subfield. Node N 3912 may allocate both bits to P4, constructing a DAO for P4 3913 containing Target T with a Path Control of 00001100b. 3915 9. The least preferred subfield (00000011b) has no active bits. 3916 Had there been active bits, those bits would have been added to 3917 the Path Control field of the DAO constructed for P4. 3919 10. The process of populating the DAO messages destined for P1, P2, 3920 P3, P4 with other targets (other than T) proceeds as according 3921 the aggregate path control fields collected for those targets. 3923 9.10. Multicast Destination Advertisement Messages 3925 A special case of DAO operation, distinct from unicast DAO operation, 3926 is multicast DAO operation which may be used to populate '1-hop' 3927 routing table entries. 3929 1. A node MAY multicast a DAO message to the link-local scope all- 3930 RPL-nodes multicast address. 3932 2. A multicast DAO message MUST be used only to advertise 3933 information about the node itself, i.e. prefixes directly 3934 connected to or owned by the node, such as a multicast group that 3935 the node is subscribed to or a global address owned by the node. 3937 3. A multicast DAO message MUST NOT be used to relay connectivity 3938 information learned (e.g. through unicast DAO) from another node. 3940 4. A node MUST NOT perform any other DAO related processing on a 3941 received multicast DAO message, in particular a node MUST NOT 3942 perform the actions of a DAO parent upon receipt of a multicast 3943 DAO. 3945 o The multicast DAO may be used to enable direct P2P communication, 3946 without needing the DODAG to relay the packets. 3948 10. Security Mechanisms 3950 This section describes the generation and processing of secure RPL 3951 messages. The high order bit of the RPL message code identifies 3952 whether a RPL message is secure or not. In addition to secure 3953 versions of basic control messages (DIS, DIO, DAO, DAO-ACK), RPL has 3954 several messages which are relevant only in networks with security 3955 enabled. 3957 Implementation complexity and size is a core concern for LLNs such 3958 that it may be economically or physically impossible to include 3959 sophisticated security provisions in a RPL implementation. 3960 Furthermore, many deployments can utilize link-layer or other 3961 security mechanisms to meet their security requirements without 3962 requiring the use of security in RPL. 3964 Therefore, the security features described in this document are 3965 OPTIONAL to implement. A given implementation MAY support a subset 3966 (including the empty set) of the described security features, for 3967 example it could support integrity and confidentiality, but not 3968 signatures. An implementation SHOULD clearly specify which security 3969 mechanisms are supported, and it is RECOMMENDED that implementers 3970 carefully consider security requirements and the availability of 3971 security mechanisms in their network. 3973 10.1. Security Overview 3975 RPL supports three security modes: 3977 o Unsecured. In this security mode, RPL uses basic DIS, DIO, DAO, 3978 and DAO-ACK messages, which do not have security sections. As a 3979 network could be using other security mechanisms, such as link- 3980 layer security, unsecured mode does not imply all messages are 3981 sent without any protection. 3983 o Pre-installed. In this security mode, RPL uses secure messages. 3984 To join a RPL Instance, a node must have a pre-installed key. 3985 Nodes use this to provide message confidentiality, integrity, and 3986 authenticity. A node may, using this preinstalled key, join the 3987 RPL network as either a host or a router. 3989 o Authenticated. In this security mode, RPL uses secure messages. 3990 To join a RPL Instance, a node must have a pre-installed key. 3991 Nodes use this key to provide message confidentiality, integrity, 3992 and authenticity. Using this preinstalled key, a node may join 3993 the network as a host only. To join the network as a router, a 3994 node must obtain a second key from a key authority. This key 3995 authority can authenticate that the requester is allowed to be a 3996 router before providing it with the second key. Authenticated 3997 mode cannot be supported by symmetric algorithms. As of this 3998 specification, RPL supports only symmetric algorithms: 3999 authenticated mode is included for the benefit of potential future 4000 cryptographic primitives. See Section 10.3. 4002 Whether or not the RPL Instance uses unsecured mode is signaled by 4003 whether it uses secure RPL messages. Whether a secured network uses 4004 the pre-installed or authenticated mode is signaled by the 'A' bit of 4005 the DAG Configuration option. 4007 This specification specifies CCM -- Counter with CBC-MAC (Cipher 4008 Block Chaining Message Authentication Code) -- as the cryptographic 4009 basis for RPL security[RFC3610]. In this specification, CCM uses 4010 AES-128 as its underlying cryptographic algorithm. There are bits 4011 reserved in the security section to specify other algorithms in the 4012 future. 4014 All secured RPL messages have either a message authentication code 4015 (MAC) or a signature. Secured RPL messages optionally also have 4016 encryption protection for confidentiality. Secured RPL message 4017 formats support both integrated encryption/authentication schemes 4018 (e.g., CCM) as well as schemes that separately encrypt and 4019 authenticate packets. 4021 10.2. Joining a Secure Network 4023 RPL security assumes that a node wishing to join a secured network 4024 has been preconfigured with a shared key for communicating with 4025 neighbors and the RPL root. To join a secure RPL network, a node 4026 either listens for secure DIOs or triggers secure DIOs by sending a 4027 secure DIS. In addition to the DIO/DIS rules in Section 8, secure 4028 DIO and DIS messages have these rules: 4030 1. If sent, this initial secure DIS MUST set the Key Identifier Mode 4031 field to 0 (00) and MUST set the Security Level field to 1 (001). 4032 The key used MUST be the preconfigured group key (Key Index 4033 0x00). 4035 2. When a node resets its Trickle timer in response to a secure DIS 4036 (Section 8.3), the next DIO it transmits MUST be a secure DIO 4037 with the same security configuration as the secure DIS. If a 4038 node receives multiple secure DIS messages before it transmits a 4039 DIO, the secure DIO MUST have the same security configuration as 4040 the last DIS it is responding to. 4042 3. When a node sends a DIO in response to a unicast secure DIS 4043 (Section 8.3), the DIO MUST be a secure DIO. 4045 The above rules allow a node to join a secured RPL Instance using the 4046 preconfigured shared key. Once a node has joined the DODAG using the 4047 preconfigured shared key, the 'A' bit of the Configuration option 4048 determines its capabilities. If the 'A' bit of the Configuration is 4049 cleared, then nodes can use this preinstalled, shared key to exchange 4050 messages normally: it can issue DIOs, DAOs, etc. 4052 If the 'A' bit of the Configuration option is set and the RPL 4053 Instance is operating in authenticated mode: 4055 1. A node MUST NOT advertise a Rank besides INFINITE_RANK in secure 4056 DIOs secured with Key Index 0x00. When processing DIO messages 4057 secured with Key Index 0x00, a processing node MUST consider the 4058 advertised Rank to be INFINITE_RANK. Any other value results in 4059 the message being discarded. 4061 2. Secure DAOs using Key Index 0x00 MUST NOT have a RPL Target 4062 option with a prefix besides the node's address. If a node 4063 receives a secured DAO message using the preinstalled, shared key 4064 where the RPL Target option does not match the IPv6 source 4065 address, it MUST discard the secured DAO message without further 4066 processing. 4068 The above rules mean that in RPL Instances where the 'A' bit is set, 4069 using Key Index 0x00 a node can join the RPL Instance as a host but 4070 not a router. A node must communicate with a key authority to obtain 4071 a key that will enable it to act as a router. 4073 10.3. Installing Keys 4075 Authenticated mode requires a would-be router to dynamically install 4076 new keys once they have joined a network as a host. Having joined as 4077 a host, the node uses standard IP messaging to communicate with an 4078 authorization server, which can provide new keys. 4080 The protocol to obtain such keys is out of scope for this 4081 specification and to be elaborated in future specifications. That 4082 elaboration is required for RPL to securely operate in authenticated 4083 mode. 4085 10.4. Consistency Checks 4087 RPL nodes send Consistency Check (CC) messages to protect against 4088 replay attacks and synchronize counters. 4090 1. If a node receives a unicast CC message with the R bit cleared, 4091 and it is a member of or is in the process of joining the 4092 associated DODAG, it SHOULD respond with a unicast CC message to 4093 the sender. This response MUST have the R bit set, and MUST have 4094 the same Nonce, RPLInstanceID and DODAGID fields as the message 4095 it received. 4097 2. If a node receives a multicast CC message, it MUST discard the 4098 message with no further processing. 4100 Consistency Check messages allow nodes to issue a challenge-response 4101 to validate a node's current Counter value. Because the CC Nonce is 4102 generated by the challenger, an adversary replaying messages is 4103 unlikely to be able to generate a correct response. The Counter in 4104 the Consistency Check response allows the challenger to validate the 4105 Counter values it hears. 4107 10.5. Counters 4109 In the simplest case, the Counter value is an unsigned integer that a 4110 node increments by one or more on each secured RPL transmission. The 4111 Counter MAY represent a timestamp that has the following properties: 4113 1. The timestamp MUST be at least six octets long. 4115 2. The timestamp MUST be in 1024Hz (binary millisecond) granularity. 4117 3. The timestamp start time MUST be January 1, 1970, 12:00:00AM UTC. 4119 4. If the Counter represents such as timestamp, the Counter value 4120 MUST be a value computed as follows. Let T be the timestamp, S 4121 be the start time of the key in use, and E be the end time of the 4122 key in use. Both S and E are represented using the same 3 rules 4123 as the timestamp described above. If E > T < S, then the Counter 4124 is invalid and a node MUST NOT generate a packet. Otherwise, the 4125 Counter value is equal to T-S. 4127 5. If the Counter represents such a timestamp, a node MAY set the 4128 'T' flag of the security section of secured RPL packets. 4130 6. If the Counter field does not present such a timestamp, then a 4131 node MUST NOT set the 'T' flag. 4133 7. If a node does not have a local timestamp that satisfies the 4134 above requirements, it MUST ignore the 'T' flag. 4136 If a node supports such timestamps and it receives a message with the 4137 'T' flag set, it MAY apply the temporal check on the received message 4138 described in Section 10.7.1. If a node receives a message without 4139 the 'T' flag set, it MUST NOT apply this temporal check. A node's 4140 security policy MAY, for application reasons, include rejecting all 4141 messages without the 'T' flag set. 4143 The 'T' flag is present because many LLNs today already maintain 4144 global time synchronization at sub-millisecond granularity for 4145 security, application, and other reasons. Allowing RPL to leverage 4146 this existing functionality when present greatly simplifies solutions 4147 to some security problems, such as delay protection. 4149 10.6. Transmission of Outgoing Packets 4151 Given an outgoing RPL control packet and required security 4152 protection, this section describes how RPL generates the secured 4153 packet to transmit. It also describes the order of cryptographic 4154 operations to provide the required protection. 4156 The requirement for security protection and the level of security to 4157 be applied to an outgoing RPL packet shall be determined by the 4158 node's security policy database. The configuration of this security 4159 policy database for outgoing packet processing is implementation 4160 specific. 4162 Where secured RPL messages are to be transmitted, a RPL node MUST set 4163 the security section (T, Sec, KIM, and LVL) in the outgoing RPL 4164 packet to describe the protection level and security settings that 4165 are applied (see Section 6.1). The Security subfield bit of the RPL 4166 message Code field MUST be set to indicate the secure RPL message. 4168 The Counter value used in constructing the AES-128 CCM Nonce 4169 (Figure 31) to secure the outgoing packet MUST be an increment of the 4170 last Counter transmitted to the particular destination address. 4172 Where security policy specifies the application of delay protection, 4173 the Timestamp Counter used in constructing the Nonce to secure the 4174 outgoing packet MUST be incremented according to the rules in 4175 Section 10.5. Where a Timestamp Counter is applied (indicated with 4176 the 'T' flag set) the locally maintained Time Counter MUST be 4177 included as part of the transmitted secured RPL message. 4179 The cryptographic algorithm used in securing the outgoing packet 4180 shall be specified by the node's security policy database and MUST be 4181 indicated in the value of the Sec field set within the outgoing 4182 message. 4184 The security policy for the outgoing packet shall determine the 4185 applicable Key Identifier Mode (KIM) and Key Identifier specifying 4186 the security key to be used for the cryptographic packet processing, 4187 including the optional use of signature keys (see Section 6.1). The 4188 security policy will also specify the algorithm (Algorithm) and level 4189 of protection (Level) in the form of authentication or authentication 4190 and encryption, and potential use of signatures that shall apply to 4191 the outgoing packet. 4193 Where encryption is applied, a node MUST replace the original packet 4194 payload with that payload encrypted using the security protection, 4195 key, and nonce specified in the security section of the packet. 4197 All secured RPL messages include integrity protection. In 4198 conjunction with the security algorithm processing, a node derives 4199 either a Message Authentication Code (MAC) or signature that MUST be 4200 included as part of the outgoing secured RPL packet. 4202 10.7. Reception of Incoming Packets 4204 This section describes the reception and processing of a secured RPL 4205 packet. Given an incoming secured RPL packet, where the Security 4206 subfield bit of the RPL message Code field is set, this section 4207 describes how RPL generates an unencrypted variant of the packet and 4208 validates its integrity. 4210 The receiver uses the RPL security control fields to determine the 4211 necessary packet security processing. If the described level of 4212 security for the message type and originator is unknown or does not 4213 meet locally maintained security policies, a node MUST discard the 4214 packet without further processing, MAY raise a management alert, and 4215 MUST NOT send any messages in response. These policies can include 4216 security levels, keys used, source identifiers, or the lack of 4217 timestamp-based counters (as indicated by the 'T' flag). The 4218 configuration of the security policy database for incoming packet 4219 processing is out of scope for this specification (it may, for 4220 example, be defined through DIO Configuration or through out-of-band 4221 administrative router configuration). 4223 Where the message security level (LVL) indicates an encrypted RPL 4224 message, the node uses the key information identified through the KIM 4225 field as well as the Nonce as input to the message payload decryption 4226 processing. The Nonce shall be derived from the message Counter 4227 field and other received and locally maintained information (see 4228 Section 10.9.1). The plaintext message contents shall be obtained by 4229 invoking the inverse cryptographic mode of operation specified by the 4230 Sec field of the received packet. 4232 The receiver shall use the Nonce and identified key information to 4233 check the integrity of the incoming packet. If the integrity check 4234 fails against the received message authentication code (MAC), a node 4235 MUST discard the packet. 4237 If the received message has an initialized (zero value) Counter value 4238 and the receiver has an incoming Counter currently maintained for the 4239 originator of the message, the receiver MUST initiate a Counter 4240 resynchronization by sending a Consistency Check response message 4241 (see Section 6.6) to the message source. The Consistency Check 4242 response message shall be protected with the current full outgoing 4243 Counter maintained for the particular node address. That outgoing 4244 Counter will be included within the security section of the message 4245 while the incoming Counter will be included within the Consistency 4246 Check message payload. 4248 Based on the specified security policy a node MAY apply replay 4249 protection for a received RPL message. The replay check SHOULD be 4250 performed before the authentication of the received packet. The 4251 Counter as obtained from the incoming packet shall be compared 4252 against the watermark of the incoming Counter maintained for the 4253 given origination node address. If the received message Counter 4254 value is non-zero and less than the maintained incoming Counter 4255 watermark a potential packet replay is indicated and the node MUST 4256 discard the incoming packet. 4258 If delay protection is specified as part of the incoming packet 4259 security policy checks, the Timestamp Counter is used to validate the 4260 timeliness of the received RPL message. If the incoming message 4261 Timestamp Counter value indicates a message transmission time prior 4262 to the locally maintained transmission time Counter for the 4263 originator address, a replay violation is indicated and the node MUST 4264 discard the incoming packet. If the received Timestamp Counter value 4265 indicates a message transmission time that is earlier than the 4266 Current time less the acceptable packet delay, a delay violation is 4267 indicated and the node MUST discard the incoming packet. 4269 Once a message has been decrypted, where applicable, and has 4270 successfully passed its integrity check, replay, and optionally delay 4271 protection checks, the node can update its local security 4272 information, such as the source's expected Counter value for replay 4273 comparison. 4275 A node MUST NOT update its security information on receipt of a 4276 message that fails security policy checks or other applied integrity, 4277 replay, or delay checks. 4279 10.7.1. Timestamp Key Checks 4281 If the 'T' flag of a message is set and a node has a local timestamp 4282 that follows the requirements in Section 10.5, then a node MAY check 4283 the temporal consistency of the message. The node computes the 4284 transmit time of the message by adding the Counter value to the start 4285 time of the associated key. If this transmit time is past the end 4286 time of the key, the node MAY discard the message without further 4287 processing. If the transmit time is too far in the past or future 4288 compared to the local time on the receiver, it MAY discard the 4289 message without further processing. 4291 10.8. Coverage of Integrity and Confidentiality 4293 For a RPL ICMPv6 message, the entire packet is within the scope of 4294 RPL security. 4296 Message authentication codes (MAC) and signatures are calculated over 4297 the entire unsecured IPv6 packet. When computing MACs and 4298 signatures, mutable IPv6 fields are considered to be filled with 4299 zeroes, following the rules in Section 3.3.3.1 of [RFC4302] (IPSec 4300 Authenticated Header). MAC and signature calculations are performed 4301 before any compression that lower layers may apply. 4303 When a RPL ICMPv6 message is encrypted, encryption starts at the 4304 first byte after the security section and continues to the last byte 4305 of the packet. The IPv6 header, ICMPv6 header, and RPL message up to 4306 the end of the security section are not encrypted, as they are needed 4307 to correctly decrypt the packet. 4309 For example, a node sending a message with LVL=5, KIM=0, and 4310 Algorithm=0 uses the CCM algorithm[RFC3610] to create a packet with 4311 attributes ENC-MAC-32: it encrypts the packet and appends a 32-bit 4312 MAC. The block cipher key is determined by the Key Index; the Nonce 4313 is computed as described in Section 10.9.1; the message to 4314 authenticate and encrypt is the RPL message starting at the first 4315 byte after the security section and ends with the last byte of the 4316 packet; the additional authentication data starts with the beginning 4317 of the IPv6 header and ends with the last byte of the RPL security 4318 section. 4320 10.9. Cryptographic Mode of Operation 4322 The cryptographic mode of operation described in this specification 4323 (Algorithm = 0) is based on CCM and the block-cipher AES- 4324 128[RFC3610]. This mode of operation is widely supported by existing 4325 implementations. CCM mode requires a nonce. 4327 10.9.1. Nonce 4329 A RPL node constructs a CCM nonce as follows: 4331 0 1 2 3 4332 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 4333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4334 | | 4335 + Source Identifier + 4336 | | 4337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4338 | Counter | 4339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4340 |Reserved | LVL | 4341 +-+-+-+-+-+-+-+-+ 4343 Figure 31: CCM Nonce 4345 Source Identifier: 8 bytes. Source Identifier is set to the logical 4346 identifier of the originator of the protected packet. 4348 Counter: 4 bytes. Counter is set to the (uncompressed) value of the 4349 corresponding field in the Security option of the RPL control 4350 message. 4352 Security Level (LVL): 3 bits. Security Level is set to the value of 4353 the corresponding field in the Security option of the RPL 4354 control message. 4356 Unassigned bits of the nonce are reserved. They MUST be set to zero 4357 when constructing the nonce. 4359 All fields of the nonce are represented in most-significant-octet and 4360 most-significant-bit first order. 4362 10.9.2. Signatures 4364 If the Key Identification Mode (KIM) mode indicates the use of 4365 signatures (a value of 3), then a node appends a signature to the 4366 data payload of the packet. The Security Level (LVL) field describes 4367 the length of this signature. 4369 The signature scheme in RPL for Security Mode 3 is an instantiation 4370 of the RSA algorithm (RSASSA-PSS) as defined in Section 8.1 of 4371 [RFC3447]. It uses as public key the pair (n,e), where n is a 2048- 4372 bit or 3072-bit RSA modulus and where e=2^{16}+1. It uses CCM mode 4373 [RFC3610] as the encryption scheme with M=0 (as a stream-cipher). 4374 Note that although [RFC3610] disallows CCM mode with M=0, this 4375 specification explicitly allows CCM mode with M=0 when used in 4376 conjunction with a signature as in this case, because the signature 4377 provides sufficient protection. It uses the SHA-256 hash function 4378 specified in Section 6.2 of [FIPS180]. It uses the message encoding 4379 rules of Section 8.1 of [RFC3447]. 4381 Let 'a' be a concatenation of a six-byte representation of Counter 4382 and the message header. The packet payload is the right- 4383 concatenation of packet data 'm' and the signature 's'. This 4384 signature scheme is invoked with the right-concatenation of the 4385 message parts a and m, whereas the signature verification is invoked 4386 with the right-concatenation of the message parts a and m, and with 4387 signature s. 4389 RSA signatures of this form provide sufficient protection for RPL 4390 networks. If needed, alternative signature schemes which produce 4391 more concise signatures is out of scope for this specification and 4392 may be the subject of a future specification. 4394 An implementation that supports RSA signing with either 2048-bit or 4395 3072-bit signatures SHOULD support verification of both 2048-bit and 4396 3072-bit RSA signatures. This is in consideration of providing an 4397 upgrade path for a RPL deployment. 4399 11. Packet Forwarding and Loop Avoidance/Detection 4401 11.1. Suggestions for Packet Forwarding 4403 This document specifies a routing protocol. These non-normative 4404 suggestions are provided to aid in the design of a forwarding 4405 implementation by illustrating how such an implementation could work 4406 with RPL 4408 When forwarding a packet to a destination, precedence is given to 4409 selection of a next-hop successor as follows: 4411 1. This specification only covers how a successor is selected from 4412 the DODAG Version that matches the RPLInstanceID marked in the 4413 IPv6 header of the packet being forwarded. Routing outside the 4414 instance can be done as long as additional rules are put in place 4415 such as strict ordering of instances and routing protocols to 4416 protect against loops. Such rules may be defined in a separate 4417 document. 4419 2. If a local administrative preference favors a route that has been 4420 learned from a different routing protocol than RPL, then use that 4421 successor. 4423 3. If the packet header specifies a source route by including a RH4 4424 header as specified in [I-D.ietf-6man-rpl-routing-header], then 4425 use that route. If the node fails to forward the packet with 4426 that specified source route, then that packet should be dropped. 4427 The node MAY log an error. The node may send an ICMPv6 Error in 4428 Source Routing Header message to the source of the packet (See 4429 Section 19.18). 4431 4. If there is an entry in the routing table matching the 4432 destination that has been learned from a multicast destination 4433 advertisement (e.g. the destination is a one-hop neighbor), then 4434 use that successor. 4436 5. If there is an entry in the routing table matching the 4437 destination that has been learned from a unicast destination 4438 advertisement (e.g. the destination is located Down the sub- 4439 DODAG), then use that successor. If there are DAO Path Control 4440 bits associated with multiple successors, then consult the Path 4441 Control bits to order the successors by preference when choosing. 4442 If, for a given DAO Path Control bit, multiple successors are 4443 recorded as having asserted that bit, precedence should be given 4444 to the successor who most recently asserted that bit. 4446 6. If there is a DODAG Version offering a route to a prefix matching 4447 the destination, then select one of those DODAG parents as a 4448 successor according to the OF and routing metrics. 4450 7. Any other as-yet-unattempted DODAG parent may be chosen for the 4451 next attempt to forward a unicast packet when no better match 4452 exists. 4454 8. Finally the packet is dropped. ICMP Destination Unreachable MAY 4455 be invoked (an inconsistency is detected). 4457 Hop Limit MUST be decremented when forwarding as per [RFC2460]. 4459 Note that the chosen successor MUST NOT be the neighbor that was the 4460 predecessor of the packet (split horizon), except in the case where 4461 it is intended for the packet to change from an upward to a downward 4462 direction, as determined by the routing table of the node making the 4463 change, such as switching from DIO routes to DAO routes as the 4464 destination is neared in order to continue traveling toward the 4465 destination. 4467 11.2. Loop Avoidance and Detection 4469 RPL loop avoidance mechanisms are kept simple and designed to 4470 minimize churn and states. Loops may form for a number of reasons, 4471 e.g. control packet loss. RPL includes a reactive loop detection 4472 technique that protects from meltdown and triggers repair of broken 4473 paths. 4475 RPL loop detection uses RPL Packet Information that is transported 4476 within the data packets, relying on an external mechanism such as 4477 [I-D.ietf-6man-rpl-option] that places in the RPL Packet Information 4478 in an IPv6 Hop-by-Hop Option header. 4480 The content of RPL Packet Information is defined as follows: 4482 Down 'O': 1-bit flag indicating whether the packet is expected to 4483 progress Up or Down. A router sets the 'O' flag when the 4484 packet is expected to progress Down (using DAO routes), and 4485 clears it when forwarding toward the DODAG root (to a node with 4486 a lower rank). A host or RPL leaf node MUST set the 'O' flag 4487 to 0. 4489 Rank-Error 'R': 1-bit flag indicating whether a rank error was 4490 detected. A rank error is detected when there is a mismatch in 4491 the relative ranks and the direction as indicated in the 'O' 4492 bit. A host or RPL leaf node MUST set the 'R' bit to 0. 4494 Forwarding-Error 'F': 1-bit flag indicating that this node can not 4495 forward the packet further towards the destination. The 'F' 4496 bit might be set by a child node that does not have a route to 4497 destination for a packet with the Down 'O' bit set. A host or 4498 RPL leaf node MUST set the 'F' bit to 0. 4500 RPLInstanceID: 8-bit field indicating the DODAG instance along which 4501 the packet is sent. 4503 SenderRank: 16-bit field set to zero by the source and to 4504 DAGRank(rank) by a router that forwards inside the RPL network. 4506 11.2.1. Source Node Operation 4508 If the source is aware of the RPLInstanceID that is preferred for the 4509 packet, then it MUST set the RPLInstanceID field associated with the 4510 packet accordingly, otherwise it MUST set it to the 4511 RPL_DEFAULT_INSTANCE. 4513 11.2.2. Router Operation 4515 11.2.2.1. Instance Forwarding 4517 The RPLInstanceID is associated by the source with the packet. This 4518 RPLInstanceID MUST match the RPL Instance onto which the packet is 4519 placed by any node, be it a host or router. The RPLInstanceID is 4520 part of the RPL Packet Information. 4522 A RPL router that forwards a packet in the RPL network MUST check if 4523 the packet includes the RPL Packet Information. If not, then the RPL 4524 router MUST insert a RPL Packet Information. If the router is an 4525 ingress router that injects the packet into the RPL network, the 4526 router MUST set the RPLInstanceID field in the RPL Packet 4527 Information. The details of how that router determines the mapping 4528 to a RPLInstanceID are out of scope for this specification and left 4529 to future specification. 4531 A router that forwards a packet to outside the RPL network MUST 4532 remove the RPL Packet Information. 4534 When a router receives a packet that specifies a given RPLInstanceID 4535 and the node can forward the packet along the DODAG associated to 4536 that instance, then the router MUST do so and leave the RPLInstanceID 4537 value unchanged. 4539 If any node can not forward a packet along the DODAG associated to 4540 the RPLInstanceID, then the node SHOULD discard the packet and send 4541 an ICMP error message. 4543 11.2.2.2. DAG Inconsistency Loop Detection 4545 The DODAG is inconsistent if the direction of a packet does not match 4546 the rank relationship. A receiver detects an inconsistency if it 4547 receives a packet with either: 4549 the 'O' bit set (to Down) from a node of a higher rank. 4551 the 'O' bit cleared (for Up) from a node of a lesser rank. 4553 When the DODAG root increments the DODAGVersionNumber, a temporary 4554 rank discontinuity may form between the next DODAG Version and the 4555 prior DODAG Version, in particular if nodes are adjusting their rank 4556 in the next DODAG Version and deferring their migration into the next 4557 DODAG Version. A router that is still a member of the prior DODAG 4558 Version may choose to forward a packet to a (future) parent that is 4559 in the next DODAG Version. In some cases this could cause the parent 4560 to detect an inconsistency because the rank-ordering in the prior 4561 DODAG Version is not necessarily the same as in the next DODAG 4562 Version and the packet may be judged to not be making forward 4563 progress. If the sending router is aware that the chosen successor 4564 has already joined the next DODAG Version, then the sending router 4565 MUST update the SenderRank to INFINITE_RANK as it forwards the 4566 packets across the discontinuity into the next DODAG Version in order 4567 to avoid a false detection of rank inconsistency. 4569 One inconsistency along the path is not considered a critical error 4570 and the packet may continue. But a second detection along the path 4571 of a same packet should not occur and the packet MUST be dropped. 4573 This process is controlled by the Rank-Error bit associated with the 4574 packet. When an inconsistency is detected on a packet, if the Rank- 4575 Error bit was not set then the Rank-Error bit is set. If it was set 4576 the packet MUST be discarded and the trickle timer MUST be reset. 4578 11.2.2.3. DAO Inconsistency Detection and Recovery 4580 DAO inconsistency loop recovery is a mechanism that applies to 4581 storing mode of operation only. 4583 In non-storing mode, the packets are source routed to the destination 4584 and DAO inconsistencies are not corrected locally. Instead, an ICMP 4585 error with a new code "Error in Source Routing Header" is sent back 4586 to the root. The "Error in Source Routing Header" message has the 4587 same format as the "Destination Unreachable Message" as specified in 4588 [RFC4443]. The portion of the invoking packet that is sent back in 4589 the ICMP message should record at least up to the routing header, and 4590 the routing header should be consumed by this node so that the 4591 destination in the IPv6 header is the next hop that this node could 4592 not reach. 4594 A DAO inconsistency happens when a router has a downward route that 4595 was previously learned from a DAO message via a child, but that 4596 downward route is not longer valid in the child, e.g. because that 4597 related state in the child has been cleaned up. With DAO 4598 inconsistency loop recovery, a packet can be used to recursively 4599 explore and cleanup the obsolete DAO states along a sub-DODAG. 4601 In a general manner, a packet that goes Down should never go Up 4602 again. If DAO inconsistency loop recovery is applied, then the 4603 router SHOULD send the packet back to the parent that passed it with 4604 the Forwarding-Error 'F' bit set and the 'O' bit left untouched. 4605 Otherwise the router MUST silently discard the packet. 4607 Upon receiving a packet with a Forwarding-Error bit set, the node 4608 MUST remove the routing states that caused forwarding to that 4609 neighbor, clear the Forwarding-Error bit and attempt to send the 4610 packet again. The packet may be sent to an alternate neighbor, after 4611 the expiration of a user-configurable implementation specific timer. 4612 If that alternate neighbor still has an inconsistent DAO state via 4613 this node, the process will recurse, this node will set the 4614 Forwarding-Error 'F' bit and the routing state in the alternate 4615 neighbor will be cleaned up as well. 4617 12. Multicast Operation 4619 This section describes further the multicast routing operations over 4620 an IPv6 RPL network, and specifically how unicast DAOs can be used to 4621 relay group registrations up. Wherever the following text mentions 4622 Multicast Listener Discovery (MLD), one can read MLDv1 ([RFC2710]) or 4623 MLDv2 ([RFC3810]). 4625 RPL provides a trivial mapping between MLD queries and RPL DAOs by 4626 transporting a multicast group in a DAO target option. The mapping 4627 excludes the support of source specific filters that are not defined 4628 in DAO options. The mapping enables to proxy a multicast 4629 registration from a non-RPL node attached to a RPL router up to the 4630 root of the DODAG, which can act as a multicast router as if the 4631 listeners were directly attached to it. 4633 Nodes that support the RPL storing mode of operation SHOULD also 4634 support multicast DAO operations as described below. Nodes that only 4635 support the non-storing mode of operation are not expected to support 4636 this section. 4638 The multicast operation is controlled by the MOP field in the DIO. 4640 If the MOP field requires multicast support, then a node that 4641 joins the RPL network as a router must operate as described in 4642 this section for multicast signaling and forwarding within the RPL 4643 network. A node that does not support the multicast operation 4644 required by the MOP field can only join as a leaf. 4646 If the MOP field does not require multicast support, then 4647 multicast is handled by some other way that is out of scope for 4648 this specification. (Examples may include a series of unicast 4649 copies or limited-scope flooding). 4651 As is traditional, a listener that is not a RPL node uses a protocol 4652 such as MLD with a router to register to a multicast group. If the 4653 listener is attached to a RPL router and multicast support is 4654 enabled, then the RPL router maps the MLD query into a RPL DAO 4655 message. A listener that is a RPL node uses a listener registration 4656 DAO message right away. 4658 Along the path between the router and the DODAG root, MLD requests 4659 are transported as DAO messages within RPL; each hop coalesces the 4660 multiple requests for a same group as a single DAO message to the 4661 parent(s), in a fashion similar to proxy IGMP, but recursively 4662 between child router and parent Up to the DODAG root. 4664 A router might select to pass a listener registration DAO message to 4665 its preferred parent only, in which case multicast packets coming 4666 back might be lost for all of its sub-DODAG if the transmission fails 4667 over that link. Alternatively the router might select to copy 4668 additional parents as it would do for DAO messages advertising 4669 unicast destinations, in which case there might be duplicates that 4670 the router will need to prune. 4672 As a result, multicast routing states are installed in each router on 4673 the way from the listeners to the DODAG root, enabling the root to 4674 copy a multicast packet to all its children routers that had issued a 4675 DAO message including a Target option for that multicast group, as 4676 well as all the attached nodes that registered over MLD. 4678 For unicast traffic, it is expected that the grounded DODAG root acts 4679 as a Low power and lossy network Border Router (LBR) and MAY 4680 redistribute the RPL routes over the external infrastructure using 4681 whatever routing protocol is used in the other routing domain. For 4682 multicast traffic, the root MAY proxy MLD for all the nodes attached 4683 to the RPL domain (this would be needed if the multicast source is 4684 located in the external infrastructure). For such a source, the 4685 packet will be replicated as it flows Down the DODAG based on the 4686 multicast routing table entries installed from the DAO message. 4688 For a multicast packet sourced from inside the DODAG, the packet is 4689 passed to the preferred parents, and if that fails then to the 4690 alternates in the DODAG. The packet is also copied to all the 4691 registered children, except for the one that passed the packet. 4692 Finally, if there is a listener in the external infrastructure then 4693 the DODAG root has to further propagate the packet into the external 4694 infrastructure. 4696 As a result, the DODAG Root acts as an automatic proxy Rendezvous 4697 Point for the RPL network, and as source towards the non-RPL domain 4698 for all multicast flows started in the RPL domain. So regardless of 4699 whether the root is actually attached to a non-RPL domain, and 4700 regardless of whether the DODAG is grounded or floating, the root can 4701 serve inner multicast streams at all times. 4703 13. Maintenance of Routing Adjacency 4705 The selection of successors, along the default paths Up along the 4706 DODAG, or along the paths learned from destination advertisements 4707 Down along the DODAG, leads to the formation of routing adjacencies 4708 that require maintenance. 4710 In IGPs such as OSPF [RFC4915] or IS-IS [RFC5120], the maintenance of 4711 a routing adjacency involves the use of Keepalive mechanisms (Hellos) 4712 or other protocols such as the Bidirectional Forwarding Detection 4713 [RFC5881] (BFD) and the MANET Neighborhood Discovery Protocol 4714 [I-D.ietf-manet-nhdp](NHDP) . Unfortunately, such a proactive 4715 approach is often not desirable in constrained environments where it 4716 would lead to excessive control traffic in light of the data traffic 4717 with a negative impact on both link loads and nodes resources. 4719 By contrast with those routing protocols, RPL does not define any 4720 'keep-alive' mechanisms to detect routing adjacency failures: this is 4721 because in many cases such a mechanism would be too expensive in 4722 terms of bandwidth and even more importantly energy (a battery 4723 operated device could not afford to send periodic Keep alive). Still 4724 RPL requires an external mechanisms to detect that a neighbor is no 4725 longer reachable. Such a mechanism should preferably be reactive to 4726 traffic in order to minimize the overhead to maintain the routing 4727 adjacency and focus on links that are actually being used. 4729 Example reactive mechanisms that can be used include: 4731 The Neighbor Unreachability Detection [RFC4861] mechanism. 4733 Layer 2 triggers [RFC5184] derived from events such as association 4734 states and L2 acknowledgements. 4736 14. Guidelines for Objective Functions 4738 An Objective Function (OF), in conjunction with routing metrics and 4739 constraints, allows for the selection of a DODAG to join, and a 4740 number of peers in that DODAG as parents. The OF is used to compute 4741 an ordered list of parents. The OF is also responsible to compute 4742 the rank of the device within the DODAG Version. 4744 The Objective Function is indicated in the DIO message using an 4745 Objective Code Point (OCP), and indicates the method that must be 4746 used to construct the DODAG. The Objective Code Points are specified 4747 in [I-D.ietf-roll-of0], and related companion specifications. 4749 14.1. Objective Function Behavior 4751 Most Objective Functions are expected to follow the same abstract 4752 behavior at a node: 4754 o The parent selection is triggered each time an event indicates 4755 that a potential next hop information is updated. This might 4756 happen upon the reception of a DIO message, a timer elapse, all 4757 DODAG parents are unavailable, or a trigger indicating that the 4758 state of a candidate neighbor has changed. 4760 o An OF scans all the interfaces on the node. Although there may 4761 typically be only one interface in most application scenarios, 4762 there might be multiple of them and an interface might be 4763 configured to be usable or not for RPL operation. An interface 4764 can also be configured with a preference or dynamically learned to 4765 be better than another by some heuristics that might be link-layer 4766 dependent and are out of scope for this specification. Finally an 4767 interface might or not match a required criterion for an Objective 4768 Function, for instance a degree of security. As a result, some 4769 interfaces might be completely excluded from the computation, for 4770 example if those interfaces cannot satisfy some advertised 4771 constraints, while others might be more or less preferred. 4773 o An OF scans all the candidate neighbors on the possible interfaces 4774 to check whether they can act as a router for a DODAG. There 4775 might be multiple of them and a candidate neighbor might need to 4776 pass some validation tests before it can be used. In particular, 4777 some link layers require experience on the activity with a router 4778 to enable the router as a next hop. 4780 o An OF computes rank of a node for comparison by adding to the rank 4781 of the candidate a value representing the relative locations of 4782 the node and the candidate in the DODAG Version. 4784 * The increase in rank must be at least MinHopRankIncrease. 4786 * To keep loop avoidance and metric optimization in alignment, 4787 the increase in rank should reflect any increase in the metric 4788 value. For example, with a purely additive metric such as ETX, 4789 the increase in rank can be made proportional to the increase 4790 in the metric. 4792 * Candidate neighbors that would cause the rank of the node to 4793 increase are not considered for parent selection. 4795 o Candidate neighbors that advertise an OF incompatible with the set 4796 of OF specified by the policy functions are ignored. 4798 o As it scans all the candidate neighbors, the OF keeps the current 4799 best parent and compares its capabilities with the current 4800 candidate neighbor. The OF defines a number of tests that are 4801 critical to reach the objective. A test between the routers 4802 determines an order relation. 4804 * If the routers are equal for that relation then the next test 4805 is attempted between the routers, 4807 * Else the best of the two routers becomes the current best 4808 parent and the scan continues with the next candidate neighbor. 4810 * Some OFs may include a test to compare the ranks that would 4811 result if the node joined either router. 4813 o When the scan is complete, the preferred parent is elected and the 4814 node's rank is computed as the preferred parent rank plus the step 4815 in rank with that parent. 4817 o Other rounds of scans might be necessary to elect alternate 4818 parents. In the next rounds: 4820 * Candidate neighbors that are not in the same DODAG are ignored. 4822 * Candidate neighbors that are of greater rank than the node are 4823 ignored. 4825 * Candidate neighbors of an equal rank to the node are ignored 4826 for parent selection. 4828 * Candidate neighbors of a lesser rank than the node are 4829 preferred. 4831 15. Suggestions for Interoperation with Neighbor Discovery 4833 This specification directly borrows the Prefix Information Option 4834 (PIO) and the Routing Information Option (RIO) from IPv6 ND. It is 4835 envisioned that, as future specifications build on this base, there 4836 may be additional cause to leverage parts of IPv6 ND. This section 4837 provides some suggestions for future specifications. 4839 First and foremost RPL is a routing protocol. One should take great 4840 care to preserve architecture when mapping functionalities between 4841 RPL and ND. RPL is for routing only. That said, there may be 4842 persuading technical reasons to allow for sharing options between RPL 4843 and IPv6 ND in a particular implementation/deployment. 4845 In general the following guidelines apply: 4847 o RPL Type codes must be allocated from the RPL Control Message 4848 Options registry. 4850 o RPL Length fields must be expressed in units of single octets, as 4851 opposed to ND Length fields which are expressed in units of 8 4852 octets. 4854 o RPL Options are generally not required to be aligned to 8 octet 4855 boundaries. 4857 o When mapping/transposing an IPv6 ND option for redistribution as a 4858 RPL option, any padding octets should be removed when possible. 4859 For example, the Prefix Length field in the PIO is sufficient to 4860 describe the length of the Prefix field. When mapping/transposing 4861 a RPL option for redistribution as an IPv6 ND option, any such 4862 padding octets should be restored. This procedure must be 4863 unambiguous. 4865 16. RPL Constants and Variables 4867 Following is a summary of RPL constants and variables: 4869 BASE_RANK This is the rank for a virtual root that might be used to 4870 coordinate multiple roots. BASE_RANK has a value of 0. 4872 ROOT_RANK This is the rank for a DODAG root. ROOT_RANK has a value 4873 of MinHopRankIncrease (as advertised by the DODAG root), such 4874 that DAGRank(ROOT_RANK) is 1. 4876 INFINITE_RANK This is the constant maximum for the rank. 4877 INFINITE_RANK has a value of 0xFFFF. 4879 RPL_DEFAULT_INSTANCE This is the RPLInstanceID that is used by this 4880 protocol by a node without any overriding policy. 4881 RPL_DEFAULT_INSTANCE has a value of 0. 4883 DEFAULT_PATH_CONTROL_SIZE This is the default value used to 4884 configure PCS in the DODAG Configuration Option, which dictates 4885 the number of significant bits in the Path Control field of the 4886 Transit Information option. DEFAULT_PATH_CONTROL_SIZE has a 4887 value of 0. This configures the simplest case limiting the 4888 fan-out to 1 and limiting a node to send a DAO message to only 4889 one parent. 4891 DEFAULT_DIO_INTERVAL_MIN This is the default value used to configure 4892 Imin for the DIO trickle timer. DEFAULT_DIO_INTERVAL_MIN has a 4893 value of 3. This configuration results in Imin of 8ms. 4895 DEFAULT_DIO_INTERVAL_DOUBLINGS This is the default value used to 4896 configure Imax for the DIO trickle timer. 4897 DEFAULT_DIO_INTERVAL_DOUBLINGS has a value of 20. This 4898 configuration results in a maximum interval of 2.3 hours. 4900 DEFAULT_DIO_REDUNDANCY_CONSTANT This is the default value used to 4901 configure k for the DIO trickle timer. 4902 DEFAULT_DIO_REDUNDANCY_CONSTANT has a value of 10. This 4903 configuration is a conservative value for trickle suppression 4904 mechanism. 4906 DEFAULT_MIN_HOP_RANK_INCREASE This is the default value of 4907 MinHopRankIncrease. DEFAULT_MIN_HOP_RANK_INCREASE has a value 4908 of 256. This configuration results in an 8-bit wide integer 4909 part of Rank. 4911 DEFAULT_DAO_DELAY This is the default value for the DelayDAO Timer. 4912 DEFAULT_DAO_DELAY has value of 1 second. See Section 9.5. 4914 DIO Timer One instance per DODAG that a node is a member of. Expiry 4915 triggers DIO message transmission. Trickle timer with variable 4916 interval in [0, DIOIntervalMin..2^DIOIntervalDoublings]. See 4917 Section 8.3.1 4919 DAG Version Increment Timer Up to one instance per DODAG that the 4920 node is acting as DODAG root of. May not be supported in all 4921 implementations. Expiry triggers increment of 4922 DODAGVersionNumber, causing a new series of updated DIO message 4923 to be sent. Interval should be chosen appropriate to 4924 propagation time of DODAG and as appropriate to application 4925 requirements (e.g. response time vs. overhead). 4927 DelayDAO Timer Up to one timer per DAO parent (the subset of DODAG 4928 parents chosen to receive destination advertisements) per 4929 DODAG. Expiry triggers sending of DAO message to the DAO 4930 parent. See Section 9.5 4932 RemoveTimer Up to one timer per DAO entry per neighbor (i.e. those 4933 neighbors that have given DAO messages to this node as a DODAG 4934 parent) Expiry may trigger No-Path advertisements or 4935 immediately deallocate the DAO entry if there are no DAO 4936 parents. 4938 17. Manageability Considerations 4940 The aim of this section is to give consideration to the manageability 4941 of RPL, and how RPL will be operated in a LLN. The scope of this 4942 section is to consider the following aspects of manageability: 4943 configuration, monitoring, fault management, accounting, and 4944 performance of the protocol in light of the recommendations set forth 4945 in [RFC5706]. 4947 17.1. Introduction 4949 Most of the existing IETF management standards are Structure of 4950 Management Information (SMI) based data models (MIB modules) to 4951 monitor and manage networking devices. 4953 For a number of protocols, the IETF community has used the IETF 4954 Standard Management Framework, including the Simple Network 4955 Management Protocol [RFC3410], the Structure of Management 4956 Information [RFC2578], and MIB data models for managing new 4957 protocols. 4959 As pointed out in [RFC5706], the common policy in terms of operation 4960 and management has been expanded to a policy that is more open to a 4961 set of tools and management protocols rather than strictly relying on 4962 a single protocol such as SNMP. 4964 In 2003, the Internet Architecture Board (IAB) held a workshop on 4965 Network Management [RFC3535] that discussed the strengths and 4966 weaknesses of some IETF network management protocols and compared 4967 them to operational needs, especially configuration. 4969 One issue discussed was the user-unfriendliness of the binary format 4970 of SNMP [RFC3410]. In the case of LLNs, it must be noted that at the 4971 time of writing, the CoRE Working Group is actively working on 4972 resource management of devices in LLNs. Still, it is felt that this 4973 section provides important guidance on how RPL should be deployed, 4974 operated, and managed. 4976 As stated in [RFC5706], "A management information model should 4977 include a discussion of what is manageable, which aspects of the 4978 protocol need to be configured, what types of operations are allowed, 4979 what protocol-specific events might occur, which events can be 4980 counted, and for which events an operator should be notified". These 4981 aspects are discussed in detail in the following sections. 4983 RPL will be used on a variety of devices that may have resources such 4984 as memory varying from a few Kbytes to several hundreds of Kbytes and 4985 even Mbytes. When memory is highly constrained, it may not be 4986 possible to satisfy all the requirements listed in this section. 4987 Still it is worth listing all of these in an exhaustive fashion, and 4988 implementers will then determine which of these requirements could be 4989 satisfied according to the available resources on the device. 4991 17.2. Configuration Management 4993 This section discusses the configuration management, listing the 4994 protocol parameters for which configuration management is relevant. 4996 Some of the RPL parameters are optional. The requirements for 4997 configuration are only applicable for the options that are used. 4999 17.2.1. Initialization Mode 5001 "Architectural Principles of the Internet" [RFC1958], Section 3.8, 5002 states: "Avoid options and parameters whenever possible. Any options 5003 and parameters should be configured or negotiated dynamically rather 5004 than manually." This is especially true in LLNs where the number of 5005 devices may be large and manual configuration is infeasible. This 5006 has been taken into account in the design of RPL whereby the DODAG 5007 root provides a number of parameters to the devices joining the 5008 DODAG, thus avoiding cumbersome configuration on the routers and 5009 potential sources of misconfiguration (e.g. values of trickle timers, 5010 ...). Still there are additional RPL parameters that a RPL 5011 implementation should allow to be configured, which are discussed in 5012 this section. 5014 17.2.1.1. DIS mode of operation upon boot-up 5016 When a node is first powered up: 5018 1. The node may decide to stay silent, waiting to receive DIO 5019 messages from DODAG of interest (advertising a supported OF and 5020 metrics/constraints) and not send any multicast DIO messages 5021 until it has joined a DODAG. 5023 2. The node may decide to send one or more DIS messages (optionally 5024 requesting DIO for a specific DODAG) as an initial probe for 5025 nearby DODAGs, and in the absence of DIO messages in reply after 5026 some configurable period of time, the node may decide to root a 5027 floating DODAG and start sending multicast DIO messages. 5029 A RPL implementation SHOULD allow configuring the preferred mode of 5030 operation listed above along with the required parameters (in the 5031 second mode: the number of DIS messages and related timer). 5033 17.2.2. DIO and DAO Base Message and Options Configuration 5035 RPL specifies a number of protocol parameters considering the large 5036 spectrum of applications where it will be used. That said, 5037 particular attention has been given to limiting the number of these 5038 parameters that must be configured on each RPL router. Instead, a 5039 number of the default values can be used, and when required these 5040 parameters can be provided by the DODAG root thus allowing for 5041 dynamic parameter setting. 5043 A RPL implementation SHOULD allow configuring the following routing 5044 protocol parameters. As pointed out above, note that a large set of 5045 parameters is configured on the DODAG root. 5047 17.2.3. Protocol Parameters to be configured on every router in the LLN 5049 A RPL implementation MUST allow configuring the following RPL 5050 parameters: 5052 o RPLInstanceID [DIO message, in DIO base message]. Although the 5053 RPLInstanceID must be configured on the DODAG root, it must also 5054 be configured as a policy on every node in order to determine 5055 whether or not the node should join a particular DODAG. Note that 5056 a second RPLInstance can be configured on the node, should it 5057 become root of a floating DODAG. 5059 o List of supported Objective Code Points (OCPs) 5061 o List of supported metrics: [I-D.ietf-roll-routing-metrics] 5062 specifies a number of metrics and constraints used for the DODAG 5063 formation. Thus a RPL implementation should allow configuring the 5064 list of metrics that a node can accept and understand. If a DIO 5065 is received with a metric and/or constraint that is not understood 5066 or supported, as specified in Section 8.5, the node would join as 5067 a leaf node. 5069 o Prefix information, along with valid and preferred lifetime and 5070 the L and A flags. [DIO message, Prefix Information option]. A 5071 RPL implementation SHOULD allow configuring if the Prefix 5072 Information Option must be carried with the DIO message to 5073 distribute the prefix information for auto-configuration. In that 5074 case, the RPL implementation MUST allow the list of prefixes to be 5075 advertised in the Prefix Information Option along with the 5076 corresponding flags. 5078 o Solicited Information [DIS message, in Solicited Information 5079 option]. Note that an RPL implementation SHOULD allow configuring 5080 when such messages should be sent and under which circumstances, 5081 along with the value of the RPLInstance ID, V/I/D flags. 5083 o 'K' flag: when a node should set the 'K' flag in a DAO message 5084 [DAO message, in DAO base message]. 5086 o MOP (Mode of Operation) [DIO message, in DIO base message]. 5088 o Route Information (and preference) [DIO message, in Route 5089 Information option] 5091 17.2.4. Protocol Parameters to be configured on every non-DODAG-root 5092 router in the LLN 5094 A RPL implementation MUST allow configuring the Target prefix [DAO 5095 message, in RPL Target option]. 5097 Furthermore, there are circumstances where a node may want to 5098 designate a Target to allow for specific processing of the Target 5099 (prioritization, ...). Such processing rules are out of scope for 5100 this specification. When used, a RPL implementation SHOULD allow 5101 configuring the Target Descriptor on a per-Target basis (for example 5102 using access lists). 5104 A node whose DODAG parent set is empty may become the DODAG root of a 5105 floating DODAG. It may also set its DAGPreference such that it is 5106 less preferred. Thus a RPL implementation MUST allow configuring the 5107 set of actions that the node should initiate in this case: 5109 o Start its own (floating) DODAG: the new DODAGID must be configured 5110 in addition to its DAGPreference. 5112 o Poison the broken path (see procedure in Section 8.2.2.5). 5114 o Trigger a local repair. 5116 17.2.5. Parameters to be configured on the DODAG root 5118 In addition, several other parameters are configured only on the 5119 DODAG root and advertised in options carried in DIO messages. 5121 As specified in Section 8.3, a RPL implementation makes use of 5122 trickle timers to govern the sending of DIO messages. The operation 5123 of the trickle algorithm is determined by a set of configurable 5124 parameters, which MUST be configurable and that are then advertised 5125 by the DODAG root along the DODAG in DIO messages. 5127 o DIOIntervalDoublings [DIO message, in DODAG configuration option] 5129 o DIOIntervalMin [DIO message, in DODAG configuration option] 5131 o DIORedundancyConstant [DIO message, in DODAG configuration option] 5133 In addition, a RPL implementation SHOULD allow for configuring the 5134 following set of RPL parameters: 5136 o Path Control Size [DIO message, in DODAG configuration option] 5138 o MinHopRankIncrease [DIO message, in DODAG configuration option] 5140 o The DODAGPreference field [DIO message, DIO Base object] 5142 o DODAGID [DIO message, in DIO base option] and [DAO message, when 5143 the 'D' flag of the DAO message is set] 5145 DAG Root behavior: in some cases, a node may not want to permanently 5146 act as a floating DODAG root if it cannot join a grounded DODAG. For 5147 example a battery-operated node may not want to act as a floating 5148 DODAG root for a long period of time. Thus a RPL implementation MAY 5149 support the ability to configure whether or not a node could act as a 5150 floating DODAG root for a configured period of time. 5152 DAG Version Number Increment: a RPL implementation may allow by 5153 configuration at the DODAG root to refresh the DODAG states by 5154 updating the DODAGVersionNumber. A RPL implementation SHOULD allow 5155 configuring whether or not periodic or event triggered mechanisms are 5156 used by the DODAG root to control DODAGVersionNumber change (which 5157 triggers a global repair as specified in Section 3.2.2. 5159 17.2.6. Configuration of RPL Parameters related to DAO-based mechanisms 5161 DAO messages are optional and used in DODAGs that require downward 5162 routing operation. This section deals with the set of parameters 5163 related to DAO messages and provides recommendations on their 5164 configuration. 5166 As stated in Section 9.5, it is recommended to delay the sending of 5167 DAO message to DAO parents in order to maximize the chances to 5168 perform route aggregation. Upon receiving a DAO message, the node 5169 should thus start a DelayDAO timer. The default value is 5170 DEFAULT_DAO_DELAY. A RPL implementation MAY allow for configuring 5171 the DelayDAO timer. 5173 In a storing mode of operation, a storing node may increment DTSN in 5174 order to reliably trigger a set of DAO updates from its immediate 5175 children, as part of routine routing table updates and maintenance. 5176 A RPL implementation MAY allow for configuring a set of rules 5177 specifying the triggers for DTSN increment (manual or event-based). 5179 When a DAO entry times out or is invalidated, a node SHOULD make a 5180 reasonable attempt to report a No-Path to each of the DAO parents. 5181 That number of attempts MAY be configurable. 5183 An implementation should support rate-limiting the sending of DAO 5184 messages. The related parameters MAY be configurable. 5186 17.2.7. Configuration of RPL Parameters related to Security mechanisms 5188 As described in Section 10, the security features described in this 5189 document are optional to implement and a given implementation may 5190 support a subset (including the empty set) of the described security 5191 features. 5193 To this end an implementation supporting described security features 5194 may conceptually implement a security policy database. In support of 5195 the security mechanisms, a RPL implementation SHOULD allow for 5196 configuring a subset of the following parameters: 5198 o Security Modes accepted [Unsecured mode, Pre-Installed mode, 5199 Authenticated mode] 5201 o KIM values accepted [Secure RPL Control messages, in Security 5202 Section] 5204 o Level values accepted [Secure RPL Control messages, in Security 5205 section] 5207 o Algorithm values accepted [Secure RPL Control messages, in 5208 Security section] 5210 o Key material in support of Authenticated or Pre-Installed key 5211 modes. 5213 In addition, a RPL implementation SHOULD allow for configuring a 5214 DODAG root with a subset of the following parameters: 5216 o Level values advertised [Secure DIO message, in Security Section] 5218 o KIM value advertised [Secure DIO message, in Security Section] 5220 o Algorithm value advertised [Secure DIO message, in Security 5221 Section] 5223 17.2.8. Default Values 5225 This document specifies default values for the following set of RPL 5226 variables: 5227 DEFAULT_PATH_CONTROL_SIZE 5228 DEFAULT_DIO_INTERVAL_MIN 5229 DEFAULT_DIO_INTERVAL_DOUBLINGS 5230 DEFAULT_DIO_REDUNDANCY_CONSTANT 5231 DEFAULT_MIN_HOP_RANK_INCREASE 5232 DEFAULT_DAO_DELAY 5234 It is recommended to specify default values in protocols; that being 5235 said, as discussed in [RFC5706], default values may make less and 5236 less sense. RPL is a routing protocol that is expected to be used in 5237 a number of contexts where network characteristics such as the number 5238 of nodes, link and nodes types are expected to vary significantly. 5239 Thus, these default values are likely to change with the context and 5240 as the technology will evolve. Indeed, LLNs' related technology 5241 (e.g. hardware, link layers) have been evolving dramatically over the 5242 past few years and such technologies are expected to change and 5243 evolve considerably in the coming years. 5245 The proposed values are not based on extensive best current practices 5246 and are considered to be conservative. 5248 17.3. Monitoring of RPL Operation 5250 Several RPL parameters should be monitored to verify the correct 5251 operation of the routing protocol and the network itself. This 5252 section lists the set of monitoring parameters of interest. 5254 17.3.1. Monitoring a DODAG parameters 5256 A RPL implementation SHOULD provide information about the following 5257 parameters: 5259 o DODAG Version number [DIO message, in DIO base message] 5261 o Status of the G flag [DIO message, in DIO base message] 5263 o Status of the MOP field [DIO message, in DIO base message] 5265 o Value of the DTSN [DIO message, in DIO base message] 5267 o Value of the rank [DIO message, in DIO base message] 5269 o DAOSequence: Incremented at each unique DAO message, echoed in the 5270 DAO-ACK message [DAO and DAO-ACK messages] 5272 o Route Information [DIO message, Route Information option] (list of 5273 IPv6 prefixes per parent along with lifetime and preference] 5275 o Trickle parameters: 5277 * DIOIntervalDoublings [DIO message, in DODAG configuration 5278 option] 5280 * DIOIntervalMin [DIO message, in DODAG configuration option] 5282 * DIORedundancyConstant [DIO message, in DODAG configuration 5283 option] 5285 o Path Control Size [DIO message, in DODAG configuration option] 5287 o MinHopRankIncrease [DIO message, in DODAG configuration option] 5289 Values that may be monitored only on the DODAG root 5291 o Transit Information [DAO, Transit Information option]: A RPL 5292 implementation SHOULD allow configuring whether the set of 5293 received Transit Information options should be displayed on the 5294 DODAG root. In this case, the RPL database of received Transit 5295 Information should also contain: the path-sequence, path control, 5296 path lifetime and parent address. 5298 17.3.2. Monitoring a DODAG inconsistencies and loop detection 5300 Detection of DODAG inconsistencies is particularly critical in RPL 5301 networks. Thus it is recommended for a RPL implementation to provide 5302 appropriate monitoring tools. A RPL implementation SHOULD provide a 5303 counter reporting the number of a times the node has detected an 5304 inconsistency with respect to a DODAG parent, e.g. if the DODAGID has 5305 changed. 5307 When possible more granular information about inconsistency detection 5308 should be provided. A RPL implementation MAY provide counters 5309 reporting the number of following inconsistencies: 5311 o Packets received with 'O' bit set (to Down) from a node with a 5312 higher rank 5314 o Packets received with 'O' bit cleared (to Up) from a node with a 5315 lower rank 5317 o Number of packets with the 'F' bit set 5318 o Number of packets with the 'R' bit set 5320 17.4. Monitoring of the RPL data structures 5322 17.4.1. Candidate Neighbor Data Structure 5324 A node in the candidate neighbor list is a node discovered by the 5325 some means and qualified to potentially become a parent (with high 5326 enough local confidence). A RPL implementation SHOULD provide a way 5327 to allow for the candidate neighbor list to be monitored with some 5328 metric reflecting local confidence (the degree of stability of the 5329 neighbors) as measured by some metrics. 5331 A RPL implementation MAY provide a counter reporting the number of 5332 times a candidate neighbor has been ignored, should the number of 5333 candidate neighbors exceeds the maximum authorized value. 5335 17.4.2. Destination Oriented Directed Acyclic Graph (DAG) Table 5337 For each DODAG, a RPL implementation is expected to keep track of the 5338 following DODAG table values: 5340 o RPLInstanceID 5342 o DODAGID 5344 o DODAGVersionNumber 5346 o Rank 5348 o Objective Code Point 5350 o A set of DODAG Parents 5352 o A set of prefixes offered upwards along the DODAG 5354 o Trickle timers used to govern the sending of DIO messages for the 5355 DODAG 5357 o List of DAO parents 5359 o DTSN 5361 o Node status (router versus leaf) 5363 A RPL implementation SHOULD allow for monitoring the set of 5364 parameters listed above. 5366 17.4.3. Routing Table and DAO Routing Entries 5368 A RPL implementation maintains several information elements related 5369 to the DODAG and the DAO entries (for storing nodes). In the case of 5370 a non storing node, a limited amount of information is maintained 5371 (the routing table is mostly reduced to a set of DODAG parents along 5372 with characteristics of the DODAG as mentioned above) whereas in the 5373 case of storing nodes, this information is augmented with routing 5374 entries. 5376 A RPL implementation SHOULD allow for the following parameters to be 5377 monitored: 5379 o Next Hop (DODAG parent) 5381 o Next Hop Interface 5383 o Path metrics value for each DODAG parent 5385 A DAO Routing Table Entry conceptually contains the following 5386 elements (for storing nodes only): 5388 o Advertising Neighbor Information 5390 o IPv6 Address 5392 o Interface ID to which DAO Parents has this entry been reported 5394 o Retry Counter 5396 o Logical equivalent of DAO Content: 5398 * DAO-Sequence 5400 * Path Sequence 5402 * DAO Lifetime 5404 * DAO Path Control 5406 o Destination Prefix (or Address or Mcast Group) 5408 A RPL implementation SHOULD provide information about the state of 5409 each DAO Routing Table entry states. 5411 17.5. Fault Management 5413 Fault management is a critical component used for troubleshooting, 5414 verification of the correct mode of operation of the protocol, 5415 network design, and is also a key component of network performance 5416 monitoring. A RPL implementation SHOULD allow providing the 5417 following information related to fault managements: 5419 o Memory overflow along with the cause (e.g. routing tables 5420 overflow, ...) 5422 o Number of times a packet could not be sent to a DODAG parent 5423 flagged as valid 5425 o Number of times a packet has been received for which the router 5426 did not have a corresponding RPLInstanceID 5428 o Number of times a local repair procedure was triggered 5430 o Number of times a global repair was triggered by the DODAG root 5432 o Number of received malformed messages 5434 o Number of seconds with packets to forward and no next hop (DODAG 5435 parent) 5437 o Number of seconds without next hop (DODAG parent) 5439 o Number of times a node has joined a DODAG as a leaf because it 5440 received a DIO with metric/constraint not understood and it was 5441 configured to join as a leaf node in this case (see Section 17.6). 5443 It is RECOMMENDED to report faults via at least error log messages. 5444 Other protocols may be used to report such faults. 5446 17.6. Policy 5448 Policy rules can be used by a RPL implementation to determine whether 5449 or not the node is allowed to join a particular DODAG advertised by a 5450 neighbor by means of DIO messages. 5452 This document specifies operation within a single DODAG. A DODAG is 5453 characterized by the following tuple (RPLInstanceID, DODAGID). 5454 Furthermore, as pointed out above, DIO messages are used to advertise 5455 other DODAG characteristics such as the routing metrics and 5456 constraints used to build to the DODAG and the Objective Function in 5457 use (specified by OCP). 5459 The first policy rules consist of specifying the following conditions 5460 that a RPL node must satisfy to join a DODAG: 5462 o RPLInstanceID 5464 o List of supported routing metrics and constraints 5466 o Objective Function (OCP values) 5468 A RPL implementation MUST allow configuring these parameters and 5469 SHOULD specify whether the node must simply ignore the DIO if the 5470 advertised DODAG is not compliant with the local policy or whether 5471 the node should join as the leaf node if only the list of supported 5472 routing metrics and constraints, and the OF is not supported. 5473 Additionally a RPL implementation SHOULD allow for the addition of 5474 the DODAGID as part of the policy. 5476 A RPL implementation SHOULD allow configuring the set of acceptable 5477 or preferred Objective Functions (OF) referenced by their Objective 5478 Codepoints (OCPs) for a node to join a DODAG, and what action should 5479 be taken if none of a node's candidate neighbors advertise one of the 5480 configured allowable Objective Functions, or if the advertised 5481 metrics/constraint is not understood/supported. Two actions can be 5482 taken in this case: 5484 o The node joins the DODAG as a leaf node as specified in 5485 Section 8.5 5487 o The node does not join the DODAG 5489 A node in an LLN may learn routing information from different routing 5490 protocols including RPL. It is in this case desirable to control via 5491 administrative preference which route should be favored. An 5492 implementation SHOULD allow for specifying an administrative 5493 preference for the routing protocol from which the route was learned. 5495 Internal Data Structures: some RPL implementations may limit the size 5496 of the candidate neighbor list in order to bound the memory usage, in 5497 which case some otherwise viable candidate neighbors may not be 5498 considered and simply dropped from the candidate neighbor list. 5500 A RPL implementation MAY provide an indicator on the size of the 5501 candidate neighbor list. 5503 17.7. Fault Isolation 5505 It is RECOMMENDED to quarantine neighbors that start emitting 5506 malformed messages at unacceptable rates. 5508 17.8. Impact on Other Protocols 5510 RPL has very limited impact on other protocols. Where more than one 5511 routing protocol is required on a router such as a LBR, it is 5512 expected for the device to support routing redistribution functions 5513 between the routing protocols to allow for reachability between the 5514 two routing domains. Such redistribution SHOULD be governed by the 5515 use of user configurable policy. 5517 With regards to the impact in terms of traffic on the network, RPL 5518 has been designed to limit the control traffic thanks to mechanisms 5519 such as Trickle timers (Section 8.3). Thus the impact of RPL on 5520 other protocols should be extremely limited. 5522 17.9. Performance Management 5524 Performance management is always an important aspect of a protocol 5525 and RPL is not an exception. Several metrics of interest have been 5526 specified by the IP Performance Monitoring (IPPM) Working Group: that 5527 being said, they will be hardly applicable to LLN considering the 5528 cost of monitoring these metrics in terms of resources on the devices 5529 and required bandwidth. Still, RPL implementation MAY support some 5530 of these, and other parameters of interest are listed below: 5532 o Number of repairs and time to repair in seconds (average, 5533 variance) 5535 o Number of times and duration during which a devices could not 5536 forward a packet because of a lack of reachable neighbor in its 5537 routing table 5539 o Monitoring of resources consumption by RPL in terms of bandwidth 5540 and required memory 5542 o Number of RPL control messages sent and received 5544 17.10. Diagnostics 5546 There may be situations where a node should be placed in "verbose" 5547 mode to improve diagnostics. Thus a RPL implementation SHOULD 5548 provide the ability to place a node in and out of verbose mode in 5549 order to get additional diagnostic information. 5551 18. Security Considerations 5553 18.1. Overview 5555 From a security perspective, RPL networks are no different from any 5556 other network. They are vulnerable to passive eavesdropping attacks 5557 and potentially even active tampering when physical access to a wire 5558 is not required to participate in communications. The very nature of 5559 ad hoc networks and their cost objectives impose additional security 5560 constraints, which perhaps make these networks the most difficult 5561 environments to secure. Devices are low-cost and have limited 5562 capabilities in terms of computing power, available storage, and 5563 power drain; and it cannot always be assumed they have a trusted 5564 computing base or a high-quality random number generator aboard. 5565 Communications cannot rely on the online availability of a fixed 5566 infrastructure and might involve short-term relationships between 5567 devices that may never have communicated before. These constraints 5568 might severely limit the choice of cryptographic algorithms and 5569 protocols and influence the design of the security architecture 5570 because the establishment and maintenance of trust relationships 5571 between devices need to be addressed with care. In addition, battery 5572 lifetime and cost constraints put severe limits on the security 5573 overhead these networks can tolerate, something that is of far less 5574 concern with higher bandwidth networks. Most of these security 5575 architectural elements can be implemented at higher layers and may, 5576 therefore, be considered to be out of scope for this specification. 5577 Special care, however, needs to be exercised with respect to 5578 interfaces to these higher layers. 5580 The security mechanisms in this standard are based on symmetric-key 5581 and public-key cryptography and use keys that are to be provided by 5582 higher layer processes. The establishment and maintenance of these 5583 keys are out of scope for this specification. The mechanisms assume 5584 a secure implementation of cryptographic operations and secure and 5585 authentic storage of keying material. 5587 The security mechanisms specified provide particular combinations of 5588 the following security services: 5590 Data confidentiality: Assurance that transmitted information is only 5591 disclosed to parties for which it is intended. 5593 Data authenticity: Assurance of the source of transmitted 5594 information (and, hereby, that information was not 5595 modified in transit). 5597 Replay protection: Assurance that a duplicate of transmitted 5598 information is detected. 5600 Timeliness (delay protection): Assurance that transmitted 5601 information was received in a timely manner. 5603 The actual protection provided can be adapted on a per-packet basis 5604 and allows for varying levels of data authenticity (to minimize 5605 security overhead in transmitted packets where required) and for 5606 optional data confidentiality. When nontrivial protection is 5607 required, replay protection is always provided. 5609 Replay protection is provided via the use of a non-repeating value 5610 (nonce) in the packet protection process and storage of some status 5611 information for each originating device on the receiving device, 5612 which allows detection of whether this particular nonce value was 5613 used previously by the originating device. In addition, so-called 5614 delay protection is provided amongst those devices that have a 5615 loosely synchronized clock on board. The acceptable time delay can 5616 be adapted on a per-packet basis and allows for varying latencies (to 5617 facilitate longer latencies in packets transmitted over a multi-hop 5618 communication path). 5620 Cryptographic protection may use a key shared between two peer 5621 devices (link key) or a key shared among a group of devices (group 5622 key), thus allowing some flexibility and application-specific 5623 tradeoffs between key storage and key maintenance costs versus the 5624 cryptographic protection provided. If a group key is used for peer- 5625 to-peer communication, protection is provided only against outsider 5626 devices and not against potential malicious devices in the key- 5627 sharing group. 5629 Data authenticity may be provided using symmetric-key based or 5630 public-key based techniques. With public-key based techniques (via 5631 signatures), one corroborates evidence as to the unique originator of 5632 transmitted information, whereas with symmetric-key based techniques 5633 data authenticity is only provided relative to devices in a key- 5634 sharing group. Thus, public-key based authentication may be useful 5635 in scenarios that require a more fine-grained authentication than can 5636 be provided with symmetric-key based authentication techniques alone, 5637 such as with group communications (broadcast, multicast), or in 5638 scenarios that require non-repudiation. 5640 19. IANA Considerations 5642 19.1. RPL Control Message 5644 The RPL Control Message is an ICMP information message type that is 5645 to be used carry DODAG Information Objects, DODAG Information 5646 Solicitations, and Destination Advertisement Objects in support of 5647 RPL operation. 5649 IANA has defined an ICMPv6 Type Number Registry. The suggested type 5650 value for the RPL Control Message is 155, to be confirmed by IANA. 5652 19.2. New Registry for RPL Control Codes 5654 IANA is requested to create a registry, RPL Control Codes, for the 5655 Code field of the ICMPv6 RPL Control Message. 5657 New codes may be allocated only by an IETF Review. Each code should 5658 be tracked with the following qualities: 5660 o Code 5662 o Description 5664 o Defining RFC 5666 The following codes are currently defined: 5668 +------+----------------------------------------------+-------------+ 5669 | Code | Description | Reference | 5670 +------+----------------------------------------------+-------------+ 5671 | 0x00 | DODAG Information Solicitation | This | 5672 | | | document | 5673 | | | | 5674 | 0x01 | DODAG Information Object | This | 5675 | | | document | 5676 | | | | 5677 | 0x02 | Destination Advertisement Object | This | 5678 | | | document | 5679 | | | | 5680 | 0x03 | Destination Advertisement Object | This | 5681 | | Acknowledgment | document | 5682 | | | | 5683 | 0x80 | Secure DODAG Information Solicitation | This | 5684 | | | document | 5685 | | | | 5686 | 0x81 | Secure DODAG Information Object | This | 5687 | | | document | 5688 | 0x82 | Secure Destination Advertisement Object | This | 5689 | | | document | 5690 | | | | 5691 | 0x83 | Secure Destination Advertisement Object | This | 5692 | | Acknowledgment | document | 5693 | | | | 5694 | 0x8A | Consistency Check | This | 5695 | | | document | 5696 +------+----------------------------------------------+-------------+ 5698 RPL Control Codes 5700 19.3. New Registry for the Mode of Operation (MOP) 5702 IANA is requested to create a registry for the 3-bit Mode of 5703 Operation (MOP), which is contained in the DIO Base. 5705 New values may be allocated only by an IETF Review. Each value 5706 should be tracked with the following qualities: 5708 o Mode of Operation Value 5710 o Capability description 5712 o Defining RFC 5714 Four values are currently defined: 5716 +----------+------------------------------------------+-------------+ 5717 | MOP | Description | Reference | 5718 | value | | | 5719 +----------+------------------------------------------+-------------+ 5720 | 0 | No downward routes maintained by RPL | This | 5721 | | | document | 5722 | | | | 5723 | 1 | Non-Storing mode of operation | This | 5724 | | | document | 5725 | | | | 5726 | 2 | Storing mode of operation with no | This | 5727 | | multicast support | document | 5728 | | | | 5729 | 3 | Storing mode of operation with multicast | This | 5730 | | support | document | 5731 +----------+------------------------------------------+-------------+ 5733 DIO Mode of operation 5735 The rest of the range, decimal 4 to 7, is currently unassigned. 5737 19.4. RPL Control Message Option 5739 IANA is requested to create a registry for the RPL Control Message 5740 Options 5742 New values may be allocated only by an IETF Review. Each value 5743 should be tracked with the following qualities: 5745 o Value 5747 o Meaning 5749 o Defining RFC 5751 +-------+-----------------------+---------------+ 5752 | Value | Meaning | Reference | 5753 +-------+-----------------------+---------------+ 5754 | 0 | Pad1 | This document | 5755 | | | | 5756 | 1 | PadN | This document | 5757 | | | | 5758 | 2 | DAG Metric Container | This Document | 5759 | | | | 5760 | 3 | Routing Information | This Document | 5761 | | | | 5762 | 4 | DODAG Configuration | This Document | 5763 | | | | 5764 | 5 | RPL Target | This Document | 5765 | | | | 5766 | 6 | Transit Information | This Document | 5767 | | | | 5768 | 7 | Solicited Information | This Document | 5769 | | | | 5770 | 8 | Prefix Information | This Document | 5771 | | | | 5772 | 9 | Target Descriptor | This Document | 5773 +-------+-----------------------+---------------+ 5775 RPL Control Message Options 5777 19.5. Objective Code Point (OCP) Registry 5779 IANA is requested to create a registry to manage the codespace of the 5780 Objective Code Point (OCP) field. 5782 No OCP codepoints are defined in this specification. 5784 New codes may be allocated only by an IETF Review. Each code should 5785 be tracked with the following qualities: 5787 o OCP code 5789 o Description 5791 o Defining RFC 5793 19.6. New Registry for the Security Section Algorithm 5795 IANA is requested to create a registry for the values of 8-bit 5796 Algorithm field in the Security Section. 5798 New values may be allocated only by an IETF Review. Each value 5799 should be tracked with the following qualities: 5801 o Value 5803 o Encryption/MAC 5805 o Signature 5807 o Defining RFC 5809 The following value is currently defined: 5811 +-------+------------------+------------------+---------------+ 5812 | Value | Encryption/MAC | Signature | Reference | 5813 +-------+------------------+------------------+---------------+ 5814 | 0 | CCM with AES-128 | RSA with SHA-256 | This document | 5815 +-------+------------------+------------------+---------------+ 5817 Security Section Algorithm 5819 19.7. New Registry for the Security Section Flags 5821 IANA is requested to create a registry for the 8-bit Security Section 5822 Flag Field. 5824 New bit numbers may be allocated only by an IETF Review. Each bit 5825 should be tracked with the following qualities: 5827 o Bit number (counting from bit 0 as the most significant bit) 5829 o Capability description 5831 o Defining RFC 5832 No bit is currently defined for the Security Section Flags. 5834 19.8. New Registry for Per-KIM Security Levels 5836 IANA is requested to create one registry for the 3-bit Security Level 5837 (LVL) Field per allocated KIM value. 5839 For a given KIM value, new levels may be allocated only by an IETF 5840 Review. Each level should be tracked with the following qualities: 5842 o Level 5844 o KIM value 5846 o Description 5848 o Defining RFC 5850 The following levels pre KIM value are currently defined: 5852 +-------+-----------+---------------+---------------+ 5853 | Level | KIM value | Description | Reference | 5854 +-------+-----------+---------------+---------------+ 5855 | 0 | 0 | See Figure 11 | This document | 5856 | | | | | 5857 | 1 | 0 | See Figure 11 | This document | 5858 | | | | | 5859 | 2 | 0 | See Figure 11 | This document | 5860 | | | | | 5861 | 3 | 0 | See Figure 11 | This document | 5862 | | | | | 5863 | 0 | 1 | See Figure 11 | This document | 5864 | | | | | 5865 | 1 | 1 | See Figure 11 | This document | 5866 | | | | | 5867 | 2 | 1 | See Figure 11 | This document | 5868 | | | | | 5869 | 3 | 1 | See Figure 11 | This document | 5870 | | | | | 5871 | 0 | 2 | See Figure 11 | This document | 5872 | | | | | 5873 | 1 | 2 | See Figure 11 | This document | 5874 | | | | | 5875 | 2 | 2 | See Figure 11 | This document | 5876 | | | | | 5877 | 3 | 2 | See Figure 11 | This document | 5878 | | | | | 5879 | 0 | 3 | See Figure 11 | This document | 5880 | | | | | 5881 | 1 | 3 | See Figure 11 | This document | 5882 | | | | | 5883 | 2 | 3 | See Figure 11 | This document | 5884 | | | | | 5885 | 3 | 3 | See Figure 11 | This document | 5886 +-------+-----------+---------------+---------------+ 5888 Per-KIM Security Levels 5890 19.9. New Registry for the DIS (DODAG Informational Solicitation) Flags 5892 IANA is requested to create a registry for the DIS (DODAG 5893 Informational Solicitation) Flag Field. 5895 New bit numbers may be allocated only by an IETF Review. Each bit 5896 should be tracked with the following qualities: 5898 o Bit number (counting from bit 0 as the most significant bit) 5900 o Capability description 5902 o Defining RFC 5904 No bit is currently defined for the DIS (DODAG Informational 5905 Solicitation) Flags. 5907 19.10. New Registry for the DODAG Information Object (DIO) Flags 5909 IANA is requested to create a registry for the 8-bit DODAG 5910 Information Object (DIO) Flag Field. 5912 New bit numbers may be allocated only by an IETF Review. Each bit 5913 should be tracked with the following qualities: 5915 o Bit number (counting from bit 0 as the most significant bit) 5917 o Capability description 5919 o Defining RFC 5921 No bit is currently defined for the DIS (DODAG Informational 5922 Solicitation) Flags. 5924 19.11. New Registry for the Destination Advertisement Object (DAO) 5925 Flags 5927 IANA is requested to create a registry for the 8-bit Destination 5928 Advertisement Object (DAO) Flag Field. 5930 New bit numbers may be allocated only by an IETF Review. Each bit 5931 should be tracked with the following qualities: 5933 o Bit number (counting from bit 0 as the most significant bit) 5935 o Capability description 5937 o Defining RFC 5939 The following bits are currently defined: 5941 +------------+--------------------------+---------------+ 5942 | Bit number | Description | Reference | 5943 +------------+--------------------------+---------------+ 5944 | 0 | DAO-ACK request | This document | 5945 | | | | 5946 | 1 | DODAGID field is present | This document | 5947 +------------+--------------------------+---------------+ 5949 DAO Base Flags 5951 19.12. New Registry for the Destination Advertisement Object (DAO) 5952 Acknowledgement Flags 5954 IANA is requested to create a registry for the 8-bit Destination 5955 Advertisement Object (DAO) Acknowledgement Flag Field. 5957 New bit numbers may be allocated only by an IETF Review. Each bit 5958 should be tracked with the following qualities: 5960 o Bit number (counting from bit 0 as the most significant bit) 5962 o Capability description 5964 o Defining RFC 5966 The following bit is currently defined: 5968 +------------+--------------------------+---------------+ 5969 | Bit number | Description | Reference | 5970 +------------+--------------------------+---------------+ 5971 | 0 | DODAGID field is present | This document | 5972 +------------+--------------------------+---------------+ 5974 DAO-ACK Base Flags 5976 19.13. New Registry for the Consistency Check (CC) Flags 5978 IANA is requested to create a registry for the 8-bit Consistency 5979 Check (CC) Flag Field. 5981 New bit numbers may be allocated only by an IETF Review. Each bit 5982 should be tracked with the following qualities: 5984 o Bit number (counting from bit 0 as the most significant bit) 5986 o Capability description 5987 o Defining RFC 5989 The following bit is currently defined: 5991 +------------+-------------+---------------+ 5992 | Bit number | Description | Reference | 5993 +------------+-------------+---------------+ 5994 | 0 | CC Response | This document | 5995 +------------+-------------+---------------+ 5997 Consistency Check Base Flags 5999 19.14. New Registry for the DODAG Configuration Option Flags 6001 IANA is requested to create a registry for the 8-bit DODAG 6002 Configuration Option Flag Field. 6004 New bit numbers may be allocated only by an IETF Review. Each bit 6005 should be tracked with the following qualities: 6007 o Bit number (counting from bit 0 as the most significant bit) 6009 o Capability description 6011 o Defining RFC 6013 The following bits are currently defined: 6015 +------------+------------------------+---------------+ 6016 | Bit number | Description | Reference | 6017 +------------+------------------------+---------------+ 6018 | 4 | Authentication Enabled | This document | 6019 | | | | 6020 | 5-7 | Path Control Size | This document | 6021 +------------+------------------------+---------------+ 6023 DODAG Configuration Option Flags 6025 19.15. New Registry for the RPL Target Option Flags 6027 IANA is requested to create a registry for the 8-bit RPL Target 6028 Option Flag Field. 6030 New bit numbers may be allocated only by an IETF Review. Each bit 6031 should be tracked with the following qualities: 6033 o Bit number (counting from bit 0 as the most significant bit) 6035 o Capability description 6037 o Defining RFC 6039 No bit is currently defined for the RPL Target Option Flags. 6041 19.16. New Registry for the Transit Information Option Flags 6043 IANA is requested to create a registry for the 8-bit Transit 6044 Information Option (RIO) Flag Field. 6046 New bit numbers may be allocated only by an IETF Review. Each bit 6047 should be tracked with the following qualities: 6049 o Bit number (counting from bit 0 as the most significant bit) 6051 o Capability description 6053 o Defining RFC 6055 The following bits are currently defined: 6057 +------------+-------------+---------------+ 6058 | Bit number | Description | Reference | 6059 +------------+-------------+---------------+ 6060 | 0 | External | This document | 6061 +------------+-------------+---------------+ 6063 Transit Information Option Flags 6065 19.17. New Registry for the Solicited Information Option Flags 6067 IANA is requested to create a registry for the 8-bit Solicited 6068 Information Option (RIO) Flag Field. 6070 New bit numbers may be allocated only by an IETF Review. Each bit 6071 should be tracked with the following qualities: 6073 o Bit number (counting from bit 0 as the most significant bit) 6075 o Capability description 6077 o Defining RFC 6079 The following bits are currently defined: 6081 +------------+----------------------------+---------------+ 6082 | Bit number | Description | Reference | 6083 +------------+----------------------------+---------------+ 6084 | 0 | Version Predicate match | This document | 6085 | | | | 6086 | 1 | InstanceID Predicate match | This document | 6087 | | | | 6088 | 2 | DODAGID Predicate match | This document | 6089 +------------+----------------------------+---------------+ 6091 Solicited Information Option Flags 6093 19.18. ICMPv6: Error in Source Routing Header 6095 In some cases RPL will return an ICMPv6 error message when a message 6096 cannot be delivered as specified by its source routing header. This 6097 ICMPv6 error message is "Error in Source Routing Header". 6099 IANA has defined an ICMPv6 "Code" Fields Registry for ICMPv6 Message 6100 Types. ICMPv6 Message Type 1 describes "Destination Unreachable" 6101 codes. The "Error in Source Routing Header" code is suggested to be 6102 allocated from the ICMPv6 Code Fields Registry for ICMPv6 Message 6103 Type 1, with a suggested code value of 7, to be confirmed by IANA. 6105 19.19. Link-Local Scope multicast address 6107 The rules for assigning new IPv6 multicast addresses are defined in 6108 [RFC3307]. This specification requires the allocation of a new 6109 permanent multicast address with a link local scope for RPL nodes 6110 called all-RPL-nodes, with a suggested value of FF02::1A, to be 6111 confirmed by IANA. 6113 20. Acknowledgements 6115 The authors would like to acknowledge the review, feedback, and 6116 comments from Roger Alexander, Emmanuel Baccelli, Dominique Barthel, 6117 Yusuf Bashir, Yoav Ben-Yehezkel, Phoebus Chen, Quynh Dang, Mischa 6118 Dohler, Mathilde Durvy, Joakim Eriksson, Omprakash Gnawali, Manhar 6119 Goindi, Mukul Goyal, Ulrich Herberg, Anders Jagd, JeongGil (John) Ko, 6120 Ajay Kumar, Quentin Lampin, Jerry Martocci, Matteo Paris, Alexandru 6121 Petrescu, Joseph Reddy, Michael Richardson, Don Sturek, Joydeep 6122 Tripathi, and Nicolas Tsiftes. 6124 The authors would like to acknowledge the guidance and input provided 6125 by the ROLL Chairs, David Culler and JP Vasseur, and the Area 6126 Director Adrian Farrel. 6128 The authors would like to acknowledge prior contributions of Robert 6129 Assimiti, Mischa Dohler, Julien Abeille, Ryuji Wakikawa, Teco Boot, 6130 Patrick Wetterwald, Bryan Mclaughlin, Carlos J. Bernardos, Thomas 6131 Watteyne, Zach Shelby, Caroline Bontoux, Marco Molteni, Billy Moon, 6132 Jim Bound, Yanick Pouffary, Henning Rogge and Arsalan Tavakoli, whom 6133 have provided useful design considerations to RPL. 6135 RPL Security Design, found in Section 10, Section 18, and elsewhere 6136 throughout the document, is primarily the contribution of the 6137 Security Design Team: Tzeta Tsao, Roger Alexander, Dave Ward, Philip 6138 Levis, Kris Pister, Rene Struik, and Adrian Farrel. 6140 21. Contributors 6142 Stephen Dawson-Haggerty 6143 UC Berkeley 6144 Soda Hall, UC Berkeley 6145 Berkeley, CA 94720 6146 USA 6148 Email: stevedh@cs.berkeley.edu 6150 22. References 6152 22.1. Normative References 6154 [I-D.ietf-6man-rpl-option] 6155 Hui, J. and J. Vasseur, "RPL Option for Carrying RPL 6156 Information in Data-Plane Datagrams", 6157 draft-ietf-6man-rpl-option-01 (work in progress), 6158 October 2010. 6160 [I-D.ietf-6man-rpl-routing-header] 6161 Hui, J., Vasseur, J., Culler, D., and V. Manral, "An IPv6 6162 Routing Header for Source Routes with RPL", 6163 draft-ietf-6man-rpl-routing-header-01 (work in progress), 6164 October 2010. 6166 [I-D.ietf-roll-routing-metrics] 6167 Vasseur, J., Kim, M., Pister, K., Dejean, N., and D. 6168 Barthel, "Routing Metrics used for Path Calculation in Low 6169 Power and Lossy Networks", 6170 draft-ietf-roll-routing-metrics-13 (work in progress), 6171 December 2010. 6173 [I-D.ietf-roll-trickle] 6174 Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 6175 "The Trickle Algorithm", draft-ietf-roll-trickle-06 (work 6176 in progress), December 2010. 6178 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 6179 Requirement Levels", BCP 14, RFC 2119, March 1997. 6181 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 6182 (IPv6) Specification", RFC 2460, December 1998. 6184 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 6185 Standards (PKCS) #1: RSA Cryptography Specifications 6186 Version 2.1", RFC 3447, February 2003. 6188 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 6189 in IPv6", RFC 3775, June 2004. 6191 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 6192 More-Specific Routes", RFC 4191, November 2005. 6194 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 6195 December 2005. 6197 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 6198 Message Protocol (ICMPv6) for the Internet Protocol 6199 Version 6 (IPv6) Specification", RFC 4443, March 2006. 6201 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 6202 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 6203 September 2007. 6205 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 6206 Address Autoconfiguration", RFC 4862, September 2007. 6208 22.2. Informative References 6210 [FIPS180] National Institute of Standards and Technology, "FIPS Pub 6211 180-3, Secure Hash Standard (SHS)", US Department of 6212 Commerce , February 2008, 6213 . 6215 [I-D.ietf-manet-nhdp] 6216 Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc 6217 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 6218 draft-ietf-manet-nhdp-14 (work in progress), July 2010. 6220 [I-D.ietf-roll-of0] 6221 Thubert, P., "RPL Objective Function 0", 6222 draft-ietf-roll-of0-04 (work in progress), December 2010. 6224 [I-D.ietf-roll-terminology] 6225 Vasseur, J., "Terminology in Low power And Lossy 6226 Networks", draft-ietf-roll-terminology-04 (work in 6227 progress), September 2010. 6229 [Perlman83] 6230 Perlman, R., "Fault-Tolerant Broadcast of Routing 6231 Information", North-Holland Computer Networks 7: 395-405, 6232 1983, . 6235 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", 6236 RFC 1958, June 1996. 6238 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 6239 August 1996. 6241 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 6242 Schoenwaelder, Ed., "Structure of Management Information 6243 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 6245 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 6246 Listener Discovery (MLD) for IPv6", RFC 2710, 6247 October 1999. 6249 [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast 6250 Addresses", RFC 3307, August 2002. 6252 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 6253 "Introduction and Applicability Statements for Internet- 6254 Standard Management Framework", RFC 3410, December 2002. 6256 [RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network 6257 Management Workshop", RFC 3535, May 2003. 6259 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 6260 CBC-MAC (CCM)", RFC 3610, September 2003. 6262 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 6263 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 6265 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 6266 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 6267 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 6268 RFC 3819, July 2004. 6270 [RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, 6271 June 2005. 6273 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 6274 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 6275 RFC 4915, June 2007. 6277 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 6278 Topology (MT) Routing in Intermediate System to 6279 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 6281 [RFC5184] Teraoka, F., Gogo, K., Mitsuya, K., Shibui, R., and K. 6282 Mitani, "Unified Layer 2 (L2) Abstractions for Layer 3 6283 (L3)-Driven Fast Handover", RFC 5184, May 2008. 6285 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 6286 "Routing Requirements for Urban Low-Power and Lossy 6287 Networks", RFC 5548, May 2009. 6289 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 6290 "Industrial Routing Requirements in Low-Power and Lossy 6291 Networks", RFC 5673, October 2009. 6293 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 6294 Management of New Protocols and Protocol Extensions", 6295 RFC 5706, November 2009. 6297 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 6298 Routing Requirements in Low-Power and Lossy Networks", 6299 RFC 5826, April 2010. 6301 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 6302 "Building Automation Routing Requirements in Low-Power and 6303 Lossy Networks", RFC 5867, June 2010. 6305 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 6306 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 6307 June 2010. 6309 Appendix A. Example Operation 6311 This appendix provides some examples to illustrate the dissemination 6312 of addressing information and prefixes with RPL. The examples depict 6313 information being distributed with PIO and RIO options, and the use 6314 of DIO and DAO messages. Note that this appendix is not normative, 6315 and that the specific details of a RPL addressing plan and 6316 autoconfiguration may vary according to specific implementations. 6317 RPL merely provides a vehicle for disseminating information that may 6318 be built upon and used by other mechanisms. 6320 Note that these examples illustrate use of address autoconfiguration 6321 schemes supported by information distributed within RPL. However, if 6322 an implementation includes another address autoconfiguration scheme, 6323 RPL nodes might be configured not to set the 'A' flag in PIO options, 6324 though the PIO can still be used to distribute prefix and addressing 6325 information. 6327 A.1. Example with External Prefixes 6329 Consider the simple network illustrated in Figure 32. In this 6330 example there are a group of routers participating in a RPL network: 6331 a DODAG Root, nodes A, Y, and Z. The DODAG Root and node Z also have 6332 connectivity to different external network domains (i.e. external to 6333 the RPL network). Note that those external networks could be RPL 6334 networks or another type of network altogether. 6336 RPL Network +-------------------+ 6337 RPL::/64 | | 6338 | External | 6339 [RPL::Root] (Root)----------+ Prefix | 6340 | | EXT_1::/64 | 6341 | | | 6342 | +-------------------+ 6343 [RPL::A] (A) 6344 : 6345 : 6346 : 6347 [RPL::Y] (Y) 6348 | +-------------------+ 6349 | | | 6350 | | External | 6351 [RPL::Z] (Z)------------+ Prefix | 6352 | | EXT_2::/64 | 6353 | | | 6354 | +-------------------+ 6355 [RPL::Host1] (Host1) 6356 Figure 32: Simple Network Example 6358 In this example the DODAG Root makes a prefix available to the RPL 6359 subnet for address autoconfiguration. Here the entire RPL subnet 6360 uses that same prefix, RPL::/64, for address autoconfiguration, 6361 though in other implementations more complex/hybrid schemes could be 6362 employed. 6364 The DODAG Root has connectivity to an external (with respect to that 6365 RPL network) prefix EXT_1::/64. The DODAG Root may have learned of 6366 connectivity to this prefix, for example, via explicit configuration 6367 or IPv6 ND on a non-RPL interface. The DODAG Root is configured to 6368 announce information on the connectivity to this prefix. 6370 Similarly, Node Z has connectivity to an external prefix EXT_2::/64. 6371 Node Z also has direct connectivity to the node Host1. 6373 1. The DODAG Root adds a RIO to its DIO messages. The RIO contains 6374 the external prefix 2001:DB8:1:1::/64. This information may be 6375 repeated in the DIO messages emitted by the other nodes within 6376 the DODAG. Thus the reachability to the prefix 2001:DB8:1:1::/64 6377 is disseminated down the DODAG. 6379 2. Node Z may announce the prefix information to a non-RPL aware 6380 host, Host1. Host1 may then participate in address 6381 autoconfiguration and obtain the address, for example, RPL:: 6382 Host1. 6384 3. Node Z may interact with another neighboring non-RPL router in 6385 EXT_2::/64. Node Z may repackage the information learned from 6386 the RPL network in order to announce that information into the 6387 other neighboring network. For example, Node Z may repackage a 6388 RIO to indicate reachability to EXT_1::/64. 6390 4. Node Z, on behalf of the non-RPL aware host Host1, will send DAOs 6391 containing Host1 as a Target and itself (Node Z) as a parent in 6392 the Transit Information option. (In storing mode that Transit 6393 Information option does not need to contain the address of Node 6394 Z). A non-storing root then becomes aware of the 1-hop link Node 6395 Z -- Host1 for use in constructing source routes. 6397 5. Node Z may advertise reachability to the target network 6398 EXT_2::/64 by sending DAO messages using EXT_2::/64 as a target 6399 in the Target option and itself (Node Z) as a parent in the 6400 Transit Information option. (In storing mode that Transit 6401 Information option does not need to contain the address of Node 6402 Z). A non-storing root then becomes aware of the 1-hop link 6403 (Node Z -- EXT_2::/64) for use in constructing source routes. 6405 Node Z may additionally advertise its reachability to EXT_2::/64 6406 to nodes in its sub-DODAG by sending DIO messages with a PIO, 6407 with the 'A' flag cleared. 6409 A.2. Example Operation in Storing Mode With Node-owned Prefixes 6411 Figure 33 illustrates the logical addressing architecture of a simple 6412 RPL network operating in storing mode. In this example each node, A, 6413 B, C, and D, owns its own prefix, and makes that prefix available for 6414 address autoconfiguration by on-link devices. (This is conveyed by 6415 setting the 'A' flag and the 'L' flag in the PIO of the DIO 6416 messages). Node A owns the prefix A::/64, node B owns B::/64, and so 6417 on. Node B autoconfigures an on-link address with respect to node A, 6418 A::B. Nodes C and D similarly autoconfigure on-link addresses from 6419 Node B's prefix, B::C and B::D respectively. Nodes have the option 6420 of setting the 'R' flag and publishing their address within the 6421 Prefix field of the PIO. 6423 +-------------+ 6424 | Root | 6425 | | 6426 | Node A | 6427 | | 6428 | A::A | 6429 +------+------+ 6430 | 6431 | 6432 | 6433 +------+------+ 6434 | A::B | 6435 | | 6436 | Node B | 6437 | | 6438 | B::B | 6439 +------+------+ 6440 | 6441 | 6442 .--------------+--------------. 6443 / \ 6444 / \ 6445 +------+------+ +------+------+ 6446 | B::C | | B::D | 6447 | | | | 6448 | Node C | | Node D | 6449 | | | | 6450 | C::C | | D::D | 6451 +-------------+ +-------------+ 6453 Figure 33: Storing Mode with Node-owned Prefixes 6455 A.2.1. DIO messages and PIO 6457 Node A, for example, will send DIO messages with a PIO as follows: 6458 'A' flag: Set 6459 'L' flag: Set 6460 'R' flag: Clear 6461 Prefix Length: 64 6462 Prefix: A:: 6464 Node B, for example, will send DIO messages with a PIO as follows: 6465 'A' flag: Set 6466 'L' flag: Set 6467 'R' flag: Set 6468 Prefix Length: 64 6469 Prefix: B::B 6471 Node C, for example, will send DIO messages with a PIO as follows: 6472 'A' flag: Set 6473 'L' flag: Set 6474 'R' flag: Clear 6475 Prefix Length: 64 6476 Prefix: C:: 6478 Node D, for example, will send DIO messages with a PIO as follows: 6479 'A' flag: Set 6480 'L' flag: Set 6481 'R' flag: Set 6482 Prefix Length: 64 6483 Prefix: D::D 6485 A.2.2. DAO messages 6487 Node B will send DAO messages to node A with the following 6488 information: 6489 o Target B::/64 6490 o Target C::/64 6491 o Target D::/64 6493 Node C will send DAO messages to node B with the following 6494 information: 6496 o Target C::/64 6498 Node D will send DAO messages to node B with the following 6499 information: 6500 o Target D::/64 6502 A.2.3. Routing Information Base 6504 Node A will conceptually collect the following information into its 6505 RIB: 6506 o A::/64 connected 6507 o B::/64 via B's link local 6508 o C::/64 via B's link local 6509 o D::/64 via B's link local 6511 Node B will conceptually collect the following information into its 6512 RIB: 6513 o ::/0 via A's link local 6514 o B::/64 connected 6515 o C::/64 via C's link local 6516 o D::/64 via D's link local 6518 Node C will conceptually collect the following information into its 6519 RIB: 6520 o ::/0 via B's link local 6521 o C::/64 connected 6523 Node D will conceptually collect the following information into its 6524 RIB: 6525 o ::/0 via B's link local 6526 o D::/64 connected 6528 A.3. Example Operation in Storing Mode With Subnet-wide Prefix 6530 Figure 34 illustrates the logical addressing architecture of a simple 6531 RPL network operating in storing mode. In this example the root node 6532 A sources a prefix which is used for address autoconfiguration over 6533 the entire RPL subnet. (This is conveyed by setting the 'A' flag and 6534 clearing the 'L' flag in the PIO of the DIO messages). Nodes A, B, 6535 C, and D all autoconfigure to the prefix A::/64. Nodes have the 6536 option of setting the 'R' flag and publishing their address within 6537 the Prefix field of the PIO. 6539 +-------------+ 6540 | Root | 6541 | | 6542 | Node A | 6543 | A::A | 6544 | | 6545 +------+------+ 6546 | 6547 | 6548 | 6549 +------+------+ 6550 | | 6551 | Node B | 6552 | A::B | 6553 | | 6554 +------+------+ 6555 | 6556 | 6557 .--------------+--------------. 6558 / \ 6559 / \ 6560 +------+------+ +------+------+ 6561 | | | | 6562 | Node C | | Node D | 6563 | A::C | | A::D | 6564 | | | | 6565 +-------------+ +-------------+ 6567 Figure 34: Storing Mode with Subnet-wide Prefix 6569 A.3.1. DIO messages and PIO 6571 Node A, for example, will send DIO messages with a PIO as follows: 6572 'A' flag: Set 6573 'L' flag: Clear 6574 'R' flag: Clear 6575 Prefix Length: 64 6576 Prefix: A:: 6578 Node B, for example, will send DIO messages with a PIO as follows: 6579 'A' flag: Set 6580 'L' flag: Clear 6581 'R' flag: Set 6582 Prefix Length: 64 6583 Prefix: A::B 6585 Node C, for example, will send DIO messages with a PIO as follows: 6586 'A' flag: Set 6587 'L' flag: Clear 6588 'R' flag: Clear 6589 Prefix Length: 64 6590 Prefix: A:: 6592 Node D, for example, will send DIO messages with a PIO as follows: 6593 'A' flag: Set 6594 'L' flag: Clear 6595 'R' flag: Set 6596 Prefix Length: 64 6597 Prefix: A::D 6599 A.3.2. DAO messages 6601 Node B will send DAO messages to node A with the following 6602 information: 6603 o Target A::B/128 6604 o Target A::C/128 6605 o Target A::D/128 6607 Node C will send DAO messages to node B with the following 6608 information: 6609 o Target A::C/128 6611 Node D will send DAO messages to node B with the following 6612 information: 6613 o Target A::D/128 6615 A.3.3. Routing Information Base 6617 Node A will conceptually collect the following information into its 6618 RIB: 6619 o A::/128 connected 6620 o B::/128 via B's link local 6621 o C::/128 via B's link local 6622 o D::/128 via B's link local 6624 Node B will conceptually collect the following information into its 6625 RIB: 6627 o ::/0 via A's link local 6628 o B::/128 connected 6629 o C::/128 via C's link local 6630 o D::/128 via D's link local 6632 Node C will conceptually collect the following information into its 6633 RIB: 6634 o ::/0 via B's link local 6635 o C::/128 connected 6637 Node D will conceptually collect the following information into its 6638 RIB: 6639 o ::/0 via B's link local 6640 o D::/128 connected 6642 A.4. Example Operation in Non-Storing Mode With Node-owned Prefixes 6644 Figure 35 illustrates the logical addressing architecture of a simple 6645 RPL network operating in non-storing mode. In this example each 6646 node, A, B, C, and D, owns its own prefix, and makes that prefix 6647 available for address autoconfiguration by on-link devices. (This is 6648 conveyed by setting the 'A' flag and the 'L' flag in the PIO of the 6649 DIO messages). Node A owns the prefix A::/64, node B owns B::/64, 6650 and so on. Node B autoconfigures an on-link address with respect to 6651 node A, A::B. Nodes C and D similarly autoconfigure on-link addresses 6652 from Node B's prefix, B::C and B::D respectively. Nodes have the 6653 option of setting the 'R' flag and publishing their address within 6654 the Prefix field of the PIO. 6656 +-------------+ 6657 | Root | 6658 | | 6659 | Node A | 6660 | | 6661 | A::A | 6662 +------+------+ 6663 | 6664 | 6665 | 6666 +------+------+ 6667 | A::B | 6668 | | 6669 | Node B | 6670 | | 6671 | B::B | 6672 +------+------+ 6673 | 6674 | 6675 .--------------+--------------. 6676 / \ 6677 / \ 6678 +------+------+ +------+------+ 6679 | B::C | | B::D | 6680 | | | | 6681 | Node C | | Node D | 6682 | | | | 6683 | C::C | | D::D | 6684 +-------------+ +-------------+ 6686 Figure 35: Non-storing Mode with Node-owned Prefixes 6688 A.4.1. DIO messages and PIO 6690 The PIO contained in the DIO messages in the non-storing mode with 6691 node-owned prefixes can be considered to be identical to those in the 6692 storing mode with node-owned prefixes case (Appendix A.2.1). 6694 A.4.2. DAO messages 6696 Node B will send DAO messages to node A with the following 6697 information: 6699 o Target B::/64, Transit A::B 6701 Node C will send DAO messages to node A with the following 6702 information: 6703 o Target C::/64, Transit B::C 6705 Node D will send DAO messages to node A with the following 6706 information: 6707 o Target D::/64, Transit B::D 6709 A.4.3. Routing Information Base 6711 Node A will conceptually collect the following information into its 6712 RIB. Note that Node A has enough information to construct source 6713 routes by doing recursive lookups into the RIB: 6714 o A::/64 connected 6715 o B::/64 via A::B 6716 o C::/64 via B::C 6717 o D::/64 via B::D 6719 Node B will conceptually collect the following information into its 6720 RIB: 6721 o ::/0 via A's link local 6722 o B::/64 connected 6724 Node C will conceptually collect the following information into its 6725 RIB: 6726 o ::/0 via B's link local 6727 o C::/64 connected 6729 Node D will conceptually collect the following information into its 6730 RIB: 6731 o ::/0 via B's link local 6732 o D::/64 connected 6734 A.5. Example Operation in Non-Storing Mode With Subnet-wide Prefix 6736 Figure 36 illustrates the logical addressing architecture of a simple 6737 RPL network operating in non-storing mode. In this example the root 6738 node A sources a prefix which is used for address autoconfiguration 6739 over the entire RPL subnet. (This is conveyed by setting the 'A' 6740 flag and clearing the 'L' flag in the PIO of the DIO messages). 6741 Nodes A, B, C, and D all autoconfigure to the prefix A::/64. Nodes 6742 must set the 'R' flag and publishing their address within the Prefix 6743 field of the PIO, in order to inform their children which address to 6744 use in the transit option. 6746 +-------------+ 6747 | Root | 6748 | | 6749 | Node A | 6750 | A::A | 6751 | | 6752 +------+------+ 6753 | 6754 | 6755 | 6756 +------+------+ 6757 | | 6758 | Node B | 6759 | A::B | 6760 | | 6761 +------+------+ 6762 | 6763 | 6764 .--------------+--------------. 6765 / \ 6766 / \ 6767 +------+------+ +------+------+ 6768 | | | | 6769 | Node C | | Node D | 6770 | A::C | | A::D | 6771 | | | | 6772 +-------------+ +-------------+ 6774 Figure 36: XXX 6776 A.5.1. DIO messages and PIO 6778 Node A, for example, will send DIO messages with a PIO as follows: 6779 'A' flag: Set 6780 'L' flag: Clear 6781 'R' flag: Set 6782 Prefix Length: 64 6783 Prefix: A::A 6785 Node B, for example, will send DIO messages with a PIO as follows: 6786 'A' flag: Set 6787 'L' flag: Clear 6788 'R' flag: Set 6789 Prefix Length: 64 6790 Prefix: A::B 6792 Node C, for example, will send DIO messages with a PIO as follows: 6793 'A' flag: Set 6794 'L' flag: Clear 6795 'R' flag: Set 6796 Prefix Length: 64 6797 Prefix: A::C 6799 Node D, for example, will send DIO messages with a PIO as follows: 6800 'A' flag: Set 6801 'L' flag: Clear 6802 'R' flag: Set 6803 Prefix Length: 64 6804 Prefix: A::D 6806 A.5.2. DAO messages 6808 Node B will send DAO messages to node A with the following 6809 information: 6810 o Target A::B/128, Transit A::A 6812 Node C will send DAO messages to node A with the following 6813 information: 6814 o Target A::C/128, Transit A::B 6816 Node D will send DAO messages to node A with the following 6817 information: 6818 o Target A::D/128, Transit A::B 6820 A.5.3. Routing Information Base 6822 Node A will conceptually collect the following information into its 6823 RIB. Note that Node A has enough information to construct source 6824 routes by doing recursive lookups into the RIB: 6825 o A::A/128 connected 6826 o B::B/128 via A::A 6827 o C::C/128 via A::B 6828 o D::D/128 via A::B 6830 Node B will conceptually collect the following information into its 6831 RIB: 6833 o ::/0 via A's link local 6834 o A::B/128 connected 6836 Node C will conceptually collect the following information into its 6837 RIB: 6838 o ::/0 via B's link local 6839 o A::C/128 connected 6841 Node D will conceptually collect the following information into its 6842 RIB: 6843 o ::/0 via B's link local 6844 o A::D/128 connected 6846 Authors' Addresses 6848 Tim Winter (editor) 6850 Email: wintert@acm.org 6852 Pascal Thubert (editor) 6853 Cisco Systems, Inc 6854 Village d'Entreprises Green Side 6855 400, Avenue de Roumanille 6856 Batiment T3 6857 Biot - Sophia Antipolis 06410 6858 France 6860 Phone: +33 497 23 26 34 6861 Email: pthubert@cisco.com 6863 Anders Brandt 6864 Sigma Designs 6865 Emdrupvej 26A, 1. 6866 Copenhagen DK-2100 6867 Denmark 6869 Email: abr@sdesigns.dk 6871 Thomas Heide Clausen 6872 LIX, Ecole Polytechnique, France 6874 Phone: +33 6 6058 9349 6875 Email: T.Clausen@computer.org 6876 URI: http://www.ThomasClausen.org/ 6878 Jonathan W. Hui 6879 Arch Rock Corporation 6880 501 2nd St. Ste. 410 6881 San Francisco, CA 94107 6882 USA 6884 Email: jhui@archrock.com 6885 Richard Kelsey 6886 Ember Corporation 6887 Boston, MA 6888 USA 6890 Phone: +1 617 951 1225 6891 Email: kelsey@ember.com 6893 Philip Levis 6894 Stanford University 6895 358 Gates Hall, Stanford University 6896 Stanford, CA 94305-9030 6897 USA 6899 Email: pal@cs.stanford.edu 6901 Kris Pister 6902 Dust Networks 6903 30695 Huntwood Ave. 6904 Hayward, CA 94544 6905 USA 6907 Email: kpister@dustnetworks.com 6909 Rene Struik 6911 Email: rstruik.ext@gmail.com 6913 JP Vasseur 6914 Cisco Systems, Inc 6915 11, Rue Camille Desmoulins 6916 Issy Les Moulineaux 92782 6917 France 6919 Email: jpv@cisco.com