idnits 2.17.1 draft-ietf-roll-rpl-19.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 (March 13, 2011) is 4755 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 6376, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-6man-rpl-option-02 == Outdated reference: A later version (-07) exists of draft-ietf-6man-rpl-routing-header-02 == Outdated reference: A later version (-20) exists of draft-ietf-roll-of0-07 ** 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: A later version (-21) exists of draft-ietf-6lowpan-nd-15 == Outdated reference: A later version (-13) exists of draft-ietf-roll-terminology-04 Summary: 3 errors (**), 0 flaws (~~), 7 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: September 14, 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 March 13, 2011 24 RPL: IPv6 Routing Protocol for Low power and Lossy Networks 25 draft-ietf-roll-rpl-19 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 September 14, 2011. 63 Copyright Notice 65 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . 21 101 3.5.1. Rank Comparison (DAGRank()) . . . . . . . . . . . . . 22 102 3.5.2. Rank Relationships . . . . . . . . . . . . . . . . . 23 103 3.6. Routing Metrics and Constraints Used By RPL . . . . . . 23 104 3.7. Loop Avoidance . . . . . . . . . . . . . . . . . . . . . 24 105 3.7.1. Greediness and Instability . . . . . . . . . . . . . 25 106 3.7.2. DODAG Loops . . . . . . . . . . . . . . . . . . . . . 27 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 . . . . . . . . . . . . . . . . . . . . . 47 136 6.7. RPL Control Message Options . . . . . . . . . . . . . . 47 137 6.7.1. RPL Control Message Option Generic Format . . . . . . 47 138 6.7.2. Pad1 . . . . . . . . . . . . . . . . . . . . . . . . 48 139 6.7.3. PadN . . . . . . . . . . . . . . . . . . . . . . . . 48 140 6.7.4. Metric Container . . . . . . . . . . . . . . . . . . 49 141 6.7.5. Route Information . . . . . . . . . . . . . . . . . . 50 142 6.7.6. DODAG Configuration . . . . . . . . . . . . . . . . . 51 143 6.7.7. RPL Target . . . . . . . . . . . . . . . . . . . . . 53 144 6.7.8. Transit Information . . . . . . . . . . . . . . . . . 55 145 6.7.9. Solicited Information . . . . . . . . . . . . . . . . 58 146 6.7.10. Prefix Information . . . . . . . . . . . . . . . . . 59 147 6.7.11. RPL Target Descriptor . . . . . . . . . . . . . . . . 62 148 7. Sequence Counters . . . . . . . . . . . . . . . . . . . . . . 64 149 7.1. Sequence Counter Overview . . . . . . . . . . . . . . . 64 150 7.2. Sequence Counter Operation . . . . . . . . . . . . . . . 65 151 8. Upward Routes . . . . . . . . . . . . . . . . . . . . . . . . 67 152 8.1. DIO Base Rules . . . . . . . . . . . . . . . . . . . . . 67 153 8.2. Upward Route Discovery and Maintenance . . . . . . . . . 68 154 8.2.1. Neighbors and Parents within a DODAG Version . . . . 68 155 8.2.2. Neighbors and Parents across DODAG Versions . . . . . 69 156 8.2.3. DIO Message Communication . . . . . . . . . . . . . . 74 157 8.3. DIO Transmission . . . . . . . . . . . . . . . . . . . . 74 158 8.3.1. Trickle Parameters . . . . . . . . . . . . . . . . . 75 159 8.4. DODAG Selection . . . . . . . . . . . . . . . . . . . . 75 160 8.5. Operation as a Leaf Node . . . . . . . . . . . . . . . . 76 161 8.6. Administrative Rank . . . . . . . . . . . . . . . . . . 77 162 9. Downward Routes . . . . . . . . . . . . . . . . . . . . . . . 78 163 9.1. Destination Advertisement Parents . . . . . . . . . . . 78 164 9.2. Downward Route Discovery and Maintenance . . . . . . . . 79 165 9.2.1. Maintenance of Path Sequence . . . . . . . . . . . . 80 166 9.2.2. Generation of DAO Messages . . . . . . . . . . . . . 80 167 9.3. DAO Base Rules . . . . . . . . . . . . . . . . . . . . . 81 168 9.4. Structure of DAO Messages . . . . . . . . . . . . . . . 81 169 9.5. DAO Transmission Scheduling . . . . . . . . . . . . . . 84 170 9.6. Triggering DAO Messages . . . . . . . . . . . . . . . . 84 171 9.7. Non-storing Mode . . . . . . . . . . . . . . . . . . . . 85 172 9.8. Storing Mode . . . . . . . . . . . . . . . . . . . . . . 86 173 9.9. Path Control . . . . . . . . . . . . . . . . . . . . . . 87 174 9.9.1. Path Control Example . . . . . . . . . . . . . . . . 88 175 9.10. Multicast Destination Advertisement Messages . . . . . . 90 176 10. Security Mechanisms . . . . . . . . . . . . . . . . . . . . . 91 177 10.1. Security Overview . . . . . . . . . . . . . . . . . . . 91 178 10.2. Joining a Secure Network . . . . . . . . . . . . . . . . 92 179 10.3. Installing Keys . . . . . . . . . . . . . . . . . . . . 93 180 10.4. Consistency Checks . . . . . . . . . . . . . . . . . . . 93 181 10.5. Counters . . . . . . . . . . . . . . . . . . . . . . . . 94 182 10.6. Transmission of Outgoing Packets . . . . . . . . . . . . 95 183 10.7. Reception of Incoming Packets . . . . . . . . . . . . . 96 184 10.7.1. Timestamp Key Checks . . . . . . . . . . . . . . . . 97 185 10.8. Coverage of Integrity and Confidentiality . . . . . . . 98 186 10.9. Cryptographic Mode of Operation . . . . . . . . . . . . 98 187 10.9.1. CCM Nonce . . . . . . . . . . . . . . . . . . . . . . 98 188 10.9.2. Signatures . . . . . . . . . . . . . . . . . . . . . 99 189 11. Packet Forwarding and Loop Avoidance/Detection . . . . . . . 101 190 11.1. Suggestions for Packet Forwarding . . . . . . . . . . . 101 191 11.2. Loop Avoidance and Detection . . . . . . . . . . . . . . 102 192 11.2.1. Source Node Operation . . . . . . . . . . . . . . . . 103 193 11.2.2. Router Operation . . . . . . . . . . . . . . . . . . 103 194 12. Multicast Operation . . . . . . . . . . . . . . . . . . . . . 106 195 13. Maintenance of Routing Adjacency . . . . . . . . . . . . . . 108 196 14. Guidelines for Objective Functions . . . . . . . . . . . . . 109 197 14.1. Objective Function Behavior . . . . . . . . . . . . . . 109 198 15. Suggestions for Interoperation with Neighbor Discovery . . . 111 199 16. Summary of Requirements for Interoperable Implementations . . 112 200 16.1. Common Requirements . . . . . . . . . . . . . . . . . . 112 201 16.2. Operation as a RPL Leaf Node (only) . . . . . . . . . . 112 202 16.3. Operation as a RPL Router . . . . . . . . . . . . . . . 113 203 16.3.1. Support for Upward Routes only . . . . . . . . . . . 113 204 16.3.2. Support for Upward Routes and Downward Routes in 205 Non-Storing mode . . . . . . . . . . . . . . . . . . 113 206 16.3.3. Support for Upward Routes and Downward Routes in 207 Storing mode . . . . . . . . . . . . . . . . . . . . 114 208 16.4. Items for Future Specification . . . . . . . . . . . . . 114 209 17. RPL Constants and Variables . . . . . . . . . . . . . . . . . 115 210 18. Manageability Considerations . . . . . . . . . . . . . . . . 117 211 18.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 117 212 18.2. Configuration Management . . . . . . . . . . . . . . . . 118 213 18.2.1. Initialization Mode . . . . . . . . . . . . . . . . . 118 214 18.2.2. DIO and DAO Base Message and Options Configuration . 119 215 18.2.3. Protocol Parameters to be configured on every 216 router in the LLN . . . . . . . . . . . . . . . . . . 119 217 18.2.4. Protocol Parameters to be configured on every 218 non-DODAG-root router in the LLN . . . . . . . . . . 120 219 18.2.5. Parameters to be configured on the DODAG root . . . . 120 220 18.2.6. Configuration of RPL Parameters related to 221 DAO-based mechanisms . . . . . . . . . . . . . . . . 121 223 18.2.7. Configuration of RPL Parameters related to 224 Security mechanisms . . . . . . . . . . . . . . . . . 122 225 18.2.8. Default Values . . . . . . . . . . . . . . . . . . . 123 226 18.3. Monitoring of RPL Operation . . . . . . . . . . . . . . 123 227 18.3.1. Monitoring a DODAG parameters . . . . . . . . . . . . 123 228 18.3.2. Monitoring a DODAG inconsistencies and loop 229 detection . . . . . . . . . . . . . . . . . . . . . . 124 230 18.4. Monitoring of the RPL data structures . . . . . . . . . 125 231 18.4.1. Candidate Neighbor Data Structure . . . . . . . . . . 125 232 18.4.2. Destination Oriented Directed Acyclic Graph (DAG) 233 Table . . . . . . . . . . . . . . . . . . . . . . . . 125 234 18.4.3. Routing Table and DAO Routing Entries . . . . . . . . 126 235 18.5. Fault Management . . . . . . . . . . . . . . . . . . . . 127 236 18.6. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 127 237 18.7. Fault Isolation . . . . . . . . . . . . . . . . . . . . 128 238 18.8. Impact on Other Protocols . . . . . . . . . . . . . . . 129 239 18.9. Performance Management . . . . . . . . . . . . . . . . . 129 240 18.10. Diagnostics . . . . . . . . . . . . . . . . . . . . . . 129 241 19. Security Considerations . . . . . . . . . . . . . . . . . . . 130 242 19.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 130 243 20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 132 244 20.1. RPL Control Message . . . . . . . . . . . . . . . . . . 132 245 20.2. New Registry for RPL Control Codes . . . . . . . . . . . 132 246 20.3. New Registry for the Mode of Operation (MOP) . . . . . . 133 247 20.4. RPL Control Message Option . . . . . . . . . . . . . . . 134 248 20.5. Objective Code Point (OCP) Registry . . . . . . . . . . 134 249 20.6. New Registry for the Security Section Algorithm . . . . 135 250 20.7. New Registry for the Security Section Flags . . . . . . 135 251 20.8. New Registry for Per-KIM Security Levels . . . . . . . . 136 252 20.9. New Registry for the DIS (DODAG Informational 253 Solicitation) Flags . . . . . . . . . . . . . . . . . . 137 254 20.10. New Registry for the DODAG Information Object (DIO) 255 Flags . . . . . . . . . . . . . . . . . . . . . . . . . 138 256 20.11. New Registry for the Destination Advertisement Object 257 (DAO) Flags . . . . . . . . . . . . . . . . . . . . . . 138 258 20.12. New Registry for the Destination Advertisement Object 259 (DAO) Acknowledgement Flags . . . . . . . . . . . . . . 139 260 20.13. New Registry for the Consistency Check (CC) Flags . . . 139 261 20.14. New Registry for the DODAG Configuration Option Flags . 140 262 20.15. New Registry for the RPL Target Option Flags . . . . . . 140 263 20.16. New Registry for the Transit Information Option Flags . 141 264 20.17. New Registry for the Solicited Information Option 265 Flags . . . . . . . . . . . . . . . . . . . . . . . . . 141 266 20.18. ICMPv6: Error in Source Routing Header . . . . . . . . . 142 267 20.19. Link-Local Scope multicast address . . . . . . . . . . . 142 268 21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 143 269 22. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 144 270 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 145 271 23.1. Normative References . . . . . . . . . . . . . . . . . . 145 272 23.2. Informative References . . . . . . . . . . . . . . . . . 146 273 Appendix A. Example Operation . . . . . . . . . . . . . . . . . 149 274 A.1. Example Operation in Storing Mode With Node-owned 275 Prefixes . . . . . . . . . . . . . . . . . . . . . . . . 149 276 A.1.1. DIO messages and PIO . . . . . . . . . . . . . . . . 150 277 A.1.2. DAO messages . . . . . . . . . . . . . . . . . . . . 151 278 A.1.3. Routing Information Base . . . . . . . . . . . . . . 151 279 A.2. Example Operation in Storing Mode With Subnet-wide 280 Prefix . . . . . . . . . . . . . . . . . . . . . . . . . 152 281 A.2.1. DIO messages and PIO . . . . . . . . . . . . . . . . 153 282 A.2.2. DAO messages . . . . . . . . . . . . . . . . . . . . 154 283 A.2.3. Routing Information Base . . . . . . . . . . . . . . 154 284 A.3. Example Operation in Non-Storing Mode With Node-owned 285 Prefixes . . . . . . . . . . . . . . . . . . . . . . . . 155 286 A.3.1. DIO messages and PIO . . . . . . . . . . . . . . . . 156 287 A.3.2. DAO messages . . . . . . . . . . . . . . . . . . . . 156 288 A.3.3. Routing Information Base . . . . . . . . . . . . . . 157 289 A.4. Example Operation in Non-Storing Mode With 290 Subnet-wide Prefix . . . . . . . . . . . . . . . . . . . 157 291 A.4.1. DIO messages and PIO . . . . . . . . . . . . . . . . 158 292 A.4.2. DAO messages . . . . . . . . . . . . . . . . . . . . 159 293 A.4.3. Routing Information Base . . . . . . . . . . . . . . 159 294 A.5. Example with External Prefixes . . . . . . . . . . . . . 160 295 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 162 297 1. Introduction 299 Low power and Lossy Networks (LLNs) consist of largely of constrained 300 nodes (with limited processing power, memory, and sometimes energy 301 when they are battery operated or energy scavenging). These routers 302 are interconnected by lossy links, typically supporting only low data 303 rates, that are usually unstable with relatively low packet delivery 304 rates. Another characteristic of such networks is that the traffic 305 patterns are not simply point-to-point, but in many cases point-to- 306 multipoint or multipoint-to-point. Furthermore such networks may 307 potentially comprise up to thousands of nodes. These characteristics 308 offer unique challenges to a routing solution: the IETF ROLL Working 309 Group has defined application-specific routing requirements for a Low 310 power and Lossy Network (LLN) routing protocol, specified in 311 [RFC5867], [RFC5826], [RFC5673], and [RFC5548]. 313 This document specifies the IPv6 Routing Protocol for Low power and 314 lossy networks (RPL). Note that although RPL was specified according 315 to the requirements set forth in the aforementioned requirement 316 documents, its use is in no way limited to these applications. 318 1.1. Design Principles 320 RPL was designed with the objective to meet the requirements spelled 321 out in [RFC5867], [RFC5826], [RFC5673], and [RFC5548]. 323 A network may run multiple instances of RPL concurrently. Each such 324 instance may serve different and potentially antagonistic constraints 325 or performance criteria. This document defines how a single instance 326 operates. 328 In order to be useful in a wide range of LLN application domains, RPL 329 separates packet processing and forwarding from the routing 330 optimization objective. Examples of such objectives include 331 minimizing energy, minimizing latency, or satisfying constraints. 332 This document describes the mode of operation of RPL. Other 333 companion documents specify routing objective functions. A RPL 334 implementation, in support of a particular LLN application, will 335 include the necessary objective function(s) as required by the 336 application. 338 RPL operations require bidirectional links. In some LLN scenarios 339 those links may exhibit asymmetric properties. It is required that 340 the reachability of a router is verified before the router can be 341 used as a parent. RPL expects an external mechanism to be triggered 342 during the parent selection phase in order to verify link properties 343 and neighbor reachability. Neighbor Unreachability Detection (NUD) 344 is such a mechanism, but alternates are possible, including 345 Bidirectional Forwarding Detection [RFC5881] and hints from lower 346 layers via L2 triggers like [RFC5184]. In a general fashion, a 347 detection mechanism that is reactive to traffic is favored in order 348 to minimize the cost of monitoring links that are not being used. 350 RPL also expects an external mechanism to access and transport some 351 control information, referred to as the "RPL Packet Information", in 352 data packets. The RPL Packet Information is defined in Section 11.2 353 and enables the association of a data packet with a RPL instance and 354 the validation of RPL routing states. The IPv6 Hop-by-Hop RPL Option 355 [I-D.ietf-6man-rpl-option] is an example of such mechanism. The 356 mechanism is required for all packets except when strict source 357 routing is used (that is for packets going downward in non-storing 358 mode as detailed further in Section 9), which by nature prevents 359 endless loops and alleviates the need for the RPL Packet Information. 360 Future companion specifications may propose alternate ways to carry 361 the RPL Packet Information in the IPv6 packets and may extend the RPL 362 Packet Information to support additional features. 364 RPL provides a mechanism to disseminate information over the 365 dynamically-formed network topology. The dissemination enables 366 minimal configuration in the nodes, allowing nodes to operate mostly 367 autonomously. This mechanism uses trickle [I-D.ietf-roll-trickle] to 368 optimize the dissemination as described in Section 8.3. 370 In some applications, RPL assembles topologies of routers that own 371 independent prefixes. Those prefixes may or may not be aggregatable 372 depending on the origin of the routers. A prefix that is owned by a 373 router is advertised as on-link. 375 RPL also introduces the capability to bind a subnet together with a 376 common prefix and to route within that subnet. A source can inject 377 information about the subnet to be disseminated by RPL, and that 378 source is authoritative for that subnet. Because many LLN links have 379 non-transitive properties, a common prefix that RPL disseminates over 380 the subnet must not be advertised as on-link. 382 RPL may in particular disseminate IPv6 Neighbor Discovery (ND) 383 information such as the [RFC4861] Prefix Information Option (PIO) and 384 the [RFC4191] Route Information Option (RIO). ND information that is 385 disseminated by RPL conserves all its original semantics for router 386 to host, with limited extensions for router to router, though it is 387 not to be confused with routing advertisements and it is never to be 388 directly redistributed in another routing protocol. A RPL node often 389 combines host and router behaviors. As a host, it will process the 390 options as specified in [RFC4191], [RFC4861], [RFC4862] and 391 [RFC3775]. As a router, the RPL node may advertise the information 392 from the options as required for the specific link, for instance in a 393 ND RA message, though the exact operation is out of scope. 395 A set of companion documents to this specification will provide 396 further guidance in the form of applicability statements specifying a 397 set of operating points appropriate to the Building Automation, Home 398 Automation, Industrial, and Urban application scenarios. 400 1.2. Expectations of Link Layer Type 402 In compliance with the layered architecture of IP, RPL does not rely 403 on any particular features of a specific link layer technology. RPL 404 is designed to be able to operate over a variety of different link 405 layers, including ones that are constrained, potentially lossy, or 406 typically utilized in conjunction with highly constrained host or 407 router devices, such as but not limited to, low power wireless or PLC 408 (Power Line Communication) technologies. 410 Implementers may find [RFC3819] a useful reference when designing a 411 link layer interface between RPL and a particular link layer 412 technology. 414 2. Terminology 416 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 417 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 418 "OPTIONAL" in this document are to be interpreted as described in RFC 419 2119 [RFC2119]. 421 Additionally, this document uses terminology from 422 [I-D.ietf-roll-terminology], and introduces the following 423 terminology: 425 DAG: Directed Acyclic Graph. A directed graph having the property 426 that all edges are oriented in such a way that no cycles exist. 427 All edges are contained in paths oriented toward and 428 terminating at one or more root nodes. 430 DAG root: A DAG root is a node within the DAG that has no outgoing 431 edge. Because the graph is acyclic, by definition all DAGs 432 must have at least one DAG root and all paths terminate at a 433 DAG root. 435 Destination Oriented DAG (DODAG): A DAG rooted at a single 436 destination, i.e. at a single DAG root (the DODAG root) with no 437 outgoing edges. 439 DODAG root: A DODAG root is the DAG root of a DODAG. The DODAG root 440 may act as a border router for the DODAG, and in particular it 441 may aggregate routes in the DODAG, and may redistribute DODAG 442 routes into other routing protocols. 444 Virtual DODAG root: A Virtual DODAG root is the result of two or 445 more RPL routers, for instance 6LoWPAN Border Routers (6LBRs), 446 coordinating to synchronize DODAG state and act in concert as 447 if they are a single DODAG root (with multiple interfaces), 448 with respect to the LLN. The coordination most likely occurs 449 between powered devices over a reliable transit link, and the 450 details of that scheme are out of scope for this specification 451 (to be defined in future companion specifications). 453 Up: Up refers to the direction from leaf nodes towards DODAG roots, 454 following DODAG edges. This follows the common terminology 455 used in graphs and depth-first-search, where vertices further 456 from the root are "deeper," or "down," and vertices closer to 457 the root are "shallower," or "up". 459 Down: Down refers to the direction from DODAG roots towards leaf 460 nodes, in the reverse direction of DODAG edges. This follows 461 the common terminology used in graphs and depth-first-search, 462 where vertices further from the root are "deeper," or "down," 463 and vertices closer to the root are "shallower," or "up". 465 Rank: A node's Rank defines the node's individual position relative 466 to other nodes with respect to a DODAG root. Rank strictly 467 increases in the Down direction and strictly decreases in the 468 Up direction. The exact way Rank is computed depends on the 469 DAG's Objective Function (OF). The Rank may analogously track 470 a simple topological distance, may be calculated as a function 471 of link metrics, and may consider other properties such as 472 constraints. 474 Objective Function (OF): Defines how routing metrics, optimization 475 objectives, and related functions are used to compute Rank. 476 Furthermore, the OF dictates how parents in the DODAG are 477 selected and thus the DODAG formation. 479 Objective Code Point (OCP): An identifier that indicates which 480 Objective Function the DODAG uses. 482 RPLInstanceID: A unique identifier within a network. DODAGs with 483 the same RPLInstanceID share the same Objective Function. 485 RPL Instance: A set of one or more DODAGs that share a 486 RPLInstanceID. A RPL node can belong to at most one DODAG in a 487 RPL Instance. Each RPL Instance operates independently of 488 other RPL Instances. This document describes operation within 489 a single RPL Instance. 491 DODAGID: The identifier of a DODAG root. The DODAGID is unique 492 within the scope of a RPL Instance in the LLN. The tuple 493 (RPLInstanceID, DODAGID) uniquely identifies a DODAG. 495 DODAG Version: A specific iteration ("Version") of a DODAG with a 496 given DODAGID. 498 DODAGVersionNumber: A sequential counter that is incremented by the 499 root to form a new Version of a DODAG. A DODAG Version is 500 identified uniquely by the (RPLInstanceID, DODAGID, 501 DODAGVersionNumber) tuple. 503 Goal: The Goal is an application specific goal that is defined 504 outside the scope of RPL. Any node that roots a DODAG will 505 need to know about this Goal to decide if the Goal can be 506 satisfied or not. A typical Goal is to construct the DODAG 507 according to a specific objective function and to keep 508 connectivity to a set of hosts (e.g. to use an objective 509 function that minimizes a metric and to be connected to a 510 specific database host to store the collected data). 512 Grounded: A DODAG is grounded when the DODAG root can satisfy the 513 Goal. 515 Floating: A DODAG is floating if it is not Grounded. A floating 516 DODAG is not expected to have the properties required to 517 satisfy the goal. It may, however, provide connectivity to 518 other nodes within the DODAG. 520 DODAG parent: A parent of a node within a DODAG is one of the 521 immediate successors of the node on a path towards the DODAG 522 root. A DODAG parent's Rank is lower than the node's. (See 523 Section 3.5.1). 525 Sub-DODAG The sub-DODAG of a node is the set of other nodes whose 526 paths to the DODAG root pass through that node. Nodes in the 527 sub-DODAG of a node have a greater Rank than that node. (See 528 Section 3.5.1). 530 Local DODAG: Local DODAGs contain one and only one root node, and 531 allows that single root node to allocate and manage a RPL 532 Instance, identified by a local RPLInstanceID, without 533 coordination with other nodes. This is typically done in order 534 to optimize routes to a destination within the LLN. (See 535 Section 5). 537 Global DODAG: A Global DODAG uses a global RPLInstanceID that may be 538 coordinated among several other nodes. (See Section 5). 540 DIO: DODAG Information Object (See Section 6.3) 542 DAO: Destination Advertisement Object (See Section 6.4) 544 DIS: DODAG Information Solicitation (See Section 6.2) 546 CC: Consistency Check (See Section 6.6) 548 As they form networks, LLN devices often mix the roles of 'host' and 549 'router' when compared to traditional IP networks. In this document, 550 'host' refers to an LLN device that can generate but does not forward 551 RPL traffic, 'router' refers to an LLN device that can forward as 552 well as generate RPL traffic, and 'node' refers to any RPL device, 553 either a host or a router. 555 3. Protocol Overview 557 The aim of this section is to describe RPL in the spirit of 558 [RFC4101]. Protocol details can be found in further sections. 560 3.1. Topology 562 This section describes the basic RPL topologies that may be formed, 563 and the rules by which these are constructed, i.e. the rules 564 governing DODAG formation. 566 3.1.1. Constructing Topologies 568 LLNs, such as Radio Networks, do not typically have a predefined 569 topologies, for example those imposed by point to point wires, so RPL 570 has to discover links and then select peers sparingly. 572 Because in many cases layer 2 ranges overlap only partially, RPL 573 forms non-transitive/NBMA network topologies upon which it computes 574 routes. 576 RPL routes are optimized for traffic to or from one or more roots 577 that act as sinks for the topology. As a result, RPL organizes a 578 topology as a Directed Acyclic Graph (DAG) that is partitioned into 579 one or more Destination Oriented DAGS (DODAGs), one DODAG per sink. 580 If the DAG has multiple roots, then it is expected that the roots are 581 federated by a common backbone such as a transit link. 583 3.1.2. RPL Identifiers 585 RPL uses four values to identify and maintain a topology: 587 o The first is a RPLInstanceID. A RPLInstanceID identifies a set of 588 one or more Destination Oriented DAGs (DODAGs). A network may 589 have multiple RPLInstanceIDs, each of which defines an independent 590 set of DODAGs, which may be optimized for different Objective 591 Functions (OFs) and/or applications. The set of DODAGs identified 592 by a RPLInstanceID is called a RPL Instance. All DODAGs in the 593 same RPL Instance use the same OF. 595 o The second is a DODAGID. The scope of a DODAGID is a RPL 596 Instance. The combination of RPLInstanceID and DODAGID uniquely 597 identifies a single DODAG in the network. A RPL Instance may have 598 multiple DODAGs, each of which has an unique DODAGID. 600 o The third is a DODAGVersionNumber. The scope of a 601 DODAGVersionNumber is a DODAG. A DODAG is sometimes reconstructed 602 from the DODAG root, by incrementing the DODAGVersionNumber. The 603 combination of RPLInstanceID, DODAGID, and DODAGVersionNumber 604 uniquely identifies a DODAG Version. 606 o The fourth is Rank. The scope of Rank is a DODAG Version. Rank 607 establishes a partial order over a DODAG Version, defining 608 individual node positions with respect to the DODAG root. 610 3.1.3. Instances, DODAGs, and DODAG Versions 612 A RPL Instance contains one or more DODAG roots. A RPL Instance may 613 provide routes to certain destination prefixes, reachable via the 614 DODAG roots or alternate paths within the DODAG. These roots may 615 operate independently, or may coordinate over a network that is not 616 necessarily as constrained as a LLN. 618 A RPL Instance may comprise: 620 o a single DODAG with a single root 622 * For example, a DODAG optimized to minimize latency rooted at a 623 single centralized lighting controller in a home automation 624 application. 626 o multiple uncoordinated DODAGs with independent roots (differing 627 DODAGIDs) 629 * For example, multiple data collection points in an urban data 630 collection application that do not have suitable connectivity 631 to coordinate with each other, or that use the formation of 632 multiple DODAGs as a means to dynamically and autonomously 633 partition the network. 635 o a single DODAG with a virtual root that coordinates LLN sinks 636 (with the same DODAGID) over a backbone network. 638 * For example, multiple border routers operating with a reliable 639 transit link, e.g. in support of a 6LowPAN application, that 640 are capable to act as logically equivalent interfaces to the 641 sink of the same DODAG. 643 o a combination of the above as suited to some application scenario. 645 Each RPL packet is associated with a particular RPLInstanceID (see 646 Section 11.2) and therefore RPL Instance (Section 5). The 647 provisioning or automated discovery of a mapping between a 648 RPLInstanceID and a type or service of application traffic is out of 649 scope for this specification (to be defined in future companion 650 specifications). 652 Figure 1 depicts an example of a RPL Instance comprising three DODAGs 653 with DODAG Roots R1, R2, and R3. Each of these DODAG Roots 654 advertises the same RPLInstanceID. The lines depict connectivity 655 between parents and children. 657 Figure 2 depicts how a DODAG Version number increment leads to a new 658 DODAG Version. This depiction illustrates a DODAG Version number 659 increment that results in a different DODAG topology. Note that a 660 new DODAG Version does not always imply a different DODAG topology. 661 To accommodate certain topology changes requires a new DODAG Version, 662 as described later in this specification. 664 Please note that in the following examples tree-like structures are 665 depicted for simplicity, although the DODAG structure allows for each 666 node to have multiple parents when the connectivity supports it. 668 +----------------------------------------------------------------+ 669 | | 670 | +--------------+ | 671 | | | | 672 | | (R1) | (R2) (R3) | 673 | | / \ | /| \ / | \ | 674 | | / \ | / | \ / | \ | 675 | | (A) (B) | (C) | (D) ... (F) (G) (H) | 676 | | /|\ |\ | / | / |\ |\ | | | 677 | | : : : : : | : (E) : : : `: : | 678 | | | / \ | 679 | +--------------+ : : | 680 | DODAG | 681 | | 682 +----------------------------------------------------------------+ 683 RPL Instance 685 Figure 1: RPL Instance 687 +----------------+ +----------------+ 688 | | | | 689 | (R1) | | (R1) | 690 | / \ | | / | 691 | / \ | | / | 692 | (A) (B) | \ | (A) | 693 | /|\ / |\ | ------\ | /|\ | 694 | : : (C) : : | \ | : : (C) | 695 | | / | \ | 696 | | ------/ | \ | 697 | | / | (B) | 698 | | | |\ | 699 | | | : : | 700 | | | | 701 +----------------+ +----------------+ 702 Version N Version N+1 704 Figure 2: DODAG Version 706 3.2. Upward Routes and DODAG Construction 708 RPL provisions routes Up towards DODAG roots, forming a DODAG 709 optimized according to an Objective Function (OF). RPL nodes 710 construct and maintain these DODAGs through DODAG Information Object 711 (DIO) messages. 713 3.2.1. Objective Function (OF) 715 The Objective Function (OF) defines how RPL nodes select and optimize 716 routes within a RPL Instance. The OF is identified by an Objective 717 Code Point (OCP) within the DIO Configuration option. An OF defines 718 how nodes translate one or more metrics and constraints, which are 719 themselves defined in [I-D.ietf-roll-routing-metrics], into a value 720 called Rank, which approximates the node's distance from a DODAG 721 root. An OF also defines how nodes select parents. Further details 722 may be found in Section 14, [I-D.ietf-roll-routing-metrics], 723 [I-D.ietf-roll-of0], and related companion specifications. 725 3.2.2. DODAG Repair 727 A DODAG Root institutes a global repair operation by incrementing the 728 DODAG Version Number. This initiates a new DODAG Version. Nodes in 729 the new DODAG Version can choose a new position whose Rank is not 730 constrained by their Rank within the old DODAG Version. 732 RPL also supports mechanisms which may be used for local repair 733 within the DODAG Version. The DIO message specifies the necessary 734 parameters as configured from and controlled by policy at the DODAG 735 root. 737 3.2.3. Security 739 RPL supports message confidentiality and integrity. It is designed 740 such that link-layer mechanisms can be used when available and 741 appropriate, yet in their absence RPL can use its own mechanisms. 742 RPL has three basic security modes. 744 In the first, called "unsecured," RPL control messages are sent 745 without any additional security mechanisms. Unsecured mode does not 746 imply that the RPL network is unsecure: it could be using other 747 present security primitives (e.g. link-layer security) to meet 748 application security requirements. 750 In the second, called "pre-installed," nodes joining a RPL Instance 751 have pre-installed keys that enable them to process and generate 752 secured RPL messages. 754 The third mode is called "authenticated." In authenticated mode, 755 nodes have pre-installed keys as in pre-installed mode, but the pre- 756 installed key may only be used to join a RPL Instance as a leaf. 757 Joining an authenticated RPL Instance as a router requires obtaining 758 a key from an authentication authority. The process by which this 759 key is obtained is out of scope for this specification. Note that 760 this specification alone does not provide sufficient detail for a RPL 761 implementation to securely operate in authenticated mode. For a RPL 762 implementation to operate securely in authenticated mode it is 763 necessary for a future companion specification to detail the 764 mechanisms by which a node obtains/requests the authentication 765 material (e.g. key, certificate), and to determine from where that 766 material should be obtained. See also Section 10.3. 768 3.2.4. Grounded and Floating DODAGs 770 DODAGs can be grounded or floating: the DODAG root advertises which 771 is the case. A grounded DODAG offers connectivity to hosts that are 772 required for satisfying the application-defined goal. A floating 773 DODAG is not expected to satisfy the goal and in most cases only 774 provides routes to nodes within the DODAG. Floating DODAGs may be 775 used, for example, to preserve inner connectivity during repair. 777 3.2.5. Local DODAGs 779 RPL nodes can optimize routes to a destination within an LLN by 780 forming a local DODAG whose DODAG Root is the desired destination. 781 Unlike global DAGs, which can consist of multiple DODAGs, local DAGs 782 have one and only one DODAG and therefore one DODAG Root. Local 783 DODAGs can be constructed on-demand. 785 3.2.6. Administrative Preference 787 An implementation/deployment may specify that some DODAG roots should 788 be used over others through an administrative preference. 789 Administrative preference offers a way to control traffic and 790 engineer DODAG formation in order to better support application 791 requirements or needs. 793 3.2.7. Datapath Validation and Loop Detection 795 The low-power and lossy nature of LLNs motivates RPL's use of on- 796 demand loop detection using data packets. Because data traffic can 797 be infrequent, maintaining a routing topology that is constantly up 798 to date with the physical topology can waste energy. Typical LLNs 799 exhibit variations in physical connectivity that are transient and 800 innocuous to traffic, but that would be costly to track closely from 801 the control plane. Transient and infrequent changes in connectivity 802 need not be addressed by RPL until there is data to send. This 803 aspect of RPL's design draws from existing, highly used LLN protocols 804 as well as extensive experimental and deployment evidence on its 805 efficacy. 807 The RPL Packet Information that is transported with data packets 808 includes the Rank of the transmitter. An inconsistency between the 809 routing decision for a packet (upward or downward) and the Rank 810 relationship between the two nodes indicates a possible loop. On 811 receiving such a packet, a node institutes a local repair operation. 813 For example, if a node receives a packet flagged as moving in the 814 upward direction, and if that packet records that the transmitter is 815 of a lower (lesser) Rank than the receiving node, then the receiving 816 node is able to conclude that the packet has not progressed in the 817 upward direction and that the DODAG is inconsistent. 819 3.2.8. Distributed Algorithm Operation 821 A high level overview of the distributed algorithm, which constructs 822 the DODAG, is as follows: 824 o Some nodes are configured to be DODAG roots, with associated DODAG 825 configurations. 827 o Nodes advertise their presence, affiliation with a DODAG, routing 828 cost, and related metrics by sending link-local multicast DIO 829 messages to all-RPL-nodes. 831 o Nodes listen for DIOs and use their information to join a new 832 DODAG (thus selecting DODAG parents), or to maintain an existing 833 DODAG, according to the specified Objective Function and Rank of 834 their neighbors. 836 o Nodes provision routing table entries, for the destinations 837 specified by the DIO message, via their DODAG parents in the DODAG 838 Version. Nodes that decide to join a DODAG can provision one or 839 more DODAG parents as the next-hop for the default route and a 840 number of other external routes for the associated instance. 842 3.3. Downward Routes and Destination Advertisement 844 RPL uses Destination Advertisement Object (DAO) messages to establish 845 downward routes. DAO messages are an optional feature for 846 applications that require P2MP or P2P traffic. RPL supports two 847 modes of downward traffic: storing (fully stateful) or non-storing 848 (fully source routed). Any given RPL Instance is either storing or 849 non-storing. In both cases, P2P packets travel Up toward a DODAG 850 Root then Down to the final destination (unless the destination is on 851 the upward route). In the non-storing case the packet will travel 852 all the way to a DODAG root before traveling Down. In the storing 853 case the packet may be directed Down towards the destination by a 854 common ancestor of the source and the destination prior to reaching a 855 DODAG Root. 857 As of this specification no implementation is expected to support 858 both storing and non-storing modes of operation. Most 859 implementations are expected to support either no downward routes, 860 non-storing mode only, or storing mode only. Other modes of 861 operation, such as a hybrid mix of storing and non-storing mode, are 862 out of scope for this specification and may be described in other 863 companion specifications. 865 This specification describes a basic mode of operation in support of 866 P2P traffic. Note that more optimized P2P solutions may be described 867 in companion specifications. 869 3.4. Local DODAGs Route Discovery 871 A RPL network can optionally support on-demand discovery of DODAGs to 872 specific destinations within an LLN. Such local DODAGs behave 873 slightly differently than global DODAGs: they are uniquely defined by 874 the combination of DODAGID and RPLInstanceID. The RPLInstanceID 875 denotes whether a DODAG is a local DODAG. 877 3.5. Rank Properties 879 The rank of a node is a scalar representation of the location of that 880 node within a DODAG Version. The rank is used to avoid and detect 881 loops, and as such must demonstrate certain properties. The exact 882 calculation of the rank is left to the Objective Function. Even 883 though the specific computation of the rank is left to the Objective 884 Function, the rank must implement generic properties regardless of 885 the Objective Function. 887 In particular, the rank of the nodes must monotonically decrease as 888 the DODAG version is followed towards the DODAG destination. In that 889 regard, the rank can be regarded as a scalar representation of the 890 location or radius of a node within a DODAG Version. 892 The details of how the Objective Function computes rank are out of 893 scope for this specification, although that computation may depend, 894 for example, on parents, link metrics, node metrics, and the node 895 configuration and policies. See Section 14 for more information. 897 The rank is not a path cost, although its value can be derived from 898 and influenced by path metrics. The rank has properties of its own 899 that are not necessarily those of all metrics: 901 Type: The rank is an abstract numeric value. 903 Function: The rank is the expression of a relative position within a 904 DODAG Version with regard to neighbors and is not necessarily 905 a good indication or a proper expression of a distance or a 906 path cost to the root. 908 Stability: The stability of the rank determines the stability of the 909 routing topology. Some dampening or filtering is RECOMMENDED 910 to keep the topology stable, and thus the rank does not 911 necessarily change as fast as some link or node metrics 912 would. A new DODAG Version would be a good opportunity to 913 reconcile the discrepancies that might form over time between 914 metrics and ranks within a DODAG Version. 916 Properties: The rank is incremented in a strictly monotonic fashion, 917 and can be used to validate a progression from or towards the 918 root. A metric, like bandwidth or jitter, does not 919 necessarily exhibit this property. 921 Abstract: The rank does not have a physical unit, but rather a range 922 of increment per hop, where the assignment of each increment 923 is to be determined by the Objective Function. 925 The rank value feeds into DODAG parent selection, according to the 926 RPL loop-avoidance strategy. Once a parent has been added, and a 927 rank value for the node within the DODAG has been advertised, the 928 node's further options with regard to DODAG parent selection and 929 movement within the DODAG are restricted in favor of loop avoidance. 931 3.5.1. Rank Comparison (DAGRank()) 933 Rank may be thought of as a fixed point number, where the position of 934 the radix point between the integer part and the fractional part is 935 determined by MinHopRankIncrease. MinHopRankIncrease is the minimum 936 increase in rank between a node and any of its DODAG parents. A 937 DODAG Root provisions MinHopRankIncrease. MinHopRankIncrease creates 938 a tradeoff between hop cost precision and the maximum number of hops 939 a network can support. A very large MinHopRankIncrease, for example, 940 allows precise characterization of a given hop's affect on Rank but 941 cannot support many hops. 943 When an objective function computes rank, the objective function 944 operates on the entire (i.e. 16-bit) rank quantity. When rank is 945 compared, e.g. for determination of parent relationships or loop 946 detection, the integer portion of the rank is to be used. The 947 integer portion of the Rank is computed by the DAGRank() macro as 948 follows, where floor(x) is the function that evaluates to the 949 greatest integer less than or equal to x: 951 DAGRank(rank) = floor(rank/MinHopRankIncrease) 953 For example, if a 16-bit rank quantity is decimal 27, and the 954 MinHopRankIncrease is decimal 16, then DAGRank(27) = floor(1.6875) = 955 1. The integer part of the rank is 1 and the fractional part is 956 11/16. 958 By convention in this document, using the macro DAGRank(node) may be 959 interpreted as DAGRank(node.rank), where node.rank is the rank value 960 as maintained by the node. 962 A node A has a rank less than the rank of a node B if DAGRank(A) is 963 less than DAGRank(B). 965 A node A has a rank equal to the rank of a node B if DAGRank(A) is 966 equal to DAGRank(B). 968 A node A has a rank greater than the rank of a node B if DAGRank(A) 969 is greater than DAGRank(B). 971 3.5.2. Rank Relationships 973 Rank computations maintain the following properties for any nodes M 974 and N that are neighbors in the LLN: 976 DAGRank(M) is less than DAGRank(N): In this case, the position of M 977 is closer to the DODAG root than the position of N. Node M 978 may safely be a DODAG parent for Node N without risk of 979 creating a loop. Further, for a node N, all parents in the 980 DODAG parent set must be of rank less than DAGRank(N). In 981 other words, the rank presented by a node N MUST be greater 982 than that presented by any of its parents. 984 DAGRank(M) equals DAGRank(N): In this case the positions of M and N 985 within the DODAG and with respect to the DODAG root are 986 similar (identical). Routing through a node with equal Rank 987 may cause a routing loop (i.e., if that node chooses to route 988 through a node with equal Rank as well). 990 DAGRank(M) is greater than DAGRank(N): In this case, the position of 991 M is farther from the DODAG root than the position of N. 992 Further, Node M may in fact be in the sub-DODAG of Node N. If 993 node N selects node M as DODAG parent there is a risk to 994 create a loop. 996 As an example, the rank could be computed in such a way so as to 997 closely track ETX (Expected Transmission Count, a fairly common 998 routing metric used in LLN and defined in 999 [I-D.ietf-roll-routing-metrics]) when the metric that an objective 1000 function minimizes is ETX, or latency, or in a more complicated way 1001 as appropriate to the objective function being used within the DODAG. 1003 3.6. Routing Metrics and Constraints Used By RPL 1005 Routing metrics are used by routing protocols to compute shortest 1006 paths. Interior Gateway Protocols (IGPs) such as IS-IS ([RFC5120]) 1007 and OSPF ([RFC4915]) use static link metrics. Such link metrics can 1008 simply reflect the bandwidth or can also be computed according to a 1009 polynomial function of several metrics defining different link 1010 characteristics. Some routing protocols support more than one 1011 metric: in the vast majority of the cases, one metric is used per 1012 (sub)topology. Less often, a second metric may be used as a tie- 1013 breaker in the presence of Equal Cost Multiple Paths (ECMP). The 1014 optimization of multiple metrics is known as an NP complete problem 1015 and is sometimes supported by some centralized path computation 1016 engine. 1018 In contrast, LLNs do require the support of both static and dynamic 1019 metrics. Furthermore, both link and node metrics are required. In 1020 the case of RPL, it is virtually impossible to define one metric, or 1021 even a composite metric, that will satisfy all use cases. 1023 In addition, RPL supports constrained-based routing where constraints 1024 may be applied to both link and nodes. If a link or a node does not 1025 satisfy a required constraint, it is 'pruned' from the candidate 1026 neighbor set, thus leading to a constrained shortest path. 1028 An Objective Function specifies the objectives used to compute the 1029 (constrained) path. Furthermore, nodes are configured to support a 1030 set of metrics and constraints, and select their parents in the DODAG 1031 according to the metrics and constraints advertised in the DIO 1032 messages. Upstream and Downstream metrics may be merged or 1033 advertised separately depending on the OF and the metrics. When they 1034 are advertised separately, it may happen that the set of DIO parents 1035 is different from the set of DAO parents (a DAO parent is a node to 1036 which unicast DAO messages are sent). Yet, all are DODAG parents 1037 with regards to the rules for Rank computation. 1039 The Objective Function is decoupled from the routing metrics and 1040 constraints used by RPL. Indeed, whereas the OF dictates rules such 1041 as DODAG parents selection, load balancing and so on, the set of 1042 metrics and/or constraints used, and thus determine the preferred 1043 path, are based on the information carried within the DAG container 1044 option in DIO messages. 1046 The set of supported link/node constraints and metrics is specified 1047 in [I-D.ietf-roll-routing-metrics]. 1049 Example 1: Shortest path: path offering the shortest end-to-end 1050 delay. 1052 Example 2: Shortest Constrained path: the path that does not traverse 1053 any battery-operated node and that optimizes the path 1054 reliability. 1056 3.7. Loop Avoidance 1058 RPL tries to avoid creating loops when undergoing topology changes 1059 and includes rank-based datapath validation mechanisms for detecting 1060 loops when they do occur (see Section 11 for more details). In 1061 practice, this means that RPL guarantees neither loop free path 1062 selection nor tight delay convergence times, but can detect and 1063 repair a loop as soon as it is used. RPL uses this loop detection to 1064 ensure that packets make forward progress within the DODAG Version 1065 and trigger repairs when necessary. 1067 3.7.1. Greediness and Instability 1069 A node is greedy if it attempts to move deeper (increase Rank) in the 1070 DODAG Version in order to increase the size of the parent set or 1071 improve some other metric. Once a node has joined a DODAG Version, 1072 RPL disallows certain behaviors, including greediness, in order to 1073 prevent resulting instabilities in the DODAG Version. 1075 Suppose a node is willing to receive and process a DIO message from a 1076 node in its own sub-DODAG, and in general a node deeper than itself. 1077 In this case, a possibility exists that a feedback loop is created, 1078 wherein two or more nodes continue to try and move in the DODAG 1079 Version while attempting to optimize against each other. In some 1080 cases, this will result in instability. It is for this reason that 1081 RPL limits the cases where a node may process DIO messages from 1082 deeper nodes to some forms of local repair. This approach creates an 1083 'event horizon', whereby a node cannot be influenced beyond some 1084 limit into an instability by the action of nodes that may be in its 1085 own sub-DODAG. 1087 3.7.1.1. Example: Greedy Parent Selection and Instability 1089 (A) (A) (A) 1090 |\ |\ |\ 1091 | `-----. | `-----. | `-----. 1092 | \ | \ | \ 1093 (B) (C) (B) \ | (C) 1094 \ | | / 1095 `-----. | | .-----' 1096 \| |/ 1097 (C) (B) 1099 -1- -2- -3- 1101 Figure 3: Greedy DODAG Parent Selection 1103 Figure 3 depicts a DODAG in 3 different configurations. A usable 1104 link between (B) and (C) exists in all 3 configurations. In 1105 Figure 3-1, Node (A) is a DODAG parent for Nodes (B) and (C). In 1106 Figure 3-2, Node (A) is a DODAG parent for Nodes (B) and (C), and 1107 Node (B) is also a DODAG parent for Node (C). In Figure 3-3, Node 1108 (A) is a DODAG parent for Nodes (B) and (C), and Node (C) is also a 1109 DODAG parent for Node (B). 1111 If a RPL node is too greedy, in that it attempts to optimize for an 1112 additional number of parents beyond its most preferred parents, then 1113 an instability can result. Consider the DODAG illustrated in 1114 Figure 3-1. In this example, Nodes (B) and (C) may most prefer Node 1115 (A) as a DODAG parent, but we will consider the case when they are 1116 operating under the greedy condition that will try to optimize for 2 1117 parents. 1119 o Let Figure 3-1 be the initial condition. 1121 o Suppose Node (C) first is able to leave the DODAG and rejoin at a 1122 lower rank, taking both Nodes (A) and (B) as DODAG parents as 1123 depicted in Figure 3-2. Now Node (C) is deeper than both Nodes 1124 (A) and (B), and Node (C) is satisfied to have 2 DODAG parents. 1126 o Suppose Node (B), in its greediness, is willing to receive and 1127 process a DIO message from Node (C) (against the rules of RPL), 1128 and then Node (B) leaves the DODAG and rejoins at a lower rank, 1129 taking both Nodes (A) and (C) as DODAG parents. Now Node (B) is 1130 deeper than both Nodes (A) and (C) and is satisfied with 2 DAG 1131 parents. 1133 o Then Node (C), because it is also greedy, will leave and rejoin 1134 deeper, to again get 2 parents and have a lower rank then both of 1135 them. 1137 o Next Node (B) will again leave and rejoin deeper, to again get 2 1138 parents 1140 o And again Node (C) leaves and rejoins deeper... 1142 o The process will repeat, and the DODAG will oscillate between 1143 Figure 3-2 and Figure 3-3 until the nodes count to infinity and 1144 restart the cycle again. 1146 o This cycle can be averted through mechanisms in RPL: 1148 * Nodes (B) and (C) stay at a rank sufficient to attach to their 1149 most preferred parent (A) and don't go for any deeper (worse) 1150 alternate parents (Nodes are not greedy) 1152 * Nodes (B) and (C) do not process DIO messages from nodes deeper 1153 than themselves (because such nodes are possibly in their own 1154 sub-DODAGs) 1156 These mechanisms are further described in Section 8.2.2.4 1158 3.7.2. DODAG Loops 1160 A DODAG loop may occur when a node detaches from the DODAG and 1161 reattaches to a device in its prior sub-DODAG. This may happen in 1162 particular when DIO messages are missed. Strict use of the DODAG 1163 Version Number can eliminate this type of loop, but this type of loop 1164 may possibly be encountered when using some local repair mechanisms. 1166 For example, consider the local repair mechanism that allows a node 1167 to detach from the DODAG, advertise a rank of INFINITE_RANK (in order 1168 to poison its routes / inform its sub-DODAG), and then to re-attach 1169 to the DODAG. In that case the node may in some cases re-attach to 1170 its own prior-sub-DODAG, causing a DODAG loop, because the poisoning 1171 may fail if the INFINITE_RANK advertisements are lost in the LLN 1172 environment. (In this case the rank-based datapath validation 1173 mechanisms would eventually detect and trigger correction of the 1174 loop). 1176 3.7.3. DAO Loops 1178 A DAO loop may occur when the parent has a route installed upon 1179 receiving and processing a DAO message from a child, but the child 1180 has subsequently cleaned up the related DAO state. This loop happens 1181 when a No-Path (a DAO message that invalidates a previously announced 1182 prefix) was missed and persists until all state has been cleaned up. 1183 RPL includes an optional mechanism to acknowledge DAO messages, which 1184 may mitigate the impact of a single DAO message being missed. RPL 1185 includes loop detection mechanisms that mitigate the impact of DAO 1186 loops and trigger their repair. (See Section 11.2.2.3). 1188 4. Traffic Flows Supported by RPL 1190 RPL supports three basic traffic flows: Multipoint-to-Point (MP2P), 1191 Point-to-Multipoint (P2MP), and Point-to-Point (P2P). 1193 4.1. Multipoint-to-Point Traffic 1195 Multipoint-to-Point (MP2P) is a dominant traffic flow in many LLN 1196 applications ([RFC5867], [RFC5826], [RFC5673], [RFC5548]). The 1197 destinations of MP2P flows are designated nodes that have some 1198 application significance, such as providing connectivity to the 1199 larger Internet or core private IP network. RPL supports MP2P 1200 traffic by allowing MP2P destinations to be reached via DODAG roots. 1202 4.2. Point-to-Multipoint Traffic 1204 Point-to-multipoint (P2MP) is a traffic pattern required by several 1205 LLN applications ([RFC5867], [RFC5826], [RFC5673], [RFC5548]). RPL 1206 supports P2MP traffic by using a destination advertisement mechanism 1207 that provisions Down routes toward destinations (prefixes, addresses, 1208 or multicast groups), and away from roots. Destination 1209 advertisements can update routing tables as the underlying DODAG 1210 topology changes. 1212 4.3. Point-to-Point Traffic 1214 RPL DODAGs provide a basic structure for point-to-point (P2P) 1215 traffic. For a RPL network to support P2P traffic, a root must be 1216 able to route packets to a destination. Nodes within the network may 1217 also have routing tables to destinations. A packet flows towards a 1218 root until it reaches an ancestor that has a known route to the 1219 destination. As pointed out later in this document, in the most 1220 constrained case (when nodes cannot store routes), that common 1221 ancestor may be the DODAG root. In other cases it may be a node 1222 closer to both the source and destination. 1224 RPL also supports the case where a P2P destination is a 'one-hop' 1225 neighbor. 1227 RPL neither specifies nor precludes additional mechanisms for 1228 computing and installing potentially more optimal routes to support 1229 arbitrary P2P traffic. 1231 5. RPL Instance 1233 Within a given LLN, there may be multiple, logically independent RPL 1234 instances. A RPL node may belong to multiple RPL instances, and may 1235 act as a router in some and as a leaf in others. This document 1236 describes how a single instance behaves. 1238 There are two types of RPL Instances: local and global. RPL divides 1239 the RPLInstanceID space between Global and Local instances to allow 1240 for both coordinated and unilateral allocation of RPLInstanceIDs. 1241 Global RPL Instances are coordinated, have one or more DODAGs, and 1242 are typically long-lived. Local RPL Instances are always a single 1243 DODAG whose singular root owns the corresponding DODAGID and 1244 allocates the Local RPLInstanceID in a unilateral manner. Local RPL 1245 Instances can be used, for example, for constructing DODAGs in 1246 support of a future on-demand routing solution. The mode of 1247 operation of Local RPL Instances is out of scope for this 1248 specification and may be described in other companion specifications. 1250 The definition and provisioning of RPL instances are out of scope for 1251 this specification. Guidelines may be application and implementation 1252 specific, and are expected to be elaborated in future companion 1253 specifications. Those operations are expected to be such that data 1254 packets coming from the outside of the RPL network can unambiguously 1255 be associated to at least one RPL instance, and be safely routed over 1256 any instance that would match the packet. 1258 Control and data packets within RPL network are tagged to 1259 unambiguously identify what RPL Instance they are part of. 1261 Every RPL control message has a RPLInstanceID field. Some RPL 1262 control messages, when referring to a local RPLInstanceID as defined 1263 below, may also include a DODAGID. 1265 Data packets that flow within the RPL network expose the 1266 RPLInstanceID as part of the RPL Packet Information that RPL 1267 requires, as further described in Section 11.2. For data packets 1268 coming from outside the RPL network, the ingress router determines 1269 the RPLInstanceID and places it into the resulting packet that it 1270 injects into the RPL network. 1272 5.1. RPL Instance ID 1274 A global RPLInstanceID MUST be unique to the whole LLN. Mechanisms 1275 for allocating and provisioning global RPLInstanceID are out of scope 1276 for this specification. There can be up to 128 global instance in 1277 the whole network. Local instances are always used in conjunction 1278 with a DODAGID (which is either given explicitly or implicitly in 1279 some cases), and up 64 local instances per DODAGID can be supported. 1280 Local instances are allocated and managed by the node that owns the 1281 DODAGID, without any explicit coordination with other nodes, as 1282 further detailed below. 1284 A global RPLinstanceID is encoded in a RPLinstanceID field as 1285 follows: 1287 0 1 2 3 4 5 6 7 1288 +-+-+-+-+-+-+-+-+ 1289 |0| ID | Global RPLinstanceID in 0..127 1290 +-+-+-+-+-+-+-+-+ 1292 Figure 4: RPL Instance ID field format for global instances 1294 A local RPLInstanceID is autoconfigured by the node that owns the 1295 DODAGID and it MUST be unique for that DODAGID. The DODAGID used to 1296 configure the local RPLInstanceID MUST be a reachable IPv6 address of 1297 the node, and MUST be used as an endpoint of all communications 1298 within that local instance. 1300 A local RPLinstanceID is encoded in a RPLinstanceID field as follows: 1302 0 1 2 3 4 5 6 7 1303 +-+-+-+-+-+-+-+-+ 1304 |1|D| ID | Local RPLInstanceID in 0..63 1305 +-+-+-+-+-+-+-+-+ 1307 Figure 5: RPL Instance ID field format for local instances 1309 The D flag in a Local RPLInstanceID is always set to 0 in RPL control 1310 messages. It is used in data packets to indicate whether the DODAGID 1311 is the source or the destination of the packet. If the D flag is set 1312 to 1 then the destination address of the IPv6 packet MUST be the 1313 DODAGID. If the D flag is cleared then the source address of the 1314 IPv6 packet MUST be the DODAGID. 1316 For example, consider a node A that is the DODAG Root of a local RPL 1317 Instance, and has allocated a local RPLInstanceID. By definition, 1318 all traffic traversing that local RPL Instance will either originate 1319 or terminate at node A. The DODAGID in this case will be the 1320 reachable IPv6 address of node A, and all traffic will contain the 1321 address of node A, thus the DODAGID, in either the source or 1322 destination address. Thus the Local RPLInstanceID may indicate that 1323 the DODAGID is equivalent to either the source address or the 1324 destination address by setting the D flag appropriately. 1326 6. ICMPv6 RPL Control Message 1328 This document defines the RPL Control Message, a new ICMPv6 [RFC4443] 1329 message. A RPL Control Message is identified by a code, and composed 1330 of a base that depends on the code, and a series of options. 1332 Most RPL Control Message have the scope of a link. The only 1333 exception is for the DAO / DAO-ACK messages in non-storing mode, 1334 which are exchanged using a unicast address over multiple hops and 1335 thus uses global or unique-local addresses for both the source and 1336 destination addresses. For all other RPL Control messages, the 1337 source address is a link-local address, and the destination address 1338 is either the all-RPL-nodes multicast address or a link-local unicast 1339 address of the destination. The all-RPL-nodes multicast address is a 1340 new address with a requested value of FF02::1A (to be confirmed by 1341 IANA). 1343 In accordance with [RFC4443], the RPL Control Message consists of an 1344 ICMPv6 header followed by a message body. The message body is 1345 comprised of a message base and possibly a number of options as 1346 illustrated in Figure 6. 1348 0 1 2 3 1349 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 1350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1351 | Type | Code | Checksum | 1352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1353 | | 1354 . Base . 1355 . . 1356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1357 | | 1358 . Option(s) . 1359 . . 1360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1362 Figure 6: RPL Control Message 1364 The RPL Control message is an ICMPv6 information message with a 1365 requested Type of 155 (to be confirmed by IANA). 1367 The Code field identifies the type of RPL Control Message. This 1368 document defines codes for the following RPL Control Message types 1369 (all codes are to be confirmed by IANA Section 20.2): 1371 o 0x00: DODAG Information Solicitation (Section 6.2) 1373 o 0x01: DODAG Information Object (Section 6.3) 1375 o 0x02: Destination Advertisement Object (Section 6.4) 1377 o 0x03: Destination Advertisement Object Acknowledgment 1378 (Section 6.5) 1380 o 0x80: Secure DODAG Information Solicitation (Section 6.2.2) 1382 o 0x81: Secure DODAG Information Object (Section 6.3.2) 1384 o 0x82: Secure Destination Advertisement Object (Section 6.4.2) 1386 o 0x83: Secure Destination Advertisement Object Acknowledgment 1387 (Section 6.5.2) 1389 o 0x8A: Consistency Check (Section 6.6) 1391 If a node receives a RPL control message with an unknown Code field, 1392 the node MUST discard the message without any further processing, MAY 1393 raise a management alert, and MUST NOT send any messages in response. 1395 The checksum is computed as specified in [RFC4443]. It is set to 1396 zero for the RPL security operations specified below, and computed 1397 once the rest of the content of the RPL message including the 1398 security fields is all set. 1400 The high order bit (0x80) of the code denotes whether the RPL message 1401 has security enabled. Secure RPL messages have a format to support 1402 confidentiality and integrity, illustrated in Figure 7. 1404 0 1 2 3 1405 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 1406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1407 | Type | Code | Checksum | 1408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1409 | | 1410 . Security . 1411 . . 1412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1413 | | 1414 . Base . 1415 . . 1416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1417 | | 1418 . Option(s) . 1419 . . 1420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1422 Figure 7: Secure RPL Control Message 1424 The remainder of this section describes the currently defined RPL 1425 Control Message Base formats followed by the currently defined RPL 1426 Control Message Options. 1428 6.1. RPL Security Fields 1430 Each RPL message has a secure variant. The secure variants provide 1431 integrity and replay protection as well as optional confidentiality 1432 and delay protection. Because security covers the base message as 1433 well as options, in secured messages the security information lies 1434 between the checksum and base, as shown in Figure 7. 1436 The level of security and the algorithms in use are indicated in the 1437 protocol messages as described below: 1439 0 1 2 3 1440 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 1441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1442 |T| Reserved | Algorithm |KIM|Resvd| LVL | Flags | 1443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1444 | Counter | 1445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1446 | | 1447 . Key Identifier . 1448 . . 1449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1450 Figure 8: Security Section 1452 Message authentication codes (MACs) and signatures provide 1453 authentication over the entire unsecured ICMPv6 RPL control message, 1454 including the Security section with all fields defined, but with the 1455 ICMPv6 checksum temporarily set to zero. Encryption provides 1456 confidentiality of the secured RPL ICMPv6 message starting at the 1457 first byte after the Security section and continuing to the last byte 1458 of the packet. The security transformation yields a secured ICMPv6 1459 RPL message with the inclusion of the cryptographic fields (MAC, 1460 signature, etc.). In other words, the security transformation itself 1461 (e.g. the Signature and/or Algorithm in use) will detail how to 1462 incorporate the cryptographic fields into the secured packet. The 1463 Security section itself does not explicitly carry those cryptographic 1464 fields. Use of the Security section is further detailed in 1465 Section 19 and Section 10. 1467 Counter is Time (T): If the Counter is Time flag is set then the 1468 Counter field is a timestamp. If the flag is cleared then the 1469 Counter is an incrementing counter. Section 10.5 describes the 1470 details of the 'T' flag and Counter field. 1472 Reserved: 7-bit unused field. The field MUST be initialized to zero 1473 by the sender and MUST be ignored by the receiver. 1475 Security Algorithm (Algorithm): The Security Algorithm field 1476 specifies the encryption, MAC, and signature scheme the network 1477 uses. Supported values of this field are as follows: 1479 +-----------+-------------------+------------------------+ 1480 | Algorithm | Encryption/MAC | Signature | 1481 +-----------+-------------------+------------------------+ 1482 | 0 | CCM with AES-128 | RSA with SHA-256 | 1483 | 1-255 | Unassigned | Unassigned | 1484 +-----------+-------------------+------------------------+ 1486 Figure 9: Security Algorithm (Algorithm) Encoding 1488 Section 10.9 describes the algorithms in greater detail. 1490 Key Identifier Mode (KIM): The Key Identifier Mode is a 2-bit field 1491 that indicates whether the key used for packet protection is 1492 determined implicitly or explicitly and indicates the 1493 particular representation of the Key Identifier field. The Key 1494 Identifier Mode is set one of the values from the table below: 1496 +------+-----+-----------------------------+------------+ 1497 | Mode | KIM | Meaning | Key | 1498 | | | | Identifier | 1499 | | | | Length | 1500 | | | | (octets) | 1501 +------+-----+-----------------------------+------------+ 1502 | 0 | 00 | Group key used. | 1 | 1503 | | | Key determined by Key Index | | 1504 | | | field. | | 1505 | | | | | 1506 | | | Key Source is not present. | | 1507 | | | Key Index is present. | | 1508 +------+-----+-----------------------------+------------+ 1509 | 1 | 01 | Per-pair key used. | 0 | 1510 | | | Key determined by source | | 1511 | | | and destination of packet. | | 1512 | | | | | 1513 | | | Key Source is not present. | | 1514 | | | Key Index is not present. | | 1515 +------+-----+-----------------------------+------------+ 1516 | 2 | 10 | Group key used. | 9 | 1517 | | | Key determined by Key Index | | 1518 | | | and Key Source Identifier. | | 1519 | | | | | 1520 | | | Key Source is present. | | 1521 | | | Key Index is present. | | 1522 +------+-----+-----------------------------+------------+ 1523 | 3 | 11 | Node's signature key used. | 0/9 | 1524 | | | If packet is encrypted, | 1525 | | | it uses a group key, Key | | 1526 | | | Index and Key Source | | 1527 | | | specify key. | | 1528 | | | | | 1529 | | | Key Source may be present. | | 1530 | | | Key Index may be present. | | 1531 +------+-----+-----------------------------+------------+ 1533 Figure 10: Key Identifier Mode (KIM) Encoding 1535 In Mode 3 (KIM=11), the presence or absence of the Key Source 1536 and Key Identifier depends on the Security Level (LVL) 1537 described below. If the Security Level indicates there is 1538 encryption, then the fields are present; if it indicates there 1539 is no encryption, then the fields are not present. 1541 Resvd: 3-bit unused field. The field MUST be initialized to zero by 1542 the sender and MUST be ignored by the receiver. 1544 Security Level (LVL): The Security Level is a 3-bit field that 1545 indicates the provided packet protection. This value can be 1546 adapted on a per-packet basis and allows for varying levels of 1547 data authenticity and, optionally, for data confidentiality. 1548 The KIM field indicates whether signatures are used and the 1549 meaning of the Level field. Note that the assigned values of 1550 Security Level are not necessarily ordered-- a higher value of 1551 LVL does not necessarily equate to increased security. The 1552 Security Level is set to one of the values in the tables below: 1554 +---------------------------+ 1555 | KIM=0,1,2 | 1556 +-------+--------------------+------+ 1557 | LVL | Attributes | MAC | 1558 | | | Len | 1559 +-------+--------------------+------+ 1560 | 0 | MAC-32 | 4 | 1561 | 1 | ENC-MAC-32 | 4 | 1562 | 2 | MAC-64 | 8 | 1563 | 3 | ENC-MAC-64 | 8 | 1564 | 4-7 | Unassigned | N/A | 1565 +-------+--------------------+------+ 1567 +---------------------+ 1568 | KIM=3 | 1569 +-------+---------------+-----+ 1570 | LVL | Attributes | Sig | 1571 | | | Len | 1572 +-------+---------------+-----+ 1573 | 0 | Sign-3072 | 384 | 1574 | 1 | ENC-Sign-3072 | 384 | 1575 | 2 | Sign-2048 | 256 | 1576 | 3 | ENC-Sign-2048 | 256 | 1577 | 4-7 | Unassigned | N/A | 1578 +-------+---------------+-----+ 1580 Figure 11: Security Level (LVL) Encoding 1582 The MAC attribute indicates that the message has a Message 1583 Authentication Code of the specified length. The ENC attribute 1584 indicates that the message is encrypted. The Sign attribute 1585 indicates that the message has a signature of the specified 1586 length. 1588 Flags: 8-bit unused field reserved for flags. The field MUST be 1589 initialized to zero by the sender and MUST be ignored by the 1590 receiver. 1592 Counter: The Counter field indicates the non-repeating 4-octet value 1593 used to construct the cryptographic mechanism that implements 1594 packet protection and allows for the provision of semantic 1595 security. See Section 10.9.1. 1597 Key Identifier: The Key Identifier field indicates which key was 1598 used to protect the packet. This field provides various levels 1599 of granularity of packet protection, including peer-to-peer 1600 keys, group keys, and signature keys. This field is 1601 represented as indicated by the Key Identifier Mode field and 1602 is formatted as follows: 1604 0 1 2 3 1605 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 1606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1607 | | 1608 . Key Source . 1609 . . 1610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1611 | | 1612 . Key Index . 1613 . . 1614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1616 Figure 12: Key Identifier 1618 Key Source: The Key Source field, when present, indicates the 1619 logical identifier of the originator of a group key. 1620 When present this field is 8 bytes in length. 1622 Key Index: The Key Index field, when present, allows unique 1623 identification of different keys with the same 1624 originator. It is the responsibility of each key 1625 originator to make sure that actively used keys that it 1626 issues have distinct key indices and that all key indices 1627 have a value unequal to 0x00. Value 0x00 is reserved for 1628 a pre-installed, shared key. When present this field is 1629 1 byte in length. 1631 Unassigned bits of the Security section are reserved. They MUST be 1632 set to zero on transmission and MUST be ignored on reception. 1634 6.2. DODAG Information Solicitation (DIS) 1636 The DODAG Information Solicitation (DIS) message may be used to 1637 solicit a DODAG Information Object from a RPL node. Its use is 1638 analogous to that of a Router Solicitation as specified in IPv6 1639 Neighbor Discovery; a node may use DIS to probe its neighborhood for 1640 nearby DODAGs. Section 8.3 describes how nodes respond to a DIS. 1642 6.2.1. Format of the DIS Base Object 1644 0 1 2 1645 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1647 | Flags | Reserved | Option(s)... 1648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1650 Figure 13: The DIS Base Object 1652 Flags: 8-bit unused field reserved for flags. The field MUST be 1653 initialized to zero by the sender and MUST be ignored by the 1654 receiver. 1656 Reserved: 8-bit unused field. The field MUST be initialized to zero 1657 by the sender and MUST be ignored by the receiver. 1659 Unassigned bits of the DIS Base are reserved. They MUST be set to 1660 zero on transmission and MUST be ignored on reception. 1662 6.2.2. Secure DIS 1664 A Secure DIS message follows the format in Figure 7, where the base 1665 format is the DIS message shown in Figure 13. 1667 6.2.3. DIS Options 1669 The DIS message MAY carry valid options. 1671 This specification allows for the DIS message to carry the following 1672 options: 1673 0x00 Pad1 1674 0x01 PadN 1675 0x07 Solicited Information 1677 6.3. DODAG Information Object (DIO) 1679 The DODAG Information Object carries information that allows a node 1680 to discover a RPL Instance, learn its configuration parameters, 1681 select a DODAG parent set, and maintain the DODAG. 1683 6.3.1. Format of the DIO Base Object 1685 0 1 2 3 1686 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 1687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1688 | RPLInstanceID |Version Number | Rank | 1689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1690 |G|0| MOP | Prf | DTSN | Flags | Reserved | 1691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1692 | | 1693 + + 1694 | | 1695 + DODAGID + 1696 | | 1697 + + 1698 | | 1699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1700 | Option(s)... 1701 +-+-+-+-+-+-+-+-+ 1703 Figure 14: The DIO Base Object 1705 Grounded (G): The Grounded (G) flag indicates whether the DODAG 1706 advertised can satisfy the application-defined goal. If the 1707 flag is set, the DODAG is grounded. If the flag is cleared, 1708 the DODAG is floating. 1710 Mode of Operation (MOP): The Mode of Operation (MOP) field 1711 identifies the mode of operation of the RPL Instance as 1712 administratively provisioned at and distributed by the DODAG 1713 Root. All nodes who join the DODAG must be able to honor the 1714 MOP in order to fully participate as a router, or else they 1715 must only join as a leaf. MOP is encoded as in the figure 1716 below: 1718 +-----+-------------------------------------------------+ 1719 | MOP | Meaning | 1720 +-----+-------------------------------------------------+ 1721 | 0 | No downward routes maintained by RPL | 1722 | 1 | Non storing mode | 1723 | 2 | Storing without multicast support | 1724 | 3 | Storing with multicast support | 1725 | | | 1726 | | All other values are unassigned | 1727 +-----+-------------------------------------------------+ 1729 A value of 0 indicates that destination advertisement messages 1730 are disabled and the DODAG maintains only upward routes 1732 Figure 15: Mode of Operation (MOP) Encoding 1734 DODAGPreference (Prf): A 3-bit unsigned integer that defines how 1735 preferable the root of this DODAG is compared to other DODAG 1736 roots within the instance. DAGPreference ranges from 0x00 1737 (least preferred) to 0x07 (most preferred). The default is 0 1738 (least preferred). Section 8.2 describes how DAGPreference 1739 affects DIO processing. 1741 Version Number: 8-bit unsigned integer set by the DODAG root to the 1742 DODAGVersionNumber. Section 8.2 describes the rules for DODAG 1743 Version numbers and how they affect DIO processing. 1745 Rank: 16-bit unsigned integer indicating the DODAG rank of the node 1746 sending the DIO message. Section 8.2 describes how Rank is set 1747 and how it affects DIO processing. 1749 RPLInstanceID: 8-bit field set by the DODAG root that indicates 1750 which RPL Instance the DODAG is part of. 1752 Destination Advertisement Trigger Sequence Number (DTSN): 8-bit 1753 unsigned integer set by the node issuing the DIO message. The 1754 Destination Advertisement Trigger Sequence Number (DTSN) flag 1755 is used as part of the procedure to maintain downward routes. 1756 The details of this process are described in Section 9. 1758 Flags: 8-bit unused field reserved for flags. The field MUST be 1759 initialized to zero by the sender and MUST be ignored by the 1760 receiver. 1762 Reserved: 8-bit unused field. The field MUST be initialized to zero 1763 by the sender and MUST be ignored by the receiver. 1765 DODAGID: 128-bit IPv6 address set by a DODAG root which uniquely 1766 identifies a DODAG. The DODAGID MUST be a routable IPv6 1767 address belonging to the DODAG root. 1769 Unassigned bits of the DIO Base are reserved. They MUST be set to 1770 zero on transmission and MUST be ignored on reception. 1772 6.3.2. Secure DIO 1774 A Secure DIO message follows the format in Figure 7, where the base 1775 format is the DIO message shown in Figure 14. 1777 6.3.3. DIO Options 1779 The DIO message MAY carry valid options. 1781 This specification allows for the DIO message to carry the following 1782 options: 1783 0x00 Pad1 1784 0x01 PadN 1785 0x02 Metric Container 1786 0x03 Routing Information 1787 0x04 DODAG Configuration 1788 0x08 Prefix Information 1790 6.4. Destination Advertisement Object (DAO) 1792 The Destination Advertisement Object (DAO) is used to propagate 1793 destination information upwards along the DODAG. In storing mode the 1794 DAO message is unicast by the child to the selected parent(s). In 1795 non-storing mode the DAO message is unicast to the DODAG root. The 1796 DAO message may optionally, upon explicit request or error, be 1797 acknowledged by its destination with a Destination Advertisement 1798 Acknowledgement (DAO-ACK) message back to the sender of the DAO. 1800 6.4.1. Format of the DAO Base Object 1801 0 1 2 3 1802 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 1803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1804 | RPLInstanceID |K|D| Flags | Reserved | DAOSequence | 1805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1806 | | 1807 + + 1808 | | 1809 + DODAGID* + 1810 | | 1811 + + 1812 | | 1813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1814 | Option(s)... 1815 +-+-+-+-+-+-+-+-+ 1817 The '*' denotes that the DODAGID is not always present, as described 1818 below. 1820 Figure 16: The DAO Base Object 1822 RPLInstanceID: 8-bit field indicating the topology instance 1823 associated with the DODAG, as learned from the DIO. 1825 K: The 'K' flag indicates that the recipient is expected to send a 1826 DAO-ACK back. (See Section 9.3 1828 D: The 'D' flag indicates that the DODAGID field is present. This 1829 flag MUST be set when a local RPLInstanceID is used. 1831 Flags: The 6-bits remaining unused in the Flags field are reserved 1832 for flags. The field MUST be initialized to zero by the sender 1833 and MUST be ignored by the receiver. 1835 Reserved: 8-bit unused field. The field MUST be initialized to zero 1836 by the sender and MUST be ignored by the receiver. 1838 DAOSequence: Incremented at each unique DAO message from a node and 1839 echoed in the DAO-ACK message. 1841 DODAGID (optional): 128-bit unsigned integer set by a DODAG root 1842 which uniquely identifies a DODAG. This field is only present 1843 when the 'D' flag is set. This field is typically only present 1844 when a local RPLInstanceID is in use, in order to identify the 1845 DODAGID that is associated with the RPLInstanceID. When a 1846 global RPLInstanceID is in use this field need not be present. 1848 Unassigned bits of the DAO Base are reserved. They MUST be set to 1849 zero on transmission and MUST be ignored on reception. 1851 6.4.2. Secure DAO 1853 A Secure DAO message follows the format in Figure 7, where the base 1854 format is the DAO message shown in Figure 16. 1856 6.4.3. DAO Options 1858 The DAO message MAY carry valid options. 1860 This specification allows for the DAO message to carry the following 1861 options: 1862 0x00 Pad1 1863 0x01 PadN 1864 0x05 RPL Target 1865 0x06 Transit Information 1866 0x09 RPL Target Descriptor 1868 A special case of the DAO message, termed a No-Path, is used in 1869 storing mode to clear downward routing state that has been 1870 provisioned through DAO operation. The No-Path carries a Target 1871 option and an associated Transit Information option with a lifetime 1872 of 0x00000000 to indicate a loss of reachability to that Target. 1874 6.5. Destination Advertisement Object Acknowledgement (DAO-ACK) 1876 The DAO-ACK message is sent as a unicast packet by a DAO recipient (a 1877 DAO parent or DODAG root) in response to a unicast DAO message. 1879 6.5.1. Format of the DAO-ACK Base Object 1880 0 1 2 3 1881 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 1882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1883 | RPLInstanceID |D| Reserved | DAOSequence | Status | 1884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1885 | | 1886 + + 1887 | | 1888 + DODAGID* + 1889 | | 1890 + + 1891 | | 1892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1893 | Option(s)... 1894 +-+-+-+-+-+-+-+-+ 1896 The '*' denotes that the DODAGID is not always present, as described 1897 below. 1899 Figure 17: The DAO ACK Base Object 1901 RPLInstanceID: 8-bit field indicating the topology instance 1902 associated with the DODAG, as learned from the DIO. 1904 D: The 'D' flag indicates that the DODAGID field is present. This 1905 would typically only be set when a local RPLInstanceID is used. 1907 Flags: The 7-bits remaining unused in the Flags field are reserved 1908 for flags. The field MUST be initialized to zero by the sender 1909 and MUST be ignored by the receiver. 1911 DAOSequence: Incremented at each DAO message from a node, and echoed 1912 in the DAO-ACK by the recipient. The DAOSequence is used to 1913 correlate a DAO message and a DAO ACK message and is not to be 1914 confused with the Transit Information option Path Sequence that 1915 is associated to a given target Down the DODAG. 1917 Status: Indicates the completion. Status 0 is defined as 1918 unqualified acceptance in this specification. The remaining 1919 status values are reserved as rejection codes. No rejection 1920 status codes are defined in this specification, although status 1921 codes SHOULD be allocated according to the following guidelines 1922 in future specifications: 1923 0: Unqualified acceptance (i.e. the node receiving the 1924 DAO-ACK is not rejected). 1926 1-127: Not an outright rejection; the node sending the DAO- 1927 ACK is willing to act as a Parent, but the receiving 1928 node is suggested to find and use an alternate parent 1929 instead. 1930 127-255: Rejection; the node sending the DAO-ACK is unwilling 1931 to act as a Parent. 1933 DODAGID (optional): 128-bit unsigned integer set by a DODAG root 1934 which uniquely identifies a DODAG. This field is only present 1935 when the 'D' flag is set. This field is typically only present 1936 when a local RPLInstanceID is in use, in order to identify the 1937 DODAGID that is associated with the RPLInstanceID. When a 1938 global RPLInstanceID is in use this field need not be present. 1940 Unassigned bits of the DAO-ACK Base are reserved. They MUST be set 1941 to zero on transmission and MUST be ignored on reception. 1943 6.5.2. Secure DAO-ACK 1945 A Secure DAO-ACK message follows the format in Figure 7, where the 1946 base format is the DAO-ACK message shown in Figure 17. 1948 6.5.3. DAO-ACK Options 1950 This specification does not define any options to be carried by the 1951 DAO-ACK message. 1953 6.6. Consistency Check (CC) 1955 The CC message is used to check secure message counters and issue 1956 challenge/responses. A CC message MUST be sent as a secured RPL 1957 message. 1959 6.6.1. Format of the CC Base Object 1960 0 1 2 3 1961 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 1962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1963 | RPLInstanceID |R| Flags | CC Nonce | 1964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1965 | | 1966 + + 1967 | | 1968 + DODAGID + 1969 | | 1970 + + 1971 | | 1972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1973 | Destination Counter | 1974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1975 | Option(s)... 1976 +-+-+-+-+-+-+-+-+ 1978 Figure 18: The CC Base Object 1980 RPLInstanceID: 8-bit field indicating the topology instance 1981 associated with the DODAG, as learned from the DIO. 1983 R: The 'R' flag indicates whether the CC message is a response. A 1984 message with the 'R' flag cleared is a request; a message with 1985 the 'R' flag set is a response. 1987 Flags: The 7-bits remaining unused in the Flags field are reserved 1988 for flags. The field MUST be initialized to zero by the sender 1989 and MUST be ignored by the receiver. 1991 CC Nonce: 16-bit unsigned integer set by a CC request. The 1992 corresponding CC response includes the same CC nonce value as 1993 the request. 1995 Destination Counter: 32-bit unsigned integer value indicating the 1996 sender's estimate of the destination's current security Counter 1997 value. If the sender does not have an estimate, it SHOULD set 1998 the Destination Counter field to zero. 2000 Unassigned bits of the CC Base are reserved. They MUST be set to 2001 zero on transmission and MUST be ignored on reception. 2003 The Destination Counter value allows new or recovered nodes to 2004 resynchronize through CC message exchanges. This is important to 2005 ensure that a Counter value is not repeated for a given security key 2006 even in the event of devices recovering from a failure that created a 2007 loss of Counter state. For example, where a CC request or other RPL 2008 message is received with an initialized Counter within the message 2009 security section, the provision of the Incoming Counter within the CC 2010 response message allows the requesting node to reset its Outgoing 2011 Counter to a value greater than the last value received by the 2012 responding node; the Incoming Counter will also be updated from the 2013 received CC response. 2015 6.6.2. CC Options 2017 This specification allows for the CC message to carry the following 2018 options: 2019 0x00 Pad1 2020 0x01 PadN 2022 6.7. RPL Control Message Options 2024 6.7.1. RPL Control Message Option Generic Format 2026 RPL Control Message Options all follow this format: 2028 0 1 2 2029 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - 2031 | Option Type | Option Length | Option Data 2032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - 2034 Figure 19: RPL Option Generic Format 2036 Option Type: 8-bit identifier of the type of option. The Option 2037 Type values are to be confirmed by IANA Section 20.4. 2039 Option Length: 8-bit unsigned integer, representing the length in 2040 octets of the option, not including the Option Type and Length 2041 fields. 2043 Option Data: A variable length field that contains data specific to 2044 the option. 2046 When processing a RPL message containing an option for which the 2047 Option Type value is not recognized by the receiver, the receiver 2048 MUST silently ignore the unrecognized option and continue to process 2049 the following option, correctly handling any remaining options in the 2050 message. 2052 RPL message options may have alignment requirements. Following the 2053 convention in IPv6, options with alignment requirements are aligned 2054 in a packet such that multi-octet values within the Option Data field 2055 of each option fall on natural boundaries (i.e., fields of width n 2056 octets are placed at an integer multiple of n octets from the start 2057 of the header, for n = 1, 2, 4, or 8). 2059 6.7.2. Pad1 2061 The Pad1 option MAY be present in DIS, DIO, DAO, DAO-ACK, and CC 2062 messages, and its format is as follows: 2064 0 2065 0 1 2 3 4 5 6 7 2066 +-+-+-+-+-+-+-+-+ 2067 | Type = 0 | 2068 +-+-+-+-+-+-+-+-+ 2070 Figure 20: Format of the Pad 1 Option 2072 The Pad1 option is used to insert a single octet of padding into the 2073 message to enable options alignment. If more than one octet of 2074 padding is required, the PadN option should be used rather than 2075 multiple Pad1 options. 2077 NOTE! the format of the Pad1 option is a special case - it has 2078 neither Option Length nor Option Data fields. 2080 6.7.3. PadN 2082 The PadN option MAY be present in DIS, DIO, DAO, DAO-ACK, and CC 2083 messages, 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 = 1 | Option Length | 0x00 Padding... 2089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - 2091 Figure 21: Format of the Pad N Option 2093 The PadN option is used to insert two or more octets of padding into 2094 the message to enable options alignment. PadN Option data MUST be 2095 ignored by the receiver. 2097 Option Type: 0x01 (to be confirmed by IANA) 2098 Option Length: For N octets of padding, where 2 <= N <= 7, the 2099 Option Length field contains the value N-2. An Option Length 2100 of 0 indicates a total padding of 2 octets. An Option Length 2101 of 5 indicates a total padding of 7 octets, which is the 2102 maximum padding size allowed with the PadN option. 2104 Option Data: For N (N > 1) octets of padding, the Option Data 2105 consists of N-2 zero-valued octets. 2107 6.7.4. Metric Container 2109 The Metric Container option MAY be present in DIO or DAO messages, 2110 and its format is as follows: 2112 0 1 2 2113 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - 2115 | Type = 2 | Option Length | Metric Data 2116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - 2118 Figure 22: Format of the Metric Container Option 2120 The Metric Container is used to report metrics along the DODAG. The 2121 Metric Container may contain a number of discrete node, link, and 2122 aggregate path metrics and constraints specified in 2123 [I-D.ietf-roll-routing-metrics] as chosen by the implementer. 2125 The Metric Container MAY appear more than once in the same RPL 2126 control message, for example to accommodate a use case where the 2127 Metric Data is longer than 256 bytes. More information is in 2128 [I-D.ietf-roll-routing-metrics]. 2130 The processing and propagation of the Metric Container is governed by 2131 implementation specific policy functions. 2133 Option Type: 0x02 (to be confirmed by IANA) 2135 Option Length: The Option Length field contains the length in octets 2136 of the Metric Data. 2138 Metric Data: The order, content, and coding of the Metric Container 2139 data is as specified in [I-D.ietf-roll-routing-metrics]. 2141 6.7.5. Route Information 2143 The Route Information option MAY be present in DIO messages, and 2144 carries the same information as the IPv6 Neighbor Discovery (ND) 2145 Route Information option as defined in [RFC4191]. The root of a 2146 DODAG is authoritative for setting that information and the 2147 information is unchanged as propagated down the DODAG. A RPL router 2148 may trivially transform it back into a ND option to advertise in its 2149 own RAs so a node attached to the RPL router will end up using the 2150 DODAG for which the root has the best preference for the destination 2151 of a packet. In addition to the existing ND semantics, it is 2152 possible for an Objective function to use this information to favor a 2153 DODAG which root is most preferred for a specific destination. The 2154 format of the option is modified slightly (Type, Length, Prefix) in 2155 order to be carried as a RPL option as follows: 2157 0 1 2 3 2158 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 2159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2160 | Type = 3 | Option Length | Prefix Length |Resvd|Prf|Resvd| 2161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2162 | Route Lifetime | 2163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2164 | | 2165 . Prefix (Variable Length) . 2166 . . 2167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2169 Figure 23: Format of the Route Information Option 2171 The Route Information option is used to indicate that connectivity to 2172 the specified destination prefix is available from the DODAG root. 2174 In the event that a RPL Control Message may need to specify 2175 connectivity to more than one destination, the Route Information 2176 option may be repeated. 2178 [RFC4191] should be consulted as the authoritative reference with 2179 respect to the Route Information option. The field descriptions are 2180 transcribed here for convenience: 2182 Option Type: 0x03 (to be confirmed by IANA) 2184 Option Length: Variable, length of the option in octets excluding 2185 the Type and Length fields. Note that this length is expressed 2186 in units of single-octets, unlike in IPv6 ND. 2188 Prefix Length 8-bit unsigned integer. The number of leading bits in 2189 the Prefix that are valid. The value ranges from 0 to 128. 2190 The Prefix field has the number of bytes inferred from the 2191 Option Length field, that must be at least the Prefix Length. 2192 Note that in RPL this means that the Prefix field may have 2193 lengths other than 0, 8, or 16. 2195 Prf: 2-bit signed integer. The Route Preference indicates whether 2196 to prefer the router associated with this prefix over others, 2197 when multiple identical prefixes (for different routers) have 2198 been received. If the Reserved (10) value is received, the 2199 Route Information Option MUST be ignored. As per [RFC4191], 2200 the Reserved (10) value MUST NOT be sent. ([RFC4191] restricts 2201 the Preference to just three values to reinforce that it is not 2202 a metric). 2204 Resvd: Two 3-bit unused fields. They MUST be initialized to zero by 2205 the sender and MUST be ignored by the receiver. 2207 Route Lifetime 32-bit unsigned integer. The length of time in 2208 seconds (relative to the time the packet is sent) that the 2209 prefix is valid for route determination. A value of all one 2210 bits (0xffffffff) represents infinity. 2212 Prefix Variable-length field containing an IP address or a prefix of 2213 an IPv6 address. The Prefix Length field contains the number 2214 of valid leading bits in the prefix. The bits in the prefix 2215 after the prefix length (if any) are reserved and MUST be 2216 initialized to zero by the sender and ignored by the receiver. 2217 Note that in RPL this field may have lengths other than 0, 8, 2218 or 16. 2220 Unassigned bits of the Route Information option are reserved. They 2221 MUST be set to zero on transmission and MUST be ignored on reception. 2223 6.7.6. DODAG Configuration 2225 The DODAG Configuration option MAY be present in DIO messages, and 2226 its format is as follows: 2228 0 1 2 3 2229 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 2230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2231 | Type = 4 |Opt Length = 14| Flags |A| PCS | DIOIntDoubl. | 2232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2233 | DIOIntMin. | DIORedun. | MaxRankIncrease | 2234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2235 | MinHopRankIncrease | OCP | 2236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2237 | Reserved | Def. Lifetime | Lifetime Unit | 2238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2240 Figure 24: Format of the DODAG Configuration Option 2242 The DODAG Configuration option is used to distribute configuration 2243 information for DODAG Operation through the DODAG. 2245 The information communicated in this option is generally static and 2246 unchanging within the DODAG, therefore it is not necessary to include 2247 in every DIO. This information is configured at the DODAG Root and 2248 distributed throughout the DODAG with the DODAG Configuration Option. 2249 Nodes other than the DODAG Root MUST NOT modify this information when 2250 propagating the DODAG Configuration option. This option MAY be 2251 included occasionally by the DODAG Root (as determined by the DODAG 2252 Root), and MUST be included in response to a unicast request, e.g. a 2253 unicast DODAG Information Solicitation (DIS) message. 2255 Option Type: 0x04 (to be confirmed by IANA) 2257 Option Length: 14 2259 Flags: The 4-bits remaining unused in the Flags field are reserved 2260 for flags. The field MUST be initialized to zero by the sender 2261 and MUST be ignored by the receiver. 2263 Authentication Enabled (A): One bit flag describing the security 2264 mode of the network. The bit describe whether a node must 2265 authenticate with a key authority before joining the network as 2266 a router. If the DIO is not a secure DIO, the 'A' bit MUST be 2267 zero. 2269 Path Control Size (PCS): 3-bit unsigned integer used to configure 2270 the number of bits that may be allocated to the Path Control 2271 field (see Section 9.9). Note that when PCS is consulted to 2272 determine the width of the Path Control field a value of 1 is 2273 added, i.e. a PCS value of 0 results in 1 active bit in the 2274 Path Control field. The default value of PCS is 2275 DEFAULT_PATH_CONTROL_SIZE. 2277 DIOIntervalDoublings: 8-bit unsigned integer used to configure Imax 2278 of the DIO trickle timer (see Section 8.3.1). The default 2279 value of DIOIntervalDoublings is 2280 DEFAULT_DIO_INTERVAL_DOUBLINGS. 2282 DIOIntervalMin: 8-bit unsigned integer used to configure Imin of the 2283 DIO trickle timer (see Section 8.3.1). The default value of 2284 DIOIntervalMin is DEFAULT_DIO_INTERVAL_MIN. 2286 DIORedundancyConstant: 8-bit unsigned integer used to configure k of 2287 the DIO trickle timer (see Section 8.3.1). The default value 2288 of DIORedundancyConstant is DEFAULT_DIO_REDUNDANCY_CONSTANT. 2290 MaxRankIncrease: 16-bit unsigned integer used to configure 2291 DAGMaxRankIncrease, the allowable increase in rank in support 2292 of local repair. If DAGMaxRankIncrease is 0 then this 2293 mechanism is disabled. 2295 MinHopRankInc 16-bit unsigned integer used to configure 2296 MinHopRankIncrease as described in Section 3.5.1. The default 2297 value of MinHopRankInc is DEFAULT_MIN_HOP_RANK_INCREASE. 2299 Default Lifetime: 8-bit unsigned integer. This is the lifetime that 2300 is used as default for all RPL routes. It is expressed in 2301 units of Lifetime Units, e.g. the default lifetime in seconds 2302 is (Default Lifetime) * (Lifetime Unit). 2304 Lifetime Unit: 16-bit unsigned integer. Provides the unit in 2305 seconds that is used to express route lifetimes in RPL. For 2306 very stable networks, it can be hours to days. 2308 Objective Code Point (OCP) 16-bit unsigned integer. The OCP field 2309 identifies the OF and is managed by the IANA. 2311 6.7.7. RPL Target 2313 The RPL Target option MAY be present in DAO messages, and its format 2314 is as follows: 2316 0 1 2 3 2317 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 2318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2319 | Type = 5 | Option Length | Flags | Prefix Length | 2320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2321 | | 2322 + + 2323 | Target Prefix (Variable Length) | 2324 . . 2325 . . 2326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2328 Figure 25: Format of the RPL Target Option 2330 The RPL Target Option is used to indicate a target IPv6 address, 2331 prefix, or multicast group that is reachable or queried along the 2332 DODAG. In a DAO, the RPL Target option indicates reachability. 2334 A RPL Target Option May optionally be paired with a RPL Target 2335 Descriptor Option (Figure 30) that qualifies the target. 2337 A set of one or more Transit Information options (Section 6.7.8) MAY 2338 directly follow a set of one or more Target option in a DAO message 2339 (where each Target Option MAY be paired with a RPL Target Descriptor 2340 Option as above). The structure of the DAO message, detailing how 2341 Target options are used in conjunction with Transit Information 2342 options, is further described in Section 9.4. 2344 The RPL Target option may be repeated as necessary to indicate 2345 multiple targets. 2347 Option Type: 0x05 (to be confirmed by IANA) 2349 Option Length: Variable, length of the option in octets excluding 2350 the Type and Length fields. 2352 Flags: 8-bit unused field reserved for flags. The field MUST be 2353 initialized to zero by the sender and MUST be ignored by the 2354 receiver. 2356 Prefix Length: 8-bit unsigned integer. Number of valid leading bits 2357 in the IPv6 Prefix. 2359 Target Prefix: Variable-length field identifying an IPv6 destination 2360 address, prefix, or multicast group. The Prefix Length field 2361 contains the number of valid leading bits in the prefix. The 2362 bits in the prefix after the prefix length (if any) are 2363 reserved and MUST be set to zero on transmission and MUST be 2364 ignored on receipt. 2366 6.7.8. Transit Information 2368 The Transit Information option MAY be present in DAO messages, and 2369 its format is as follows: 2371 0 1 2 3 2372 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 2373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2374 | Type = 6 | Option Length |E| Flags | Path Control | 2375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2376 | Path Sequence | Path Lifetime | | 2377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 2378 | | 2379 + + 2380 | | 2381 + Parent Address* + 2382 | | 2383 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2384 | | 2385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2387 The '*' denotes that the Parent Address is not always present, as 2388 described below. 2390 Figure 26: Format of the Transit Information option 2392 The Transit Information option is used for a node to indicate 2393 attributes for a path to one or more destinations. The destinations 2394 are indicated by one or more Target options that immediately precede 2395 the Transit Information option(s). 2397 The Transit Information option can be used for a node to indicate its 2398 DODAG parents to an ancestor that is collecting DODAG routing 2399 information, typically for the purpose of constructing source routes. 2400 In the non-storing mode of operation this ancestor will be the DODAG 2401 Root, and this option is carried by the DAO message. In the storing 2402 mode of operation the Parent Address is not needed, since the DAO 2403 message is sent directly to the parent. The option length is used to 2404 determine whether the Parent Address is present or not. 2406 A non-storing node that has more than one DAO parent MAY include a 2407 Transit Information option for each DAO parent as part of the non- 2408 storing destination advertisement operation. The node may distribute 2409 the bits in the Path Control field among different groups of DAO 2410 parents in order to signal a preference among parents. That 2411 preference may influence the decision of the DODAG root when 2412 selecting among the alternate parents/paths for constructing downward 2413 routes. 2415 One or more Transit Information options MUST be preceded by one or 2416 more RPL Target options. In this manner the RPL Target option 2417 indicates the child node, and the Transit Information option(s) 2418 enumerate the DODAG parents. The structure of the DAO message, 2419 further detailing how Target options are used in conjunction with 2420 Transit Information options, is further described in Section 9.4. 2422 A typical non-storing node will use multiple Transit Information 2423 options, and it will send the DAO message thus formed directly to the 2424 root. A typical storing node will use one Transit Information option 2425 with no parent field, and will send the DAO message thus formed, with 2426 additional adjustments to Path Control as detailed later, to one or 2427 multiple parents. 2429 For example, in a non-storing mode of operation let Tgt(T) denote a 2430 Target option for a target T. Let Trnst(P) denote a Transit 2431 Information option that contains a parent address P. Consider the 2432 case of a non-storing node N that advertises the self-owned targets 2433 N1 and N2 and has parents P1, P2, and P3. In that case the DAO 2434 message would be expected to contain the sequence ( (Tgt(N1), 2435 Tgt(N2)), (Trnst(P1), Trnst(P2), Trnst(P3)) ), such that the group of 2436 Target options {N1, N2} are described by the Transit Information 2437 options as having the parents {P1, P2, P3}. The non-storing node 2438 would then address that DAO message directly to the DODAG root, and 2439 forward that DAO message through one of the DODAG parents P1, P2, or 2440 P3. 2442 Option Type: 0x06 (to be confirmed by IANA) 2444 Option Length: Variable, depending on whether or not Parent Address 2445 is present. 2447 External (E): 1-bit flag. The 'E' flag is set to indicate that the 2448 parent router redistributes external targets into the RPL 2449 network. An external target is a target that has been learned 2450 through an alternate protocol. The external targets are listed 2451 in the target options that immediately precede the Transit 2452 Information option. An external target is not expected to 2453 support RPL messages and options. 2455 Flags: The 7-bits remaining unused in the Flags field are reserved 2456 for flags. The field MUST be initialized to zero by the sender 2457 and MUST be ignored by the receiver. 2459 Path Control: 8-bit bitfield. The Path Control field limits the 2460 number of DAO-Parents to which a DAO message advertising 2461 connectivity to a specific destination may be sent, as well as 2462 providing some indication of relative preference. The limit 2463 provides some bound on overall DAO message fan-out in the LLN. 2464 The assignment and ordering of the bits in the path control 2465 also serves to communicate preference. Not all of these bits 2466 may be enabled as according to the PCS in the DODAG 2467 Configuration. The Path Control field is divided into four 2468 subfields which contain two bits each: PC1, PC2, PC3, and PC4, 2469 as illustrated in Figure 27. The subfields are ordered by 2470 preference, with PC1 being the most preferred and PC4 being the 2471 least preferred. Within a subfield there is no order of 2472 preference. By grouping the parents (as in ECMP) and ordering 2473 them, the parents may be associated with specific bits in the 2474 Path Control field in a way that communicates preference. 2476 0 1 2 3 4 5 6 7 2477 +-+-+-+-+-+-+-+-+ 2478 |PC1|PC2|PC3|PC4| 2479 +-+-+-+-+-+-+-+-+ 2481 Figure 27: Path Control Preference Sub-field Encoding 2483 Path Sequence: 8-bit unsigned integer. When a RPL Target option is 2484 issued by the node that owns the Target Prefix (i.e. in a DAO 2485 message), that node sets the Path Sequence and increments the 2486 Path Sequence each time it issues a RPL Target option with 2487 updated information. 2489 Path Lifetime: 8-bit unsigned integer. The length of time in 2490 Lifetime Units (obtained from the Configuration option) that 2491 the prefix is valid for route determination. The period starts 2492 when a new Path Sequence is seen. A value of all one bits 2493 (0xFF) represents infinity. A value of all zero bits (0x00) 2494 indicates a loss of reachability. A DAO message that contains 2495 a Transit Information option with a Path Lifetime of 0x00 for a 2496 Target is referred as a No-Path (for that Target) in this 2497 document. 2499 Parent Address (optional): IPv6 Address of the DODAG Parent of the 2500 node originally issuing the Transit Information Option. This 2501 field may not be present, as according to the DODAG Mode of 2502 Operation (storing or non-storing) and indicated by the Transit 2503 Information option length. 2505 Unassigned bits of the Transit Information option are reserved. They 2506 MUST be set to zero on transmission and MUST be ignored on reception. 2508 6.7.9. Solicited Information 2510 The Solicited Information option MAY be present in DIS messages, and 2511 its format is as follows: 2513 0 1 2 3 2514 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2516 | Type = 7 |Opt Length = 19| RPLInstanceID |V|I|D| Flags | 2517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2518 | | 2519 + + 2520 | | 2521 + DODAGID + 2522 | | 2523 + + 2524 | | 2525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2526 |Version Number | 2527 +-+-+-+-+-+-+-+-+ 2529 Figure 28: Format of the Solicited Information Option 2531 The Solicited Information option is used for a node to request DIO 2532 messages from a subset of neighboring nodes. The Solicited 2533 Information option may specify a number of predicate criteria to be 2534 matched by a receiving node. This is used by the requester to limit 2535 the number of replies from "non-interesting" nodes. These predicates 2536 affect whether a node resets its DIO trickle timer, as described in 2537 Section 8.3. 2539 The Solicited Information option contains flags that indicate which 2540 predicates a node should check when deciding whether to reset its 2541 Trickle timer. A node resets its Trickle timer when all predicates 2542 are true. If a flag is set, then the RPL node MUST check the 2543 associated predicate. If a flag is cleared, then the RPL node MUST 2544 NOT check the associated predicate. (If a flag is cleared, the RPL 2545 node assumes that the associated predicate is true). 2547 Option Type: 0x07 (to be confirmed by IANA) 2549 Option Length: 19 2551 V: The V flag is the Version predicate. The Version predicate is 2552 true if the receiver's DODAGVersionNumber matches the requested 2553 Version Number. If the V flag is cleared then the Version 2554 field is not valid and the Version field MUST be set to zero on 2555 transmission and ignored upon receipt. 2557 I: The I flag is the InstanceID predicate. The InstanceID 2558 predicate is true when the RPL node's current RPLInstanceID 2559 matches the requested RPLInstanceID. If the I flag is cleared 2560 then the RPLInstanceID field is not valid and the RPLInstanceID 2561 field MUST be set to zero on transmission and ignored upon 2562 receipt. 2564 D: The D flag is the DODAGID predicate. The DODAGID predicate is 2565 true if the RPL node's parent set has the same DODAGID as the 2566 DODAGID field. If the D flag is cleared then the DODAGID field 2567 is not valid and the DODAGID field MUST be set to zero on 2568 transmission and ignored upon receipt. 2570 Flags: The 5-bits remaining unused in the Flags field are reserved 2571 for flags. The field MUST be initialized to zero by the sender 2572 and MUST be ignored by the receiver. 2574 Version Number: 8-bit unsigned integer containing the value of 2575 DODAGVersionNumber that is being solicited when valid. 2577 RPLInstanceID: 8-bit unsigned integer containing the RPLInstanceID 2578 that is being solicited when valid. 2580 DODAGID: 128-bit unsigned integer containing the DODAGID that is 2581 being solicited when valid. 2583 Unassigned bits of the Solicited Information option are reserved. 2584 They MUST be set to zero on transmission and MUST be ignored on 2585 reception. 2587 6.7.10. Prefix Information 2589 The Prefix Information option MAY be present in DIO messages, and 2590 carries the information that is specified for the IPv6 ND Prefix 2591 Information Option in [RFC4861], [RFC4862] and [RFC3775] for use by 2592 RPL nodes and IPv6 hosts. In particular, a RPL node may use this 2593 option for the purpose of State-Less Address Auto-Configuration 2594 (SLAAC) from a prefix advertised by a parent as specified in 2595 [RFC4862], and advertise its own address as specified in [RFC3775]. 2596 The root of a DODAG is authoritative for setting that information. 2597 The information is propagated down the DODAG unchanged, with the 2598 exception that a RPL router may overwrite the Interface ID if the 'R' 2599 flag is set to indicate its full address in the PIO The format of the 2600 option is modified (Type, Length, Prefix) in order to be carried as a 2601 RPL option as follows: 2603 0 1 2 3 2604 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 2605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2606 | Type = 8 |Opt Length = 30| Prefix Length |L|A|R|Reserved1| 2607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2608 | Valid Lifetime | 2609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2610 | Preferred Lifetime | 2611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2612 | Reserved2 | 2613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2614 | | 2615 + + 2616 | | 2617 + Prefix + 2618 | | 2619 + + 2620 | | 2621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2623 Figure 29: Format of the Prefix Information Option 2625 The Prefix Information option may be used to distribute the prefix in 2626 use inside the DODAG, e.g. for address autoconfiguration. 2628 [RFC4861] and [RFC3775] should be consulted as the authoritative 2629 reference with respect to the Prefix Information option. The field 2630 descriptions are transcribed here for convenience: 2632 Option Type: 0x08 (to be confirmed by IANA) 2634 Option Length: 30. Note that this length is expressed in units of 2635 single-octets, unlike in IPv6 ND. 2637 Prefix Length 8-bit unsigned integer. The number of leading bits in 2638 the Prefix that are valid. The value ranges from 0 to 128. 2639 The prefix length field provides necessary information for on- 2640 link determination (when combined with the L flag in the prefix 2641 information option). It also assists with address 2642 autoconfiguration as specified in [RFC4862], for which there 2643 may be more restrictions on the prefix length. 2645 L 1-bit on-link flag. When set, indicates that this prefix can 2646 be used for on-link determination. When not set the 2647 advertisement makes no statement about on-link or off-link 2648 properties of the prefix. In other words, if the L flag is not 2649 set a RPL node MUST NOT conclude that an address derived from 2650 the prefix is off-link. That is, it MUST NOT update a previous 2651 indication that the address is on-link. A RPL node acting as a 2652 router MUST NOT propagate a PIO with the L flag set. A RPL 2653 node acting as a router MAY propagate a PIO with the L flag not 2654 set. 2656 A 1-bit autonomous address-configuration flag. When set 2657 indicates that this prefix can be used for stateless address 2658 configuration as specified in [RFC4862]. When both protocols 2659 (ND RAs and RPL DIOs) are used to carry PIOs on the same link, 2660 it is possible to use either one for SLAAC by a RPL node. It 2661 is also possible to make either protocol ineligible for SLAAC 2662 operation by forcing the A flag to 0 for PIOs carried in that 2663 protocol. 2665 R 1-bit Router address flag. When set, indicates that the Prefix 2666 field contains a complete IPv6 address assigned to the sending 2667 router that can be used as parent in a target option. The 2668 indicated prefix is the first Prefix Length bits of the Prefix 2669 field. The router IPv6 address has the same scope and conforms 2670 to the same lifetime values as the advertised prefix. This use 2671 of the Prefix field is compatible with its use in advertising 2672 the prefix itself, since Prefix Advertisement uses only the 2673 leading bits. Interpretation of this flag bit is thus 2674 independent of the processing required for the On-Link (L) and 2675 Autonomous Address-Configuration (A) flag bits. 2677 Reserved1 5-bit unused field. It MUST be initialized to zero by the 2678 sender and MUST be ignored by the receiver. 2680 Valid Lifetime 32-bit unsigned integer. The length of time in 2681 seconds (relative to the time the packet is sent) that the 2682 prefix is valid for the purpose of on-link determination. A 2683 value of all one bits (0xffffffff) represents infinity. The 2684 Valid Lifetime is also used by [RFC4862]. 2686 Preferred Lifetime 32-bit unsigned integer. The length of time in 2687 seconds (relative to the time the packet is sent) that 2688 addresses generated from the prefix via stateless address 2689 autoconfiguration remain preferred [RFC4862]. A value of all 2690 one bits (0xffffffff) represents infinity. See [RFC4862]. 2691 Note that the value of this field MUST NOT exceed the Valid 2692 Lifetime field to avoid preferring addresses that are no longer 2693 valid. 2695 Reserved2 This field is unused. It MUST be initialized to zero by 2696 the sender and MUST be ignored by the receiver. 2698 Prefix An IPv6 address or a prefix of an IPv6 address. The Prefix 2699 Length field contains the number of valid leading bits in the 2700 prefix. The bits in the prefix after the prefix length are 2701 reserved and MUST be initialized to zero by the sender and 2702 ignored by the receiver. A router SHOULD NOT send a prefix 2703 option for the link-local prefix and a host SHOULD ignore such 2704 a prefix option. A non-storing node SHOULD refrain from 2705 advertising a prefix till it owns an address of that prefix, 2706 and then it SHOULD advertise its full address in this field, 2707 with the 'R' flag set. The children of a node that so 2708 advertises a full address with the 'R' flag set may then use 2709 that address to determine the content of the Parent Address 2710 field of the Transit Information Option. 2712 Unassigned bits of the Prefix Information option are reserved. They 2713 MUST be set to zero on transmission and MUST be ignored on reception. 2715 6.7.11. RPL Target Descriptor 2717 The RPL Target option MAY be immediately followed by one opaque 2718 descriptor that qualifies that specific target. 2720 0 1 2 3 2721 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 2722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2723 | Type = 9 |Opt Length = 4 | Descriptor 2724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2725 Descriptor (cont.) | 2726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2728 Figure 30: Format of the RPL Target Descriptor Option 2730 The RPL Target Descriptor Option is used to qualify a target, 2731 something that is sometimes called tagging. 2733 There can be at most one descriptor per target. The descriptor is 2734 set by the node that injects the target in the RPL network. It MUST 2735 be copied but not modified by routers that propagate the target Up 2736 the DODAG in DAO messages. 2738 Option Type: 0x09 (to be confirmed by IANA) 2740 Option Length: 4 2742 Descriptor: 32-bit unsigned integer. Opaque. 2744 7. Sequence Counters 2746 This section describes the general scheme for bootstrap and operation 2747 of sequence counters in RPL, such as the DODAGVersionNumber in the 2748 DIO message, the DAOSequence in the DAO message, and the Path 2749 Sequence in the Transit Information option. 2751 7.1. Sequence Counter Overview 2753 This specification utilizes three different sequence numbers to 2754 validate the freshness and the synchronization of protocol 2755 information: 2757 DODAGVersionNumber: This sequence counter is present in the DIO 2758 base to indicate the Version of the DODAG being formed. The 2759 DODAGVersionNumber is monotonically incremented by the root 2760 each time the root decides to form a new Version of the DODAG 2761 in order to revalidate the integrity and allow a global repairs 2762 to occur. The DODAGVersionNumber is propagated unchanged Down 2763 the DODAG as routers join the new DODAG Version. The 2764 DODAGVersionNumber is globally significant in a DODAG and 2765 indicates the Version of the DODAG that a router is operating 2766 in. An older (lesser) value indicates that the originating 2767 router has not migrated to the new DODAG Version and can not be 2768 used as a parent once the receiving node has migrated to the 2769 newer DODAG Version. 2771 DAOSequence: This sequence counter is present in the DAO base to 2772 correlate a DAO message and a DAO ACK message. The DAOSequence 2773 number is locally significant to the node that issues a DAO 2774 message for its own consumption to detect the loss of a DAO 2775 message and enable retries. 2777 Path Sequence: This sequence counter is present in the Transit 2778 Information option in a DAO message. The purpose of this 2779 counter is to differentiate a movement where a newer route 2780 supersedes a stale one from a route redundancy scenario where 2781 multiple routes exist in parallel for a same target. The Path 2782 Sequence is globally significant in a DODAG and indicates the 2783 freshness of the route to the associated target. An older 2784 (lesser) value received from an originating router indicates 2785 that the originating router holds stale routing states and the 2786 originating router should not be considered anymore as a 2787 potential next-hop for the target. The Path Sequence is 2788 computed by the node that advertises the target, that is the 2789 target itself or a router that advertises a target on behalf of 2790 a host, and is unchanged as the DAO content is propagated 2791 towards the root by parent routers. If a host does not pass a 2792 counter to its router, then the router is in charge of 2793 computing the Path Sequence on behalf of the host and the host 2794 can only register to one router for that purpose. If a DAO 2795 message containing a same target is issued to multiple parents 2796 at a given point of time for the purpose of route redundancy, 2797 then the Path Sequence is the same in all the DAO messages for 2798 that same target. 2800 7.2. Sequence Counter Operation 2802 RPL sequence counters are subdivided in a 'lollipop' fashion 2803 ([Perlman83]), where the values from 128 and greater are used as a 2804 linear sequence to indicate a restart and bootstrap the counter, and 2805 the values less than or equal to 127 used as a circular sequence 2806 number space of size 128 as in [RFC1982]. Consideration is given to 2807 the mode of operation when transitioning from the linear region to 2808 the circular region. Finally, when operating in the circular region, 2809 if sequence numbers are detected to be too far apart then they are 2810 not comparable, as detailed below. 2812 A window of comparison, SEQUENCE_WINDOW = 16, is configured based on 2813 a value of 2^N, where N is defined to be 4 in this specification. 2815 For a given sequence counter, 2817 1. The sequence counter SHOULD be initialized to an implementation 2818 defined value which is 128 or greater prior to use. A 2819 recommended value is 240 (256 - SEQUENCE_WINDOW). 2821 2. When a sequence counter increment would cause the sequence 2822 counter to increment beyond its maximum value, the sequence 2823 counter MUST wrap back to zero. When incrementing a sequence 2824 counter greater than or equal to 128, the maximum value is 255. 2825 When incrementing a sequence counter less than 128, the maximum 2826 value is 127. 2828 3. When comparing two sequence counters, the following rules MUST be 2829 applied: 2831 1. When a first sequence counter A is in the interval [128..255] 2832 and a second sequence counter B is in [0..127]: 2834 1. If (256 + B - A) is less than or equal to 2835 SEQUENCE_WINDOW, then B is greater than A, A is less than 2836 B, and the two are not equal. 2838 2. If (256 + B - A) is greater than SEQUENCE_WINDOW, then A 2839 is greater than B, B is less than A, and the two are not 2840 equal. 2842 For example, if A is 240, and B is 5, then (256 + 5 - 240) is 2843 21. 21 is greater than SEQUENCE_WINDOW (16), thus 240 is 2844 greater than 5. As another example, if A is 250 and B is 5, 2845 then (256 + 5 - 250) is 11. 11 is less than SEQUENCE_WINDOW 2846 (16), thus 250 is less than 5. 2848 2. In the case where both sequence counters to be compared are 2849 less than or equal to 127, and in the case where both 2850 sequence counters to be compared are greater than or equal to 2851 128: 2853 1. If the absolute magnitude of difference between the two 2854 sequence counters is less than or equal to 2855 SEQUENCE_WINDOW, then a comparison as described in 2856 [RFC1982] is used to determine the relationships greater 2857 than, less than, and equal. 2859 2. If the absolute magnitude of difference of the two 2860 sequence counters is greater than SEQUENCE_WINDOW, then a 2861 desynchronization has occurred and the two sequence 2862 numbers are not comparable. 2864 4. If two sequence numbers are determined to be not comparable, i.e. 2865 the results of the comparison are not defined, then a node should 2866 consider the comparison as if it has evaluated in such a way so 2867 as to give precedence to the sequence number that has most 2868 recently been observed to increment. Failing this, the node 2869 should consider the comparison as if it has evaluated in such a 2870 way so as to minimize the resulting changes to its own state. 2872 8. Upward Routes 2874 This section describes how RPL discovers and maintains upward routes. 2875 It describes the use of DODAG Information Objects (DIOs), the 2876 messages used to discover and maintain these routes. It specifies 2877 how RPL generates and responds to DIOs. It also describes DODAG 2878 Information Solicitation (DIS) messages, which are used to trigger 2879 DIO transmissions. 2881 As mentioned in Section 3.2.8, nodes that decide to join a DODAG MUST 2882 provision at least one DODAG parent as a default route for the 2883 associated instance. This default route enables a packet to be 2884 forwarded upwards until it eventually hits a common ancestor from 2885 which it will be routed downwards to the destination. If the 2886 destination is not in the DODAG, then the DODAG root may be able to 2887 forward the packet using connectivity to the outside of the DODAG; if 2888 it can not forward the packet outside then the DODAG root has to drop 2889 it. 2891 A DIO message can also transport explicit routing information: 2893 DODAGID The DODAGID is a Global or Unique Local IPv6 Address of the 2894 root. A node that joins a DODAG SHOULD provision a host route 2895 via a DODAG parent to the address used by the root as DODAGID. 2897 RIO Prefix The root MAY place one or more Route Information options 2898 in a DIO message. The RIO is used to advertise an external 2899 route that is reachable via the root, associated with a 2900 preference, as presented in Section 6.7.5, which incorporates 2901 the RIO from [RFC4191]. It is interpreted as a capability of 2902 the root as opposed to a routing advertisement and it MUST NOT 2903 be redistributed in another routing protocol though it SHOULD 2904 be used by an ingress RPL router to select a DODAG when a 2905 packet is injected in a RPL domain from a node attached to that 2906 RPL router. An Objective Function MAY use the routes 2907 advertised in RIO or the preference for those routes in order 2908 to favor a DODAG versus another one for a same instance. 2910 8.1. DIO Base Rules 2912 1. For the following DIO Base fields, a node that is not a DODAG 2913 root MUST advertise the same values as its preferred DODAG parent 2914 (defined in Section 8.2.1). In this way these values will 2915 propagate Down the DODAG unchanged and advertised by every node 2916 that has a route to that DODAG root. These fields are: 2917 1. Grounded (G) 2918 2. Mode of Operation (MOP) 2919 3. DAGPreference (Prf) 2920 4. Version 2921 5. RPLInstanceID 2922 6. DODAGID 2924 2. A node MAY update the following fields at each hop: 2925 1. Rank 2926 2. DTSN 2928 3. The DODAGID field each root sets MUST be unique within the RPL 2929 Instance and MUST be a routable IPv6 address belonging to the 2930 root. 2932 8.2. Upward Route Discovery and Maintenance 2934 Upward route discovery allows a node to join a DODAG by discovering 2935 neighbors that are members of the DODAG of interest and identifying a 2936 set of parents. The exact policies for selecting neighbors and 2937 parents is implementation-dependent and driven by the OF. This 2938 section specifies the set of rules those policies must follow for 2939 interoperability. 2941 8.2.1. Neighbors and Parents within a DODAG Version 2943 RPL's upward route discovery algorithms and processing are in terms 2944 of three logical sets of link-local nodes. First, the candidate 2945 neighbor set is a subset of the nodes that can be reached via link- 2946 local multicast. The selection of this set is implementation- 2947 dependent and OF-dependent. Second, the parent set is a restricted 2948 subset of the candidate neighbor set. Finally, the preferred parent 2949 is a member of the parent set that is the preferred next hop in 2950 upward routes. The preferred parent is conceptually a single parent 2951 although it may be a set of multiple parents if those parents are 2952 equally preferred and have identical rank. 2954 More precisely: 2956 1. The DODAG parent set MUST be a subset of the candidate neighbor 2957 set. 2959 2. A DODAG root MUST have a DODAG parent set of size zero. 2961 3. A node that is not a DODAG root MAY maintain a DODAG parent set 2962 of size greater than or equal to one. 2964 4. A node's preferred DODAG parent MUST be a member of its DODAG 2965 parent set. 2967 5. A node's rank MUST be greater than all elements of its DODAG 2968 parent set. 2970 6. When Neighbor Unreachability Detection (NUD) [RFC4861], or an 2971 equivalent mechanism, determines that a neighbor is no longer 2972 reachable, a RPL node MUST NOT consider this node in the 2973 candidate neighbor set when calculating and advertising routes 2974 until it determines that it is again reachable. Routes through 2975 an unreachable neighbor MUST be removed from the routing table. 2977 These rules ensure that there is a consistent partial order on nodes 2978 within the DODAG. As long as node ranks do not change, following the 2979 above rules ensures that every node's route to a DODAG root is loop- 2980 free, as rank decreases on each hop to the root. 2982 The OF can guide candidate neighbor set and parent set selection, as 2983 discussed in [I-D.ietf-roll-of0]. 2985 8.2.2. Neighbors and Parents across DODAG Versions 2987 The above rules govern a single DODAG Version. The rules in this 2988 section define how RPL operates when there are multiple DODAG 2989 Versions: 2991 8.2.2.1. DODAG Version 2993 1. The tuple (RPLInstanceID, DODAGID, DODAGVersionNumber) uniquely 2994 defines a DODAG Version. Every element of a node's DODAG parent 2995 set, as conveyed by the last heard DIO message from each DODAG 2996 parent, MUST belong to the same DODAG Version. Elements of a 2997 node's candidate neighbor set MAY belong to different DODAG 2998 Versions. 3000 2. A node is a member of a DODAG Version if every element of its 3001 DODAG parent set belongs to that DODAG Version, or if that node 3002 is the root of the corresponding DODAG. 3004 3. A node MUST NOT send DIOs for DODAG Versions of which it is not a 3005 member. 3007 4. DODAG roots MAY increment the DODAGVersionNumber that they 3008 advertise and thus move to a new DODAG Version. When a DODAG 3009 root increments its DODAGVersionNumber, it MUST follow the 3010 conventions of Serial Number Arithmetic as described in 3011 Section 7. Events triggering the increment of the 3012 DODAGVersionNumber are described later in this section and in 3013 Section 18. 3015 5. Within a given DODAG, a node that is a not a root MUST NOT 3016 advertise a DODAGVersionNumber higher than the highest 3017 DODAGVersionNumber it has heard. Higher is defined as the 3018 greater-than operator in Section 7. 3020 6. Once a node has advertised a DODAG Version by sending a DIO, it 3021 MUST NOT be a member of a previous DODAG Version of the same 3022 DODAG (i.e. with the same RPLInstanceID, the same DODAGID, and a 3023 lower DODAGVersionNumber). Lower is defined as the less-than 3024 operator in Section 7. 3026 When the DODAG parent set becomes empty on a node that is not a root, 3027 (i.e. the last parent has been removed, causing the node to no longer 3028 be associated with that DODAG), then the DODAG information should not 3029 be suppressed until after the expiration of an implementation- 3030 specific local timer. During the interval prior to suppression of 3031 the 'old' DODAG state, the node will be able to observe if the 3032 DODAGVersionNumber has been incremented should any new parents 3033 appear. This will help protect against the possibility of loops that 3034 may occur if that node were to inadvertently rejoin the old DODAG 3035 Version in its own prior sub-DODAG. 3037 As the DODAGVersionNumber is incremented, a new DODAG Version spreads 3038 outward from the DODAG root. A parent that advertises the new 3039 DODAGVersionNumber cannot belong to the sub-DODAG of a node 3040 advertising an older DODAGVersionNumber. Therefore a node can safely 3041 add a parent of any Rank with a newer DODAGVersionNumber without 3042 forming a loop. 3044 For example, suppose that a node has left a DODAG with 3045 DODAGVersionNumber N. Suppose that node had a sub-DODAG, and did 3046 attempt to poison that sub-DODAG by advertising a rank of 3047 INFINITE_RANK, but those advertisements may have become lost in the 3048 LLN. Then, if the node did observe a candidate neighbor advertising 3049 a position in that original DODAG at DODAGVersionNumber N, that 3050 candidate neighbor could possibly have been in the node's former sub- 3051 DODAG and there is a possible case where to add that candidate 3052 neighbor as a parent could cause a loop. If that candidate neighbor 3053 in this case is observed to advertise a DODAGVersionNumber N+1, then 3054 that candidate neighbor is certain to be safe, since it is certain 3055 not to be in that original node's sub-DODAG as it has been able to 3056 increment the DODAGVersionNumber by hearing from the DODAG root while 3057 that original node was detached. It is for this reason that it is 3058 useful for the detached node to remember the original DODAG 3059 information, including the DODAGVersionNumber N. 3061 Exactly when a DODAG Root increments the DODAGVersionNumber is 3062 implementation dependent and out of scope for this specification. 3064 Examples include incrementing the DODAGVersionNumber periodically, 3065 upon administrative intervention, or on application-level detection 3066 of lost connectivity or DODAG inefficiency. 3068 After a node transitions to and advertises a new DODAG Version, the 3069 rules above make it unable to advertise the previous DODAG Version 3070 (prior DODAGVersionNumber) once it has committed to advertising the 3071 new DODAG Version. 3073 8.2.2.2. DODAG Roots 3075 1. A DODAG root without possibility to satisfy the application- 3076 defined goal MUST NOT set the Grounded bit. 3078 2. A DODAG root MUST advertise a rank of ROOT_RANK. 3080 3. A node whose DODAG parent set is empty MAY become the DODAG Root 3081 of a floating DODAG. It MAY also set its DAGPreference such that 3082 it is less preferred. 3084 In a deployment that uses non-RPL links to federate a number of LLN 3085 roots, it is possible to run RPL over those non-RPL links and use one 3086 router as a "backbone root". The backbone root is the virtual root 3087 of the DODAG, and exposes a rank of BASE_RANK over the backbone. All 3088 the LLN roots that are parented to that backbone root, including the 3089 backbone root if it also serves as LLN root itself, expose a rank of 3090 ROOT_RANK to the LLN. These virtual roots are part of the same DODAG 3091 and advertise the same DODAGID. They coordinate DODAGVersionNumbers 3092 and other DODAG parameters with the virtual root over the backbone. 3093 The method of coordination is out of scope for this specification (to 3094 be defined in future companion specifications). 3096 8.2.2.3. DODAG Selection 3098 The objective function and the set of advertised routing metrics and 3099 constraints of a DAG determines how a node selects its neighbor set, 3100 parent set, and preferred parents. This selection implicitly also 3101 determines the DODAG within a DAG. Such selection can include 3102 administrative preference (Prf) as well as metrics or other 3103 considerations. 3105 If a node has the option to join a more preferred DODAG while still 3106 meeting other optimization objectives, then the node will generally 3107 seek to join the more preferred DODAG as determined by the OF. All 3108 else being equal, it is left to the implementation to determine which 3109 DODAG is most preferred (since, as a reminder, a node must only join 3110 one DODAG per RPL Instance). 3112 8.2.2.4. Rank and Movement within a DODAG Version 3114 1. A node MUST NOT advertise a Rank less than or equal to any member 3115 of its parent set within the DODAG Version. 3117 2. A node MAY advertise a Rank lower than its prior advertisement 3118 within the DODAG Version. 3120 3. Let L be the lowest rank within a DODAG Version that a given node 3121 has advertised. Within the same DODAG Version, that node MUST 3122 NOT advertise an effective rank higher than L + 3123 DAGMaxRankIncrease. INFINITE_RANK is an exception to this rule: 3124 a node MAY advertise an INFINITE_RANK within a DODAG version 3125 without restriction. If a node's Rank were to be higher than 3126 allowed by L + DAGMaxRankIncrease, when it advertises Rank it 3127 MUST advertise its Rank as INFINITE_RANK. 3129 4. A node MAY, at any time, choose to join a different DODAG within 3130 a RPL Instance. Such a join has no rank restrictions, unless 3131 that different DODAG is a DODAG Version of which this node has 3132 previously been a member, in which case the rule of the previous 3133 bullet (3) must be observed. Until a node transmits a DIO 3134 indicating its new DODAG membership, it MUST forward packets 3135 along the previous DODAG. 3137 5. A node MAY, at any time after hearing the next DODAGVersionNumber 3138 advertised from suitable DODAG parents, choose to migrate to the 3139 next DODAG Version within the DODAG. 3141 Conceptually, an implementation is maintaining a DODAG parent set 3142 within the DODAG Version. Movement entails changes to the DODAG 3143 parent set. Moving Up does not present the risk to create a loop but 3144 moving Down might, so that operation is subject to additional 3145 constraints. 3147 When a node migrates to the next DODAG Version, the DODAG parent set 3148 needs to be rebuilt for the new Version. An implementation could 3149 defer to migrate for some reasonable amount of time, to see if some 3150 other neighbors with potentially better metrics but higher rank 3151 announce themselves. Similarly, when a node jumps into a new DODAG 3152 it needs to construct a new DODAG parent set for this new DODAG. 3154 If a node needs to move Down a DODAG that it is attached to, 3155 increasing its Rank, then it MAY poison its routes and delay before 3156 moving as described in Section 8.2.2.5. 3158 A node is allowed to join any DODAG Version that it has never been a 3159 prior member of without any restrictions, but if the node has been a 3160 prior member of the DODAG Version then it must continue to observe 3161 the rule that it may not advertise a rank higher than 3162 L+DAGMaxRankIncrease at any point in the life of the DODAG Version. 3163 This rule must be observed so as not to create a loophole that would 3164 allow the node to effectively increment its rank all the way to 3165 INFINITE_RANK, which may have impact on other nodes and create a 3166 resource-wasting count-to-infinity scenario. 3168 8.2.2.5. Poisoning 3170 1. A node poisons routes by advertising a Rank of INFINITE_RANK. 3172 2. A node MUST NOT have any nodes with a Rank of INFINITE_RANK in 3173 its parent set. 3175 Although an implementation may advertise INFINITE_RANK for the 3176 purposes of poisoning, doing so is not the same as setting Rank to 3177 INFINITE_RANK. For example, a node may continue to send data packets 3178 whose RPL Packet Information includes a Rank that is not 3179 INFINITE_RANK, yet still advertise INFINITE_RANK in its DIOs. 3181 When a (former) parent is observed to advertise a Rank of 3182 INFINITE_RANK, that (former) parent has detached from the DODAG and 3183 is no longer able to act as a parent, nor is there any way that 3184 another node may be considered to have a Rank greater-than 3185 INFINITE_RANK. Therefore that (former) parent cannot act as a parent 3186 any longer and is removed from the parent set. 3188 8.2.2.6. Detaching 3190 1. A node unable to stay connected to a DODAG within a given DODAG 3191 Version, i.e. that cannot retain non-empty parent set without 3192 violating the rules of this specification, MAY detach from this 3193 DODAG Version. A node that detaches becomes root of its own 3194 floating DODAG and SHOULD immediately advertise this new 3195 situation in a DIO as an alternate to poisoning. 3197 8.2.2.7. Following a Parent 3199 1. If a node receives a DIO from one of its DODAG parents, 3200 indicating that the parent has left the DODAG, that node SHOULD 3201 stay in its current DODAG through an alternative DODAG parent, if 3202 possible. It MAY follow the leaving parent. 3204 A DODAG parent may have moved, migrated to the next DODAG Version, or 3205 jumped to a different DODAG. A node ought to give some preference to 3206 remaining in the current DODAG, if possible via an alternate parent, 3207 but ought to follow the parent if there are no other options. 3209 8.2.3. DIO Message Communication 3211 When an DIO message is received, the receiving node must first 3212 determine whether or not the DIO message should be accepted for 3213 further processing, and subsequently present the DIO message for 3214 further processing if eligible. 3216 1. If the DIO message is malformed, then the DIO message is not 3217 eligible for further processing and a node MUST silently discard 3218 it. (See Section 18 for error logging). 3220 2. If the sender of the DIO message is a member of the candidate 3221 neighbor set and the DIO message is not malformed, the node MUST 3222 process the DIO. 3224 8.2.3.1. DIO Message Processing 3226 As DIO messages are received from candidate neighbors, the neighbors 3227 may be promoted to DODAG parents by following the rules of DODAG 3228 discovery as described in Section 8.2. When a node places a neighbor 3229 into the DODAG parent set, the node becomes attached to the DODAG 3230 through the new DODAG parent node. 3232 The most preferred parent should be used to restrict which other 3233 nodes may become DODAG parents. Some nodes in the DODAG parent set 3234 may be of a rank less than or equal to the most preferred DODAG 3235 parent. (This case may occur, for example, if an energy constrained 3236 device is at a lesser rank but should be avoided as per an 3237 optimization objective, resulting in a more preferred parent at a 3238 greater rank). 3240 8.3. DIO Transmission 3242 RPL nodes transmit DIOs using a Trickle timer 3243 ([I-D.ietf-roll-trickle]). A DIO from a sender with a lesser DAGRank 3244 that causes no changes to the recipient's parent set, preferred 3245 parent, or Rank SHOULD be considered consistent with respect to the 3246 Trickle timer. 3248 The following packets and events MUST be considered inconsistencies 3249 with respect to the Trickle timer, and cause the Trickle timer to 3250 reset: 3252 o When a node detects an inconsistency when forwarding a packet, as 3253 detailed in Section 11.2. 3255 o When a node receives a multicast DIS message without a Solicited 3256 Information option, unless a DIS flag restricts this behavior. 3258 o When a node receives a multicast DIS with a Solicited Information 3259 option and the node matches all of the predicates in the Solicited 3260 Information option, unless a DIS flag restricts this behavior. 3262 o When a node joins a new DODAG Version (e.g. by updating its 3263 DODAGVersionNumber, joining a new RPL Instance, etc.). 3265 Note that this list is not exhaustive, and an implementation MAY 3266 consider other messages or events to be inconsistencies. 3268 A node SHOULD NOT reset its DIO trickle timer in response to unicast 3269 DIS messages. When a node receives a unicast DIS without a Solicited 3270 Information option, it MUST unicast a DIO to the sender in response. 3271 This DIO MUST include a DODAG Configuration option. When a node 3272 receives a unicast DIS message with a Solicited Information option 3273 and matches the predicates of that Solicited Information option, it 3274 MUST unicast a DIO to the sender in response. This unicast DIO MUST 3275 include a DODAG Configuration Option. Thus a node MAY transmit a 3276 unicast DIS message to a potential DODAG parent in order to probe for 3277 DODAG Configuration and other parameters. 3279 8.3.1. Trickle Parameters 3281 The configuration parameters of the trickle timer are specified as 3282 follows: 3284 Imin: learned from the DIO message as (2^DIOIntervalMin)ms. The 3285 default value of DIOIntervalMin is DEFAULT_DIO_INTERVAL_MIN. 3287 Imax: learned from the DIO message as DIOIntervalDoublings. The 3288 default value of DIOIntervalDoublings is 3289 DEFAULT_DIO_INTERVAL_DOUBLINGS. 3291 k: learned from the DIO message as DIORedundancyConstant. The 3292 default value of DIORedundancyConstant is 3293 DEFAULT_DIO_REDUNDANCY_CONSTANT. In RPL, when k has the value 3294 of 0x00 this is to be treated as a redundancy constant of 3295 infinity in RPL, i.e. Trickle never suppresses messages. 3297 8.4. DODAG Selection 3299 The DODAG selection is implementation and OF dependent. In order to 3300 limit erratic movements, and all metrics being equal, nodes SHOULD 3301 keep their previous selection. Also, nodes SHOULD provide a means to 3302 filter out a parent whose availability is detected as fluctuating, at 3303 least when more stable choices are available. 3305 When connection to a grounded DODAG is not possible or preferable for 3306 security or other reasons, scattered DODAGs MAY aggregate as much as 3307 possible into larger DODAGs in order to allow connectivity within the 3308 LLN. 3310 A node SHOULD verify that bidirectional connectivity and adequate 3311 link quality is available with a candidate neighbor before it 3312 considers that candidate as a DODAG parent. 3314 8.5. Operation as a Leaf Node 3316 In some cases a RPL node may attach to a DODAG as a leaf node only. 3317 One example of such a case is when a node does not understand or does 3318 not support (policy) the RPL Instance's OF or advertised metric/ 3319 constraint. As specified in Section 18.6 related to policy function, 3320 the node may either join the DODAG as a leaf node or may not join the 3321 DODAG. As mentioned in Section 18.5, it is then recommended to log a 3322 fault. 3324 A leaf node does not extend DODAG connectivity but in some cases the 3325 leaf node may still need to transmit DIOs on occasion, in particular 3326 when the leaf node may not have always been acting as a leaf node and 3327 an inconsistency is detected. 3329 A node operating as a leaf node must obey the following rules: 3331 1. It MUST NOT transmit DIOs containing the DAG Metric Container. 3333 2. Its DIOs MUST advertise a DAGRank of INFINITE_RANK. 3335 3. It MAY suppress DIO transmission, unless the DIO transmission has 3336 been triggered due to detection of inconsistency when a packet is 3337 being forwarded or in response to a unicast DIS message, in which 3338 case the DIO transmission MUST NOT be suppressed. 3340 4. It MAY transmit unicast DAOs as described in Section 9.2. 3342 5. It MAY transmit multicast DAOs to the '1 hop' neighborhood as 3343 described in Section 9.10. 3345 A particular case that requires a leaf node to send a DIO is if that 3346 leaf node was a prior member of another DODAG and another node 3347 forwards a message assuming the old topology, triggering an 3348 inconsistency. The leaf node needs to transmit a DIO in order to 3349 repair the inconsistency. Note that due to the lossy nature of LLNs, 3350 even though the leaf node may have optimistically poisoned its routes 3351 by advertising a rank of INFINITE_RANK in the old DODAG prior to 3352 becoming a leaf node, that advertisement may have become lost and a 3353 leaf node must be capable to send a DIO later in order to repair the 3354 inconsistency. 3356 In the general case, the leaf node MUST NOT advertise itself as a 3357 router (i.e. send DIOs). 3359 8.6. Administrative Rank 3361 In some cases it might be beneficial to adjust the rank advertised by 3362 a node beyond that computed by the OF based on some implementation 3363 specific policy and properties of the node. For example, a node that 3364 has limited battery should be a leaf unless there is no other choice, 3365 and may then augment the rank computation specified by the OF in 3366 order to expose an exaggerated rank. 3368 9. Downward Routes 3370 This section describes how RPL discovers and maintains downward 3371 routes. RPL constructs and maintains downward routes with 3372 Destination Advertisement Object (DAO) messages. Downward routes 3373 support P2MP flows, from the DODAG roots toward the leaves. Downward 3374 routes also support P2P flows: P2P messages can flow toward a DODAG 3375 Root (or a common ancestor) through an upward route, then away from 3376 the DODAG Root to a destination through a downward route. 3378 This specification describes the two modes a RPL Instance may choose 3379 from for maintaining downward routes. In the first mode, called 3380 "storing", nodes store downward routing tables for their sub-DODAG. 3381 Each hop on a downward route in a storing network examines its 3382 routing table to decide on the next hop. In the second mode, called 3383 "non-storing", nodes do not store downward routing tables. Downward 3384 packets are routed with source routes populated by a DODAG Root 3385 [I-D.ietf-6man-rpl-routing-header]. 3387 RPL allows a simple one-hop P2P optimization for both storing and 3388 non-storing networks. A node may send a P2P packet destined to a 3389 one-hop neighbor directly to that node. 3391 9.1. Destination Advertisement Parents 3393 To establish downward routes, RPL nodes send DAO messages upwards. 3394 The next hop destinations of these DAO messages are called DAO 3395 parents. The collection of a node's DAO parents is called the DAO 3396 parent set. 3398 1. A node MAY send DAO messages using the all-RPL-nodes multicast 3399 address, which is an optimization to provision one-hop routing. 3400 The 'K' bit MUST be cleared on transmission of the multicast DAO. 3402 2. A node's DAO parent set MUST be a subset of its DODAG parent set. 3404 3. In storing mode operation, a node MUST NOT address unicast DAO 3405 messages to nodes that are not DAO parents. 3407 4. In storing mode operation, the IPv6 source and destination 3408 addresses of a DAO message MUST be link-local addresses. 3410 5. In non-storing mode operation, a node MUST NOT address unicast 3411 DAO messages to nodes that are not DODAG roots. 3413 6. In non-storing mode operation, the IPv6 source and destination 3414 addresses of a DAO message MUST be a unique-local or a global 3415 addresses. 3417 The selection of DAO parents is implementation and objective function 3418 specific. 3420 9.2. Downward Route Discovery and Maintenance 3422 Destination Advertisement may be configured to be entirely disabled, 3423 or operate in either a storing or non-storing mode, as reported in 3424 the MOP in the DIO message. 3426 1. All nodes who join a DODAG MUST abide by the MOP setting from the 3427 root. Nodes that do not have the capability to fully participate 3428 as a router, e.g. that does not match the advertised MOP, MAY 3429 join the DODAG as a leaf. 3431 2. If the MOP is 0, indicating no downward routing, nodes MUST NOT 3432 transmit DAO messages, and MAY ignore DAO messages. 3434 3. In non-storing mode, the DODAG Root SHOULD store source routing 3435 table entries for destinations learned from DAOs. The DODAG Root 3436 MUST be able to generate source routes for those destinations 3437 learned from DAOs which were stored. 3439 4. In storing mode, all non-root, non-leaf nodes MUST store routing 3440 table entries for destinations learned from DAOs. 3442 A DODAG can have one of several possible modes of operation, as 3443 defined by the MOP field. Either it does not support downward 3444 routes, it supports downward routes through source routing from DODAG 3445 Roots, or it supports downward routes through in-network routing 3446 tables. 3448 When downward routes are supported through source routing from DODAG 3449 Roots, it is generally expected that the DODAG Root has stored the 3450 source routing information learned from DAOs in order to construct 3451 the source routes. If the DODAG Root fails to store some 3452 information, then some destinations may be unreachable. 3454 When downward routes are supported through in-network routing tables, 3455 the multicast operation defined in this specification may or may not 3456 be supported, also as indicated by the MOP field. 3458 When downward routes are supported through in-network routing tables 3459 as described in this specification, it is expected that nodes acting 3460 as routers have been provisioned sufficiently to hold the required 3461 routing table state. If a node acting as a router is unable to hold 3462 the full routing table state then the routing state is not complete, 3463 messages may be dropped as a consequence, and a fault may be logged 3464 (Section 18.5). Future extensions to RPL may elaborate on refined 3465 actions/behaviors to manage this case. 3467 As of this specification RPL does not support mixed-mode operation, 3468 where some nodes source route and other store routing tables: future 3469 extensions to RPL may support this mode of operation. 3471 9.2.1. Maintenance of Path Sequence 3473 For each Target that is associated with (owned by) a node, that node 3474 is responsible to emit DAO messages in order to provision the 3475 downward routes. The Target+Transit information contained in those 3476 DAO messages subsequently propagates Up the DODAG. The Path Sequence 3477 counter in the Transit information option is used to indicate 3478 freshness and update stale downward routing information as described 3479 in Section 7. 3481 For a Target that is associated with (owned by) a node, that node 3482 MUST increment the Path Sequence counter, and generate a new DAO 3483 message, when: 3485 1. The Path Lifetime is to be updated (e.g. a refresh or a no-Path) 3487 2. The Parent Address list is to be changed 3489 For a Target that is associated with (owned by) a node, that node MAY 3490 increment the Path Sequence counter, and generate a new DAO message, 3491 on occasion in order to refresh the downward routing information. In 3492 storing mode, the node generates such DAO to each of its DAO parents 3493 in order to enable multipath. All DAOs generated at the same time 3494 for a same target MUST be sent with the same path sequence in the 3495 transit information. 3497 9.2.2. Generation of DAO Messages 3499 A node might send DAO messages when it receives DAO messages, as a 3500 result of changes in its DAO parent set, or in response to another 3501 event such as the expiry of a related prefix lifetime. In the case 3502 of receiving DAOs, it matters whether the DAO message is "new," or 3503 contains new information. In non-storing mode, every DAO message a 3504 node receives is "new." In storing mode, a DAO message is "new" if 3505 it satisfies any of these criteria for a contained Target: 3507 1. it has a newer Path Sequence number, 3509 2. it has additional Path Control bits, or 3511 3. is a No-Path DAO message that removes the last downward route to 3512 a prefix. 3514 A node that receives a DAO message from its sub-DODAG MAY suppress 3515 scheduling a DAO message transmission if that DAO message is not new. 3517 9.3. DAO Base Rules 3519 1. If a node sends a DAO message with newer or different information 3520 than the prior DAO message transmission, it MUST increment the 3521 DAOSequence field by at least one. A DAO message transmission 3522 that is identical to the prior DAO message transmission MAY 3523 increment the DAOSequence field. 3525 2. The RPLInstanceID and DODAGID fields of a DAO message MUST be the 3526 same value as the members of the node's parent set and the DIOs 3527 it transmits. 3529 3. A node MAY set the 'K' flag in a unicast DAO message to solicit a 3530 unicast DAO-ACK in response in order to confirm the attempt. 3532 4. A node receiving a unicast DAO message with the 'K' flag set 3533 SHOULD respond with a DAO-ACK. A node receiving a DAO message 3534 without the 'K' flag set MAY respond with a DAO-ACK, especially 3535 to report an error condition. 3537 5. A node that sets the 'K' flag in a unicast DAO message but does 3538 not receive a DAO-ACK in response MAY reschedule the DAO message 3539 transmission for another attempt, up until an implementation- 3540 specific number of retries. 3542 6. Nodes SHOULD ignore DAOs without newer sequence numbers and MUST 3543 NOT process them further. 3545 Unlike the Version field of a DIO, which is incremented only by a 3546 DODAG Root and repeated unchanged by other nodes, DAOSequence values 3547 are unique to each node. The sequence number space for unicast and 3548 multicast DAO messages can be either the same or distinct. It is 3549 RECOMMENDED to use the same sequence number space. 3551 9.4. Structure of DAO Messages 3553 DAOs follow a common structure in both storing and non-storing 3554 networks. In the most general form, a DAO message may include 3555 several groups of options, where each group consists of one or more 3556 Target options followed by one or more Transit Information options. 3557 The entire group of Transit Information options applies to the entire 3558 group of Target options. Later sections describe further details for 3559 each mode of operation. 3561 1. RPL nodes MUST include one or more RPL Target Options in each DAO 3562 message they transmit. One RPL Target Option MUST have a prefix 3563 that includes the node's IPv6 address if that node needs the 3564 DODAG to provision downward routes to that node. The RPL Target 3565 Option MAY be immediately followed by an opaque RPL Target 3566 Descriptor Option that qualifies it. 3568 2. When a node updates the information in a Transit Information 3569 option for a Target option that covers one of its addresses, it 3570 MUST increment the Path Sequence number in that Transit 3571 Information option. The Path Sequence number MAY be incremented 3572 occasionally to cause a refresh to the downward routes. 3574 3. One or more RPL Target Option in a unicast DAO message MUST be 3575 followed by one or more Transit Information Option. All the 3576 transit options apply to all the target options that immediately 3577 precede them. 3579 4. Multicast DAOs MUST NOT include the Parent Address in Transit 3580 Information options. 3582 5. A node that receives and processes a DAO message containing 3583 information for a specific Target, and that has prior information 3584 for that Target, MUST use the Path Sequence number in the Transit 3585 Information option associated with that Target in order to 3586 determine whether or not the DAO message contains updated 3587 information as per Section 7. 3589 6. If a node receives a DAO message that does not follow the above 3590 rules, it MUST discard the DAO message without further 3591 processing. 3593 In non-storing mode, the root builds a strict source routing header, 3594 hop-by-hop, by recursively looking up one-hop information that ties a 3595 target (address or prefix) and a transit address together. In some 3596 cases, when a child address is derived from a prefix that is owned 3597 and advertised by a parent, that parent-child relationship may be 3598 inferred by the root for the purpose of constructing the source 3599 routing header. In all other cases it is necessary to inform the 3600 root of the transit-target relationship from a reachable target, so 3601 as to later enable the recursive construction of the routing header. 3602 An address that is advertised as target in a DAO message MUST be 3603 collocated in the same router, or reachable onlink by the router that 3604 owns the address that is indicated in the associated transit 3605 information. The following additional rules apply to ensure the 3606 continuity of the end-to-end source route path: 3608 1. The address of a parent used in the transit option MUST be taken 3609 from a PIO from that parent with the 'R' flag set. The 'R' flag 3610 in a PIO indicates that the prefix field actually contains the 3611 full parent address but the child SHOULD NOT assume that the 3612 parent address is onlink. 3614 2. A PIO with a 'A' flag set indicates that the RPL child node may 3615 use the prefix to autoconfigure an address. A parent that 3616 advertises a prefix in a PIO with the 'A' flag set MUST ensure 3617 that the address or the whole prefix in the PIO is reachable from 3618 the root by advertising it as a DAO target. If the parent also 3619 sets the 'L' flag indicating that the prefix is onlink, then it 3620 MUST advertise the whole prefix as target in a DAO message. If 3621 the 'L' flag is cleared, indicating a subnet operation, and the 3622 'R' flag is set, indicating that the parent provides its own 3623 address in the PIO, then the parent MUST advertise that address 3624 as a DAO target. 3626 3. An address that is advertised as target in a DAO message MUST be 3627 collocated in the same router or reachable onlink by the router 3628 that owns the address that is indicated in the associated transit 3629 information. 3631 4. In order to enable an optimum compression of the routing header, 3632 the parent SHOULD set the 'R' flag in all PIOs with the 'A' flag 3633 set and the 'L' flag cleared, and the child SHOULD prefer to use 3634 as transit the address of the parent that is found in the PIO 3635 that is used to autoconfigure the address that is advertised as 3636 target in the DAO message. 3638 5. A router might have targets that are not known to be on-link for 3639 a parent, either because they are addresses located on an 3640 alternate interface or because they belong to nodes that are 3641 external to RPL, for instance connected hosts. In order to 3642 inject such a target in the RPL network, the router MUST 3643 advertise itself as the Parent Address in the Transit Information 3644 option for that target, using an address that is on-link for that 3645 nodes DAO parent. If the target belongs to an external node then 3646 the router MUST set the External 'E' flag in the transit 3647 information. 3649 A child node that has autoconfigured an address from a parent PIO 3650 with the 'L' flag set does not need to advertise that address as a 3651 DAO target since the parent insures that the whole prefix is already 3652 reachable from the root. But if the 'L' flag is not set then it is 3653 necessary in non-storing mode for the child node to inform the root 3654 of the parent-child relationship, using a reachable address of the 3655 parent, so as to enable the recursive construction of the routing 3656 header. This is done by associating an address of the parent as 3657 transit with the address of the child as target in a DAO message. 3659 9.5. DAO Transmission Scheduling 3661 Because DAOs flow upwards, receiving a unicast DAO can trigger 3662 sending a unicast DAO to a DAO parent. 3664 1. On receiving a unicast DAO message with updated information, such 3665 as containing a Transit Information option with a new Path 3666 Sequence, a node SHOULD send a DAO. It SHOULD NOT send this DAO 3667 message immediately. It SHOULD delay sending the DAO message in 3668 order to aggregate DAO information from other nodes for which it 3669 is a DAO parent. 3671 2. A node SHOULD delay sending a DAO message with a timer 3672 (DelayDAO). Receiving a DAO message starts the DelayDAO timer. 3673 DAO messages received while the DelayDAO timer is active do not 3674 reset the timer. When the DelayDAO timer expires, the node sends 3675 a DAO. 3677 3. When a node adds a node to its DAO parent set, it SHOULD schedule 3678 a DAO message transmission. 3680 DelayDAO's value and calculation is implementation-dependent. A 3681 default value of DEFAULT_DAO_DELAY is defined in this specification. 3683 9.6. Triggering DAO Messages 3685 Nodes can trigger their sub-DODAG to send DAO messages. Each node 3686 maintains a DAO Trigger Sequence Number (DTSN), which it communicates 3687 through DIO messages. 3689 1. If a node hears one of its DAO parents increment its DTSN, the 3690 node MUST schedule a DAO message transmission using rules in 3691 Section 9.3 and Section 9.5. 3693 2. In non-storing mode, if a node hears one of its DAO parents 3694 increment its DTSN, the node MUST increment its own DTSN. 3696 In a storing mode of operation, as part of routine routing table 3697 updates and maintenance, a storing node MAY increment DTSN in order 3698 to reliably trigger a set of DAO updates from its immediate children. 3699 In a storing mode of operation it is not necessary to trigger DAO 3700 updates from the entire sub-DODAG, since that state information will 3701 propagate hop-by-hop Up the DODAG. 3703 In a non-storing mode of operation, a DTSN increment will also cause 3704 the immediate children of a node to increment their DTSN in turn, 3705 triggering a set of DAO updates from the entire sub-DODAG. In a non- 3706 storing mode of operation typically only the root would independently 3707 increment the DTSN when a DAO refresh is needed but a global repair 3708 (such as by incrementing DODAGVersionNumber) is not desired. In a 3709 non-storing mode of operation typically all non-root nodes would 3710 increment their DTSN only when their parent(s) are observed to do so. 3712 In the general, a node may trigger DAO updates according to 3713 implementation specific logic, such as based on the detection of a 3714 downward route inconsistency or occasionally based upon an internal 3715 timer. 3717 In the case of triggered DAOs, selecting a proper DAODelay can 3718 greatly reduce the number of DAOs transmitted. The trigger flows 3719 Down the DODAG; in the best case the DAOs flow Up the DODAG such that 3720 leaves send DAOs first, with each node sending a DAO message only 3721 once. Such a scheduling could be approximated by setting DAODelay 3722 inversely proportional to Rank. Note that this suggestion is 3723 intended as an optimization to allow efficient aggregation (it is not 3724 required for correct operation in the general case). 3726 9.7. Non-storing Mode 3728 In non-storing mode, RPL routes messages downward using IP source 3729 routing. The following rule applies to nodes that are in non-storing 3730 mode. Storing mode has a separate set of rules, described in 3731 Section 9.8. 3733 1. The Parent Address field of a Transit Information Option MUST 3734 contain one or more addresses. All of these addresses MUST be 3735 addresses of DAO parents of the sender. 3737 2. DAOs are sent directly to the root along a default route 3738 installed as part of the parent selection. 3740 3. When a node removes a node from its DAO parent set, it MAY 3741 generate a new DAO message with an updated Transit Information 3742 option. 3744 In non-storing mode, a node uses DAOs to report its DAO parents to 3745 the DODAG Root. The DODAG Root can piece together a downward route 3746 to a node by using DAO parent sets from each node in the route. The 3747 Path Sequence information may be used to detect stale DAO 3748 information. The purpose of this per-hop route calculation is to 3749 minimize traffic when DAO parents change. If nodes reported complete 3750 source routes, then on a DAO parent change the entire sub-DODAG would 3751 have to send new DAOs to the DODAG Root. Therefore, in non-storing 3752 mode, a node can send a single DAO, although it might choose to send 3753 more than one DAO message to each of multiple DAO parents. 3755 Nodes pack DAOs by sending a single DAO message with multiple RPL 3756 Target Options. Each RPL Target Option has its own, immediately 3757 following, Transit Information options. 3759 9.8. Storing Mode 3761 In storing mode, RPL routes messages downward by the IPv6 destination 3762 address. The following rule apply to nodes that are in storing mode: 3764 1. The Parent Address field of a Transmit Information option MUST be 3765 empty. 3767 2. On receiving a unicast DAO, a node MUST compute if the DAO would 3768 change the set of prefixes that the node itself advertises. This 3769 computation SHOULD include consultation of the Path Sequence 3770 information in the Transit Information options associated with 3771 the DAO, to determine if the DAO message contains newer 3772 information that supersedes the information already stored at the 3773 node. If so, the node MUST generate a new DAO message and 3774 transmit it, following the rules in Section 9.5. Such a change 3775 includes receiving a No-Path DAO. 3777 3. When a node generates a new DAO, it SHOULD unicast it to each of 3778 its DAO parents. It MUST NOT unicast the DAO message to nodes 3779 that are not DAO parents. 3781 4. When a node removes a node from its DAO parent set, it SHOULD 3782 send a No-Path DAO message (Section 6.4.3) to that removed DAO 3783 parent to invalidate the existing route. 3785 5. If messages to an advertised downwards address suffer from a 3786 forwarding error, neighbor unreachable detected (NUD), or similar 3787 failure, a node MAY mark the address as unreachable and generate 3788 an appropriate No-Path DAO. 3790 DAOs advertise what destination addresses and prefixes a node has 3791 routes to. Unlike in non-storing mode, these DAOs do not communicate 3792 information about the routes themselves: that information is stored 3793 within the network and is implicit from the IPv6 source address. 3794 When a storing node generates a DAO, it uses the stored state of DAOs 3795 it has received to produce a set of RPL Target options and their 3796 associated Transmit Information options. 3798 Because this information is stored within each node's routing tables, 3799 in storing mode DAOs are communicated directly to DAO parents, who 3800 store this information. 3802 9.9. Path Control 3804 A DAO message from a node contains one or more Target Options. Each 3805 Target Option specifies either a prefix advertised by the node, a 3806 prefix of addresses reachable outside the LLN, the address of 3807 destination in the node's sub-DODAG, or a multicast group that a node 3808 in the sub-DODAG is listening to. The Path Control field of the 3809 Transit Information option allows nodes to request or allow for 3810 multiple downward routes. A node constructs the Path Control field 3811 of a Transit Information option as follows: 3813 1. The bit width of the path control field MUST be equal to the 3814 value (PCS + 1), where PCS is specified in the control field of 3815 the DODAG Configuration Option. Bits greater than or equal to 3816 the value (PCS + 1) MUST be cleared on transmission and MUST be 3817 ignored on reception. Bits below that value are considered 3818 "active" bits. 3820 2. The node MUST logically construct groupings of its DAO parents 3821 while populating the Path Control field, where each group 3822 consists of DAO parents of equal preference. Those groups MUST 3823 then be ordered according to preference, which allows for a 3824 logical mapping of DAO parents onto Path Control subfields (See 3825 Figure 27). Groups MAY be repeated in order to extend over the 3826 entire bit width of the patch control field, but the order, 3827 including repeated groups, MUST be retained so that preference is 3828 properly communicated. 3830 3. For a RPL Target option describing a node's own address or a 3831 prefix outside the LLN, at least one active bit of the Path 3832 Control field MUST be set. More active bits of the Path Control 3833 field MAY be set. 3835 4. If a node receives multiple DAOs with the same RPL Target option, 3836 it MUST bitwise-OR the Path Control fields it receives. This 3837 aggregated bitwise-OR represents the number of downward routes 3838 the prefix requests. 3840 5. When a node sends a DAO message to one of its DAO parents, it 3841 MUST select one or more of the bits that are set active in the 3842 subfield that is mapped to the group containing that DAO parent 3843 from the aggregated Path Control field. A given bit can only be 3844 presented as active to one parent. The DAO message it transmits 3845 to its parent MUST have these active bits set and all other 3846 active bits cleared. 3848 6. For the RPL Target option and DAOSequence number, the DAOs a node 3849 sends to different DAO parents MUST have disjoint sets of active 3850 Path Control bits. A node MUST NOT set the same active bit on 3851 DAOs to two different DAO parents. 3853 7. Path control bits SHOULD be allocated according to the preference 3854 mapping of DAO parents onto Path Control subfields, such that the 3855 active Path Control bits, or groupings of bits, that belong to a 3856 particular Path Control subfield are allocated to DAO parents 3857 within the group that was mapped to that subfield. 3859 8. In a non-storing mode of operation, a node MAY pass DAOs through 3860 without performing any further processing on the Path Control 3861 field. 3863 9. A node MUST NOT unicast a DAO message that has no active bits in 3864 the Path Control field set. It is possible that, for a given 3865 Target option, that a node does not have enough aggregate Path 3866 Control bits to send a DAO message containing that Target to each 3867 of its DAO Parents, in which case those least preferred DAO 3868 Parents may not get a DAO message for that Target. 3870 The Path Control field allows a node to bound how many downward 3871 routes will be generated to it. It sets a number of bits in the Path 3872 Control field equal to the maximum number of downward routes it 3873 prefers. Each bit is sent to at most one DAO parent; clusters of 3874 bits can be sent to a single DAO parent for it to divide among its 3875 own DAO parents. 3877 A node that provisions a DAO route for a Target that has an 3878 associated Path Control field SHOULD use the content of that Path 3879 Control field in order to determine an order of preference among 3880 multiple alternative DAO routes for that Target. The Path Control 3881 field assignment is derived from preference (of the DAO parents), as 3882 determined on the basis of this node's best knowledge of the "end-to- 3883 end" aggregated metrics in the "downward" direction as per the 3884 objective function. In non storing mode the root can determine the 3885 downward route by aggregating the information from each received DAO, 3886 which includes the Path Control indications of preferred DAO parents. 3888 9.9.1. Path Control Example 3890 Suppose that there is an LLN operating in storing mode that contains 3891 a Node N with four parents, P1, P2, P3, and P4. Let N have three 3892 children, C1, C2, and C3 in its sub-DODAG. Let PCS be 7, such that 3893 there will be 8 active bits in the Path Control field: 11111111b. 3894 Consider the following example: 3896 The Path Control field is split into 4 subfields, PC1 (11000000b), 3897 PC2 (00110000b), PC3 (00001100b), and PC4 (00000011b), such that 3898 those 4 subfields represent 4 different levels of preference as per 3899 Figure 27. The implementation at Node N, in this example, groups 3900 {P1, P2} to be of equal preference to each other, and the most 3901 preferred group overall. {P3} is less preferred to {P1, P2}, and more 3902 preferred to {P4}. Let Node N then perform its path control mapping 3903 such that: 3905 {P1, P2} -> PC1 (11000000b) in the Path Control field 3906 {P3} -> PC2 (00110000b) in the Path Control field 3907 {P4} -> PC3 (00001100b) in the Path Control field 3908 {P4} -> PC4 (00000011b) in the Path Control field 3910 Note that the implementation repeated {P4} in order to get complete 3911 coverage of the Path Control field. 3913 1. Let C1 send a DAO containing a Target T with a Path Control 3914 10000000b. Node N stores an entry associating 10000000b with 3915 the Path Control field for C1 and Target T. 3917 2. Let C2 send a DAO containing a Target T with a Path Control 3918 00010000b. Node N stores an entry associating 00010000b with 3919 the Path Control field for C1 and Target T. 3921 3. Let C3 send a DAO containing a Target T with a Path Control 3922 00001100b. Node N stores an entry associating 00001100b with 3923 the Path Control field for C1 and Target T. 3925 4. At some later time, Node N generates a DAO for Target T. Node N 3926 will construct an aggregate Path Control field by ORing together 3927 the contribution from each of its children that have given a DAO 3928 for Target T. The aggregate Path Control field thus has the 3929 active bits set as: 10011100b. 3931 5. Node N then distributes the aggregate Path Control bits among 3932 its parents P1, P2, P3, and P4 in order to prepare the DAO 3933 messages. 3935 6. P1 and P2 are eligible to receive active bits from the most 3936 preferred subfield (11000000b). Those bits are 10000000b in the 3937 aggregate Path Control field. Node N must the bit to one of the 3938 two parents only. In this case, Node P1 is allocated the bit, 3939 and gets the Path Control field 10000000b for its DAO. There 3940 are no bits left to allocate to Node P2, thus Node P2 would have 3941 a Path Control field of 00000000b and a DAO cannot be generated 3942 to Node P2 since there are no active bits. 3944 7. The second-most preferred subfield (00110000b) has the active 3945 bits 00010000b. Node N has mapped P3 to this subfield. Node N 3946 may allocates the active bit to P3, constructing a DAO for P3 3947 containing Target T with a Path Control of 00010000b. 3949 8. The third-most preferred subfield (00001100b) has the active 3950 bits 00001100b. Node N has mapped P4 to this subfield. Node N 3951 may allocate both bits to P4, constructing a DAO for P4 3952 containing Target T with a Path Control of 00001100b. 3954 9. The least preferred subfield (00000011b) has no active bits. 3955 Had there been active bits, those bits would have been added to 3956 the Path Control field of the DAO constructed for P4. 3958 10. The process of populating the DAO messages destined for P1, P2, 3959 P3, P4 with other targets (other than T) proceeds as according 3960 the aggregate path control fields collected for those targets. 3962 9.10. Multicast Destination Advertisement Messages 3964 A special case of DAO operation, distinct from unicast DAO operation, 3965 is multicast DAO operation which may be used to populate '1-hop' 3966 routing table entries. 3968 1. A node MAY multicast a DAO message to the link-local scope all- 3969 RPL-nodes multicast address. 3971 2. A multicast DAO message MUST be used only to advertise 3972 information about the node itself, i.e. prefixes directly 3973 connected to or owned by the node, such as a multicast group that 3974 the node is subscribed to or a global address owned by the node. 3976 3. A multicast DAO message MUST NOT be used to relay connectivity 3977 information learned (e.g. through unicast DAO) from another node. 3979 4. A node MUST NOT perform any other DAO related processing on a 3980 received multicast DAO message, in particular a node MUST NOT 3981 perform the actions of a DAO parent upon receipt of a multicast 3982 DAO. 3984 o The multicast DAO may be used to enable direct P2P communication, 3985 without needing the DODAG to relay the packets. 3987 10. Security Mechanisms 3989 This section describes the generation and processing of secure RPL 3990 messages. The high order bit of the RPL message code identifies 3991 whether a RPL message is secure or not. In addition to secure 3992 versions of basic control messages (DIS, DIO, DAO, DAO-ACK), RPL has 3993 several messages which are relevant only in networks with security 3994 enabled. 3996 Implementation complexity and size is a core concern for LLNs such 3997 that it may be economically or physically impossible to include 3998 sophisticated security provisions in a RPL implementation. 3999 Furthermore, many deployments can utilize link-layer or other 4000 security mechanisms to meet their security requirements without 4001 requiring the use of security in RPL. 4003 Therefore, the security features described in this document are 4004 OPTIONAL to implement. A given implementation MAY support a subset 4005 (including the empty set) of the described security features, for 4006 example it could support integrity and confidentiality, but not 4007 signatures. An implementation SHOULD clearly specify which security 4008 mechanisms are supported, and it is RECOMMENDED that implementers 4009 carefully consider security requirements and the availability of 4010 security mechanisms in their network. 4012 10.1. Security Overview 4014 RPL supports three security modes: 4016 o Unsecured. In this security mode, RPL uses basic DIS, DIO, DAO, 4017 and DAO-ACK messages, which do not have security sections. As a 4018 network could be using other security mechanisms, such as link- 4019 layer security, unsecured mode does not imply all messages are 4020 sent without any protection. 4022 o Pre-installed. In this security mode, RPL uses secure messages. 4023 To join a RPL Instance, a node must have a pre-installed key. 4024 Nodes use this to provide message confidentiality, integrity, and 4025 authenticity. A node may, using this preinstalled key, join the 4026 RPL network as either a host or a router. 4028 o Authenticated. In this security mode, RPL uses secure messages. 4029 To join a RPL Instance, a node must have a pre-installed key. 4030 Nodes use this key to provide message confidentiality, integrity, 4031 and authenticity. Using this preinstalled key, a node may join 4032 the network as a host only. To join the network as a router, a 4033 node must obtain a second key from a key authority. This key 4034 authority can authenticate that the requester is allowed to be a 4035 router before providing it with the second key. Authenticated 4036 mode cannot be supported by symmetric algorithms. As of this 4037 specification, RPL supports only symmetric algorithms: 4038 authenticated mode is included for the benefit of potential future 4039 cryptographic primitives. See Section 10.3. 4041 Whether or not the RPL Instance uses unsecured mode is signaled by 4042 whether it uses secure RPL messages. Whether a secured network uses 4043 the pre-installed or authenticated mode is signaled by the 'A' bit of 4044 the DAG Configuration option. 4046 This specification specifies CCM -- Counter with CBC-MAC (Cipher 4047 Block Chaining Message Authentication Code) -- as the cryptographic 4048 basis for RPL security[RFC3610]. In this specification, CCM uses 4049 AES-128 as its underlying cryptographic algorithm. There are bits 4050 reserved in the security section to specify other algorithms in the 4051 future. 4053 All secured RPL messages have either a message authentication code 4054 (MAC) or a signature. Secured RPL messages optionally also have 4055 encryption protection for confidentiality. Secured RPL message 4056 formats support both integrated encryption/authentication schemes 4057 (e.g., CCM) as well as schemes that separately encrypt and 4058 authenticate packets. 4060 10.2. Joining a Secure Network 4062 RPL security assumes that a node wishing to join a secured network 4063 has been preconfigured with a shared key for communicating with 4064 neighbors and the RPL root. To join a secure RPL network, a node 4065 either listens for secure DIOs or triggers secure DIOs by sending a 4066 secure DIS. In addition to the DIO/DIS rules in Section 8, secure 4067 DIO and DIS messages have these rules: 4069 1. If sent, this initial secure DIS MUST set the Key Identifier Mode 4070 field to 0 (00) and MUST set the Security Level field to 1 (001). 4071 The key used MUST be the preconfigured group key (Key Index 4072 0x00). 4074 2. When a node resets its Trickle timer in response to a secure DIS 4075 (Section 8.3), the next DIO it transmits MUST be a secure DIO 4076 with the same security configuration as the secure DIS. If a 4077 node receives multiple secure DIS messages before it transmits a 4078 DIO, the secure DIO MUST have the same security configuration as 4079 the last DIS it is responding to. 4081 3. When a node sends a DIO in response to a unicast secure DIS 4082 (Section 8.3), the DIO MUST be a secure DIO. 4084 The above rules allow a node to join a secured RPL Instance using the 4085 preconfigured shared key. Once a node has joined the DODAG using the 4086 preconfigured shared key, the 'A' bit of the Configuration option 4087 determines its capabilities. If the 'A' bit of the Configuration is 4088 cleared, then nodes can use this preinstalled, shared key to exchange 4089 messages normally: it can issue DIOs, DAOs, etc. 4091 If the 'A' bit of the Configuration option is set and the RPL 4092 Instance is operating in authenticated mode: 4094 1. A node MUST NOT advertise a Rank besides INFINITE_RANK in secure 4095 DIOs secured with Key Index 0x00. When processing DIO messages 4096 secured with Key Index 0x00, a processing node MUST consider the 4097 advertised Rank to be INFINITE_RANK. Any other value results in 4098 the message being discarded. 4100 2. Secure DAOs using Key Index 0x00 MUST NOT have a RPL Target 4101 option with a prefix besides the node's address. If a node 4102 receives a secured DAO message using the preinstalled, shared key 4103 where the RPL Target option does not match the IPv6 source 4104 address, it MUST discard the secured DAO message without further 4105 processing. 4107 The above rules mean that in RPL Instances where the 'A' bit is set, 4108 using Key Index 0x00 a node can join the RPL Instance as a host but 4109 not a router. A node must communicate with a key authority to obtain 4110 a key that will enable it to act as a router. 4112 10.3. Installing Keys 4114 Authenticated mode requires a would-be router to dynamically install 4115 new keys once they have joined a network as a host. Having joined as 4116 a host, the node uses standard IP messaging to communicate with an 4117 authorization server, which can provide new keys. 4119 The protocol to obtain such keys is out of scope for this 4120 specification and to be elaborated in future specifications. That 4121 elaboration is required for RPL to securely operate in authenticated 4122 mode. 4124 10.4. Consistency Checks 4126 RPL nodes send Consistency Check (CC) messages to protect against 4127 replay attacks and synchronize counters. 4129 1. If a node receives a unicast CC message with the R bit cleared, 4130 and it is a member of or is in the process of joining the 4131 associated DODAG, it SHOULD respond with a unicast CC message to 4132 the sender. This response MUST have the R bit set, and MUST have 4133 the same CC Nonce, RPLInstanceID and DODAGID fields as the 4134 message it received. 4136 2. If a node receives a multicast CC message, it MUST discard the 4137 message with no further processing. 4139 Consistency Check messages allow nodes to issue a challenge-response 4140 to validate a node's current Counter value. Because the CC Nonce is 4141 generated by the challenger, an adversary replaying messages is 4142 unlikely to be able to generate a correct response. The Counter in 4143 the Consistency Check response allows the challenger to validate the 4144 Counter values it hears. 4146 10.5. Counters 4148 In the simplest case, the Counter value is an unsigned integer that a 4149 node increments by one or more on each secured RPL transmission. The 4150 Counter MAY represent a timestamp that has the following properties: 4152 1. The timestamp MUST be at least six octets long. 4154 2. The timestamp MUST be in 1024Hz (binary millisecond) granularity. 4156 3. The timestamp start time MUST be January 1, 1970, 12:00:00AM UTC. 4158 4. If the Counter represents such as timestamp, the Counter value 4159 MUST be a value computed as follows. Let T be the timestamp, S 4160 be the start time of the key in use, and E be the end time of the 4161 key in use. Both S and E are represented using the same 3 rules 4162 as the timestamp described above. If E > T < S, then the Counter 4163 is invalid and a node MUST NOT generate a packet. Otherwise, the 4164 Counter value is equal to T-S. 4166 5. If the Counter represents such a timestamp, a node MAY set the 4167 'T' flag of the security section of secured RPL packets. 4169 6. If the Counter field does not present such a timestamp, then a 4170 node MUST NOT set the 'T' flag. 4172 7. If a node does not have a local timestamp that satisfies the 4173 above requirements, it MUST ignore the 'T' flag. 4175 If a node supports such timestamps and it receives a message with the 4176 'T' flag set, it MAY apply the temporal check on the received message 4177 described in Section 10.7.1. If a node receives a message without 4178 the 'T' flag set, it MUST NOT apply this temporal check. A node's 4179 security policy MAY, for application reasons, include rejecting all 4180 messages without the 'T' flag set. 4182 The 'T' flag is present because many LLNs today already maintain 4183 global time synchronization at sub-millisecond granularity for 4184 security, application, and other reasons. Allowing RPL to leverage 4185 this existing functionality when present greatly simplifies solutions 4186 to some security problems, such as delay protection. 4188 10.6. Transmission of Outgoing Packets 4190 Given an outgoing RPL control packet and required security 4191 protection, this section describes how RPL generates the secured 4192 packet to transmit. It also describes the order of cryptographic 4193 operations to provide the required protection. 4195 The requirement for security protection and the level of security to 4196 be applied to an outgoing RPL packet shall be determined by the 4197 node's security policy database. The configuration of this security 4198 policy database for outgoing packet processing is implementation 4199 specific. 4201 Where secured RPL messages are to be transmitted, a RPL node MUST set 4202 the security section (T, Sec, KIM, and LVL) in the outgoing RPL 4203 packet to describe the protection level and security settings that 4204 are applied (see Section 6.1). The Security subfield bit of the RPL 4205 message Code field MUST be set to indicate the secure RPL message. 4207 The Counter value used in constructing the AES-128 CCM Nonce 4208 (Figure 31) to secure the outgoing packet MUST be an increment of the 4209 last Counter transmitted to the particular destination address. 4211 Where security policy specifies the application of delay protection, 4212 the Timestamp Counter used in constructing the CCM Nonce to secure 4213 the outgoing packet MUST be incremented according to the rules in 4214 Section 10.5. Where a Timestamp Counter is applied (indicated with 4215 the 'T' flag set) the locally maintained Time Counter MUST be 4216 included as part of the transmitted secured RPL message. 4218 The cryptographic algorithm used in securing the outgoing packet 4219 shall be specified by the node's security policy database and MUST be 4220 indicated in the value of the Sec field set within the outgoing 4221 message. 4223 The security policy for the outgoing packet shall determine the 4224 applicable Key Identifier Mode (KIM) and Key Identifier specifying 4225 the security key to be used for the cryptographic packet processing, 4226 including the optional use of signature keys (see Section 6.1). The 4227 security policy will also specify the algorithm (Algorithm) and level 4228 of protection (Level) in the form of authentication or authentication 4229 and encryption, and potential use of signatures that shall apply to 4230 the outgoing packet. 4232 Where encryption is applied, a node MUST replace the original packet 4233 payload with that payload encrypted using the security protection, 4234 key, and CCM nonce specified in the security section of the packet. 4236 All secured RPL messages include integrity protection. In 4237 conjunction with the security algorithm processing, a node derives 4238 either a Message Authentication Code (MAC) or signature that MUST be 4239 included as part of the outgoing secured RPL packet. 4241 10.7. Reception of Incoming Packets 4243 This section describes the reception and processing of a secured RPL 4244 packet. Given an incoming secured RPL packet, where the Security 4245 subfield bit of the RPL message Code field is set, this section 4246 describes how RPL generates an unencrypted variant of the packet and 4247 validates its integrity. 4249 The receiver uses the RPL security control fields to determine the 4250 necessary packet security processing. If the described level of 4251 security for the message type and originator is unknown or does not 4252 meet locally maintained security policies, a node MUST discard the 4253 packet without further processing, MAY raise a management alert, and 4254 MUST NOT send any messages in response. These policies can include 4255 security levels, keys used, source identifiers, or the lack of 4256 timestamp-based counters (as indicated by the 'T' flag). The 4257 configuration of the security policy database for incoming packet 4258 processing is out of scope for this specification (it may, for 4259 example, be defined through DIO Configuration or through out-of-band 4260 administrative router configuration). 4262 Where the message security level (LVL) indicates an encrypted RPL 4263 message, the node uses the key information identified through the KIM 4264 field as well as the CCM Nonce as input to the message payload 4265 decryption processing. The CCM Nonce shall be derived from the 4266 message Counter field and other received and locally maintained 4267 information (see Section 10.9.1). The plaintext message contents 4268 shall be obtained by invoking the inverse cryptographic mode of 4269 operation specified by the Sec field of the received packet. 4271 The receiver shall use the CCM Nonce and identified key information 4272 to check the integrity of the incoming packet. If the integrity 4273 check fails against the received message authentication code (MAC), a 4274 node MUST discard the packet. 4276 If the received message has an initialized (zero value) Counter value 4277 and the receiver has an incoming Counter currently maintained for the 4278 originator of the message, the receiver MUST initiate a Counter 4279 resynchronization by sending a Consistency Check response message 4280 (see Section 6.6) to the message source. The Consistency Check 4281 response message shall be protected with the current full outgoing 4282 Counter maintained for the particular node address. That outgoing 4283 Counter will be included within the security section of the message 4284 while the incoming Counter will be included within the Consistency 4285 Check message payload. 4287 Based on the specified security policy a node MAY apply replay 4288 protection for a received RPL message. The replay check SHOULD be 4289 performed before the authentication of the received packet. The 4290 Counter as obtained from the incoming packet shall be compared 4291 against the watermark of the incoming Counter maintained for the 4292 given origination node address. If the received message Counter 4293 value is non-zero and less than the maintained incoming Counter 4294 watermark a potential packet replay is indicated and the node MUST 4295 discard the incoming packet. 4297 If delay protection is specified as part of the incoming packet 4298 security policy checks, the Timestamp Counter is used to validate the 4299 timeliness of the received RPL message. If the incoming message 4300 Timestamp Counter value indicates a message transmission time prior 4301 to the locally maintained transmission time Counter for the 4302 originator address, a replay violation is indicated and the node MUST 4303 discard the incoming packet. If the received Timestamp Counter value 4304 indicates a message transmission time that is earlier than the 4305 Current time less the acceptable packet delay, a delay violation is 4306 indicated and the node MUST discard the incoming packet. 4308 Once a message has been decrypted, where applicable, and has 4309 successfully passed its integrity check, replay, and optionally delay 4310 protection checks, the node can update its local security 4311 information, such as the source's expected Counter value for replay 4312 comparison. 4314 A node MUST NOT update its security information on receipt of a 4315 message that fails security policy checks or other applied integrity, 4316 replay, or delay checks. 4318 10.7.1. Timestamp Key Checks 4320 If the 'T' flag of a message is set and a node has a local timestamp 4321 that follows the requirements in Section 10.5, then a node MAY check 4322 the temporal consistency of the message. The node computes the 4323 transmit time of the message by adding the Counter value to the start 4324 time of the associated key. If this transmit time is past the end 4325 time of the key, the node MAY discard the message without further 4326 processing. If the transmit time is too far in the past or future 4327 compared to the local time on the receiver, it MAY discard the 4328 message without further processing. 4330 10.8. Coverage of Integrity and Confidentiality 4332 For a RPL ICMPv6 message, the entire packet is within the scope of 4333 RPL security. 4335 Message authentication codes (MAC) and signatures are calculated over 4336 the entire unsecured IPv6 packet. When computing MACs and 4337 signatures, mutable IPv6 fields are considered to be filled with 4338 zeroes, following the rules in Section 3.3.3.1 of [RFC4302] (IPSec 4339 Authenticated Header). MAC and signature calculations are performed 4340 before any compression that lower layers may apply. 4342 When a RPL ICMPv6 message is encrypted, encryption starts at the 4343 first byte after the security section and continues to the last byte 4344 of the packet. The IPv6 header, ICMPv6 header, and RPL message up to 4345 the end of the security section are not encrypted, as they are needed 4346 to correctly decrypt the packet. 4348 For example, a node sending a message with LVL=1, KIM=0, and 4349 Algorithm=0 uses the CCM algorithm [RFC3610] to create a packet with 4350 attributes ENC-MAC-32: it encrypts the packet and appends a 32-bit 4351 MAC. The block cipher key is determined by the Key Index; the CCM 4352 Nonce is computed as described in Section 10.9.1; the message to 4353 authenticate and encrypt is the RPL message starting at the first 4354 byte after the security section and ends with the last byte of the 4355 packet; the additional authentication data starts with the beginning 4356 of the IPv6 header and ends with the last byte of the RPL security 4357 section. 4359 10.9. Cryptographic Mode of Operation 4361 The cryptographic mode of operation described in this specification 4362 (Algorithm = 0) is based on CCM and the block-cipher AES- 4363 128[RFC3610]. This mode of operation is widely supported by existing 4364 implementations. CCM mode requires a nonce (CCM nonce). 4366 10.9.1. CCM Nonce 4368 A RPL node constructs a CCM nonce as follows: 4370 0 1 2 3 4371 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 4372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4373 | | 4374 + Source Identifier + 4375 | | 4376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4377 | Counter | 4378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4379 |KIM|Resvd| LVL | 4380 +-+-+-+-+-+-+-+-+ 4382 Figure 31: CCM Nonce 4384 Source Identifier: 8 bytes. Source Identifier is set to the logical 4385 identifier of the originator of the protected packet. 4387 Counter: 4 bytes. Counter is set to the (uncompressed) value of the 4388 corresponding field in the Security option of the RPL control 4389 message. 4391 Key Identifier Mode (KIM): 2 bits. KIM is set to the value of the 4392 corresponding field in the Security option of the RPL control 4393 message. 4395 Security Level (LVL): 3 bits. Security Level is set to the value of 4396 the corresponding field in the Security option of the RPL 4397 control message. 4399 Unassigned bits of the CCM nonce are reserved. They MUST be set to 4400 zero when constructing the CCM nonce. 4402 All fields of the CCM nonce are represented in most-significant-octet 4403 and most-significant-bit first order. 4405 10.9.2. Signatures 4407 If the Key Identification Mode (KIM) mode indicates the use of 4408 signatures (a value of 3), then a node appends a signature to the 4409 data payload of the packet. The Security Level (LVL) field describes 4410 the length of this signature. 4412 The signature scheme in RPL for Security Mode 3 is an instantiation 4413 of the RSA algorithm (RSASSA-PSS) as defined in Section 8.1 of 4414 [RFC3447]. It uses as public key the pair (n,e), where n is a 2048- 4415 bit or 3072-bit RSA modulus and where e=2^{16}+1. It uses CCM mode 4416 [RFC3610] as the encryption scheme with M=0 (as a stream-cipher). 4418 Note that although [RFC3610] disallows the CCM mode with M=0, RPL 4419 explicitly allows the CCM mode with M=0 when used in conjunction with 4420 a signature, because the signature provides sufficient data 4421 authentication. Here, the CCM mode with M=0 is specified as in 4422 [RFC3610], but where the M' field in Section 2.2 MUST be set to 0. 4423 It uses the SHA-256 hash function specified in Section 6.2 of 4424 [FIPS180]. It uses the message encoding rules of Section 8.1 of 4425 [RFC3447]. 4427 Let 'a' be a concatenation of a six-byte representation of Counter 4428 and the message header. The packet payload is the right- 4429 concatenation of packet data 'm' and the signature 's'. This 4430 signature scheme is invoked with the right-concatenation of the 4431 message parts a and m, whereas the signature verification is invoked 4432 with the right-concatenation of the message parts a and m, and with 4433 signature s. 4435 RSA signatures of this form provide sufficient protection for RPL 4436 networks. If needed, alternative signature schemes which produce 4437 more concise signatures is out of scope for this specification and 4438 may be the subject of a future specification. 4440 An implementation that supports RSA signing with either 2048-bit or 4441 3072-bit signatures SHOULD support verification of both 2048-bit and 4442 3072-bit RSA signatures. This is in consideration of providing an 4443 upgrade path for a RPL deployment. 4445 11. Packet Forwarding and Loop Avoidance/Detection 4447 11.1. Suggestions for Packet Forwarding 4449 This document specifies a routing protocol. These non-normative 4450 suggestions are provided to aid in the design of a forwarding 4451 implementation by illustrating how such an implementation could work 4452 with RPL 4454 When forwarding a packet to a destination, precedence is given to 4455 selection of a next-hop successor as follows: 4457 1. This specification only covers how a successor is selected from 4458 the DODAG Version that matches the RPLInstanceID marked in the 4459 IPv6 header of the packet being forwarded. Routing outside the 4460 instance can be done as long as additional rules are put in place 4461 such as strict ordering of instances and routing protocols to 4462 protect against loops. Such rules may be defined in a separate 4463 document. 4465 2. If a local administrative preference favors a route that has been 4466 learned from a different routing protocol than RPL, then use that 4467 successor. 4469 3. If the packet header specifies a source route by including a RH4 4470 header as specified in [I-D.ietf-6man-rpl-routing-header], then 4471 use that route. If the node fails to forward the packet with 4472 that specified source route, then that packet should be dropped. 4473 The node MAY log an error. The node may send an ICMPv6 Error in 4474 Source Routing Header message to the source of the packet (See 4475 Section 20.18). 4477 4. If there is an entry in the routing table matching the 4478 destination that has been learned from a multicast destination 4479 advertisement (e.g. the destination is a one-hop neighbor), then 4480 use that successor. 4482 5. If there is an entry in the routing table matching the 4483 destination that has been learned from a unicast destination 4484 advertisement (e.g. the destination is located Down the sub- 4485 DODAG), then use that successor. If there are DAO Path Control 4486 bits associated with multiple successors, then consult the Path 4487 Control bits to order the successors by preference when choosing. 4488 If, for a given DAO Path Control bit, multiple successors are 4489 recorded as having asserted that bit, precedence should be given 4490 to the successor who most recently asserted that bit. 4492 6. If there is a DODAG Version offering a route to a prefix matching 4493 the destination, then select one of those DODAG parents as a 4494 successor according to the OF and routing metrics. 4496 7. Any other as-yet-unattempted DODAG parent may be chosen for the 4497 next attempt to forward a unicast packet when no better match 4498 exists. 4500 8. Finally the packet is dropped. ICMP Destination Unreachable MAY 4501 be invoked (an inconsistency is detected). 4503 Hop Limit MUST be decremented when forwarding as per [RFC2460]. 4505 Note that the chosen successor MUST NOT be the neighbor that was the 4506 predecessor of the packet (split horizon), except in the case where 4507 it is intended for the packet to change from an upward to a downward 4508 direction, as determined by the routing table of the node making the 4509 change, such as switching from DIO routes to DAO routes as the 4510 destination is neared in order to continue traveling toward the 4511 destination. 4513 11.2. Loop Avoidance and Detection 4515 RPL loop avoidance mechanisms are kept simple and designed to 4516 minimize churn and states. Loops may form for a number of reasons, 4517 e.g. control packet loss. RPL includes a reactive loop detection 4518 technique that protects from meltdown and triggers repair of broken 4519 paths. 4521 RPL loop detection uses RPL Packet Information that is transported 4522 within the data packets, relying on an external mechanism such as 4523 [I-D.ietf-6man-rpl-option] that places in the RPL Packet Information 4524 in an IPv6 Hop-by-Hop Option header. 4526 The content of RPL Packet Information is defined as follows: 4528 Down 'O': 1-bit flag indicating whether the packet is expected to 4529 progress Up or Down. A router sets the 'O' flag when the 4530 packet is expected to progress Down (using DAO routes), and 4531 clears it when forwarding toward the DODAG root (to a node with 4532 a lower rank). A host or RPL leaf node MUST set the 'O' flag 4533 to 0. 4535 Rank-Error 'R': 1-bit flag indicating whether a rank error was 4536 detected. A rank error is detected when there is a mismatch in 4537 the relative ranks and the direction as indicated in the 'O' 4538 bit. A host or RPL leaf node MUST set the 'R' bit to 0. 4540 Forwarding-Error 'F': 1-bit flag indicating that this node can not 4541 forward the packet further towards the destination. The 'F' 4542 bit might be set by a child node that does not have a route to 4543 destination for a packet with the Down 'O' bit set. A host or 4544 RPL leaf node MUST set the 'F' bit to 0. 4546 RPLInstanceID: 8-bit field indicating the DODAG instance along which 4547 the packet is sent. 4549 SenderRank: 16-bit field set to zero by the source and to 4550 DAGRank(rank) by a router that forwards inside the RPL network. 4552 11.2.1. Source Node Operation 4554 If the source is aware of the RPLInstanceID that is preferred for the 4555 packet, then it MUST set the RPLInstanceID field associated with the 4556 packet accordingly, otherwise it MUST set it to the 4557 RPL_DEFAULT_INSTANCE. 4559 11.2.2. Router Operation 4561 11.2.2.1. Instance Forwarding 4563 The RPLInstanceID is associated by the source with the packet. This 4564 RPLInstanceID MUST match the RPL Instance onto which the packet is 4565 placed by any node, be it a host or router. The RPLInstanceID is 4566 part of the RPL Packet Information. 4568 A RPL router that forwards a packet in the RPL network MUST check if 4569 the packet includes the RPL Packet Information. If not, then the RPL 4570 router MUST insert a RPL Packet Information. If the router is an 4571 ingress router that injects the packet into the RPL network, the 4572 router MUST set the RPLInstanceID field in the RPL Packet 4573 Information. The details of how that router determines the mapping 4574 to a RPLInstanceID are out of scope for this specification and left 4575 to future specification. 4577 A router that forwards a packet to outside the RPL network MUST 4578 remove the RPL Packet Information. 4580 When a router receives a packet that specifies a given RPLInstanceID 4581 and the node can forward the packet along the DODAG associated to 4582 that instance, then the router MUST do so and leave the RPLInstanceID 4583 value unchanged. 4585 If any node can not forward a packet along the DODAG associated to 4586 the RPLInstanceID, then the node SHOULD discard the packet and send 4587 an ICMP error message. 4589 11.2.2.2. DAG Inconsistency Loop Detection 4591 The DODAG is inconsistent if the direction of a packet does not match 4592 the rank relationship. A receiver detects an inconsistency if it 4593 receives a packet with either: 4595 the 'O' bit set (to Down) from a node of a higher rank. 4597 the 'O' bit cleared (for Up) from a node of a lesser rank. 4599 When the DODAG root increments the DODAGVersionNumber, a temporary 4600 rank discontinuity may form between the next DODAG Version and the 4601 prior DODAG Version, in particular if nodes are adjusting their rank 4602 in the next DODAG Version and deferring their migration into the next 4603 DODAG Version. A router that is still a member of the prior DODAG 4604 Version may choose to forward a packet to a (future) parent that is 4605 in the next DODAG Version. In some cases this could cause the parent 4606 to detect an inconsistency because the rank-ordering in the prior 4607 DODAG Version is not necessarily the same as in the next DODAG 4608 Version and the packet may be judged to not be making forward 4609 progress. If the sending router is aware that the chosen successor 4610 has already joined the next DODAG Version, then the sending router 4611 MUST update the SenderRank to INFINITE_RANK as it forwards the 4612 packets across the discontinuity into the next DODAG Version in order 4613 to avoid a false detection of rank inconsistency. 4615 One inconsistency along the path is not considered a critical error 4616 and the packet may continue. But a second detection along the path 4617 of a same packet should not occur and the packet MUST be dropped. 4619 This process is controlled by the Rank-Error bit associated with the 4620 packet. When an inconsistency is detected on a packet, if the Rank- 4621 Error bit was not set then the Rank-Error bit is set. If it was set 4622 the packet MUST be discarded and the trickle timer MUST be reset. 4624 11.2.2.3. DAO Inconsistency Detection and Recovery 4626 DAO inconsistency loop recovery is a mechanism that applies to 4627 storing mode of operation only. 4629 In non-storing mode, the packets are source routed to the destination 4630 and DAO inconsistencies are not corrected locally. Instead, an ICMP 4631 error with a new code "Error in Source Routing Header" is sent back 4632 to the root. The "Error in Source Routing Header" message has the 4633 same format as the "Destination Unreachable Message" as specified in 4634 [RFC4443]. The portion of the invoking packet that is sent back in 4635 the ICMP message should record at least up to the routing header, and 4636 the routing header should be consumed by this node so that the 4637 destination in the IPv6 header is the next hop that this node could 4638 not reach. 4640 A DAO inconsistency happens when a router has a downward route that 4641 was previously learned from a DAO message via a child, but that 4642 downward route is not longer valid in the child, e.g. because that 4643 related state in the child has been cleaned up. With DAO 4644 inconsistency loop recovery, a packet can be used to recursively 4645 explore and cleanup the obsolete DAO states along a sub-DODAG. 4647 In a general manner, a packet that goes Down should never go Up 4648 again. If DAO inconsistency loop recovery is applied, then the 4649 router SHOULD send the packet back to the parent that passed it with 4650 the Forwarding-Error 'F' bit set and the 'O' bit left untouched. 4651 Otherwise the router MUST silently discard the packet. 4653 Upon receiving a packet with a Forwarding-Error bit set, the node 4654 MUST remove the routing states that caused forwarding to that 4655 neighbor, clear the Forwarding-Error bit and attempt to send the 4656 packet again. The packet may be sent to an alternate neighbor, after 4657 the expiration of a user-configurable implementation specific timer. 4658 If that alternate neighbor still has an inconsistent DAO state via 4659 this node, the process will recurse, this node will set the 4660 Forwarding-Error 'F' bit and the routing state in the alternate 4661 neighbor will be cleaned up as well. 4663 12. Multicast Operation 4665 This section describes further a multicast routing operation over an 4666 IPv6 RPL network, and specifically how unicast DAOs can be used to 4667 relay group registrations up. The same DODAG construct can used to 4668 forward unicast and multicast traffic. The registration uses DAO 4669 messages that are identical to unicast except for the type of address 4670 that is transported. The main difference is that the multicast 4671 traffic going down is copied to all the children that have registered 4672 to the multicast group whereas unicast traffic is passed to one child 4673 only. 4675 Nodes that support the RPL storing mode of operation SHOULD also 4676 support multicast DAO operations as described below. Nodes that only 4677 support the non-storing mode of operation are not expected to support 4678 this section. 4680 The multicast operation is controlled by the MOP field in the DIO. 4682 o If the MOP field requires multicast support, then a node that 4683 joins the RPL network as a router must operate as described in 4684 this section for multicast signaling and forwarding within the RPL 4685 network. A node that does not support the multicast operation 4686 required by the MOP field can only join as a leaf. 4688 o If the MOP field does not require multicast support, then 4689 multicast is handled by some other way that is out of scope for 4690 this specification. (Examples may include a series of unicast 4691 copies or limited-scope flooding). 4693 A router might select to pass a listener registration DAO message to 4694 its preferred parent only, in which case multicast packets coming 4695 back might be lost for all of its sub-DODAG if the transmission fails 4696 over that link. Alternatively the router might select to copy 4697 additional parents as it would do for DAO messages advertising 4698 unicast destinations, in which case there might be duplicates that 4699 the router will need to prune. 4701 As a result, multicast routing states are installed in each router on 4702 the way from the listeners to the DODAG root, enabling the root to 4703 copy a multicast packet to all its children routers that had issued a 4704 DAO message including a Target option for that multicast group. 4706 For a multicast packet sourced from inside the DODAG, the packet is 4707 passed to the preferred parents, and if that fails then to the 4708 alternates in the DODAG. The packet is also copied to all the 4709 registered children, except for the one that passed the packet. 4710 Finally, if there is a listener in the external infrastructure then 4711 the DODAG root has to further propagate the packet into the external 4712 infrastructure. 4714 As a result, the DODAG Root acts as an automatic proxy Rendezvous 4715 Point for the RPL network, and as source towards the non-RPL domain 4716 for all multicast flows started in the RPL domain. So regardless of 4717 whether the root is actually attached to a non-RPL domain, and 4718 regardless of whether the DODAG is grounded or floating, the root can 4719 serve inner multicast streams at all times. 4721 13. Maintenance of Routing Adjacency 4723 The selection of successors, along the default paths Up along the 4724 DODAG, or along the paths learned from destination advertisements 4725 Down along the DODAG, leads to the formation of routing adjacencies 4726 that require maintenance. 4728 In IGPs such as OSPF [RFC4915] or IS-IS [RFC5120], the maintenance of 4729 a routing adjacency involves the use of Keepalive mechanisms (Hellos) 4730 or other protocols such as the Bidirectional Forwarding Detection 4731 [RFC5881] (BFD) and the MANET Neighborhood Discovery Protocol 4732 [I-D.ietf-manet-nhdp](NHDP) . Unfortunately, such a proactive 4733 approach is often not desirable in constrained environments where it 4734 would lead to excessive control traffic in light of the data traffic 4735 with a negative impact on both link loads and nodes resources. 4737 By contrast with those routing protocols, RPL does not define any 4738 'keep-alive' mechanisms to detect routing adjacency failures: this is 4739 because in many cases such a mechanism would be too expensive in 4740 terms of bandwidth and even more importantly energy (a battery 4741 operated device could not afford to send periodic Keep alive). Still 4742 RPL requires an external mechanisms to detect that a neighbor is no 4743 longer reachable. Such a mechanism should preferably be reactive to 4744 traffic in order to minimize the overhead to maintain the routing 4745 adjacency and focus on links that are actually being used. 4747 Example reactive mechanisms that can be used include: 4749 The Neighbor Unreachability Detection [RFC4861] mechanism. 4751 Layer 2 triggers [RFC5184] derived from events such as association 4752 states and L2 acknowledgements. 4754 14. Guidelines for Objective Functions 4756 An Objective Function (OF), in conjunction with routing metrics and 4757 constraints, allows for the selection of a DODAG to join, and a 4758 number of peers in that DODAG as parents. The OF is used to compute 4759 an ordered list of parents. The OF is also responsible to compute 4760 the rank of the device within the DODAG Version. 4762 The Objective Function is indicated in the DIO message using an 4763 Objective Code Point (OCP), and indicates the method that must be 4764 used to construct the DODAG. The Objective Code Points are specified 4765 in [I-D.ietf-roll-of0], and related companion specifications. 4767 14.1. Objective Function Behavior 4769 Most Objective Functions are expected to follow the same abstract 4770 behavior at a node: 4772 o The parent selection is triggered each time an event indicates 4773 that a potential next hop information is updated. This might 4774 happen upon the reception of a DIO message, a timer elapse, all 4775 DODAG parents are unavailable, or a trigger indicating that the 4776 state of a candidate neighbor has changed. 4778 o An OF scans all the interfaces on the node. Although there may 4779 typically be only one interface in most application scenarios, 4780 there might be multiple of them and an interface might be 4781 configured to be usable or not for RPL operation. An interface 4782 can also be configured with a preference or dynamically learned to 4783 be better than another by some heuristics that might be link-layer 4784 dependent and are out of scope for this specification. Finally an 4785 interface might or not match a required criterion for an Objective 4786 Function, for instance a degree of security. As a result, some 4787 interfaces might be completely excluded from the computation, for 4788 example if those interfaces cannot satisfy some advertised 4789 constraints, while others might be more or less preferred. 4791 o An OF scans all the candidate neighbors on the possible interfaces 4792 to check whether they can act as a router for a DODAG. There 4793 might be multiple of them and a candidate neighbor might need to 4794 pass some validation tests before it can be used. In particular, 4795 some link layers require experience on the activity with a router 4796 to enable the router as a next hop. 4798 o An OF computes rank of a node for comparison by adding to the rank 4799 of the candidate a value representing the relative locations of 4800 the node and the candidate in the DODAG Version. 4802 * The increase in rank must be at least MinHopRankIncrease. 4804 * To keep loop avoidance and metric optimization in alignment, 4805 the increase in rank should reflect any increase in the metric 4806 value. For example, with a purely additive metric such as ETX, 4807 the increase in rank can be made proportional to the increase 4808 in the metric. 4810 * Candidate neighbors that would cause the rank of the node to 4811 increase are not considered for parent selection. 4813 o Candidate neighbors that advertise an OF incompatible with the set 4814 of OF specified by the policy functions are ignored. 4816 o As it scans all the candidate neighbors, the OF keeps the current 4817 best parent and compares its capabilities with the current 4818 candidate neighbor. The OF defines a number of tests that are 4819 critical to reach the objective. A test between the routers 4820 determines an order relation. 4822 * If the routers are equal for that relation then the next test 4823 is attempted between the routers, 4825 * Else the best of the two routers becomes the current best 4826 parent and the scan continues with the next candidate neighbor. 4828 * Some OFs may include a test to compare the ranks that would 4829 result if the node joined either router. 4831 o When the scan is complete, the preferred parent is elected and the 4832 node's rank is computed as the preferred parent rank plus the step 4833 in rank with that parent. 4835 o Other rounds of scans might be necessary to elect alternate 4836 parents. In the next rounds: 4838 * Candidate neighbors that are not in the same DODAG are ignored. 4840 * Candidate neighbors that are of greater rank than the node are 4841 ignored. 4843 * Candidate neighbors of an equal rank to the node are ignored 4844 for parent selection. 4846 * Candidate neighbors of a lesser rank than the node are 4847 preferred. 4849 15. Suggestions for Interoperation with Neighbor Discovery 4851 This specification directly borrows the Prefix Information Option 4852 (PIO) and the Routing Information Option (RIO) from IPv6 ND. It is 4853 envisioned that, as future specifications build on this base, there 4854 may be additional cause to leverage parts of IPv6 ND. This section 4855 provides some suggestions for future specifications. 4857 First and foremost RPL is a routing protocol. One should take great 4858 care to preserve architecture when mapping functionalities between 4859 RPL and ND. RPL is for routing only. That said, there may be 4860 persuading technical reasons to allow for sharing options between RPL 4861 and IPv6 ND in a particular implementation/deployment. 4863 In general the following guidelines apply: 4865 o RPL Type codes must be allocated from the RPL Control Message 4866 Options registry. 4868 o RPL Length fields must be expressed in units of single octets, as 4869 opposed to ND Length fields which are expressed in units of 8 4870 octets. 4872 o RPL Options are generally not required to be aligned to 8 octet 4873 boundaries. 4875 o When mapping/transposing an IPv6 ND option for redistribution as a 4876 RPL option, any padding octets should be removed when possible. 4877 For example, the Prefix Length field in the PIO is sufficient to 4878 describe the length of the Prefix field. When mapping/transposing 4879 a RPL option for redistribution as an IPv6 ND option, any such 4880 padding octets should be restored. This procedure must be 4881 unambiguous. 4883 16. Summary of Requirements for Interoperable Implementations 4885 This section summarizes basic interoperability and references 4886 normative text for RPL implementations operating in one of three 4887 major modes. Implementations are expected to support either no 4888 downward routes, non-storing mode only, or storing mode only. A 4889 fourth mode, operation as a leaf, is also possible. 4891 Implementations conforming to this specification may contain 4892 different subsets of capabilities as appropriate to the application 4893 scenario. It is important for the implementer to support a level of 4894 interoperability consistent with that required by the application 4895 scenario. To this end, further guidance may be provided beyond this 4896 specification (e.g. as applicability statements), and it is 4897 understood that in some cases such further guidance may override 4898 portions of this specification. 4900 16.1. Common Requirements 4902 In a general case the greatest level of interoperability may be 4903 achieved when all of the nodes in a RPL LLN are cooperating to use 4904 the same MOP, OF, metrics, and constraints, and are thus able to act 4905 as RPL Routers. When a node is not capable to be a RPL Router it may 4906 be possible to interoperate in a more limited manner as a RPL leaf. 4908 All RPL implementations need to support the use of RPL Packet 4909 Information transported within data packets (Section 11.2). One such 4910 mechanism is described in [I-D.ietf-6man-rpl-option]. 4912 RPL implementations will need to support the use of Neighbor 4913 Unreachability Detection (NUD), or an equivalent mechanism, to 4914 maintain the reachability of neighboring RPL nodes (Section 8.2.1). 4915 Alternate mechanisms may be optimized to the constrained capabilities 4916 of the implementation, such as hints from the link layer. 4918 This specification provides means to obtain a PIO and thus form an 4919 IPv6 address. When that mechanism is used it may be necessary to 4920 perform address resolution and duplicate address detection through an 4921 external process, such as IPv6 ND ([RFC4861]) or 6LoWPAN ND 4922 ([I-D.ietf-6lowpan-nd]). 4924 16.2. Operation as a RPL Leaf Node (only) 4926 o An implementation of a Leaf Node (only) does not ever participate 4927 as a RPL Router. Interoperable implementations of leaf nodes 4928 behave as summarized in Section 8.5. 4930 o Support of a particular MOP encoding is not required, although if 4931 the leaf node sends DAO messages to setup downward routes the leaf 4932 node should do so in a manner consistent with the mode of 4933 operation described by the MOP. 4934 o Support of a particular OF is not required. 4935 o In brief summary, a leaf node does not generally issue DIO 4936 messages, it may issue DAO and DIS messages. A leaf node accepts 4937 DIO messages though it generally ignores DAO and DIS messages. 4939 16.3. Operation as a RPL Router 4941 If further guidance is not available then a RPL Router implementation 4942 MUST at least support the metric-less OF0 [I-D.ietf-roll-of0]. 4944 For consistent operation a RPL Router implementation needs to support 4945 the MOP in use by the DODAG. 4947 All RPL Routers will need to implement Trickle 4948 ([I-D.ietf-roll-trickle]) 4950 16.3.1. Support for Upward Routes only 4952 An implementation of a RPL router that supports only Upward Routes 4953 supports the following: 4954 o Upward Routes (Section 8) 4955 o MOP encoding 0 (Section 20.3) 4956 o In brief summary DIO and DIS messages are issued, and DAO messages 4957 are not issued. DIO and DIS messages are accepted, and DAO 4958 messages are ignored. 4960 16.3.2. Support for Upward Routes and Downward Routes in Non-Storing 4961 mode 4963 An implementation of a RPL router that supports Upward Routes and 4964 Downward Routes in Non-Storing mode supports the following: 4965 o Upward Routes (Section 8) 4966 o Downward Routes (Non-Storing) (Section 9) 4967 o MOP encoding 1 (Section 20.3) 4968 o Source-routed downward traffic 4969 ([I-D.ietf-6man-rpl-routing-header]) 4970 o In brief summary DIO and DIS messages are issued, and DAO messages 4971 are issued to the DODAG Root. DIO and DIS messages are accepted, 4972 and DAO messages are ignored by nodes other than DODAG Roots. 4973 Multicast is not supported through the means described in this 4974 specification, though it may be supported through some alternate 4975 means. 4977 16.3.3. Support for Upward Routes and Downward Routes in Storing mode 4979 An implementation of a RPL router that supports Upward Routes and 4980 Downward Routes in Storing mode supports the following: 4981 o Upward Routes (Section 8) 4982 o Downward Routes (Storing) (Section 9) 4983 o MOP encoding 2 (Section 20.3) 4984 o In brief summary DIO, DIS, and DAO messages are issued. DIO, DIS, 4985 and DAO messages are accepted. Multicast is not supported through 4986 the means described in this specification, though it may be 4987 supported through some alternate means. 4989 16.3.3.1. Optional support for basic multicast scheme 4991 A Storing mode implementation may be enhanced with basic multicast 4992 support through the following additions: 4993 o Basic Multicast Support (Section 12) 4994 o MOP encoding 3 (Section 20.3) 4996 16.4. Items for Future Specification 4998 A number of items are left to future specification, including but not 4999 limited to: 5000 o How to attach a non-RPL node such as an IPv6 host, e.g. to 5001 consistently distribute at least PIO material to the attached 5002 node. 5003 o How to obtain authentication material in support if authenticated 5004 mode is used (Section 10.3). 5005 o Details of operation over multiple simultaneous instances. 5006 o Advanced configuration mechanisms, such as provisioning of 5007 RPLInstanceIDs, parameterization of objective functions, and 5008 parameters to control security. (It is expected that such 5009 mechanisms might extend the DIO as a means to disseminate 5010 information across the DODAG). 5012 17. RPL Constants and Variables 5014 Following is a summary of RPL constants and variables: 5016 BASE_RANK This is the rank for a virtual root that might be used to 5017 coordinate multiple roots. BASE_RANK has a value of 0. 5019 ROOT_RANK This is the rank for a DODAG root. ROOT_RANK has a value 5020 of MinHopRankIncrease (as advertised by the DODAG root), such 5021 that DAGRank(ROOT_RANK) is 1. 5023 INFINITE_RANK This is the constant maximum for the rank. 5024 INFINITE_RANK has a value of 0xFFFF. 5026 RPL_DEFAULT_INSTANCE This is the RPLInstanceID that is used by this 5027 protocol by a node without any overriding policy. 5028 RPL_DEFAULT_INSTANCE has a value of 0. 5030 DEFAULT_PATH_CONTROL_SIZE This is the default value used to 5031 configure PCS in the DODAG Configuration Option, which dictates 5032 the number of significant bits in the Path Control field of the 5033 Transit Information option. DEFAULT_PATH_CONTROL_SIZE has a 5034 value of 0. This configures the simplest case limiting the 5035 fan-out to 1 and limiting a node to send a DAO message to only 5036 one parent. 5038 DEFAULT_DIO_INTERVAL_MIN This is the default value used to configure 5039 Imin for the DIO trickle timer. DEFAULT_DIO_INTERVAL_MIN has a 5040 value of 3. This configuration results in Imin of 8ms. 5042 DEFAULT_DIO_INTERVAL_DOUBLINGS This is the default value used to 5043 configure Imax for the DIO trickle timer. 5044 DEFAULT_DIO_INTERVAL_DOUBLINGS has a value of 20. This 5045 configuration results in a maximum interval of 2.3 hours. 5047 DEFAULT_DIO_REDUNDANCY_CONSTANT This is the default value used to 5048 configure k for the DIO trickle timer. 5049 DEFAULT_DIO_REDUNDANCY_CONSTANT has a value of 10. This 5050 configuration is a conservative value for trickle suppression 5051 mechanism. 5053 DEFAULT_MIN_HOP_RANK_INCREASE This is the default value of 5054 MinHopRankIncrease. DEFAULT_MIN_HOP_RANK_INCREASE has a value 5055 of 256. This configuration results in an 8-bit wide integer 5056 part of Rank. 5058 DEFAULT_DAO_DELAY This is the default value for the DelayDAO Timer. 5059 DEFAULT_DAO_DELAY has value of 1 second. See Section 9.5. 5061 DIO Timer One instance per DODAG that a node is a member of. Expiry 5062 triggers DIO message transmission. Trickle timer with variable 5063 interval in [0, DIOIntervalMin..2^DIOIntervalDoublings]. See 5064 Section 8.3.1 5066 DAG Version Increment Timer Up to one instance per DODAG that the 5067 node is acting as DODAG root of. May not be supported in all 5068 implementations. Expiry triggers increment of 5069 DODAGVersionNumber, causing a new series of updated DIO message 5070 to be sent. Interval should be chosen appropriate to 5071 propagation time of DODAG and as appropriate to application 5072 requirements (e.g. response time vs. overhead). 5074 DelayDAO Timer Up to one timer per DAO parent (the subset of DODAG 5075 parents chosen to receive destination advertisements) per 5076 DODAG. Expiry triggers sending of DAO message to the DAO 5077 parent. See Section 9.5 5079 RemoveTimer Up to one timer per DAO entry per neighbor (i.e. those 5080 neighbors that have given DAO messages to this node as a DODAG 5081 parent) Expiry may trigger No-Path advertisements or 5082 immediately deallocate the DAO entry if there are no DAO 5083 parents. 5085 18. Manageability Considerations 5087 The aim of this section is to give consideration to the manageability 5088 of RPL, and how RPL will be operated in a LLN. The scope of this 5089 section is to consider the following aspects of manageability: 5090 configuration, monitoring, fault management, accounting, and 5091 performance of the protocol in light of the recommendations set forth 5092 in [RFC5706]. 5094 18.1. Introduction 5096 Most of the existing IETF management standards are Structure of 5097 Management Information (SMI) based data models (MIB modules) to 5098 monitor and manage networking devices. 5100 For a number of protocols, the IETF community has used the IETF 5101 Standard Management Framework, including the Simple Network 5102 Management Protocol [RFC3410], the Structure of Management 5103 Information [RFC2578], and MIB data models for managing new 5104 protocols. 5106 As pointed out in [RFC5706], the common policy in terms of operation 5107 and management has been expanded to a policy that is more open to a 5108 set of tools and management protocols rather than strictly relying on 5109 a single protocol such as SNMP. 5111 In 2003, the Internet Architecture Board (IAB) held a workshop on 5112 Network Management [RFC3535] that discussed the strengths and 5113 weaknesses of some IETF network management protocols and compared 5114 them to operational needs, especially configuration. 5116 One issue discussed was the user-unfriendliness of the binary format 5117 of SNMP [RFC3410]. In the case of LLNs, it must be noted that at the 5118 time of writing, the CoRE Working Group is actively working on 5119 resource management of devices in LLNs. Still, it is felt that this 5120 section provides important guidance on how RPL should be deployed, 5121 operated, and managed. 5123 As stated in [RFC5706], "A management information model should 5124 include a discussion of what is manageable, which aspects of the 5125 protocol need to be configured, what types of operations are allowed, 5126 what protocol-specific events might occur, which events can be 5127 counted, and for which events an operator should be notified". These 5128 aspects are discussed in detail in the following sections. 5130 RPL will be used on a variety of devices that may have resources such 5131 as memory varying from a few Kbytes to several hundreds of Kbytes and 5132 even Mbytes. When memory is highly constrained, it may not be 5133 possible to satisfy all the requirements listed in this section. 5134 Still it is worth listing all of these in an exhaustive fashion, and 5135 implementers will then determine which of these requirements could be 5136 satisfied according to the available resources on the device. 5138 18.2. Configuration Management 5140 This section discusses the configuration management, listing the 5141 protocol parameters for which configuration management is relevant. 5143 Some of the RPL parameters are optional. The requirements for 5144 configuration are only applicable for the options that are used. 5146 18.2.1. Initialization Mode 5148 "Architectural Principles of the Internet" [RFC1958], Section 3.8, 5149 states: "Avoid options and parameters whenever possible. Any options 5150 and parameters should be configured or negotiated dynamically rather 5151 than manually." This is especially true in LLNs where the number of 5152 devices may be large and manual configuration is infeasible. This 5153 has been taken into account in the design of RPL whereby the DODAG 5154 root provides a number of parameters to the devices joining the 5155 DODAG, thus avoiding cumbersome configuration on the routers and 5156 potential sources of misconfiguration (e.g. values of trickle timers, 5157 ...). Still there are additional RPL parameters that a RPL 5158 implementation should allow to be configured, which are discussed in 5159 this section. 5161 18.2.1.1. DIS mode of operation upon boot-up 5163 When a node is first powered up: 5165 1. The node may decide to stay silent, waiting to receive DIO 5166 messages from DODAG of interest (advertising a supported OF and 5167 metrics/constraints) and not send any multicast DIO messages 5168 until it has joined a DODAG. 5170 2. The node may decide to send one or more DIS messages (optionally 5171 requesting DIO for a specific DODAG) as an initial probe for 5172 nearby DODAGs, and in the absence of DIO messages in reply after 5173 some configurable period of time, the node may decide to root a 5174 floating DODAG and start sending multicast DIO messages. 5176 A RPL implementation SHOULD allow configuring the preferred mode of 5177 operation listed above along with the required parameters (in the 5178 second mode: the number of DIS messages and related timer). 5180 18.2.2. DIO and DAO Base Message and Options Configuration 5182 RPL specifies a number of protocol parameters considering the large 5183 spectrum of applications where it will be used. That said, 5184 particular attention has been given to limiting the number of these 5185 parameters that must be configured on each RPL router. Instead, a 5186 number of the default values can be used, and when required these 5187 parameters can be provided by the DODAG root thus allowing for 5188 dynamic parameter setting. 5190 A RPL implementation SHOULD allow configuring the following routing 5191 protocol parameters. As pointed out above, note that a large set of 5192 parameters is configured on the DODAG root. 5194 18.2.3. Protocol Parameters to be configured on every router in the LLN 5196 A RPL implementation MUST allow configuring the following RPL 5197 parameters: 5199 o RPLInstanceID [DIO message, in DIO base message]. Although the 5200 RPLInstanceID must be configured on the DODAG root, it must also 5201 be configured as a policy on every node in order to determine 5202 whether or not the node should join a particular DODAG. Note that 5203 a second RPLInstance can be configured on the node, should it 5204 become root of a floating DODAG. 5206 o List of supported Objective Code Points (OCPs) 5208 o List of supported metrics: [I-D.ietf-roll-routing-metrics] 5209 specifies a number of metrics and constraints used for the DODAG 5210 formation. Thus a RPL implementation should allow configuring the 5211 list of metrics that a node can accept and understand. If a DIO 5212 is received with a metric and/or constraint that is not understood 5213 or supported, as specified in Section 8.5, the node would join as 5214 a leaf node. 5216 o Prefix information, along with valid and preferred lifetime and 5217 the L and A flags. [DIO message, Prefix Information option]. A 5218 RPL implementation SHOULD allow configuring if the Prefix 5219 Information Option must be carried with the DIO message to 5220 distribute the prefix information for auto-configuration. In that 5221 case, the RPL implementation MUST allow the list of prefixes to be 5222 advertised in the Prefix Information Option along with the 5223 corresponding flags. 5225 o Solicited Information [DIS message, in Solicited Information 5226 option]. Note that an RPL implementation SHOULD allow configuring 5227 when such messages should be sent and under which circumstances, 5228 along with the value of the RPLInstance ID, V/I/D flags. 5230 o 'K' flag: when a node should set the 'K' flag in a DAO message 5231 [DAO message, in DAO base message]. 5233 o MOP (Mode of Operation) [DIO message, in DIO base message]. 5235 o Route Information (and preference) [DIO message, in Route 5236 Information option] 5238 18.2.4. Protocol Parameters to be configured on every non-DODAG-root 5239 router in the LLN 5241 A RPL implementation MUST allow configuring the Target prefix [DAO 5242 message, in RPL Target option]. 5244 Furthermore, there are circumstances where a node may want to 5245 designate a Target to allow for specific processing of the Target 5246 (prioritization, ...). Such processing rules are out of scope for 5247 this specification. When used, a RPL implementation SHOULD allow 5248 configuring the Target Descriptor on a per-Target basis (for example 5249 using access lists). 5251 A node whose DODAG parent set is empty may become the DODAG root of a 5252 floating DODAG. It may also set its DAGPreference such that it is 5253 less preferred. Thus a RPL implementation MUST allow configuring the 5254 set of actions that the node should initiate in this case: 5256 o Start its own (floating) DODAG: the new DODAGID must be configured 5257 in addition to its DAGPreference. 5259 o Poison the broken path (see procedure in Section 8.2.2.5). 5261 o Trigger a local repair. 5263 18.2.5. Parameters to be configured on the DODAG root 5265 In addition, several other parameters are configured only on the 5266 DODAG root and advertised in options carried in DIO messages. 5268 As specified in Section 8.3, a RPL implementation makes use of 5269 trickle timers to govern the sending of DIO messages. The operation 5270 of the trickle algorithm is determined by a set of configurable 5271 parameters, which MUST be configurable and that are then advertised 5272 by the DODAG root along the DODAG in DIO messages. 5274 o DIOIntervalDoublings [DIO message, in DODAG configuration option] 5276 o DIOIntervalMin [DIO message, in DODAG configuration option] 5278 o DIORedundancyConstant [DIO message, in DODAG configuration option] 5280 In addition, a RPL implementation SHOULD allow for configuring the 5281 following set of RPL parameters: 5283 o Path Control Size [DIO message, in DODAG configuration option] 5285 o MinHopRankIncrease [DIO message, in DODAG configuration option] 5287 o The DODAGPreference field [DIO message, DIO Base object] 5289 o DODAGID [DIO message, in DIO base option] and [DAO message, when 5290 the 'D' flag of the DAO message is set] 5292 DAG Root behavior: in some cases, a node may not want to permanently 5293 act as a floating DODAG root if it cannot join a grounded DODAG. For 5294 example a battery-operated node may not want to act as a floating 5295 DODAG root for a long period of time. Thus a RPL implementation MAY 5296 support the ability to configure whether or not a node could act as a 5297 floating DODAG root for a configured period of time. 5299 DAG Version Number Increment: a RPL implementation may allow by 5300 configuration at the DODAG root to refresh the DODAG states by 5301 updating the DODAGVersionNumber. A RPL implementation SHOULD allow 5302 configuring whether or not periodic or event triggered mechanisms are 5303 used by the DODAG root to control DODAGVersionNumber change (which 5304 triggers a global repair as specified in Section 3.2.2. 5306 18.2.6. Configuration of RPL Parameters related to DAO-based mechanisms 5308 DAO messages are optional and used in DODAGs that require downward 5309 routing operation. This section deals with the set of parameters 5310 related to DAO messages and provides recommendations on their 5311 configuration. 5313 As stated in Section 9.5, it is recommended to delay the sending of 5314 DAO message to DAO parents in order to maximize the chances to 5315 perform route aggregation. Upon receiving a DAO message, the node 5316 should thus start a DelayDAO timer. The default value is 5317 DEFAULT_DAO_DELAY. A RPL implementation MAY allow for configuring 5318 the DelayDAO timer. 5320 In a storing mode of operation, a storing node may increment DTSN in 5321 order to reliably trigger a set of DAO updates from its immediate 5322 children, as part of routine routing table updates and maintenance. 5323 A RPL implementation MAY allow for configuring a set of rules 5324 specifying the triggers for DTSN increment (manual or event-based). 5326 When a DAO entry times out or is invalidated, a node SHOULD make a 5327 reasonable attempt to report a No-Path to each of the DAO parents. 5328 That number of attempts MAY be configurable. 5330 An implementation should support rate-limiting the sending of DAO 5331 messages. The related parameters MAY be configurable. 5333 18.2.7. Configuration of RPL Parameters related to Security mechanisms 5335 As described in Section 10, the security features described in this 5336 document are optional to implement and a given implementation may 5337 support a subset (including the empty set) of the described security 5338 features. 5340 To this end an implementation supporting described security features 5341 may conceptually implement a security policy database. In support of 5342 the security mechanisms, a RPL implementation SHOULD allow for 5343 configuring a subset of the following parameters: 5345 o Security Modes accepted [Unsecured mode, Pre-Installed mode, 5346 Authenticated mode] 5348 o KIM values accepted [Secure RPL Control messages, in Security 5349 Section] 5351 o Level values accepted [Secure RPL Control messages, in Security 5352 section] 5354 o Algorithm values accepted [Secure RPL Control messages, in 5355 Security section] 5357 o Key material in support of Authenticated or Pre-Installed key 5358 modes. 5360 In addition, a RPL implementation SHOULD allow for configuring a 5361 DODAG root with a subset of the following parameters: 5363 o Level values advertised [Secure DIO message, in Security Section] 5365 o KIM value advertised [Secure DIO message, in Security Section] 5367 o Algorithm value advertised [Secure DIO message, in Security 5368 Section] 5370 18.2.8. Default Values 5372 This document specifies default values for the following set of RPL 5373 variables: 5374 DEFAULT_PATH_CONTROL_SIZE 5375 DEFAULT_DIO_INTERVAL_MIN 5376 DEFAULT_DIO_INTERVAL_DOUBLINGS 5377 DEFAULT_DIO_REDUNDANCY_CONSTANT 5378 DEFAULT_MIN_HOP_RANK_INCREASE 5379 DEFAULT_DAO_DELAY 5381 It is recommended to specify default values in protocols; that being 5382 said, as discussed in [RFC5706], default values may make less and 5383 less sense. RPL is a routing protocol that is expected to be used in 5384 a number of contexts where network characteristics such as the number 5385 of nodes, link and nodes types are expected to vary significantly. 5386 Thus, these default values are likely to change with the context and 5387 as the technology will evolve. Indeed, LLNs' related technology 5388 (e.g. hardware, link layers) have been evolving dramatically over the 5389 past few years and such technologies are expected to change and 5390 evolve considerably in the coming years. 5392 The proposed values are not based on extensive best current practices 5393 and are considered to be conservative. 5395 18.3. Monitoring of RPL Operation 5397 Several RPL parameters should be monitored to verify the correct 5398 operation of the routing protocol and the network itself. This 5399 section lists the set of monitoring parameters of interest. 5401 18.3.1. Monitoring a DODAG parameters 5403 A RPL implementation SHOULD provide information about the following 5404 parameters: 5406 o DODAG Version number [DIO message, in DIO base message] 5408 o Status of the G flag [DIO message, in DIO base message] 5410 o Status of the MOP field [DIO message, in DIO base message] 5412 o Value of the DTSN [DIO message, in DIO base message] 5414 o Value of the rank [DIO message, in DIO base message] 5416 o DAOSequence: Incremented at each unique DAO message, echoed in the 5417 DAO-ACK message [DAO and DAO-ACK messages] 5419 o Route Information [DIO message, Route Information option] (list of 5420 IPv6 prefixes per parent along with lifetime and preference] 5422 o Trickle parameters: 5424 * DIOIntervalDoublings [DIO message, in DODAG configuration 5425 option] 5427 * DIOIntervalMin [DIO message, in DODAG configuration option] 5429 * DIORedundancyConstant [DIO message, in DODAG configuration 5430 option] 5432 o Path Control Size [DIO message, in DODAG configuration option] 5434 o MinHopRankIncrease [DIO message, in DODAG configuration option] 5436 Values that may be monitored only on the DODAG root 5438 o Transit Information [DAO, Transit Information option]: A RPL 5439 implementation SHOULD allow configuring whether the set of 5440 received Transit Information options should be displayed on the 5441 DODAG root. In this case, the RPL database of received Transit 5442 Information should also contain: the path-sequence, path control, 5443 path lifetime and parent address. 5445 18.3.2. Monitoring a DODAG inconsistencies and loop detection 5447 Detection of DODAG inconsistencies is particularly critical in RPL 5448 networks. Thus it is recommended for a RPL implementation to provide 5449 appropriate monitoring tools. A RPL implementation SHOULD provide a 5450 counter reporting the number of a times the node has detected an 5451 inconsistency with respect to a DODAG parent, e.g. if the DODAGID has 5452 changed. 5454 When possible more granular information about inconsistency detection 5455 should be provided. A RPL implementation MAY provide counters 5456 reporting the number of following inconsistencies: 5458 o Packets received with 'O' bit set (to Down) from a node with a 5459 higher rank 5461 o Packets received with 'O' bit cleared (to Up) from a node with a 5462 lower rank 5464 o Number of packets with the 'F' bit set 5465 o Number of packets with the 'R' bit set 5467 18.4. Monitoring of the RPL data structures 5469 18.4.1. Candidate Neighbor Data Structure 5471 A node in the candidate neighbor list is a node discovered by the 5472 some means and qualified to potentially become a parent (with high 5473 enough local confidence). A RPL implementation SHOULD provide a way 5474 to allow for the candidate neighbor list to be monitored with some 5475 metric reflecting local confidence (the degree of stability of the 5476 neighbors) as measured by some metrics. 5478 A RPL implementation MAY provide a counter reporting the number of 5479 times a candidate neighbor has been ignored, should the number of 5480 candidate neighbors exceeds the maximum authorized value. 5482 18.4.2. Destination Oriented Directed Acyclic Graph (DAG) Table 5484 For each DODAG, a RPL implementation is expected to keep track of the 5485 following DODAG table values: 5487 o RPLInstanceID 5489 o DODAGID 5491 o DODAGVersionNumber 5493 o Rank 5495 o Objective Code Point 5497 o A set of DODAG Parents 5499 o A set of prefixes offered upwards along the DODAG 5501 o Trickle timers used to govern the sending of DIO messages for the 5502 DODAG 5504 o List of DAO parents 5506 o DTSN 5508 o Node status (router versus leaf) 5510 A RPL implementation SHOULD allow for monitoring the set of 5511 parameters listed above. 5513 18.4.3. Routing Table and DAO Routing Entries 5515 A RPL implementation maintains several information elements related 5516 to the DODAG and the DAO entries (for storing nodes). In the case of 5517 a non storing node, a limited amount of information is maintained 5518 (the routing table is mostly reduced to a set of DODAG parents along 5519 with characteristics of the DODAG as mentioned above) whereas in the 5520 case of storing nodes, this information is augmented with routing 5521 entries. 5523 A RPL implementation SHOULD allow for the following parameters to be 5524 monitored: 5526 o Next Hop (DODAG parent) 5528 o Next Hop Interface 5530 o Path metrics value for each DODAG parent 5532 A DAO Routing Table Entry conceptually contains the following 5533 elements (for storing nodes only): 5535 o Advertising Neighbor Information 5537 o IPv6 Address 5539 o Interface ID to which DAO Parents has this entry been reported 5541 o Retry Counter 5543 o Logical equivalent of DAO Content: 5545 * DAO-Sequence 5547 * Path Sequence 5549 * DAO Lifetime 5551 * DAO Path Control 5553 o Destination Prefix (or Address or Mcast Group) 5555 A RPL implementation SHOULD provide information about the state of 5556 each DAO Routing Table entry states. 5558 18.5. Fault Management 5560 Fault management is a critical component used for troubleshooting, 5561 verification of the correct mode of operation of the protocol, 5562 network design, and is also a key component of network performance 5563 monitoring. A RPL implementation SHOULD allow providing the 5564 following information related to fault managements: 5566 o Memory overflow along with the cause (e.g. routing tables 5567 overflow, ...) 5569 o Number of times a packet could not be sent to a DODAG parent 5570 flagged as valid 5572 o Number of times a packet has been received for which the router 5573 did not have a corresponding RPLInstanceID 5575 o Number of times a local repair procedure was triggered 5577 o Number of times a global repair was triggered by the DODAG root 5579 o Number of received malformed messages 5581 o Number of seconds with packets to forward and no next hop (DODAG 5582 parent) 5584 o Number of seconds without next hop (DODAG parent) 5586 o Number of times a node has joined a DODAG as a leaf because it 5587 received a DIO with metric/constraint not understood and it was 5588 configured to join as a leaf node in this case (see Section 18.6). 5590 It is RECOMMENDED to report faults via at least error log messages. 5591 Other protocols may be used to report such faults. 5593 18.6. Policy 5595 Policy rules can be used by a RPL implementation to determine whether 5596 or not the node is allowed to join a particular DODAG advertised by a 5597 neighbor by means of DIO messages. 5599 This document specifies operation within a single DODAG. A DODAG is 5600 characterized by the following tuple (RPLInstanceID, DODAGID). 5601 Furthermore, as pointed out above, DIO messages are used to advertise 5602 other DODAG characteristics such as the routing metrics and 5603 constraints used to build to the DODAG and the Objective Function in 5604 use (specified by OCP). 5606 The first policy rules consist of specifying the following conditions 5607 that a RPL node must satisfy to join a DODAG: 5609 o RPLInstanceID 5611 o List of supported routing metrics and constraints 5613 o Objective Function (OCP values) 5615 A RPL implementation MUST allow configuring these parameters and 5616 SHOULD specify whether the node must simply ignore the DIO if the 5617 advertised DODAG is not compliant with the local policy or whether 5618 the node should join as the leaf node if only the list of supported 5619 routing metrics and constraints, and the OF is not supported. 5620 Additionally a RPL implementation SHOULD allow for the addition of 5621 the DODAGID as part of the policy. 5623 A RPL implementation SHOULD allow configuring the set of acceptable 5624 or preferred Objective Functions (OF) referenced by their Objective 5625 Codepoints (OCPs) for a node to join a DODAG, and what action should 5626 be taken if none of a node's candidate neighbors advertise one of the 5627 configured allowable Objective Functions, or if the advertised 5628 metrics/constraint is not understood/supported. Two actions can be 5629 taken in this case: 5631 o The node joins the DODAG as a leaf node as specified in 5632 Section 8.5 5634 o The node does not join the DODAG 5636 A node in an LLN may learn routing information from different routing 5637 protocols including RPL. It is in this case desirable to control via 5638 administrative preference which route should be favored. An 5639 implementation SHOULD allow for specifying an administrative 5640 preference for the routing protocol from which the route was learned. 5642 Internal Data Structures: some RPL implementations may limit the size 5643 of the candidate neighbor list in order to bound the memory usage, in 5644 which case some otherwise viable candidate neighbors may not be 5645 considered and simply dropped from the candidate neighbor list. 5647 A RPL implementation MAY provide an indicator on the size of the 5648 candidate neighbor list. 5650 18.7. Fault Isolation 5652 It is RECOMMENDED to quarantine neighbors that start emitting 5653 malformed messages at unacceptable rates. 5655 18.8. Impact on Other Protocols 5657 RPL has very limited impact on other protocols. Where more than one 5658 routing protocol is required on a router such as a LBR, it is 5659 expected for the device to support routing redistribution functions 5660 between the routing protocols to allow for reachability between the 5661 two routing domains. Such redistribution SHOULD be governed by the 5662 use of user configurable policy. 5664 With regards to the impact in terms of traffic on the network, RPL 5665 has been designed to limit the control traffic thanks to mechanisms 5666 such as Trickle timers (Section 8.3). Thus the impact of RPL on 5667 other protocols should be extremely limited. 5669 18.9. Performance Management 5671 Performance management is always an important aspect of a protocol 5672 and RPL is not an exception. Several metrics of interest have been 5673 specified by the IP Performance Monitoring (IPPM) Working Group: that 5674 being said, they will be hardly applicable to LLN considering the 5675 cost of monitoring these metrics in terms of resources on the devices 5676 and required bandwidth. Still, RPL implementation MAY support some 5677 of these, and other parameters of interest are listed below: 5679 o Number of repairs and time to repair in seconds (average, 5680 variance) 5682 o Number of times and duration during which a devices could not 5683 forward a packet because of a lack of reachable neighbor in its 5684 routing table 5686 o Monitoring of resources consumption by RPL in terms of bandwidth 5687 and required memory 5689 o Number of RPL control messages sent and received 5691 18.10. Diagnostics 5693 There may be situations where a node should be placed in "verbose" 5694 mode to improve diagnostics. Thus a RPL implementation SHOULD 5695 provide the ability to place a node in and out of verbose mode in 5696 order to get additional diagnostic information. 5698 19. Security Considerations 5700 19.1. Overview 5702 From a security perspective, RPL networks are no different from any 5703 other network. They are vulnerable to passive eavesdropping attacks 5704 and potentially even active tampering when physical access to a wire 5705 is not required to participate in communications. The very nature of 5706 ad hoc networks and their cost objectives impose additional security 5707 constraints, which perhaps make these networks the most difficult 5708 environments to secure. Devices are low-cost and have limited 5709 capabilities in terms of computing power, available storage, and 5710 power drain; and it cannot always be assumed they have a trusted 5711 computing base or a high-quality random number generator aboard. 5712 Communications cannot rely on the online availability of a fixed 5713 infrastructure and might involve short-term relationships between 5714 devices that may never have communicated before. These constraints 5715 might severely limit the choice of cryptographic algorithms and 5716 protocols and influence the design of the security architecture 5717 because the establishment and maintenance of trust relationships 5718 between devices need to be addressed with care. In addition, battery 5719 lifetime and cost constraints put severe limits on the security 5720 overhead these networks can tolerate, something that is of far less 5721 concern with higher bandwidth networks. Most of these security 5722 architectural elements can be implemented at higher layers and may, 5723 therefore, be considered to be out of scope for this specification. 5724 Special care, however, needs to be exercised with respect to 5725 interfaces to these higher layers. 5727 The security mechanisms in this standard are based on symmetric-key 5728 and public-key cryptography and use keys that are to be provided by 5729 higher layer processes. The establishment and maintenance of these 5730 keys are out of scope for this specification. The mechanisms assume 5731 a secure implementation of cryptographic operations and secure and 5732 authentic storage of keying material. 5734 The security mechanisms specified provide particular combinations of 5735 the following security services: 5737 Data confidentiality: Assurance that transmitted information is only 5738 disclosed to parties for which it is intended. 5740 Data authenticity: Assurance of the source of transmitted 5741 information (and, hereby, that information was not 5742 modified in transit). 5744 Replay protection: Assurance that a duplicate of transmitted 5745 information is detected. 5747 Timeliness (delay protection): Assurance that transmitted 5748 information was received in a timely manner. 5750 The actual protection provided can be adapted on a per-packet basis 5751 and allows for varying levels of data authenticity (to minimize 5752 security overhead in transmitted packets where required) and for 5753 optional data confidentiality. When nontrivial protection is 5754 required, replay protection is always provided. 5756 Replay protection is provided via the use of a non-repeating value 5757 (CCM nonce) in the packet protection process and storage of some 5758 status information (originating device and the CCM nonce counter last 5759 received from that device), which allows detection of whether this 5760 particular CCM nonce value was used previously by the originating 5761 device. In addition, so-called delay protection is provided amongst 5762 those devices that have a loosely synchronized clock on board. The 5763 acceptable time delay can be adapted on a per-packet basis and allows 5764 for varying latencies (to facilitate longer latencies in packets 5765 transmitted over a multi-hop communication path). 5767 Cryptographic protection may use a key shared between two peer 5768 devices (link key) or a key shared among a group of devices (group 5769 key), thus allowing some flexibility and application-specific 5770 tradeoffs between key storage and key maintenance costs versus the 5771 cryptographic protection provided. If a group key is used for peer- 5772 to-peer communication, protection is provided only against outsider 5773 devices and not against potential malicious devices in the key- 5774 sharing group. 5776 Data authenticity may be provided using symmetric-key based or 5777 public-key based techniques. With public-key based techniques (via 5778 signatures), one corroborates evidence as to the unique originator of 5779 transmitted information, whereas with symmetric-key based techniques 5780 data authenticity is only provided relative to devices in a key- 5781 sharing group. Thus, public-key based authentication may be useful 5782 in scenarios that require a more fine-grained authentication than can 5783 be provided with symmetric-key based authentication techniques alone, 5784 such as with group communications (broadcast, multicast), or in 5785 scenarios that require non-repudiation. 5787 20. IANA Considerations 5789 20.1. RPL Control Message 5791 The RPL Control Message is an ICMP information message type that is 5792 to be used carry DODAG Information Objects, DODAG Information 5793 Solicitations, and Destination Advertisement Objects in support of 5794 RPL operation. 5796 IANA has defined an ICMPv6 Type Number Registry. The suggested type 5797 value for the RPL Control Message is 155, to be confirmed by IANA. 5799 20.2. New Registry for RPL Control Codes 5801 IANA is requested to create a registry, RPL Control Codes, for the 5802 Code field of the ICMPv6 RPL Control Message. 5804 New codes may be allocated only by an IETF Review. Each code should 5805 be tracked with the following qualities: 5807 o Code 5809 o Description 5811 o Defining RFC 5813 The following codes are currently defined: 5815 +------+----------------------------------------------+-------------+ 5816 | Code | Description | Reference | 5817 +------+----------------------------------------------+-------------+ 5818 | 0x00 | DODAG Information Solicitation | This | 5819 | | | document | 5820 | | | | 5821 | 0x01 | DODAG Information Object | This | 5822 | | | document | 5823 | | | | 5824 | 0x02 | Destination Advertisement Object | This | 5825 | | | document | 5826 | | | | 5827 | 0x03 | Destination Advertisement Object | This | 5828 | | Acknowledgment | document | 5829 | | | | 5830 | 0x80 | Secure DODAG Information Solicitation | This | 5831 | | | document | 5832 | | | | 5833 | 0x81 | Secure DODAG Information Object | This | 5834 | | | document | 5835 | 0x82 | Secure Destination Advertisement Object | This | 5836 | | | document | 5837 | | | | 5838 | 0x83 | Secure Destination Advertisement Object | This | 5839 | | Acknowledgment | document | 5840 | | | | 5841 | 0x8A | Consistency Check | This | 5842 | | | document | 5843 +------+----------------------------------------------+-------------+ 5845 RPL Control Codes 5847 20.3. New Registry for the Mode of Operation (MOP) 5849 IANA is requested to create a registry for the 3-bit Mode of 5850 Operation (MOP), which is contained in the DIO Base. 5852 New values may be allocated only by an IETF Review. Each value 5853 should be tracked with the following qualities: 5855 o Mode of Operation Value 5857 o Capability description 5859 o Defining RFC 5861 Four values are currently defined: 5863 +----------+------------------------------------------+-------------+ 5864 | MOP | Description | Reference | 5865 | value | | | 5866 +----------+------------------------------------------+-------------+ 5867 | 0 | No downward routes maintained by RPL | This | 5868 | | | document | 5869 | | | | 5870 | 1 | Non-Storing mode of operation | This | 5871 | | | document | 5872 | | | | 5873 | 2 | Storing mode of operation with no | This | 5874 | | multicast support | document | 5875 | | | | 5876 | 3 | Storing mode of operation with multicast | This | 5877 | | support | document | 5878 +----------+------------------------------------------+-------------+ 5880 DIO Mode of operation 5882 The rest of the range, decimal 4 to 7, is currently unassigned. 5884 20.4. RPL Control Message Option 5886 IANA is requested to create a registry for the RPL Control Message 5887 Options 5889 New values may be allocated only by an IETF Review. Each value 5890 should be tracked with the following qualities: 5892 o Value 5894 o Meaning 5896 o Defining RFC 5898 +-------+-----------------------+---------------+ 5899 | Value | Meaning | Reference | 5900 +-------+-----------------------+---------------+ 5901 | 0 | Pad1 | This document | 5902 | | | | 5903 | 1 | PadN | This document | 5904 | | | | 5905 | 2 | DAG Metric Container | This Document | 5906 | | | | 5907 | 3 | Routing Information | This Document | 5908 | | | | 5909 | 4 | DODAG Configuration | This Document | 5910 | | | | 5911 | 5 | RPL Target | This Document | 5912 | | | | 5913 | 6 | Transit Information | This Document | 5914 | | | | 5915 | 7 | Solicited Information | This Document | 5916 | | | | 5917 | 8 | Prefix Information | This Document | 5918 | | | | 5919 | 9 | Target Descriptor | This Document | 5920 +-------+-----------------------+---------------+ 5922 RPL Control Message Options 5924 20.5. Objective Code Point (OCP) Registry 5926 IANA is requested to create a registry to manage the codespace of the 5927 Objective Code Point (OCP) field. 5929 No OCP codepoints are defined in this specification. 5931 New codes may be allocated only by an IETF Review. Each code should 5932 be tracked with the following qualities: 5934 o OCP code 5936 o Description 5938 o Defining RFC 5940 20.6. New Registry for the Security Section Algorithm 5942 IANA is requested to create a registry for the values of 8-bit 5943 Algorithm field in the Security Section. 5945 New values may be allocated only by an IETF Review. Each value 5946 should be tracked with the following qualities: 5948 o Value 5950 o Encryption/MAC 5952 o Signature 5954 o Defining RFC 5956 The following value is currently defined: 5958 +-------+------------------+------------------+---------------+ 5959 | Value | Encryption/MAC | Signature | Reference | 5960 +-------+------------------+------------------+---------------+ 5961 | 0 | CCM with AES-128 | RSA with SHA-256 | This document | 5962 +-------+------------------+------------------+---------------+ 5964 Security Section Algorithm 5966 20.7. New Registry for the Security Section Flags 5968 IANA is requested to create a registry for the 8-bit Security Section 5969 Flag Field. 5971 New bit numbers may be allocated only by an IETF Review. Each bit 5972 should be tracked with the following qualities: 5974 o Bit number (counting from bit 0 as the most significant bit) 5976 o Capability description 5978 o Defining RFC 5979 No bit is currently defined for the Security Section Flags. 5981 20.8. New Registry for Per-KIM Security Levels 5983 IANA is requested to create one registry for the 3-bit Security Level 5984 (LVL) Field per allocated KIM value. 5986 For a given KIM value, new levels may be allocated only by an IETF 5987 Review. Each level should be tracked with the following qualities: 5989 o Level 5991 o KIM value 5993 o Description 5995 o Defining RFC 5997 The following levels pre KIM value are currently defined: 5999 +-------+-----------+---------------+---------------+ 6000 | Level | KIM value | Description | Reference | 6001 +-------+-----------+---------------+---------------+ 6002 | 0 | 0 | See Figure 11 | This document | 6003 | | | | | 6004 | 1 | 0 | See Figure 11 | This document | 6005 | | | | | 6006 | 2 | 0 | See Figure 11 | This document | 6007 | | | | | 6008 | 3 | 0 | See Figure 11 | This document | 6009 | | | | | 6010 | 0 | 1 | See Figure 11 | This document | 6011 | | | | | 6012 | 1 | 1 | See Figure 11 | This document | 6013 | | | | | 6014 | 2 | 1 | See Figure 11 | This document | 6015 | | | | | 6016 | 3 | 1 | See Figure 11 | This document | 6017 | | | | | 6018 | 0 | 2 | See Figure 11 | This document | 6019 | | | | | 6020 | 1 | 2 | See Figure 11 | This document | 6021 | | | | | 6022 | 2 | 2 | See Figure 11 | This document | 6023 | | | | | 6024 | 3 | 2 | See Figure 11 | This document | 6025 | | | | | 6026 | 0 | 3 | See Figure 11 | This document | 6027 | | | | | 6028 | 1 | 3 | See Figure 11 | This document | 6029 | | | | | 6030 | 2 | 3 | See Figure 11 | This document | 6031 | | | | | 6032 | 3 | 3 | See Figure 11 | This document | 6033 +-------+-----------+---------------+---------------+ 6035 Per-KIM Security Levels 6037 20.9. New Registry for the DIS (DODAG Informational Solicitation) Flags 6039 IANA is requested to create a registry for the DIS (DODAG 6040 Informational Solicitation) Flag Field. 6042 New bit numbers may be allocated only by an IETF Review. Each bit 6043 should be tracked with the following qualities: 6045 o Bit number (counting from bit 0 as the most significant bit) 6047 o Capability description 6049 o Defining RFC 6051 No bit is currently defined for the DIS (DODAG Informational 6052 Solicitation) Flags. 6054 20.10. New Registry for the DODAG Information Object (DIO) Flags 6056 IANA is requested to create a registry for the 8-bit DODAG 6057 Information Object (DIO) Flag Field. 6059 New bit numbers may be allocated only by an IETF Review. Each bit 6060 should be tracked with the following qualities: 6062 o Bit number (counting from bit 0 as the most significant bit) 6064 o Capability description 6066 o Defining RFC 6068 No bit is currently defined for the DIS (DODAG Informational 6069 Solicitation) Flags. 6071 20.11. New Registry for the Destination Advertisement Object (DAO) 6072 Flags 6074 IANA is requested to create a registry for the 8-bit Destination 6075 Advertisement Object (DAO) Flag Field. 6077 New bit numbers may be allocated only by an IETF Review. Each bit 6078 should be tracked with the following qualities: 6080 o Bit number (counting from bit 0 as the most significant bit) 6082 o Capability description 6084 o Defining RFC 6086 The following bits are currently defined: 6088 +------------+------------------------------+---------------+ 6089 | Bit number | Description | Reference | 6090 +------------+------------------------------+---------------+ 6091 | 0 | DAO-ACK request (K) | This document | 6092 | | | | 6093 | 1 | DODAGID field is present (D) | This document | 6094 +------------+------------------------------+---------------+ 6096 DAO Base Flags 6098 20.12. New Registry for the Destination Advertisement Object (DAO) 6099 Acknowledgement Flags 6101 IANA is requested to create a registry for the 8-bit Destination 6102 Advertisement Object (DAO) Acknowledgement Flag Field. 6104 New bit numbers may be allocated only by an IETF Review. Each bit 6105 should be tracked with the following qualities: 6107 o Bit number (counting from bit 0 as the most significant bit) 6109 o Capability description 6111 o Defining RFC 6113 The following bit is currently defined: 6115 +------------+------------------------------+---------------+ 6116 | Bit number | Description | Reference | 6117 +------------+------------------------------+---------------+ 6118 | 0 | DODAGID field is present (D) | This document | 6119 +------------+------------------------------+---------------+ 6121 DAO-ACK Base Flags 6123 20.13. New Registry for the Consistency Check (CC) Flags 6125 IANA is requested to create a registry for the 8-bit Consistency 6126 Check (CC) Flag Field. 6128 New bit numbers may be allocated only by an IETF Review. Each bit 6129 should be tracked with the following qualities: 6131 o Bit number (counting from bit 0 as the most significant bit) 6133 o Capability description 6134 o Defining RFC 6136 The following bit is currently defined: 6138 +------------+-----------------+---------------+ 6139 | Bit number | Description | Reference | 6140 +------------+-----------------+---------------+ 6141 | 0 | CC Response (R) | This document | 6142 +------------+-----------------+---------------+ 6144 Consistency Check Base Flags 6146 20.14. New Registry for the DODAG Configuration Option Flags 6148 IANA is requested to create a registry for the 8-bit DODAG 6149 Configuration Option Flag Field. 6151 New bit numbers may be allocated only by an IETF Review. Each bit 6152 should be tracked with the following qualities: 6154 o Bit number (counting from bit 0 as the most significant bit) 6156 o Capability description 6158 o Defining RFC 6160 The following bits are currently defined: 6162 +------------+----------------------------+---------------+ 6163 | Bit number | Description | Reference | 6164 +------------+----------------------------+---------------+ 6165 | 4 | Authentication Enabled (A) | This document | 6166 | | | | 6167 | 5-7 | Path Control Size (PCS) | This document | 6168 +------------+----------------------------+---------------+ 6170 DODAG Configuration Option Flags 6172 20.15. New Registry for the RPL Target Option Flags 6174 IANA is requested to create a registry for the 8-bit RPL Target 6175 Option Flag Field. 6177 New bit numbers may be allocated only by an IETF Review. Each bit 6178 should be tracked with the following qualities: 6180 o Bit number (counting from bit 0 as the most significant bit) 6182 o Capability description 6184 o Defining RFC 6186 No bit is currently defined for the RPL Target Option Flags. 6188 20.16. New Registry for the Transit Information Option Flags 6190 IANA is requested to create a registry for the 8-bit Transit 6191 Information Option (RIO) Flag Field. 6193 New bit numbers may be allocated only by an IETF Review. Each bit 6194 should be tracked with the following qualities: 6196 o Bit number (counting from bit 0 as the most significant bit) 6198 o Capability description 6200 o Defining RFC 6202 The following bits are currently defined: 6204 +------------+--------------+---------------+ 6205 | Bit number | Description | Reference | 6206 +------------+--------------+---------------+ 6207 | 0 | External (E) | This document | 6208 +------------+--------------+---------------+ 6210 Transit Information Option Flags 6212 20.17. New Registry for the Solicited Information Option Flags 6214 IANA is requested to create a registry for the 8-bit Solicited 6215 Information Option (RIO) Flag Field. 6217 New bit numbers may be allocated only by an IETF Review. Each bit 6218 should be tracked with the following qualities: 6220 o Bit number (counting from bit 0 as the most significant bit) 6222 o Capability description 6224 o Defining RFC 6226 The following bits are currently defined: 6228 +------------+--------------------------------+---------------+ 6229 | Bit number | Description | Reference | 6230 +------------+--------------------------------+---------------+ 6231 | 0 | Version Predicate match (V) | This document | 6232 | | | | 6233 | 1 | InstanceID Predicate match (I) | This document | 6234 | | | | 6235 | 2 | DODAGID Predicate match (D) | This document | 6236 +------------+--------------------------------+---------------+ 6238 Solicited Information Option Flags 6240 20.18. ICMPv6: Error in Source Routing Header 6242 In some cases RPL will return an ICMPv6 error message when a message 6243 cannot be delivered as specified by its source routing header. This 6244 ICMPv6 error message is "Error in Source Routing Header". 6246 IANA has defined an ICMPv6 "Code" Fields Registry for ICMPv6 Message 6247 Types. ICMPv6 Message Type 1 describes "Destination Unreachable" 6248 codes. The "Error in Source Routing Header" code is suggested to be 6249 allocated from the ICMPv6 Code Fields Registry for ICMPv6 Message 6250 Type 1, with a suggested code value of 7, to be confirmed by IANA. 6252 20.19. Link-Local Scope multicast address 6254 The rules for assigning new IPv6 multicast addresses are defined in 6255 [RFC3307]. This specification requires the allocation of a new 6256 permanent multicast address with a link local scope for RPL nodes 6257 called all-RPL-nodes, with a suggested value of FF02::1A, to be 6258 confirmed by IANA. 6260 21. Acknowledgements 6262 The authors would like to acknowledge the review, feedback, and 6263 comments from Roger Alexander, Emmanuel Baccelli, Dominique Barthel, 6264 Yusuf Bashir, Yoav Ben-Yehezkel, Phoebus Chen, Quynh Dang, Mischa 6265 Dohler, Mathilde Durvy, Joakim Eriksson, Omprakash Gnawali, Manhar 6266 Goindi, Mukul Goyal, Ulrich Herberg, Anders Jagd, JeongGil (John) Ko, 6267 Ajay Kumar, Quentin Lampin, Jerry Martocci, Matteo Paris, Alexandru 6268 Petrescu, Joseph Reddy, Michael Richardson, Don Sturek, Joydeep 6269 Tripathi, and Nicolas Tsiftes. 6271 The authors would like to acknowledge the guidance and input provided 6272 by the ROLL Chairs, David Culler and JP Vasseur, and the Area 6273 Director Adrian Farrel. 6275 The authors would like to acknowledge prior contributions of Robert 6276 Assimiti, Mischa Dohler, Julien Abeille, Ryuji Wakikawa, Teco Boot, 6277 Patrick Wetterwald, Bryan Mclaughlin, Carlos J. Bernardos, Thomas 6278 Watteyne, Zach Shelby, Caroline Bontoux, Marco Molteni, Billy Moon, 6279 Jim Bound, Yanick Pouffary, Henning Rogge and Arsalan Tavakoli, whom 6280 have provided useful design considerations to RPL. 6282 RPL Security Design, found in Section 10, Section 19, and elsewhere 6283 throughout the document, is primarily the contribution of the 6284 Security Design Team: Tzeta Tsao, Roger Alexander, Dave Ward, Philip 6285 Levis, Kris Pister, Rene Struik, and Adrian Farrel. 6287 Thanks also to Jari Arkko and Ralph Droms for their attentive 6288 reviews, especially with respect to interoperability considerations 6289 and integration with other IETF specifications. 6291 22. Contributors 6293 Stephen Dawson-Haggerty 6294 UC Berkeley 6295 Soda Hall, UC Berkeley 6296 Berkeley, CA 94720 6297 USA 6299 Email: stevedh@cs.berkeley.edu 6301 23. References 6303 23.1. Normative References 6305 [I-D.ietf-6man-rpl-option] 6306 Hui, J. and J. Vasseur, "RPL Option for Carrying RPL 6307 Information in Data-Plane Datagrams", 6308 draft-ietf-6man-rpl-option-02 (work in progress), 6309 February 2011. 6311 [I-D.ietf-6man-rpl-routing-header] 6312 Hui, J., Vasseur, J., Culler, D., and V. Manral, "An IPv6 6313 Routing Header for Source Routes with RPL", 6314 draft-ietf-6man-rpl-routing-header-02 (work in progress), 6315 March 2011. 6317 [I-D.ietf-roll-of0] 6318 Thubert, P., "RPL Objective Function 0", 6319 draft-ietf-roll-of0-07 (work in progress), March 2011. 6321 [I-D.ietf-roll-routing-metrics] 6322 Vasseur, J., Kim, M., Pister, K., Dejean, N., and D. 6323 Barthel, "Routing Metrics used for Path Calculation in Low 6324 Power and Lossy Networks", 6325 draft-ietf-roll-routing-metrics-19 (work in progress), 6326 March 2011. 6328 [I-D.ietf-roll-trickle] 6329 Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 6330 "The Trickle Algorithm", draft-ietf-roll-trickle-08 (work 6331 in progress), January 2011. 6333 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 6334 Requirement Levels", BCP 14, RFC 2119, March 1997. 6336 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 6337 (IPv6) Specification", RFC 2460, December 1998. 6339 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 6340 Standards (PKCS) #1: RSA Cryptography Specifications 6341 Version 2.1", RFC 3447, February 2003. 6343 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 6344 in IPv6", RFC 3775, June 2004. 6346 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 6347 More-Specific Routes", RFC 4191, November 2005. 6349 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 6350 December 2005. 6352 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 6353 Message Protocol (ICMPv6) for the Internet Protocol 6354 Version 6 (IPv6) Specification", RFC 4443, March 2006. 6356 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 6357 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 6358 September 2007. 6360 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 6361 Address Autoconfiguration", RFC 4862, September 2007. 6363 23.2. Informative References 6365 [FIPS180] National Institute of Standards and Technology, "FIPS Pub 6366 180-3, Secure Hash Standard (SHS)", US Department of 6367 Commerce , February 2008, 6368 . 6370 [I-D.ietf-6lowpan-nd] 6371 Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor 6372 Discovery Optimization for Low-power and Lossy Networks", 6373 draft-ietf-6lowpan-nd-15 (work in progress), 6374 December 2010. 6376 [I-D.ietf-manet-nhdp] 6377 Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc 6378 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 6379 draft-ietf-manet-nhdp-15 (work in progress), 6380 December 2010. 6382 [I-D.ietf-roll-terminology] 6383 Vasseur, J., "Terminology in Low power And Lossy 6384 Networks", draft-ietf-roll-terminology-04 (work in 6385 progress), September 2010. 6387 [Perlman83] 6388 Perlman, R., "Fault-Tolerant Broadcast of Routing 6389 Information", North-Holland Computer Networks 7: 395-405, 6390 1983, . 6393 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", 6394 RFC 1958, June 1996. 6396 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 6397 August 1996. 6399 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 6400 Schoenwaelder, Ed., "Structure of Management Information 6401 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 6403 [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast 6404 Addresses", RFC 3307, August 2002. 6406 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 6407 "Introduction and Applicability Statements for Internet- 6408 Standard Management Framework", RFC 3410, December 2002. 6410 [RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network 6411 Management Workshop", RFC 3535, May 2003. 6413 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 6414 CBC-MAC (CCM)", RFC 3610, September 2003. 6416 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 6417 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 6418 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 6419 RFC 3819, July 2004. 6421 [RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, 6422 June 2005. 6424 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 6425 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 6426 RFC 4915, June 2007. 6428 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 6429 Topology (MT) Routing in Intermediate System to 6430 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 6432 [RFC5184] Teraoka, F., Gogo, K., Mitsuya, K., Shibui, R., and K. 6433 Mitani, "Unified Layer 2 (L2) Abstractions for Layer 3 6434 (L3)-Driven Fast Handover", RFC 5184, May 2008. 6436 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 6437 "Routing Requirements for Urban Low-Power and Lossy 6438 Networks", RFC 5548, May 2009. 6440 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 6441 "Industrial Routing Requirements in Low-Power and Lossy 6442 Networks", RFC 5673, October 2009. 6444 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 6445 Management of New Protocols and Protocol Extensions", 6446 RFC 5706, November 2009. 6448 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 6449 Routing Requirements in Low-Power and Lossy Networks", 6450 RFC 5826, April 2010. 6452 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 6453 "Building Automation Routing Requirements in Low-Power and 6454 Lossy Networks", RFC 5867, June 2010. 6456 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 6457 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 6458 June 2010. 6460 Appendix A. Example Operation 6462 This appendix provides some examples to illustrate the dissemination 6463 of addressing information and prefixes with RPL. The examples depict 6464 information being distributed with PIO and RIO options, and the use 6465 of DIO and DAO messages. Note that this appendix is not normative, 6466 and that the specific details of a RPL addressing plan and 6467 autoconfiguration may vary according to specific implementations. 6468 RPL merely provides a vehicle for disseminating information that may 6469 be built upon and used by other mechanisms. 6471 Note that these examples illustrate use of address autoconfiguration 6472 schemes supported by information distributed within RPL. However, if 6473 an implementation includes another address autoconfiguration scheme, 6474 RPL nodes might be configured not to set the 'A' flag in PIO options, 6475 though the PIO can still be used to distribute prefix and addressing 6476 information. 6478 A.1. Example Operation in Storing Mode With Node-owned Prefixes 6480 Figure 32 illustrates the logical addressing architecture of a simple 6481 RPL network operating in storing mode. In this example each node, A, 6482 B, C, and D, owns its own prefix, and makes that prefix available for 6483 address autoconfiguration by on-link devices. (This is conveyed by 6484 setting the 'A' flag and the 'L' flag in the PIO of the DIO 6485 messages). Node A owns the prefix A::/64, node B owns B::/64, and so 6486 on. Node B autoconfigures an on-link address with respect to node A, 6487 A::B. Nodes C and D similarly autoconfigure on-link addresses from 6488 Node B's prefix, B::C and B::D respectively. Nodes have the option 6489 of setting the 'R' flag and publishing their address within the 6490 Prefix field of the PIO. 6492 +-------------+ 6493 | Root | 6494 | | 6495 | Node A | 6496 | | 6497 | A::A | 6498 +------+------+ 6499 | 6500 | 6501 | 6502 +------+------+ 6503 | A::B | 6504 | | 6505 | Node B | 6506 | | 6507 | B::B | 6508 +------+------+ 6509 | 6510 | 6511 .--------------+--------------. 6512 / \ 6513 / \ 6514 +------+------+ +------+------+ 6515 | B::C | | B::D | 6516 | | | | 6517 | Node C | | Node D | 6518 | | | | 6519 | C::C | | D::D | 6520 +-------------+ +-------------+ 6522 Figure 32: Storing Mode with Node-owned Prefixes 6524 A.1.1. DIO messages and PIO 6526 Node A, for example, will send DIO messages with a PIO as follows: 6527 'A' flag: Set 6528 'L' flag: Set 6529 'R' flag: Clear 6530 Prefix Length: 64 6531 Prefix: A:: 6533 Node B, for example, will send DIO messages with a PIO as follows: 6534 'A' flag: Set 6535 'L' flag: Set 6536 'R' flag: Set 6537 Prefix Length: 64 6538 Prefix: B::B 6540 Node C, for example, will send DIO messages with a PIO as follows: 6541 'A' flag: Set 6542 'L' flag: Set 6543 'R' flag: Clear 6544 Prefix Length: 64 6545 Prefix: C:: 6547 Node D, for example, will send DIO messages with a PIO as follows: 6548 'A' flag: Set 6549 'L' flag: Set 6550 'R' flag: Set 6551 Prefix Length: 64 6552 Prefix: D::D 6554 A.1.2. DAO messages 6556 Node B will send DAO messages to node A with the following 6557 information: 6558 o Target B::/64 6559 o Target C::/64 6560 o Target D::/64 6562 Node C will send DAO messages to node B with the following 6563 information: 6564 o Target C::/64 6566 Node D will send DAO messages to node B with the following 6567 information: 6568 o Target D::/64 6570 A.1.3. Routing Information Base 6572 Node A will conceptually collect the following information into its 6573 RIB: 6574 o A::/64 connected 6575 o B::/64 via B's link local 6576 o C::/64 via B's link local 6577 o D::/64 via B's link local 6579 Node B will conceptually collect the following information into its 6580 RIB: 6582 o ::/0 via A's link local 6583 o B::/64 connected 6584 o C::/64 via C's link local 6585 o D::/64 via D's link local 6587 Node C will conceptually collect the following information into its 6588 RIB: 6589 o ::/0 via B's link local 6590 o C::/64 connected 6592 Node D will conceptually collect the following information into its 6593 RIB: 6594 o ::/0 via B's link local 6595 o D::/64 connected 6597 A.2. Example Operation in Storing Mode With Subnet-wide Prefix 6599 Figure 33 illustrates the logical addressing architecture of a simple 6600 RPL network operating in storing mode. In this example the root node 6601 A sources a prefix which is used for address autoconfiguration over 6602 the entire RPL subnet. (This is conveyed by setting the 'A' flag and 6603 clearing the 'L' flag in the PIO of the DIO messages). Nodes A, B, 6604 C, and D all autoconfigure to the prefix A::/64. Nodes have the 6605 option of setting the 'R' flag and publishing their address within 6606 the Prefix field of the PIO. 6608 +-------------+ 6609 | Root | 6610 | | 6611 | Node A | 6612 | A::A | 6613 | | 6614 +------+------+ 6615 | 6616 | 6617 | 6618 +------+------+ 6619 | | 6620 | Node B | 6621 | A::B | 6622 | | 6623 +------+------+ 6624 | 6625 | 6626 .--------------+--------------. 6627 / \ 6628 / \ 6629 +------+------+ +------+------+ 6630 | | | | 6631 | Node C | | Node D | 6632 | A::C | | A::D | 6633 | | | | 6634 +-------------+ +-------------+ 6636 Figure 33: Storing Mode with Subnet-wide Prefix 6638 A.2.1. DIO messages and PIO 6640 Node A, for example, will send DIO messages with a PIO as follows: 6641 'A' flag: Set 6642 'L' flag: Clear 6643 'R' flag: Clear 6644 Prefix Length: 64 6645 Prefix: A:: 6647 Node B, for example, will send DIO messages with a PIO as follows: 6648 'A' flag: Set 6649 'L' flag: Clear 6650 'R' flag: Set 6651 Prefix Length: 64 6652 Prefix: A::B 6654 Node C, for example, will send DIO messages with a PIO as follows: 6655 'A' flag: Set 6656 'L' flag: Clear 6657 'R' flag: Clear 6658 Prefix Length: 64 6659 Prefix: A:: 6661 Node D, for example, will send DIO messages with a PIO as follows: 6662 'A' flag: Set 6663 'L' flag: Clear 6664 'R' flag: Set 6665 Prefix Length: 64 6666 Prefix: A::D 6668 A.2.2. DAO messages 6670 Node B will send DAO messages to node A with the following 6671 information: 6672 o Target A::B/128 6673 o Target A::C/128 6674 o Target A::D/128 6676 Node C will send DAO messages to node B with the following 6677 information: 6678 o Target A::C/128 6680 Node D will send DAO messages to node B with the following 6681 information: 6682 o Target A::D/128 6684 A.2.3. Routing Information Base 6686 Node A will conceptually collect the following information into its 6687 RIB: 6688 o A::A/128 connected 6689 o A::B/128 via B's link local 6690 o A::C/128 via B's link local 6691 o A::D/128 via B's link local 6693 Node B will conceptually collect the following information into its 6694 RIB: 6696 o ::/0 via A's link local 6697 o A::B/128 connected 6698 o A::C/128 via C's link local 6699 o A::D/128 via D's link local 6701 Node C will conceptually collect the following information into its 6702 RIB: 6703 o ::/0 via B's link local 6704 o A::C/128 connected 6706 Node D will conceptually collect the following information into its 6707 RIB: 6708 o ::/0 via B's link local 6709 o A::D/128 connected 6711 A.3. Example Operation in Non-Storing Mode With Node-owned Prefixes 6713 Figure 34 illustrates the logical addressing architecture of a simple 6714 RPL network operating in non-storing mode. In this example each 6715 node, A, B, C, and D, owns its own prefix, and makes that prefix 6716 available for address autoconfiguration by on-link devices. (This is 6717 conveyed by setting the 'A' flag and the 'L' flag in the PIO of the 6718 DIO messages). Node A owns the prefix A::/64, node B owns B::/64, 6719 and so on. Node B autoconfigures an on-link address with respect to 6720 node A, A::B. Nodes C and D similarly autoconfigure on-link addresses 6721 from Node B's prefix, B::C and B::D respectively. Nodes have the 6722 option of setting the 'R' flag and publishing their address within 6723 the Prefix field of the PIO. 6725 +-------------+ 6726 | Root | 6727 | | 6728 | Node A | 6729 | | 6730 | A::A | 6731 +------+------+ 6732 | 6733 | 6734 | 6735 +------+------+ 6736 | A::B | 6737 | | 6738 | Node B | 6739 | | 6740 | B::B | 6741 +------+------+ 6742 | 6743 | 6744 .--------------+--------------. 6745 / \ 6746 / \ 6747 +------+------+ +------+------+ 6748 | B::C | | B::D | 6749 | | | | 6750 | Node C | | Node D | 6751 | | | | 6752 | C::C | | D::D | 6753 +-------------+ +-------------+ 6755 Figure 34: Non-storing Mode with Node-owned Prefixes 6757 A.3.1. DIO messages and PIO 6759 The PIO contained in the DIO messages in the non-storing mode with 6760 node-owned prefixes can be considered to be identical to those in the 6761 storing mode with node-owned prefixes case (Appendix A.1.1). 6763 A.3.2. DAO messages 6765 Node B will send DAO messages to node A with the following 6766 information: 6768 o Target B::/64, Transit A::B 6770 Node C will send DAO messages to node A with the following 6771 information: 6772 o Target C::/64, Transit B::C 6774 Node D will send DAO messages to node A with the following 6775 information: 6776 o Target D::/64, Transit B::D 6778 A.3.3. Routing Information Base 6780 Node A will conceptually collect the following information into its 6781 RIB. Note that Node A has enough information to construct source 6782 routes by doing recursive lookups into the RIB: 6783 o A::/64 connected 6784 o B::/64 via A::B 6785 o C::/64 via B::C 6786 o D::/64 via B::D 6788 Node B will conceptually collect the following information into its 6789 RIB: 6790 o ::/0 via A's link local 6791 o B::/64 connected 6793 Node C will conceptually collect the following information into its 6794 RIB: 6795 o ::/0 via B's link local 6796 o C::/64 connected 6798 Node D will conceptually collect the following information into its 6799 RIB: 6800 o ::/0 via B's link local 6801 o D::/64 connected 6803 A.4. Example Operation in Non-Storing Mode With Subnet-wide Prefix 6805 Figure 35 illustrates the logical addressing architecture of a simple 6806 RPL network operating in non-storing mode. In this example the root 6807 node A sources a prefix which is used for address autoconfiguration 6808 over the entire RPL subnet. (This is conveyed by setting the 'A' 6809 flag and clearing the 'L' flag in the PIO of the DIO messages). 6810 Nodes A, B, C, and D all autoconfigure to the prefix A::/64. Nodes 6811 must set the 'R' flag and publishing their address within the Prefix 6812 field of the PIO, in order to inform their children which address to 6813 use in the transit option. 6815 +-------------+ 6816 | Root | 6817 | | 6818 | Node A | 6819 | A::A | 6820 | | 6821 +------+------+ 6822 | 6823 | 6824 | 6825 +------+------+ 6826 | | 6827 | Node B | 6828 | A::B | 6829 | | 6830 +------+------+ 6831 | 6832 | 6833 .--------------+--------------. 6834 / \ 6835 / \ 6836 +------+------+ +------+------+ 6837 | | | | 6838 | Node C | | Node D | 6839 | A::C | | A::D | 6840 | | | | 6841 +-------------+ +-------------+ 6843 Figure 35: Non-Storing Mode With Subnet-wide Prefix 6845 A.4.1. DIO messages and PIO 6847 Node A, for example, will send DIO messages with a PIO as follows: 6848 'A' flag: Set 6849 'L' flag: Clear 6850 'R' flag: Set 6851 Prefix Length: 64 6852 Prefix: A::A 6854 Node B, for example, will send DIO messages with a PIO as follows: 6855 'A' flag: Set 6856 'L' flag: Clear 6857 'R' flag: Set 6858 Prefix Length: 64 6859 Prefix: A::B 6861 Node C, for example, will send DIO messages with a PIO as follows: 6862 'A' flag: Set 6863 'L' flag: Clear 6864 'R' flag: Set 6865 Prefix Length: 64 6866 Prefix: A::C 6868 Node D, for example, will send DIO messages with a PIO as follows: 6869 'A' flag: Set 6870 'L' flag: Clear 6871 'R' flag: Set 6872 Prefix Length: 64 6873 Prefix: A::D 6875 A.4.2. DAO messages 6877 Node B will send DAO messages to node A with the following 6878 information: 6879 o Target A::B/128, Transit A::A 6881 Node C will send DAO messages to node A with the following 6882 information: 6883 o Target A::C/128, Transit A::B 6885 Node D will send DAO messages to node A with the following 6886 information: 6887 o Target A::D/128, Transit A::B 6889 A.4.3. Routing Information Base 6891 Node A will conceptually collect the following information into its 6892 RIB. Note that Node A has enough information to construct source 6893 routes by doing recursive lookups into the RIB: 6894 o A::A/128 connected 6895 o A::B/128 via A::A 6896 o A::C/128 via A::B 6897 o A::D/128 via A::B 6899 Node B will conceptually collect the following information into its 6900 RIB: 6902 o ::/0 via A's link local 6903 o A::B/128 connected 6905 Node C will conceptually collect the following information into its 6906 RIB: 6907 o ::/0 via B's link local 6908 o A::C/128 connected 6910 Node D will conceptually collect the following information into its 6911 RIB: 6912 o ::/0 via B's link local 6913 o A::D/128 connected 6915 A.5. Example with External Prefixes 6917 Consider the simple network illustrated in Figure 36. In this 6918 example there are a group of routers participating in a RPL network: 6919 a DODAG Root, nodes A, Y, and Z. The DODAG Root and node Z also have 6920 connectivity to different external network domains (i.e. external to 6921 the RPL network). Note that those external networks could be RPL 6922 networks or another type of network altogether. 6924 RPL Network +-------------------+ 6925 RPL::/64 | | 6926 | External | 6927 [RPL::Root] (Root)----------+ Prefix | 6928 | | EXT_1::/64 | 6929 | | | 6930 | +-------------------+ 6931 [RPL::A] (A) 6932 : 6933 : 6934 : 6935 [RPL::Y] (Y) 6936 | +-------------------+ 6937 | | | 6938 | | External | 6939 [RPL::Z] (Z)------------+ Prefix | 6940 : | EXT_2::/64 | 6941 : | | 6942 : +-------------------+ 6944 Figure 36: Simple Network Example 6946 In this example the DODAG Root makes a prefix available to the RPL 6947 subnet for address autoconfiguration. Here the entire RPL subnet 6948 uses that same prefix, RPL::/64, for address autoconfiguration, 6949 though in other implementations more complex/hybrid schemes could be 6950 employed. 6952 The DODAG Root has connectivity to an external (with respect to that 6953 RPL network) prefix EXT_1::/64. The DODAG Root may have learned of 6954 connectivity to this prefix, for example, via explicit configuration 6955 or IPv6 ND on a non-RPL interface. The DODAG Root is configured to 6956 announce information on the connectivity to this prefix. 6958 Similarly, Node Z has connectivity to an external prefix EXT_2::/64. 6959 Node Z also has a sub-DODAG underneath of it. 6961 1. The DODAG Root adds a RIO to its DIO messages. The RIO contains 6962 the external prefix EXT_1::/64. This information may be repeated 6963 in the DIO messages emitted by the other nodes within the DODAG. 6964 Thus the reachability to the prefix EXT_1::/64 is disseminated 6965 down the DODAG. 6967 2. Node Z may advertise reachability to the target network 6968 EXT_2::/64 by sending DAO messages using EXT_2::/64 as a target 6969 in the Target option and itself (Node Z) as a parent in the 6970 Transit Information option. (In storing mode that Transit 6971 Information option does not need to contain the address of Node 6972 Z). A non-storing root then becomes aware of the 1-hop link 6973 (Node Z -- EXT_2::/64) for use in constructing source routes. 6974 Node Z may additionally advertise its reachability to EXT_2::/64 6975 to nodes in its sub-DODAG by sending DIO messages with a PIO, 6976 with the 'A' flag cleared. 6978 Authors' Addresses 6980 Tim Winter (editor) 6982 Email: wintert@acm.org 6984 Pascal Thubert (editor) 6985 Cisco Systems, Inc 6986 Village d'Entreprises Green Side 6987 400, Avenue de Roumanille 6988 Batiment T3 6989 Biot - Sophia Antipolis 06410 6990 France 6992 Phone: +33 497 23 26 34 6993 Email: pthubert@cisco.com 6995 Anders Brandt 6996 Sigma Designs 6997 Emdrupvej 26A, 1. 6998 Copenhagen DK-2100 6999 Denmark 7001 Email: abr@sdesigns.dk 7003 Thomas Heide Clausen 7004 LIX, Ecole Polytechnique, France 7006 Phone: +33 6 6058 9349 7007 Email: T.Clausen@computer.org 7008 URI: http://www.ThomasClausen.org/ 7010 Jonathan W. Hui 7011 Arch Rock Corporation 7012 501 2nd St. Ste. 410 7013 San Francisco, CA 94107 7014 USA 7016 Email: jhui@archrock.com 7017 Richard Kelsey 7018 Ember Corporation 7019 Boston, MA 7020 USA 7022 Phone: +1 617 951 1225 7023 Email: kelsey@ember.com 7025 Philip Levis 7026 Stanford University 7027 358 Gates Hall, Stanford University 7028 Stanford, CA 94305-9030 7029 USA 7031 Email: pal@cs.stanford.edu 7033 Kris Pister 7034 Dust Networks 7035 30695 Huntwood Ave. 7036 Hayward, CA 94544 7037 USA 7039 Email: kpister@dustnetworks.com 7041 Rene Struik 7043 Email: rstruik.ext@gmail.com 7045 JP Vasseur 7046 Cisco Systems, Inc 7047 11, Rue Camille Desmoulins 7048 Issy Les Moulineaux 92782 7049 France 7051 Email: jpv@cisco.com