idnits 2.17.1 draft-thubert-6lo-rfc6775-update-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6775, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 4, 2016) is 2913 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) == Missing Reference: 'IEEE802154' is mentioned on line 685, but not defined == Missing Reference: 'IEEE80211' is mentioned on line 668, but not defined == Missing Reference: 'IEEE802151' is mentioned on line 676, but not defined == Unused Reference: 'I-D.ietf-6man-rs-refresh' is defined on line 562, but no explicit reference was found in the text == Unused Reference: 'I-D.nordmark-6man-dad-approaches' is defined on line 589, but no explicit reference was found in the text == Unused Reference: 'I-D.vyncke-6man-mcast-not-efficient' is defined on line 605, but no explicit reference was found in the text == Unused Reference: 'RFC7559' is defined on line 651, but no explicit reference was found in the text == Unused Reference: 'RFC7772' is defined on line 661, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-6lo-6lobac-04 == Outdated reference: A later version (-20) exists of draft-ietf-6lo-backbone-router-01 == Outdated reference: A later version (-09) exists of draft-ietf-6lo-dect-ule-04 == Outdated reference: A later version (-22) exists of draft-ietf-6lo-nfc-03 == Outdated reference: A later version (-02) exists of draft-ietf-6man-rs-refresh-01 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-09 == Outdated reference: A later version (-10) exists of draft-ietf-6tisch-terminology-07 == Outdated reference: A later version (-08) exists of draft-ietf-bier-architecture-03 == Outdated reference: A later version (-04) exists of draft-sarikaya-6lo-ap-nd-02 Summary: 0 errors (**), 0 flaws (~~), 18 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6lo P. Thubert, Ed. 3 Internet-Draft cisco 4 Updates: 6775 (if approved) E. Nordmark 5 Intended status: Standards Track Arista Networks 6 Expires: November 5, 2016 S. Chakrabarti 7 Ericsson 8 May 4, 2016 10 An Update to 6LoWPAN ND 11 draft-thubert-6lo-rfc6775-update-00 13 Abstract 15 This specification proposes an update to 6LoWPAN Neighbor Discovery, 16 to clarify the role of the protocol as a registration technique, and 17 provide enhancements to the registration capabilities, in particular 18 for the registration to a backbone router for proxy ND operations. 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 http://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 November 5, 2016. 37 Copyright Notice 39 Copyright (c) 2016 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 (http://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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Updating RFC 6775 . . . . . . . . . . . . . . . . . . . . . . 4 57 3.1. Extended Address Registration Option . . . . . . . . . . 4 58 3.2. Link-local Scope and Consequences . . . . . . . . . . . . 5 59 4. Applicability and Requirements Served . . . . . . . . . . . . 6 60 5. The Enhanced Address Registration Option (EARO) . . . . . . . 7 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 63 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 64 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 66 9.2. Informative References . . . . . . . . . . . . . . . . . 12 67 9.3. External Informative References . . . . . . . . . . . . . 15 68 Appendix A. Requirements . . . . . . . . . . . . . . . . . . . . 15 69 A.1. Requirements Related to Mobility . . . . . . . . . . . . 16 70 A.2. Requirements Related to Routing Protocols . . . . . . . . 16 71 A.3. Requirements Related to the Variety of Low-Power Link 72 types . . . . . . . . . . . . . . . . . . . . . . . . . . 17 73 A.4. Requirements Related to Proxy Operations . . . . . . . . 18 74 A.5. Requirements Related to Security . . . . . . . . . . . . 18 75 A.6. Requirements Related to Scalability . . . . . . . . . . . 19 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 78 1. Introduction 80 The scope of this draft is an IPv6 Low Power Lossy Network (LLN), 81 which can be a simple star or a more complex mesh topology. The LLN 82 may be anchored at an IPv6 Backbone Router (6BBR). The Backbone 83 Routers interconnect the LLNs over a Backbone Link and emulate that 84 the LLN nodes are present on the Backbone using proxy-ND operations. 86 IPv6 Neighbor Discovery (ND) Optimization for IPv6 over Low-Power 87 Wireless Personal Area Networks(6LoWPANs) [RFC6775] introduced a 88 proactive registration mechanism to IPv6 ND services for nodes 89 belonging to a LLN. 91 This specification modifies and extends the behaviour and protocol 92 elements of [RFC6775] to enable additional capabilities, in 93 particular the registration to a 6BBR for proxy ND operations 94 [I-D.ietf-6lo-backbone-router]. 96 2. Terminology 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 Readers are expected to be familiar with all the terms and concepts 103 that are discussed in "Neighbor Discovery for IP version 6" 104 [RFC4861], "IPv6 Stateless Address Autoconfiguration" [RFC4862], 105 "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): 106 Overview, Assumptions, Problem Statement, and Goals" [RFC4919], 107 Neighbor Discovery Optimization for Low-power and Lossy Networks 108 [RFC6775] and "Multi-link Subnet Support in IPv6" 109 [I-D.ietf-ipv6-multilink-subnets]. 111 Additionally, this document uses terminology from "Terms Used in 112 Routing for Low-Power and Lossy Networks" [RFC7102] and 113 [I-D.ietf-6tisch-terminology], as well as this additional 114 terminology: 116 Backbone This is an IPv6 transit link that interconnects 2 or more 117 Backbone Routers. It is expected to be deployed as a high 118 speed backbone in order to federate a potentially large set of 119 LLNS. Also referred to as a LLN backbone or Backbone network. 121 Backbone Router An IPv6 router that federates the LLN using a 122 Backbone link as a backbone. A BBR acts as a 6LoWPAN Border 123 Routers (6LBR) and an Energy Aware Default Router (NEAR). 125 Extended LLN This is the aggregation of multiple LLNs as defined in 126 [RFC4919], interconnected by a Backbone Link via Backbone 127 Routers, and forming a single IPv6 MultiLink Subnet. 129 Registration The process during which a wireless Node registers its 130 address(es) with the Border Router so the 6BBR can proxy ND for 131 it over the backbone. 133 Binding The state in the 6BBR that associates an IP address with a 134 MAC address, a port and some other information about the node 135 that owns the IP address. 137 Registered Node The node for which the registration is performed, 138 which owns the fields in the EARO option. 140 Registering Node The node that performs the registration to the 141 6BBR, either for one of its own addresses, in which case it is 142 Registered Node and indicates its own MAC Address as SLLA in 143 the NS(ARO), or on behalf of a Registered Node that is 144 reachable over a LLN mesh. In the latter case, if the 145 Registered Node is reachable from the 6BBR over a Mesh-Under 146 mesh, the Registering Node indicates the MAC Address of the 147 Registered Node as SLLA in the NS(ARO). Otherwise, it is 148 expected that the Registered Device is reachable over a Route- 149 Over mesh from the Registering Node, in which case the SLLA in 150 the NS(ARO) is that of the Registering Node, which causes it to 151 attract the packets from the 6BBR to the Registered Node and 152 route them over the LLN. 154 Registered Address The address owned by the Registered Node node 155 that is being registered. 157 3. Updating RFC 6775 159 The support of this specification is signaled in Router Advertisement 160 (RA) messages by 6LoWPAN Router (6LR) (how: tbd). A Registering Node 161 that supports this specification will favor registering to a 6LR that 162 indicates support for this specification over that of [RFC6775]. 164 3.1. Extended Address Registration Option 166 This specification extends the Address Registration Option (ARO) used 167 for the process of address registration. The new ARO is referred to 168 as Extended ARO (EARO), and its semantics are modified as follows: 170 The address that is being registered with a Neighbor Solicitation 171 (NS) with an EARO is now the Target Address, as opposed to the Source 172 Address as specified in [RFC6775]. This change enables a 6LBR to use 173 an address of his as source to the proxy-registration of an address 174 that belongs to a LLN Node to a 6BBR. This also limits the use of an 175 address as source address before it is registered and the associated 176 Duplicate Address Detection (DAD) is complete. 178 The Unique ID in the EARO option does no more have to be a MAC 179 address. A new TLV format is introduced and a IANA registry is 180 created for the type (TBD). This enables in particular the use of a 181 Provable Temporary UID (PT-UID) as opposed to burn-in MAC address, 182 the PT-UID providing a trusted anchor by the 6LR and 6LBR to protect 183 the state associated to the node. 185 The specification introduces a Transaction ID (TID) field in the 186 EARO. The TID MUST be provided by a node that supports this 187 specification and a new T flag MUST be set to indicate so. The T bit 188 can be used to determine whether the peer supports this 189 specification. 191 3.2. Link-local Scope and Consequences 193 The use of link-local addresses as source address for the 194 registration, and the expectation for the scope of those addresses, 195 are clarified as follows: 197 A link is abstracted as a one-hop point-to-point communication 198 medium. There is no need nor expectation that a link-local address 199 is unique across the whole LLN. A 6LR assumes that the link-local 200 address of a Registering Node is unique as long as the 6LR does not 201 have a conflicting registration for that address. 203 An exchange between two nodes using link-local addresses implies that 204 they are reachable over one hop and that at least one of the 2 nodes 205 acts as a 6LR. A node MUST register a link-local address to a 6LR in 206 order to obtain link scope reachability from that 6LR beyond the 207 current exchange, and in particular to use it as Source Address to 208 register other addresses. 210 A consequence of this model is that the Duplicate Address Detection 211 (DAD) process between the 6LR and a 6LoWPAN Border Router (6LBR), 212 which is based on a Duplicate Address Request (DAR) / Duplicate 213 Address Confirmation (DAC) exchange as described in [RFC6775], does 214 not take place for link-local addresses. 216 It is desired that a 6LR does not need to modify its state associated 217 to the Source Address of an NS(EARO) message. For that reason, when 218 possible, it is RECOMMENDED to use an address that is already 219 registered with a 6LR as source for the NS(EARO) message. 221 When a Registering Node does not yet have an already-registered 222 address, it MUST register a link-local address, using it as both the 223 Source and the Target Address of an NS(EARO) message. In that case, 224 it is RECOMMENDED to use a link-local address that is (expected to 225 be) globally unique, e.g. derived from a burn-in MAC address. 227 Since there is no DAR/DAC exchange for link-local addresses, the 6LR 228 may answer immediately to the registration of a link-local address, 229 based solely on its existing state and the Source Link-Layer Option 230 that MUST be placed in the NS(EARO) message as required in [RFC6775]. 232 A node must register its IPv6 Global Unicast IPv6 Addresses (GUA) to 233 a 6LR in order to obtain a global reachability for these addresses 234 via that 6LR. In particular a Registering NODE registering a GUA 235 SHOULD NOT use that GUA as Source Address for the registration to a 236 6LR that conforms this specification. 238 What makes this model practical in existing LLNs, which can grow to 239 large number of nodes, is that a subnet may encompass multiple links, 240 which can be LLN links or can be backbone links that federate a 241 number of LLN links, effectively forming a non-broadcast multi-access 242 (NBMA) multi-link subnet (MLSN). 244 4. Applicability and Requirements Served 246 This specification extends 6LoWPAN ND to sequence the registration 247 and serves the requirements expressed Appendix A.1 by enabling the 248 mobility of devices from one LLN to the next based on the 249 complementary work in [I-D.ietf-6lo-backbone-router]. 251 In the context of the the TimeSlotted Channel Hopping (TSCH) mode of 252 [IEEE802154], the 6TiSCH architecture [I-D.ietf-6tisch-architecture] 253 introduces how a 6LoWPAN ND host could connect to the Internet via a 254 RPL mesh Network, but this requires additions to the 6LOWPAN ND 255 protocol to support mobility and reachability in a secured and 256 manageable environment. This specification details the new 257 operations that are required to implement the 6TiSCH architecture and 258 serves the requirements listed in Appendix A.2. 260 The term LLN is used loosely in this specification to cover multiple 261 types of WLANs and WPANs, including Low-Power Wi-Fi, BLUETOOTH(R) Low 262 Energy, IEEE802.11AH and IEEE802.15.4 wireless meshes, so as to 263 address the requirements discussed in Appendix A.3 265 This specification can be used by any wireless node to associate at 266 Layer-3 with a 6BBR and register its IPv6 addresses to obtain routing 267 services including proxy-ND operations over the backbone, effectively 268 providing a solution to the requirements expressed in Appendix A.4. 270 Efficiency aware IPv6 Neighbor Discovery Optimizations 271 [I-D.chakrabarti-nordmark-6man-efficient-nd] suggests that 6LoWPAN ND 272 [RFC6775] can be extended to other types of links beyond IEEE802.15.4 273 for which it was defined. The registration technique is beneficial 274 when the Link-Layer technique used to carry IPv6 multicast packets is 275 not sufficiently efficient in terms of delivery ratio or energy 276 consumption in the end devices, in particular to enable energy- 277 constrained sleeping nodes. The value of such extension is 278 especially apparent in the case of mobile wireless nodes, to reduce 279 the multicast operations that are related to classical ND ([RFC4861], 280 [RFC4862]) and plague the wireless medium. This serves scalability 281 requirements listed in Appendix A.6. 283 5. The Enhanced Address Registration Option (EARO) 285 With the ARO option defined in 6LoWPAN ND [RFC6775], the address 286 being registered and its owner can be uniquely identified and matched 287 with the Binding Table entries of each Backbone Router. 289 The Enhanced Address Registration Option (EARO) is intended to be 290 used as a replacement to the ARO option within Neighbor Discovery NS 291 and NA messages between a LLN node and its 6LoWPAN Router (6LR), as 292 well as in Duplicate Address Request (DAR) and the Duplicate Address 293 Confirmation (DAC) messages between 6LRs and 6LBRs in LLNs meshes 294 such as 6TiSCH networks. 296 An NS message with an EARO option is a registration if and only if it 297 also carries an SLLAO option. The AERO option also used in NS and NA 298 messages between Backbone Routers over the backbone link to sort out 299 the distributed registration state, and in that case, it does not 300 carry the SLLAO option and is not confused with a registration. 302 The EARO extends the ARO and is recognized by the setting of the TID 303 bit. A node that supports this specification MUST always use an EARO 304 as a replacement to an ARO in its registration to a router. This is 305 harmless since the TID bit and fields are reserved in [RFC6775] are 306 ignored by a legacy router. A router that supports this 307 specification answers to an ARO with an ARO and to an EARO with an 308 EARO. 310 This specification changes the behavior of the peers in a 311 registration flows. To enable backward compatibility, a node that 312 registers to a router that is not known to support this specification 313 MUST behave as prescribed by [RFC6775]. Once the router is known to 314 support this specification, the node MUST obey this specification. 316 When using the EARO option, the address being registered is found in 317 the Target Address field of the NS and NA messages. This differs 318 from 6LoWPAN ND [RFC6775] which specifies that the address being 319 registered is the source of the NS. 321 The reason for this change is to enable proxy-registrations on behalf 322 of other nodes in Route-Over meshes, for instance to enable that a 323 RPL root registers addresses on behalf LLN nodes that are deeper in a 324 6TiSCH mesh. In that case, the Registering Node MUST indicate its 325 own address as source of the ND message and its MAC address in the 326 Source Link-Layer Address Option (SLLAO), since it still expects to 327 get the packets and route them down the mesh. But the Registered 328 Address belongs to another node, the Registered Node, and that 329 address is indicated in the Target Address field of the NS message. 331 One way of achieving all the above is for a node to first register an 332 address that it owns in order to validate that the router supports 333 this specification, placing the same address in the Source and Target 334 Address fields of the NS message. The node may for instance register 335 an address that is based on EUI-64. For such address, DAD is not 336 required and using the SLLAO option in the NS is actually more 337 amenable with older ND specifications such as ODAD [RFC4429]. 339 Once that first registration is complete, the node knows from the 340 setting of the TID in the response whether the router supports this 341 specification. If this is verified, the node may register other 342 addresses that it owns, or proxy-register addresses on behalf some 343 another node, indicating those addresses being registered in the 344 Target Address field of the NS messages, while using one of its own, 345 already registered, addresses as source. 347 The format of the EARO option is as follows: 349 0 1 2 3 350 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 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Type | Length = 2 | Status | Reserved | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Reserved |T| TID | Registration Lifetime | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | | 357 + Owner Unique ID (EUI-64 or equivalent) + 358 | | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 Figure 1: EARO 363 Option Fields 365 Type: 367 Length: 2 369 Status: 371 +-------+-----------------------------------------------------------+ 372 | Value | Description | 373 +-------+-----------------------------------------------------------+ 374 | 0..2 | See [RFC6775]. Note that a Status of 1 "Duplicate | 375 | | Address" applies to the Registered Address. If the Source | 376 | | Address differs from the Registered Address it conflicts | 377 | | with an existing registration, "Invalid Source Address" | 378 | | should be used instead. | 379 | | | 380 | 3 | Moved: The registration fails because it is not the | 381 | | freshest. | 382 | | | 383 | 4 | Removed: The binding state was removed. This may be | 384 | | placed in an asynchronous NS(ARO) message, or as the | 385 | | rejection of a proxy registration to a Backbone Router. | 386 | | | 387 | 5 | Proof requested | 388 | | | 389 | 6 | Invalid Source Address: The address used as source of the | 390 | | NS(ARO) conflicts with an existing registration, or is | 391 | | not usable on this link, e.g. it is not topologically | 392 | | correct. | 393 | | | 394 | 7 | Administrative Rejection: The address is reserved for | 395 | | another use by an administrative decision (e.g. placed in | 396 | | a DHCPv6 pool). The Registering Node is requested to | 397 | | form a different address and retry. | 398 +-------+-----------------------------------------------------------+ 400 Table 1 402 Reserved: This field is unused. It MUST be initialized to zero by 403 the sender and MUST be ignored by the receiver. 405 T: One bit flag. Set if the next octet is a used as a TID. 407 TID: 1-byte integer; a transaction id that is maintained by the node 408 and incremented with each transaction. it is recommended that the 409 node maintains the TID in a persistent storage. 411 Registration Lifetime: 16-bit integer; expressed in minutes. 0 412 means that the registration has ended and the state should be 413 removed. 415 Owner Unique Identifier (OUI): A globally unique identifier for the 416 node associated. This can be the EUI-64 derived IID of an 417 interface, or some provable ID obtained cryptographically. 419 New status values are introduced, their values to be confirmed by 420 IANA: 422 Moved: This status indicates that the registration is rejected 423 because another more recent registration was done, as indicated by 424 a same OUI and a more recent TID. One possible cause is a stale 425 registration that has progressed slowly in the network and was 426 passed by a more recent one. It could also indicate a OUI 427 collision. 429 Removed: This status is expected in asynchronous messages from a 430 registrar (6LR, 6LBR, 6BBR) to indicate that the registration 431 state is removed, for instance due to time out of a lifetime, or a 432 movement. It is used for instance by a 6BBR in a NA(ARO) message 433 to indicate that the ownership of the proxy state on the backbone 434 was transfered to another 6BBR, which is indicative of a movement 435 of the device. The receiver of the NA is the device that has 436 performed a registration that is now stale and it should clean up 437 its state. 439 6. Security Considerations 441 This specification expects that the link layer is sufficiently 442 protected, either by means of physical or IP security for the 443 Backbone Link or MAC sublayer cryptography. In particular, it is 444 expected that the LLN MAC provides secure unicast to/from the 445 Backbone Router and secure Broadcast from the Backbone Router in a 446 way that prevents tempering with or replaying the RA messages. 448 The use of EUI-64 for forming the Interface ID in the link-local 449 address prevents the usage of Secure ND ([RFC3971] and [RFC3972]) and 450 address privacy techniques. This specification RECOMMENDS the use of 451 additional protection against address theft such as provided by 452 [I-D.sarikaya-6lo-ap-nd], which guarantees the ownership of the OUID. 454 When the ownership of the OUID cannot be assessed, this specification 455 limits the cases where the OUID and the TID are multicasted, and 456 obfuscates them in responses to attempts to take over an address. 458 The LLN nodes depend on the 6LBR and the 6BBR for their operation. A 459 trust model must be put in place to ensure that the right devices are 460 acting in these roles, so as to avoid threats such as black-holing, 461 or bombing attack whereby an impersonated 6LBR would destroy state in 462 the network by using the "Removed" status code. 464 7. IANA Considerations 466 This document requires the following additions: 468 Address Registration Option Status Values Registry 470 +--------+--------------------------+ 471 | Status | Description | 472 +--------+--------------------------+ 473 | 3 | Moved | 474 | | | 475 | 4 | Removed | 476 | | | 477 | 5 | Proof requested | 478 | | | 479 | 6 | Invalid Source Address | 480 | | | 481 | 7 | Administrative Rejection | 482 +--------+--------------------------+ 484 IANA is required to change the registry accordingly 486 Table 2: New ARO Status values 488 8. Acknowledgments 490 Kudos to Eric Levy-Abegnoli who designed the First Hop Security 491 infrastructure at Cisco. 493 9. References 495 9.1. Normative References 497 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 498 Requirement Levels", BCP 14, RFC 2119, 499 DOI 10.17487/RFC2119, March 1997, 500 . 502 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 503 for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, 504 . 506 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 507 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 508 DOI 10.17487/RFC4861, September 2007, 509 . 511 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 512 Address Autoconfiguration", RFC 4862, 513 DOI 10.17487/RFC4862, September 2007, 514 . 516 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 517 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 518 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 519 Low-Power and Lossy Networks", RFC 6550, 520 DOI 10.17487/RFC6550, March 2012, 521 . 523 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 524 Bormann, "Neighbor Discovery Optimization for IPv6 over 525 Low-Power Wireless Personal Area Networks (6LoWPANs)", 526 RFC 6775, DOI 10.17487/RFC6775, November 2012, 527 . 529 9.2. Informative References 531 [I-D.chakrabarti-nordmark-6man-efficient-nd] 532 Chakrabarti, S., Nordmark, E., Thubert, P., and M. 533 Wasserman, "IPv6 Neighbor Discovery Optimizations for 534 Wired and Wireless Networks", draft-chakrabarti-nordmark- 535 6man-efficient-nd-07 (work in progress), February 2015. 537 [I-D.delcarpio-6lo-wlanah] 538 Vega, L., Robles, I., and R. Morabito, "IPv6 over 539 802.11ah", draft-delcarpio-6lo-wlanah-01 (work in 540 progress), October 2015. 542 [I-D.ietf-6lo-6lobac] 543 Lynn, K., Martocci, J., Neilson, C., and S. Donaldson, 544 "Transmission of IPv6 over MS/TP Networks", draft-ietf- 545 6lo-6lobac-04 (work in progress), February 2016. 547 [I-D.ietf-6lo-backbone-router] 548 Thubert, P., "IPv6 Backbone Router", draft-ietf-6lo- 549 backbone-router-01 (work in progress), March 2016. 551 [I-D.ietf-6lo-dect-ule] 552 Mariager, P., Petersen, J., Shelby, Z., Logt, M., and D. 553 Barthel, "Transmission of IPv6 Packets over DECT Ultra Low 554 Energy", draft-ietf-6lo-dect-ule-04 (work in progress), 555 February 2016. 557 [I-D.ietf-6lo-nfc] 558 Hong, Y. and J. Youn, "Transmission of IPv6 Packets over 559 Near Field Communication", draft-ietf-6lo-nfc-03 (work in 560 progress), March 2016. 562 [I-D.ietf-6man-rs-refresh] 563 Nordmark, E., Yourtchenko, A., and S. Krishnan, "IPv6 564 Neighbor Discovery Optional RS/RA Refresh", draft-ietf- 565 6man-rs-refresh-01 (work in progress), March 2016. 567 [I-D.ietf-6tisch-architecture] 568 Thubert, P., "An Architecture for IPv6 over the TSCH mode 569 of IEEE 802.15.4", draft-ietf-6tisch-architecture-09 (work 570 in progress), November 2015. 572 [I-D.ietf-6tisch-terminology] 573 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 574 "Terminology in IPv6 over the TSCH mode of IEEE 575 802.15.4e", draft-ietf-6tisch-terminology-07 (work in 576 progress), March 2016. 578 [I-D.ietf-bier-architecture] 579 Wijnands, I., Rosen, E., Dolganow, A., Przygienda, A., and 580 S. Aldrin, "Multicast using Bit Index Explicit 581 Replication", draft-ietf-bier-architecture-03 (work in 582 progress), January 2016. 584 [I-D.ietf-ipv6-multilink-subnets] 585 Thaler, D. and C. Huitema, "Multi-link Subnet Support in 586 IPv6", draft-ietf-ipv6-multilink-subnets-00 (work in 587 progress), July 2002. 589 [I-D.nordmark-6man-dad-approaches] 590 Nordmark, E., "Possible approaches to make DAD more robust 591 and/or efficient", draft-nordmark-6man-dad-approaches-02 592 (work in progress), October 2015. 594 [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks] 595 Popa, D. and J. Hui, "6LoPLC: Transmission of IPv6 Packets 596 over IEEE 1901.2 Narrowband Powerline Communication 597 Networks", draft-popa-6lo-6loplc-ipv6-over- 598 ieee19012-networks-00 (work in progress), March 2014. 600 [I-D.sarikaya-6lo-ap-nd] 601 Sarikaya, B. and P. Thubert, "Address Protected Neighbor 602 Discovery for Low-power and Lossy Networks", draft- 603 sarikaya-6lo-ap-nd-02 (work in progress), March 2016. 605 [I-D.vyncke-6man-mcast-not-efficient] 606 Vyncke, E., Thubert, P., Levy-Abegnoli, E., and A. 607 Yourtchenko, "Why Network-Layer Multicast is Not Always 608 Efficient At Datalink Layer", draft-vyncke-6man-mcast-not- 609 efficient-01 (work in progress), February 2014. 611 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 612 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 613 DOI 10.17487/RFC3810, June 2004, 614 . 616 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 617 "SEcure Neighbor Discovery (SEND)", RFC 3971, 618 DOI 10.17487/RFC3971, March 2005, 619 . 621 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 622 RFC 3972, DOI 10.17487/RFC3972, March 2005, 623 . 625 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 626 over Low-Power Wireless Personal Area Networks (6LoWPANs): 627 Overview, Assumptions, Problem Statement, and Goals", 628 RFC 4919, DOI 10.17487/RFC4919, August 2007, 629 . 631 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 632 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 633 DOI 10.17487/RFC6282, September 2011, 634 . 636 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 637 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 638 2014, . 640 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 641 Interface Identifiers with IPv6 Stateless Address 642 Autoconfiguration (SLAAC)", RFC 7217, 643 DOI 10.17487/RFC7217, April 2014, 644 . 646 [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets 647 over ITU-T G.9959 Networks", RFC 7428, 648 DOI 10.17487/RFC7428, February 2015, 649 . 651 [RFC7559] Krishnan, S., Anipko, D., and D. Thaler, "Packet-Loss 652 Resiliency for Router Solicitations", RFC 7559, 653 DOI 10.17487/RFC7559, May 2015, 654 . 656 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 657 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 658 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 659 . 661 [RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy 662 Consumption of Router Advertisements", BCP 202, RFC 7772, 663 DOI 10.17487/RFC7772, February 2016, 664 . 666 9.3. External Informative References 668 [IEEE80211] 669 IEEE standard for Information Technology, "IEEE Standard 670 for Information technology-- Telecommunications and 671 information exchange between systems Local and 672 metropolitan area networks-- Specific requirements Part 673 11: Wireless LAN Medium Access Control (MAC) and Physical 674 Layer (PHY) Specifications". 676 [IEEE802151] 677 IEEE standard for Information Technology, "IEEE Standard 678 for Information Technology - Telecommunications and 679 Information Exchange Between Systems - Local and 680 Metropolitan Area Networks - Specific Requirements. - Part 681 15.1: Wireless Medium Access Control (MAC) and Physical 682 Layer (PHY) Specifications for Wireless Personal Area 683 Networks (WPANs)". 685 [IEEE802154] 686 IEEE standard for Information Technology, "IEEE Standard 687 for Local and metropolitan area networks-- Part 15.4: Low- 688 Rate Wireless Personal Area Networks (LR-WPANs)". 690 Appendix A. Requirements 692 This section lists requirements that were discussed at 6lo for an 693 update to 6LoWPAN ND. This specification meets most of them, but 694 those listed in Appendix A.5 which are deferred to a different 695 specification such as [I-D.sarikaya-6lo-ap-nd]. 697 A.1. Requirements Related to Mobility 699 Due to the unstable nature of LLN links, even in a LLN of immobile 700 nodes a 6LoWPAN Node may change its point of attachment to a 6LR, say 701 6LR-a, and may not be able to notify 6LR-a. Consequently, 6LR-a may 702 still attract traffic that it cannot deliver any more. When links to 703 a 6LR change state, there is thus a need to identify stale states in 704 a 6LR and restore reachability in a timely fashion. 706 Req1.1: Upon a change of point of attachment, connectivity via a new 707 6LR MUST be restored timely without the need to de-register from the 708 previous 6LR. 710 Req1.2: For that purpose, the protocol MUST enable to differentiate 711 between multiple registrations from one 6LoWPAN Node and 712 registrations from different 6LoWPAN Nodes claiming the same address. 714 Req1.3: Stale states MUST be cleaned up in 6LRs. 716 Req1.4: A 6LoWPAN Node SHOULD also be capable to register its Address 717 to multiple 6LRs, and this, concurrently. 719 A.2. Requirements Related to Routing Protocols 721 The point of attachment of a 6LoWPAN Node may be a 6LR in an LLN 722 mesh. IPv6 routing in a LLN can be based on RPL, which is the 723 routing protocol that was defined at the IETF for this particular 724 purpose. Other routing protocols than RPL are also considered by 725 Standard Defining Organizations (SDO) on the basis of the expected 726 network characteristics. It is required that a 6LoWPAN Node attached 727 via ND to a 6LR would need to participate in the selected routing 728 protocol to obtain reachability via the 6LR. 730 Next to the 6LBR unicast address registered by ND, other addresses 731 including multicast addresses are needed as well. For example a 732 routing protocol often uses a multicast address to register changes 733 to established paths. ND needs to register such a multicast address 734 to enable routing concurrently with discovery. 736 Multicast is needed for groups. Groups MAY be formed by device type 737 (e.g. routers, street lamps), location (Geography, RPL sub-tree), or 738 both. 740 The Bit Index Explicit Replication (BIER) Architecture 741 [I-D.ietf-bier-architecture] proposes an optimized technique to 742 enable multicast in a LLN with a very limited requirement for routing 743 state in the nodes. 745 Related requirements are: 747 Req2.1: The ND registration method SHOULD be extended in such a 748 fashion that the 6LR MAY advertise the Address of a 6LoWPAN Node over 749 the selected routing protocol and obtain reachability to that Address 750 using the selected routing protocol. 752 Req2.2: Considering RPL, the Address Registration Option that is used 753 in the ND registration SHOULD be extended to carry enough information 754 to generate a DAO message as specified in [RFC6550] section 6.4, in 755 particular the capability to compute a Path Sequence and, as an 756 option, a RPLInstanceID. 758 Req2.3: Multicast operations SHOULD be supported and optimized, for 759 instance using BIER or MPL. Whether ND is appropriate for the 760 registration to the 6BBR is to be defined, considering the additional 761 burden of supporting the Multicast Listener Discovery Version 2 762 [RFC3810] (MLDv2) for IPv6. 764 A.3. Requirements Related to the Variety of Low-Power Link types 766 6LoWPAN ND [RFC6775] was defined with a focus on IEEE802.15.4 and in 767 particular the capability to derive a unique Identifier from a 768 globally unique MAC-64 address. At this point, the 6lo Working Group 769 is extending the 6LoWPAN Header Compression (HC) [RFC6282] technique 770 to other link types ITU-T G.9959 [RFC7428], Master-Slave/Token- 771 Passing [I-D.ietf-6lo-6lobac], DECT Ultra Low Energy 772 [I-D.ietf-6lo-dect-ule], Near Field Communication [I-D.ietf-6lo-nfc], 773 IEEE802.11ah [I-D.delcarpio-6lo-wlanah], as well as IEEE1901.2 774 Narrowband Powerline Communication Networks 775 [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks] and BLUETOOTH(R) 776 Low Energy [RFC7668]. 778 Related requirements are: 780 Req3.1: The support of the registration mechanism SHOULD be extended 781 to more LLN links than IEEE 802.15.4, matching at least the LLN links 782 for which an "IPv6 over foo" specification exists, as well as Low- 783 Power Wi-Fi. 785 Req3.2: As part of this extension, a mechanism to compute a unique 786 Identifier should be provided, with the capability to form a Link- 787 Local Address that SHOULD be unique at least within the LLN connected 788 to a 6LBR discovered by ND in each node within the LLN. 790 Req3.3: The Address Registration Option used in the ND registration 791 SHOULD be extended to carry the relevant forms of unique Identifier. 793 Req3.4: The Neighbour Discovery should specify the formation of a 794 site-local address that follows the security recommendations from 795 [RFC7217]. 797 A.4. Requirements Related to Proxy Operations 799 Duty-cycled devices may not be able to answer themselves to a lookup 800 from a node that uses classical ND on a backbone and may need a 801 proxy. Additionally, the duty-cycled device may need to rely on the 802 6LBR to perform registration to the 6BBR. 804 The ND registration method SHOULD defend the addresses of duty-cycled 805 devices that are sleeping most of the time and not capable to defend 806 their own Addresses. 808 Related requirements are: 810 Req4.1: The registration mechanism SHOULD enable a third party to 811 proxy register an Address on behalf of a 6LoWPAN node that may be 812 sleeping or located deeper in an LLN mesh. 814 Req4.2: The registration mechanism SHOULD be applicable to a duty- 815 cycled device regardless of the link type, and enable a 6BBR to 816 operate as a proxy to defend the registered Addresses on its behalf. 818 Req4.3: The registration mechanism SHOULD enable long sleep 819 durations, in the order of multiple days to a month. 821 A.5. Requirements Related to Security 823 In order to guarantee the operations of the 6LoWPAN ND flows, the 824 spoofing of the 6LR, 6LBR and 6BBRs roles should be avoided. Once a 825 node successfully registers an address, 6LoWPAN ND should provide 826 energy-efficient means for the 6LBR to protect that ownership even 827 when the node that registered the address is sleeping. 829 In particular, the 6LR and the 6LBR then should be able to verify 830 whether a subsequent registration for a given Address comes from the 831 original node. 833 In a LLN it makes sense to base security on layer-2 security. During 834 bootstrap of the LLN, nodes join the network after authorization by a 835 Joining Assistant (JA) or a Commissioning Tool (CT). After joining 836 nodes communicate with each other via secured links. The keys for 837 the layer-2 security are distributed by the JA/CT. The JA/CT can be 838 part of the LLN or be outside the LLN. In both cases it is needed 839 that packets are routed between JA/CT and the joining node. 841 Related requirements are: 843 Req5.1: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for 844 the 6LR, 6LBR and 6BBR to authenticate and authorize one another for 845 their respective roles, as well as with the 6LoWPAN Node for the role 846 of 6LR. 848 Req5.2: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for 849 the 6LR and the 6LBR to validate new registration of authorized 850 nodes. Joining of unauthorized nodes MUST be impossible. 852 Req5.3: 6LoWPAN ND security mechanisms SHOULD lead to small packet 853 sizes. In particular, the NS, NA, DAR and DAC messages for a re- 854 registration flow SHOULD NOT exceed 80 octets so as to fit in a 855 secured IEEE802.15.4 frame. 857 Req5.4: Recurrent 6LoWPAN ND security operations MUST NOT be 858 computationally intensive on the LoWPAN Node CPU. When a Key hash 859 calculation is employed, a mechanism lighter than SHA-1 SHOULD be 860 preferred. 862 Req5.5: The number of Keys that the 6LoWPAN Node needs to manipulate 863 SHOULD be minimized. 865 Req5.6: The 6LoWPAN ND security mechanisms SHOULD enable CCM* for use 866 at both Layer 2 and Layer 3, and SHOULD enable the reuse of security 867 code that has to be present on the device for upper layer security 868 such as TLS. 870 Req5.7: Public key and signature sizes SHOULD be minimized while 871 maintaining adequate confidentiality and data origin authentication 872 for multiple types of applications with various degrees of 873 criticality. 875 Req5.8: Routing of packets should continue when links pass from the 876 unsecured to the secured state. 878 Req5.9: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for 879 the 6LR and the 6LBR to validate whether a new registration for a 880 given address corresponds to the same 6LoWPAN Node that registered it 881 initially, and, if not, determine the rightful owner, and deny or 882 clean-up the registration that is duplicate. 884 A.6. Requirements Related to Scalability 886 Use cases from Automatic Meter Reading (AMR, collection tree 887 operations) and Advanced Metering Infrastructure (AMI, bi-directional 888 communication to the meters) indicate the needs for a large number of 889 LLN nodes pertaining to a single RPL DODAG (e.g. 5000) and connected 890 to the 6LBR over a large number of LLN hops (e.g. 15). 892 Related requirements are: 894 Req6.1: The registration mechanism SHOULD enable a single 6LBR to 895 register multiple thousands of devices. 897 Req6.2: The timing of the registration operation should allow for a 898 large latency such as found in LLNs with ten and more hops. 900 Authors' Addresses 902 Pascal Thubert (editor) 903 Cisco Systems, Inc 904 Building D 905 45 Allee des Ormes - BP1200 906 MOUGINS - Sophia Antipolis 06254 907 FRANCE 909 Phone: +33 497 23 26 34 910 Email: pthubert@cisco.com 912 Erik Nordmark 913 Arista Networks 914 Santa Clara, CA 915 USA 917 Email: nordmark@arista.com 919 Samita Chakrabarti 920 Ericsson 921 San Jose, CA 922 USA 924 Email: samita.chakrabarti@ericsson.com