idnits 2.17.1 draft-ietf-roll-efficient-npdao-09.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 (October 14, 2018) is 2021 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROLL R. Jadhav, Ed. 3 Internet-Draft Huawei 4 Intended status: Standards Track P. Thubert 5 Expires: April 17, 2019 Cisco 6 R. Sahoo 7 Z. Cao 8 Huawei 9 October 14, 2018 11 Efficient Route Invalidation 12 draft-ietf-roll-efficient-npdao-09 14 Abstract 16 This document describes the problems associated with NPDAO messaging 17 used in RPL for route invalidation and signaling changes to improve 18 route invalidation efficiency. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 17, 2019. 37 Copyright Notice 39 Copyright (c) 2018 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language and Terminology . . . . . . . . . . 3 56 1.2. Current NPDAO messaging . . . . . . . . . . . . . . . . . 4 57 1.3. Why NPDAO is important? . . . . . . . . . . . . . . . . . 5 58 2. Problems with current NPDAO messaging . . . . . . . . 5 59 2.1. Lost NPDAO due to link break to the previous parent . . . 5 60 2.2. Invalidate routes of dependent nodes . . . . . . . . . . 5 61 2.3. Possible route downtime caused by async operation of 62 NPDAO and DAO . . . . . . . . . . . . . . . . . . . . . . 6 63 3. Requirements for the NPDAO Optimization . . . . . . . . . . . 6 64 3.1. Req#1: Remove messaging dependency on link to the 65 previous parent . . . . . . . . . . . . . . . 6 66 3.2. Req#2: Dependent nodes route invalidation on parent 67 switching . . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.3. Req#3: Route invalidation should not impact data traffic 6 69 4. Proposed changes to RPL signaling . . . . . . . . . . . . . . 6 70 4.1. Change in RPL route invalidation semantics . . . . . . . 6 71 4.2. Transit Information Option changes . . . . . . . . . . . 7 72 4.3. Destination Cleanup Object (DCO) . . . . . . . . . . . . 8 73 4.3.1. Secure DCO . . . . . . . . . . . . . . . . . . . . . 10 74 4.3.2. DCO Options . . . . . . . . . . . . . . . . . . . . . 10 75 4.3.3. Path Sequence number in the DCO . . . . . . . . . . . 10 76 4.3.4. Destination Cleanup Option Acknowledgement (DCO-ACK) 10 77 4.3.5. Secure DCO-ACK . . . . . . . . . . . . . . . . . . . 11 78 4.4. Other considerations . . . . . . . . . . . . . . . . . . 12 79 4.4.1. Dependent Nodes invalidation . . . . . . . . . . . . 12 80 4.4.2. NPDAO and DCO in the same network . . . . . . . . . . 12 81 4.4.3. DCO with multiple preferred parents . . . . . . . . . 12 82 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 85 8. Normative References . . . . . . . . . . . . . . . . . . . . 14 86 Appendix A. Example Messaging . . . . . . . . . . . . . . . . . 14 87 A.1. Example DCO Messaging . . . . . . . . . . . . . . . . . . 14 88 A.2. Example DCO Messaging with multiple preferred parents . . 15 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 91 1. Introduction 93 RPL [RFC6550] (Routing Protocol for Low power and lossy networks) 94 specifies a proactive distance-vector based routing scheme. RPL has 95 an optional messaging in the form of DAO (Destination Advertisement 96 Object) messages using which the 6LBR (6Lo Border Router) and 6LR 97 (6Lo Router) can learn route towards the downstream nodes. In 98 storing mode, DAO messages would result in routing entries been 99 created on all intermediate 6LRs from the node's parent all the way 100 towards the 6LBR. 102 RPL allows use of No-Path DAO (NPDAO) messaging to invalidate a 103 routing path corresponding to the given target, thus releasing 104 resources utilized on that path. A NPDAO is a DAO message with route 105 lifetime of zero, originates at the target node and always flows 106 upstream towards the 6LBR. This document explains the problems 107 associated with the current use of NPDAO messaging and also discusses 108 the requirements for an optimized route invalidation messaging 109 scheme. Further a new pro-active route invalidation message called 110 as "Destination Cleanup Object (DCO)" is specified which fulfills 111 requirements of an optimized route invalidation messaging. 113 The document only caters to the RPL's storing mode of operation 114 (MOP). The non-storing MOP does not require use of NPDAO for route 115 invalidation since routing entries are not maintained on 6LRs. 117 1.1. Requirements Language and Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [RFC2119]. 123 6LR: 6LoWPAN Router. This is an intermediate 6lowpan router which 124 allows traffic routing through itself in a multihop 6lo network. 126 DAG: Directed Acyclic Graph. A directed graph having the property 127 that all edges are oriented in such a way that no cycles exist. 129 DODAG: Destination-oriented DAG. A DAG rooted at a single 130 destination, i.e., at a single DAG root with no outgoing edges. 132 6LBR: 6LoWPAN Border Router. A border router which is a DODAG root 133 and is the edge node for traffic flowing in and out of the 6lo 134 network. 136 DAO: Destination Advertisement Object. DAO messaging allows 137 downstream routes to the nodes to be established. 139 DIO: DODAG Information Object. DIO messaging allows upstream routes 140 to the 6LBR to be established. DIO messaging is initiated at the DAO 141 root. 143 Common Ancestor node: 6LR/6LBR node which is the first common node 144 between two paths of a target node. 146 NPDAO: No-Path DAO. A DAO message which has target with lifetime 0. 148 DCO: Destination Cleanup Object, A new RPL control message type 149 defined by this draft. DCO messaging improves proactive route 150 invalidation in RPL. 152 Regular DAO: A DAO message with non-zero lifetime. 154 LLN: Low Power and Lossy Networks. 156 Target Node: The node switching its parent whose routing adjacencies 157 are updated (created/removed). 159 This document also uses terminology described in [RFC6550]. 161 1.2. Current NPDAO messaging 163 RPL uses NPDAO messaging in the storing mode so that the node 164 changing it routing adjacencies can invalidate the previous route. 165 This is needed so that nodes along previous path can release any 166 resources (such as the routing entry) it maintains on behalf of 167 target node. 169 For the rest of this document consider the following topology: 171 (6LBR) 172 | 173 | 174 | 175 (A) 176 / \ 177 / \ 178 / \ 179 (G) (H) 180 | | 181 | | 182 | | 183 (B) (C) 184 \ ; 185 \ ; 186 \ ; 187 (D) 188 / \ 189 / \ 190 / \ 191 (E) (F) 193 Figure 1: Sample topology 195 Node (D) is connected via preferred parent (B). (D) has an alternate 196 path via (C) towards the 6LBR. Node (A) is the common ancestor for 197 (D) for paths through (B)-(G) and (C)-(H). When (D) switches from 198 (B) to (C), RPL allows sending NPDAO to (B) and regular DAO to (C). 200 1.3. Why NPDAO is important? 202 Nodes in LLNs may be resource constrained. There is limited memory 203 available and routing entry records are one of the primary elements 204 occupying dynamic memory in the nodes. Route invalidation helps 6LR 205 nodes to decide which entries could be discarded to better achieve 206 resource utilization. Thus it becomes necessary to have efficient 207 route invalidation mechanism. Also note that a single parent switch 208 may result in a "sub-tree" switching from one parent to another. 209 Thus the route invalidation needs to be done on behalf of the sub- 210 tree and not the switching node alone. In the above example, when 211 Node (D) switches parent, the route updates needs to be done for the 212 routing tables entries of (C),(H),(A),(G), and (B) with destination 213 (D),(E) and (F). Without efficient route invalidation, a 6LR may 214 have to hold a lot of stale route entries. 216 2. Problems with current NPDAO messaging 218 2.1. Lost NPDAO due to link break to the previous parent 220 When a node switches its parent, the NPDAO is to be sent to its 221 previous parent and a regular DAO to its new parent. In cases where 222 the node switches its parent because of transient or permanent parent 223 link/node failure then the NPDAO message is bound to fail. 225 2.2. Invalidate routes of dependent nodes 227 RPL does not specify how route invalidation will work for dependent 228 nodes rooted at switching node, resulting in stale routing entries of 229 the dependent nodes. The only way for 6LR to invalidate the route 230 entries for dependent nodes would be to use route lifetime expiry 231 which could be substantially high for LLNs. 233 In the example topology, when Node (D) switches its parent, Node (D) 234 generates an NPDAO on its behalf. There is no NPDAO generated by the 235 dependent child nodes (E) and (F), through the previous path via (D) 236 to (B) and (G), resulting in stale entries on nodes (B) and (G) for 237 nodes (E) and (F). 239 2.3. Possible route downtime caused by async operation of NPDAO and DAO 241 A switching node may generate both an NPDAO and DAO via two different 242 paths at almost the same time. There is a possibility that an NPDAO 243 generated may invalidate the previous route and the regular DAO sent 244 via the new path gets lost on the way. This may result in route 245 downtime impacting downward traffic for the switching node. 247 In the example topology, consider Node (D) switches from parent (B) 248 to (C). An NPDAO sent via previous route may invalidate the previous 249 route whereas there is no way to determine whether the new DAO has 250 successfully updated the route entries on the new path. 252 3. Requirements for the NPDAO Optimization 254 3.1. Req#1: Remove messaging dependency on link to the previous parent 256 When the switching node sends the NPDAO message to the previous 257 parent, it is normal that the link to the previous parent is prone to 258 failure (thats why the node decided to switch). Therefore, it is 259 required that the route invalidation does not depend on the previous 260 link which is prone to failure. The previous link referred here 261 represents the link between the node and its previous parent (from 262 whom the node is now disassociating). 264 3.2. Req#2: Dependent nodes route invalidation on parent switching 266 It should be possible to do route invalidation for dependent nodes 267 rooted at the switching node. 269 3.3. Req#3: Route invalidation should not impact data traffic 271 While sending the NPDAO and DAO messages, it is possible that the 272 NPDAO successfully invalidates the previous path, while the newly 273 sent DAO gets lost (new path not set up successfully). This will 274 result in downstream unreachability to the node switching paths. 275 Therefore, it is desirable that the route invalidation is 276 synchronized with the DAO to avoid the risk of route downtime. 278 4. Proposed changes to RPL signaling 280 4.1. Change in RPL route invalidation semantics 282 As described in Section 1.2, the NPDAO originates at the node 283 switching the parent and traverses upstream towards the root. In 284 order to solve the problems as mentioned in Section 2, the draft adds 285 new pro-active route invalidation message called as "Destination 286 Cleanup Object" (DCO) that originates at a common ancestor node 287 between the new and old path. The common ancestor node generates a 288 DCO in response to the change in the next-hop on receiving a regular 289 DAO with updated path sequence for the target. 291 In Figure 1, when node D decides to switch the path from B to C, it 292 sends a regular DAO to node C with reachability information 293 containing target as address of D and a incremented path sequence 294 number. Node C will update the routing table based on the 295 reachability information in DAO and in turn generate another DAO with 296 the same reachability information and forward it to H. Node H also 297 follows the same procedure as Node C and forwards it to node A. When 298 node A receives the regular DAO, it finds that it already has a 299 routing table entry on behalf of the target address of node D. It 300 finds however that the next hop information for reaching node D has 301 changed i.e. the node D has decided to change the paths. In this 302 case, Node A which is the common ancestor node for node D along the 303 two paths (previous and new), should generate a DCO which traverses 304 downwards in the network. 306 4.2. Transit Information Option changes 308 Every RPL message is divided into base message fields and additional 309 Options. The base fields apply to the message as a whole and options 310 are appended to add message/use-case specific attributes. As an 311 example, a DAO message may be attributed by one or more "RPL Target" 312 options which specify the reachability information for the given 313 targets. Similarly, a Transit Information option may be associated 314 with a set of RPL Target options. 316 The draft proposes a change in Transit Information option to contain 317 "Invalidate previous route" (I) bit. This I-bit signals the common 318 ancestor node to generate a DCO on behalf of the target node. The 319 I-bit is carried in the transit information option which augments the 320 reachability information for a given set of RPL Target(s). Transit 321 information option should be carried in the DAO message with I-bit 322 set in case route invalidation is sought for the correspondig 323 target(s). 325 0 1 2 3 326 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 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Type = 0x06 | Option Length |E|I| Flags | Path Control | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Path Sequence | Path Lifetime | | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 332 | | 333 + + 334 | | 335 + Parent Address* + 336 | | 337 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 Figure 2: Updated Transit Information Option (New I flag added) 343 I (Invalidate previous route) bit: 1 bit flag. The 'I' flag is set 344 by the target node to indicate that it wishes to invalidate the 345 previous route by a common ancestor node between the two paths. 347 The common ancestor node SHOULD generate a DCO message in response to 348 this I-bit when it sees that the routing adjacencies have changed for 349 the target. I-bit governs the ownership of the DCO message in a way 350 that the target node is still in control of its own route 351 invalidation. 353 4.3. Destination Cleanup Object (DCO) 355 A new ICMPv6 RPL control message type is defined by this 356 specification called as "Destination Cleanup Object" (DCO), which is 357 used for proactive cleanup of state and routing information held on 358 behalf of the target node by 6LRs. The DCO message always traverses 359 downstream and cleans up route information and other state 360 information associated with the given target. 362 0 1 2 3 363 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 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | RPLInstanceID |K|D| Flags | Reserved | DCOSequence | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | | 368 + + 369 | | 370 + DODAGID(optional) + 371 | | 372 + + 373 | | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Option(s)... 376 +-+-+-+-+-+-+-+-+ 378 Figure 3: DCO base object 380 RPLInstanceID: 8-bit field indicating the topology instance 381 associated with the DODAG, as learned from the DIO. 383 K: The 'K' flag indicates that the recipient is expected to send a 384 DCO-ACK back. If the DCO-ACK is not received even after setting the 385 'K', an implementation may choose to retry the DCO at a later time. 386 The number of retries are implementation and deployment dependent. 387 This document recommends using retries similar to what will be set 388 for DAO-ACK handling. 390 D: The 'D' flag indicates that the DODAGID field is present. This 391 flag MUST be set when a local RPLInstanceID is used. 393 Flags: The 6 bits remaining unused in the Flags field are reserved 394 for future use. These bits MUST be initialized to zero by the sender 395 and MUST be ignored by the receiver. 397 Reserved: 8-bit unused field. The field MUST be initialized to zero 398 by the sender and MUST be ignored by the receiver. 400 DCOSequence: Incremented at each unique DCO message from a node and 401 echoed in the DCO-ACK message. The initial DCOSequence can be chosen 402 randomly by the node. 404 DODAGID (optional): 128-bit unsigned integer set by a DODAG root that 405 uniquely identifies a DODAG. This field is only present when the 'D' 406 flag is set. This field is typically only present when a local 407 RPLInstanceID is in use, in order to identify the DODAGID that is 408 associated with the RPLInstanceID. When a global RPLInstanceID is in 409 use, this field need not be present. Unassigned bits of the DCO Base 410 are reserved. They MUST be set to zero on transmission and MUST be 411 ignored on reception. 413 4.3.1. Secure DCO 415 A Secure DCO message follows the format in [RFC6550] figure 7, where 416 the base message format is the DCO message shown in Figure 3. 418 4.3.2. DCO Options 420 The DCO message MAY carry valid options. This specification allows 421 for the DCO message to carry the following options: 423 0x00 Pad1 424 0x01 PadN 425 0x05 RPL Target 426 0x06 Transit Information 427 0x09 RPL Target Descriptor 429 The DCO carries a Target option and an associated Transit Information 430 option with a lifetime of 0x00000000 to indicate a loss of 431 reachability to that Target. 433 4.3.3. Path Sequence number in the DCO 435 A DCO message may contain a Path Sequence in the transit information 436 option to identify the freshness of the DCO message. The Path 437 Sequence in the DCO MUST use the same Path Sequence number present in 438 the regular DAO message when the DCO is generated in response to DAO 439 message. The DAO and DCO path sequence are picked from the same 440 sequence number set. Thus if a DCO is received by a 6LR and 441 subsequently a DAO is received with old seqeunce number, then the DAO 442 should be ignored. 444 4.3.4. Destination Cleanup Option Acknowledgement (DCO-ACK) 446 The DCO-ACK message may be sent as a unicast packet by a DCO 447 recipient in response to a unicast DCO message. 449 0 1 2 3 450 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 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | RPLInstanceID |D| Reserved | DCOSequence | Status | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | | 455 + + 456 | | 457 + DODAGID(optional) + 458 | | 459 + + 460 | | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 Figure 4: DCO-ACK base object 465 RPLInstanceID: 8-bit field indicating the topology instance 466 associated with the DODAG, as learned from the DIO. 468 D: The 'D' flag indicates that the DODAGID field is present. This 469 flag MUST be set when a local RPLInstanceID is used. 471 Reserved: 7-bit unused field. The field MUST be initialized to zero 472 by the sender and MUST be ignored by the receiver. 474 DCOSequence: The DCOSequence in DCO-ACK is copied from the 475 DCOSequence received in the DCO message. 477 Status: Indicates the completion. Status 0 is defined as unqualified 478 acceptance in this specification. The remaining status values are 479 reserved as rejection codes. 481 DODAGID (optional): 128-bit unsigned integer set by a DODAG root that 482 uniquely identifies a DODAG. This field is only present when the 'D' 483 flag is set. This field is typically only present when a local 484 RPLInstanceID is in use, in order to identify the DODAGID that is 485 associated with the RPLInstanceID. When a global RPLInstanceID is in 486 use, this field need not be present. Unassigned bits of the DCO-Ack 487 Base are reserved. They MUST be set to zero on transmission and MUST 488 be ignored on reception. 490 4.3.5. Secure DCO-ACK 492 A Secure DCO-ACK message follows the format in [RFC6550] figure 7, 493 where the base message format is the DCO-ACK message shown in 494 Figure 4. 496 4.4. Other considerations 498 4.4.1. Dependent Nodes invalidation 500 Current RPL [RFC6550] does not provide a mechanism for route 501 invalidation for dependent nodes. This document allows the dependent 502 nodes invalidation. Dependent nodes will generate their respective 503 DAOs to update their paths, and the previous route invalidation for 504 those nodes should work in the similar manner described for switching 505 node. The dependent node may set the I-bit in the transit 506 information option as part of regular DAO so as to request 507 invalidation of previous route from the common ancestor node. 509 4.4.2. NPDAO and DCO in the same network 511 Even with the changed semantics, the current NPDAO mechanism in 512 [RFC6550] can still be used, for example, when the route lifetime 513 expiry of the target happens or when the node simply decides to 514 gracefully terminate the RPL session on graceful node shutdown. 515 Moreover a deployment can have a mix of nodes supporting the proposed 516 DCO and the existing NPDAO mechanism. 518 4.4.3. DCO with multiple preferred parents 520 [RFC6550] allows a node to select multiple preferred parents for 521 route establishment. Section 9.2.1 of [RFC6550] specifies, "All DAOs 522 generated at the same time for the same Target MUST be sent with the 523 same Path Sequence in the Transit Information". Thus a DAO message 524 with the same path sequence MUST be sent to all the parents. 525 Subsequently when route invalidation has to be initiated, RPL 526 mentions that an NPDAO must be initiated with updated path sequence 527 to all the routes to be invalidated. 529 With DCO, the Target node itself does not initiate the route 530 invalidation and it is left to the common ancestor node. A common 531 ancestor node when it discovers an updated DAO from a new next-hop, 532 it initiates a DCO. With multiple preferred parents, this handling 533 does not change. But in this case it is recommended that an 534 implementation initiates a DCO after a time period such that the 535 common ancestor node may receive updated DAOs from all possible next- 536 hops. This will help to reduce DCO control overhead i.e., the common 537 ancestor can wait for updated DAOs from all possible directions 538 before initiating a DCO for route invalidation. The time period for 539 initiating a DCO could be based on the depth of the network. After 540 timeout, the DCO needs to be generated for all the next-hops for whom 541 the route invalidation needs to be done. 543 5. Acknowledgements 545 Many thanks to Cenk Gundogan, Simon Duquennoy, Georgios 546 Papadopoulous, Peter Van Der Stok for their review and comments. 548 6. IANA Considerations 550 IANA is requested to allocate new ICMPv6 RPL control codes in RPL 551 [RFC6550] for DCO and DCO-ACK messages. 553 +------+---------------------------------------------+--------------+ 554 | Code | Description | Reference | 555 +------+---------------------------------------------+--------------+ 556 | 0x04 | Destination Cleanup Object | This | 557 | | | document | 558 | 0x05 | Destination Cleanup Object Acknowledgement | This | 559 | | | document | 560 | 0x84 | Secure Destination Cleanup Object | This | 561 | | | document | 562 | 0x85 | Secure Destination Cleanup Object | This | 563 | | Acknowledgement | document | 564 +------+---------------------------------------------+--------------+ 566 IANA is requested to allocate bit 18 in the Transit Information 567 Option defined in RPL [RFC6550] section 6.7.8 for Invalidate route 568 'I' flag. 570 7. Security Considerations 572 All RPL messages support a secure version of messages which allows 573 integrity protection using either a MAC or a signature. Optionally, 574 secured RPL messages also have encryption protection for 575 confidentiality. 577 The document adds new messages (DCO, DCO-ACK) which are syntactically 578 similar to existing RPL messages such as DAO, DAO-ACK. Secure 579 versions of DCO and DCO-ACK are added similar to other RPL messages 580 (such as DAO, DAO-ACK). 582 RPL supports three security modes as mentioned in Section 10.1 of 583 [RFC6550]: 585 1. Unsecured: In this mode, it is expected that the RPL control 586 messages are secured by other security mechanisms, such as link- 587 layer security. In this mode, the RPL control messages, 588 including DCO, DCO-ACK, do not have Security sections. 589 2. Preinstalled: In this mode, RPL uses secure messages. Thus 590 secure versions of DCO, DCO-ACK MUST be used in this mode. 592 3. Authenticated: In this mode, RPL uses secure messages. Thus 593 secure versions of DCO, DCO-ACK MUST be used in this mode. 595 8. Normative References 597 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 598 Requirement Levels", BCP 14, RFC 2119, 599 DOI 10.17487/RFC2119, March 1997, 600 . 602 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 603 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 604 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 605 Low-Power and Lossy Networks", RFC 6550, 606 DOI 10.17487/RFC6550, March 2012, 607 . 609 Appendix A. Example Messaging 611 A.1. Example DCO Messaging 613 In Figure 1, node (D) switches its parent from (B) to (C). The 614 sequence of actions is as follows: 616 1. Node D switches its parent from node B to node C 617 2. D sends a regular DAO(tgt=D,pathseq=x+1,I_flag=1) in the updated 618 path to C 619 3. C checks for routing entry on behalf of D, since it cannot find 620 an entry on behalf of D it creates a new routing entry and 621 forwards the reachability information of the target D to H in a 622 DAO. 623 4. Similar to C, node H checks for routing entry on behalf of D, 624 cannot find an entry and hence creates a new routing entry and 625 forwards the reachability information of the target D to H in a 626 DAO. 627 5. Node A receives the DAO, and checks for routing entry on behalf 628 of D. It finds a routing entry but checks that the next hop for 629 target D is now changed. Node A checks the I_flag and generates 630 DCO(tgt=D,pathseq=pathseq(DAO)) to previous next hop for target D 631 which is G. Subsequently, A updates the routing entry and 632 forwards the reachability information of target D upstream 633 DAO(tgt=D,pathseq=x+1,I_flag=x) (the I_flag carries no 634 significance henceforth). 635 6. Node G receives the DCO and invalidates routing entry of target D 636 and forwards the (un)reachability information downstream to B. 637 7. Similarly, B processes the DCO by invalidating the routing entry 638 of target D and forwards the (un)reachability information 639 downstream to D. 641 8. D ignores the DCO since the target is itself. 642 9. The propagation of the DCO will stop at any node where the node 643 does not have an routing information associated with the target. 644 If the routing information is present and the pathseq associated 645 is not older, then still the DCO is dropped. 647 A.2. Example DCO Messaging with multiple preferred parents 649 (6LBR) 650 | 651 | 652 | 653 (N11) 654 / \ 655 / \ 656 / \ 657 (N21) (N22) 658 / / \ 659 / / \ 660 / / \ 661 (N31) (N32) (N33) 662 : | / 663 : | / 664 : | / 665 (N41) 667 Figure 5: Sample topology 2 669 In Figure 5, node (N41) selects multiple preferred parents (N32) and 670 (N33). The sequence of actions is as follows: 672 1. (N41) sends DAO(tgt=N41,PS=x,I_flag=1) to (N32) and (N33). Here 673 I_flag refers to the Invalidation flag and PS refers to Path 674 Sequence in Transit Information option. 675 2. (N32) sends DAO(tgt=N41,PS=x,I_flag=1) to (N22). (N33) also 676 sends DAO(tgt=N41,PS=x,I_flag=1) to (N22). (N22) learns multiple 677 routes for the same destination (N41) through multiple next-hops. 678 The route table at N22 should contain (Dst,NextHop,PS): { 679 (N41,N32,x), (N41,N33,x) }. 680 3. (N22) sends DAO(tgt=N41,PS=x,I_flag=1) to (N11). 681 4. (N11) sends DAO(tgt=N41,PS=x,I_flag=1) to (6LBR). Thus the 682 complete path is established. 683 5. (N41) decides to change preferred parent set from { N32, N33 } to 684 { N31, N32 }. 685 6. (N41) sends DAO(tgt=N41,PS=x+1,I_flag=1) to (N32). (N41) sends 686 DAO(tgt=N41,PS=x+1,I_flag=1) to (N31). 687 7. (N32) sends DAO(tgt=N41,PS=x+1,I_flag=1) to (N22). (N22) has 688 multiple routes to destination (N41). It sees that a new path 689 sequence for Target=N41 is received and thus it waits for pre- 690 determined time period to invalidate another route 691 {(N41),(N33),x}. After time period, (N22) sends 692 DCO(tgt=N41,PS=x+1) to (N33). 694 Authors' Addresses 696 Rahul Arvind Jadhav (editor) 697 Huawei 698 Kundalahalli Village, Whitefield, 699 Bangalore, Karnataka 560037 700 India 702 Phone: +91-080-49160700 703 Email: rahul.ietf@gmail.com 705 Pascal Thubert 706 Cisco Systems, Inc 707 Building D 708 45 Allee des Ormes - BP1200 709 MOUGINS - Sophia Antipolis 06254 710 France 712 Phone: +33 497 23 26 34 713 Email: pthubert@cisco.com 715 Rabi Narayan Sahoo 716 Huawei 717 Kundalahalli Village, Whitefield, 718 Bangalore, Karnataka 560037 719 India 721 Phone: +91-080-49160700 722 Email: rabinarayans@huawei.com 724 Zhen Cao 725 Huawei 726 W Chang'an Ave 727 Beijing 728 China 730 Email: zhencao.ietf@gmail.com