idnits 2.17.1 draft-thubert-roll-unaware-leaves-01.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 (February 14, 2018) is 2261 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: 'IEEEstd802154' is defined on line 419, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-6lo-rfc6775-update-11 == Outdated reference: A later version (-23) exists of draft-ietf-6lo-ap-nd-05 == Outdated reference: A later version (-18) exists of draft-ietf-roll-efficient-npdao-01 == Outdated reference: A later version (-44) exists of draft-ietf-roll-useofrplinfo-21 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROLL P. Thubert, Ed. 3 Internet-Draft Cisco 4 Updates: 6550, 6775 (if approved) February 14, 2018 5 Intended status: Standards Track 6 Expires: August 18, 2018 8 Routing for RPL Leaves 9 draft-thubert-roll-unaware-leaves-01 11 Abstract 13 This specification updates RFC 6550 and RFC 6775 unicast routing 14 service in a RPL domain to 6LoWPAN ND nodes that do not participate 15 to the routing protocol. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on August 18, 2018. 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 4 54 4. Updating RFC 6775 Update . . . . . . . . . . . . . . . . . . 4 55 5. Updated EARO . . . . . . . . . . . . . . . . . . . . . . . . 5 56 6. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 6 57 6.1. 6LN Operation . . . . . . . . . . . . . . . . . . . . . . 6 58 6.2. 6LR Operation . . . . . . . . . . . . . . . . . . . . . . 6 59 6.3. RPL Root Operation . . . . . . . . . . . . . . . . . . . 7 60 6.4. 6LBR Operation . . . . . . . . . . . . . . . . . . . . . 7 61 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 63 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 64 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 65 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 11.1. Normative References . . . . . . . . . . . . . . . . . . 8 67 11.2. Informative References . . . . . . . . . . . . . . . . . 9 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 70 1. Introduction 72 The design of Low Power and Lossy Networks (LLNs) is generally 73 focused on saving energy, which is the most constrained resource of 74 all. Other design constraints, such as a limited memory capacity, 75 duty cycling of the LLN devices and low-power lossy transmissions, 76 derive from that primary concern. 78 The IETF produced the "Routing Protocol for Low Power and Lossy 79 Networks" [RFC6550] (RPL) to provide routing services within such 80 constraints. RPL is a Distance-Vector protocol, which, compared to 81 link-state protocols, limits the amount of topological knowledge that 82 needs to be installed and maintained in each node. RPL also 83 leverages Routing Stretch to reduce further the amount of control 84 traffic and routing state that is required to operate the protocol. 85 Finally, broken routes may be fixed lazily and on-demand, based on 86 dataplane inconsistency discovery, which avoids wasting energy in the 87 proactive repair of unused paths. 89 In order to cope with lossy transmissions, RPL forms Direction- 90 Oriented Directed Acyclic Graphs (DODAGs) using DODAG Information 91 Solicitation (DIS) and DODAG Information Object (DIO) messages. For 92 most of the nodes, though not all, a DODAG provides multiple 93 forwarding solutions towards the Root of the topology via so-called 94 parents. Because it is designed to adapt to fuzzy connectivity with 95 lazy control, RPL can only provide a best effort routability, 96 connecting most of the LLN nodes, most of the time. RPL provides 97 unicast and multicast routing services back to RPL-Aware nodes. A 98 RPL-Aware Node will inject routes to self using Destination 99 Advertisement Object (DAO) messages sent to either their parents in 100 Storing Mode or to the Root indicating their parent in Non-Storing 101 mode. This process effectively forms a DODAG back to the device that 102 is a subset of the DODAG to the Root with all links reversed. 104 The IPv6 [RFC8200] Neighbor Discovery (IPv6 ND) Protocol (NDP) suite 105 [RFC4861] [RFC4862] defined for fast media such a Ethernet, relies 106 heavily on multicast operations for address discovery and duplicate 107 address detection (DAD). 109 "Neighbor Discovery Optimizations for 6LoWPAN networks" [RFC6775] 110 (6LoWPAN ND) adapts IPv6 ND for operations over energy-constrained 111 LLNs. In particular, 6LoWPAN ND introduces a unicast host address 112 registration mechanism that contributes to reduce the use of 113 multicast messages that are present in the classical IPv6 ND 114 protocol. 6LoWPAN ND defines a new Address Registration Option (ARO) 115 that is carried in the unicast Neighbor Solicitation (NS) and 116 Neighbor Advertisement (NA) messages between the 6LoWPAN Node (6LN) 117 and the 6LoWPAN Router (6LR). 6LoWPAN ND also defines the Duplicate 118 Address Request (DAR) and Duplicate Address Confirmation (DAC) 119 messages between the 6LR and the 6LoWPAN Border Router (6LBR). In an 120 LLN, the 6LBR is the central repository of all the registered 121 addresses in its domain. 123 An Update to 6LoWPAN ND [I-D.ietf-6lo-rfc6775-update] defines an 124 Extended Address Registration Option (EARO) to include a sequence 125 counter called Transaction ID (TID), which maps to the Path Sequence 126 Field found in Transit Options in RPL DAO messages. It is a 127 prerequisite for this specification. 129 When a routing protocol such as RPL is used to maintain reachability 130 within a Non-Broadcast Multi-Access (NBMA) subnet, Some nodes may act 131 as routers and participate to the routing operations whereas others 132 may be plain hosts. In 6LoWPAN ND terms, this means that 6LN that 133 may also be a 6LR and manage its own routing. 135 Alternatively, the 6LN may rely on its 6LR to perform routing and 136 forwarding on its behalf. In the context of RPL, such a 6LN is 137 called a leaf. The packet forwarding operation by the 6LR serving a 138 leaf 6LN is described in "When to use RFC 6553, 6554 and IPv6-in- 139 IPv6" [I-D.ietf-roll-useofrplinfo]. This document adds the 140 capability by a 6LR to advertise the IPv6 address(es) of the 6LN in 141 the RPL protocol. 143 With this specification, a 6LN may declare itself as a router in the 144 6LoWPAN ND exchange in order to declare that it will manage it own 145 routing. By default, the 6LN is considered as a plain host, and the 146 6LR that accepts the registration will inject routing information on 147 behalf of the 6LN in the RPL domain. 149 2. Terminology 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 153 "OPTIONAL" in this document are to be interpreted as described in 154 [RFC2119]. 156 The Terminology used in this document is consistent with and 157 incorporates that described in Terms Used in Routing for Low-Power 158 and Lossy Networks (LLNs). [RFC7102]. 160 Other terms in use in LLNs are found in Terminology for Constrained- 161 Node Networks [RFC7228]. 163 The term "byte" is used in its now customary sense as a synonym for 164 "octet". 166 "RPL", "RPL Packet Information" (RPI) and "RPL Instance", DIO, DAO 167 and DIS messages are defined in the "RPL: IPv6 Routing Protocol for 168 Low-Power and Lossy Networks" [RFC6550] specification. 170 3. Updating RFC 6550 172 This document specifies a new behavior whereby a 6LR injects DAO 173 messages for unicast addresses registered through the updated 6LoWPAN 174 ND [I-D.ietf-6lo-rfc6775-update] on behalf of 6LN nodes that are not 175 RPL-aware. 177 Upon the renewal of a registration, this specification changes the 178 behavior or the 6LR. If a DAO is sent for the registered address, 179 then the 6LR refrains from sending a DAR message. Upon reception of 180 the DAO message initiated at the 6LR, the DAR/DAC exchange happens 181 between the RPL Root and the 6LBR, the Root acting as a proxy Root on 182 behalf of the 6LR to maintain an existing state in the 6LBR. 184 4. Updating RFC 6775 Update 186 This document specifies a new flag in the EARO option, the 'R' flag, 187 used by the registering node to indicate that the 6LN that performs 188 the registration is a router and that it handles its reachability. 189 Setting the 'R' flag effectively suppresses the behavior defined in 190 this specification whereby the 6LR that processes the registration 191 advertises the registered address in DAO messages and bypasses the 192 DAR/DAC process for the renewal of a registration. 194 This document also specifies a keep-alive DAR message that the RPL 195 Root may use to maintain an existing state in the 6LBR upon receiving 196 DAO messages. The DAR message may only act as a refresher and can 197 only update the Lifetime and the TID of the state in the 6LBR. 199 5. Updated EARO 201 This document introduces a new 'R' flag in the EARO option, as 202 follows: 204 0 1 2 3 205 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 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Type | Length | Status | Reserved | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | |R|C|T| TID | Registration Lifetime | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | | 212 + Owner Unique ID (EUI-64 or Crypto-ID) + 213 | | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 Figure 1: Enhanced Address Registration Option 218 Type: 33 219 Length: 8-bit unsigned integer. The length of the option 220 (including the type and length fields) in units of 8 221 bytes. 222 Status: Defined in [RFC6775] and updated in 223 [I-D.ietf-6lo-ap-nd]. 224 Reserved: This field is unused. It MUST be initialized to zero 225 by the sender and MUST be ignored by the receiver. 226 R: When set, this flag indicates that the registering 227 node is a router that handles it reachability. If 228 the 'R' flag is not set, the registering node expects 229 that the 6LR ensures reachability for the registered 230 address. In the context of this specification, this 231 means that the 6LR will advertise the registered 232 address in the RPL domain. 233 C: --> Defined in [I-D.ietf-6lo-ap-nd]. 234 T and TID: Defined in [I-D.ietf-6lo-rfc6775-update]. 235 Owner Unique ID: Defined in [RFC6775] and updated in 236 [I-D.ietf-6lo-ap-nd]. 238 6. Protocol Operations 240 6.1. 6LN Operation 242 This specification does not alter the operation of a 6LowpAN ND- 243 compliant 6LN, which is expected to operate as follows: 245 o The 6LN obtains an IPv6 global address, for instance using 246 autoconfiguration [RFC4862] based on a Prefix Information Option 247 (PIO) [RFC4861] found in a Router Advertisement message or by some 248 other means such as DHCPv6 [RFC3315]. 249 o Once it has formed an address, the 6LN (re)registers its address 250 periodically, within the Lifetime of the previous registration, as 251 prescribed by [I-D.ietf-6lo-rfc6775-update]. 252 o Upon each consecutive registration, the 6LN increases the TID 253 field. 254 o The 6LN MAY register to more than one 6LR at the same time. In 255 that case, a same value of TID is used for each registration. 256 o The 6LN MAY use any of the 6LRs to which it register to forward 257 its packets. 259 6.2. 6LR Operation 261 Also as prescribed by [I-D.ietf-6lo-rfc6775-update], the 6LR 262 generates a DAR/DAC message upon reception of a valid NS(EARO) 263 message for a new registration. If the exchange succeeds, then the 264 6LR installs a Neighbor Cache Entry (NCE). 266 At this stage, and upon each NS(EARO) received afterwards that 267 maintain the NCE in the 6LR; if the 'R' flag was set in a NS(EARO) 268 message, the 6LR refrains from injecting the registered address into 269 RPL; else the 6LR SHOULD redistribute the registered address into RPL 270 by sending a DAO message on behalf of the 6LN. 272 The DAO message advertising the registered address MUST be 273 constructed as follows: 275 o The registered address is placed in a RPL Target Option in the DAO 276 message as the Target Prefix, and the Prefix Length is set to 128 277 o the External 'E' flag in the Transit Information Option (TIO) 278 associated to the Target Option is set to indicate that the 6LR 279 redistributes an external target into the RPL network 280 o the Path Lifetime in the TIO is computed from the Lifetime in the 281 EARO Option to adapt it to the Lifetime Units used in the RPL 282 operation. 283 o the Path Sequence in the TIO is set to the TID value found in the 284 EARO option. 286 o Additionally, in Non-Storing Mode the 6LR indicates one of its 287 global IPv6 unicast addresses as the Parent Address in the TIO. 289 If a 6LR receives a valid NS(EARO) message with the 'R' flag set and 290 the 6LR was redistributing the registered address due to previous 291 NS(EARO) messages with the flag not set, then it MUST stop 292 redistributing the address. It is up to the registering node to 293 maintain the corresponding route from then on, either keeping it 294 active by sending further DAO messages, or destroying it using a No- 295 Path DAO. 297 6.3. RPL Root Operation 299 Upon reception of a DAO message that creates or updates an existing 300 RPL state, the Root notifies the 6LR using an internal API if they 301 are collocated, or a proxied DAR/DAC exchange on behalf of the 302 registering node if they are separated. 304 In the latter case, the DAR message MUST be constructed as follows: 306 o The registered address from in the Target Option is placed in the 307 Registered Address field 308 o the Owner Unique ID field is set to all ones to indicate that it 309 is not provided 310 o the Registration Lifetime in the DAR message is adapted from the 311 Path Lifetime in the TIO. 312 o the TID value is set to the Path Sequence in the TIO. 314 Upon a status in a DAC message that is not "Success", the Root MAY 315 destroy the formed paths using a No-Path DAO downwards as specified 316 in [I-D.ietf-roll-efficient-npdao]. 318 In Non-Storing Mode, the outer IPv6 header that is used by the Root 319 to transport the source routing information in data packets down the 320 DODAG has the 6LR that serves the 6LN as final destination. This 321 way, when the final 6LR decapsulates the outer header, it also 322 removes all the RPL artifacts from the packet. 324 6.4. 6LBR Operation 326 Upon reception of a DAR message with the Owner Unique ID field is set 327 to all ones, the 6LBR checks whether and entry exists for the and 328 computes whether the TID in the DAR message is fresher than that in 329 the entry as prescribed in [I-D.ietf-6lo-rfc6775-update]. 331 If the entry does not exist, the 6LBR does not create the entry, and 332 answers with a Status "Removed" in the DAC message. 334 If the entry exists but is not fresher, the 6LBR does not update the 335 entry, and answers with a Status "Success" in the DAC message. 337 If te entry exists and the TID in the DAR message is fresher, the 338 6LBR updates the TID in the entry, and if the lifetime of the entry 339 is extended by the Registration Lifetime in the DAR message, it also 340 updates the lifetime of the entry. In that case, the 6LBR replies 341 with a Status "Success" in the DAC message. 343 7. Implementation Status 345 TBD 347 8. Security Considerations 349 TBD 351 9. IANA Considerations 353 This specification has no requirement on IANA. 355 10. Acknowledgments 357 TBD 359 11. References 361 11.1. Normative References 363 [I-D.ietf-6lo-rfc6775-update] 364 Thubert, P., Nordmark, E., Chakrabarti, S., and C. 365 Perkins, "An Update to 6LoWPAN ND", draft-ietf-6lo- 366 rfc6775-update-11 (work in progress), December 2017. 368 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 369 Requirement Levels", BCP 14, RFC 2119, 370 DOI 10.17487/RFC2119, March 1997, 371 . 373 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 374 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 375 DOI 10.17487/RFC4861, September 2007, 376 . 378 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 379 Address Autoconfiguration", RFC 4862, 380 DOI 10.17487/RFC4862, September 2007, 381 . 383 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 384 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 385 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 386 Low-Power and Lossy Networks", RFC 6550, 387 DOI 10.17487/RFC6550, March 2012, 388 . 390 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 391 Bormann, "Neighbor Discovery Optimization for IPv6 over 392 Low-Power Wireless Personal Area Networks (6LoWPANs)", 393 RFC 6775, DOI 10.17487/RFC6775, November 2012, 394 . 396 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 397 (IPv6) Specification", STD 86, RFC 8200, 398 DOI 10.17487/RFC8200, July 2017, 399 . 401 11.2. Informative References 403 [I-D.ietf-6lo-ap-nd] 404 Thubert, P., Sarikaya, B., and M. Sethi, "Address 405 Protected Neighbor Discovery for Low-power and Lossy 406 Networks", draft-ietf-6lo-ap-nd-05 (work in progress), 407 January 2018. 409 [I-D.ietf-roll-efficient-npdao] 410 Jadhav, R., Sahoo, R., and Z. Cao, "No-Path DAO 411 modifications", draft-ietf-roll-efficient-npdao-01 (work 412 in progress), October 2017. 414 [I-D.ietf-roll-useofrplinfo] 415 Robles, I., Richardson, M., and P. Thubert, "When to use 416 RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll- 417 useofrplinfo-21 (work in progress), February 2018. 419 [IEEEstd802154] 420 IEEE standard for Information Technology, "IEEE Standard 421 for Local and metropolitan area networks-- Part 15.4: Low- 422 Rate Wireless Personal Area Networks (LR-WPANs)". 424 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 425 C., and M. Carney, "Dynamic Host Configuration Protocol 426 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 427 2003, . 429 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 430 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 431 2014, . 433 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 434 Constrained-Node Networks", RFC 7228, 435 DOI 10.17487/RFC7228, May 2014, 436 . 438 Author's Address 440 Pascal Thubert (editor) 441 Cisco Systems, Inc 442 Building D 443 45 Allee des Ormes - BP1200 444 MOUGINS - Sophia Antipolis 06254 445 FRANCE 447 Phone: +33 497 23 26 34 448 Email: pthubert@cisco.com