idnits 2.17.1 draft-ietf-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 directly say this. It does mention RFC6775 though, so this could be OK. -- The abstract seems to indicate that this document updates RFC6, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 453 has weird spacing: '...on this link,...' -- The document date (December 23, 2016) is 2681 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 759, but not defined == Missing Reference: 'IEEE80211' is mentioned on line 742, but not defined == Missing Reference: 'IEEE802151' is mentioned on line 750, but not defined == Outdated reference: A later version (-08) exists of draft-ietf-6lo-6lobac-05 == Outdated reference: A later version (-20) exists of draft-ietf-6lo-backbone-router-02 == Outdated reference: A later version (-09) exists of draft-ietf-6lo-dect-ule-07 == Outdated reference: A later version (-22) exists of draft-ietf-6lo-nfc-05 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-10 == 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-04 Summary: 0 errors (**), 0 flaws (~~), 12 warnings (==), 3 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: June 26, 2017 S. Chakrabarti 7 Ericsson 8 December 23, 2016 10 An Update to 6LoWPAN ND 11 draft-ietf-6lo-rfc6775-update-00 13 Abstract 15 This specification updates 6LoWPAN Neighbor Discovery (RFC6775), to 16 clarify the role of the protocol as a registration technique, 17 simplify the registration operation in 6LoWPAN routers, and provide 18 enhancements to the registration capabilities, in particular for the 19 registration to a backbone router for proxy ND operations. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 29, 2017. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Updating RFC 6775 . . . . . . . . . . . . . . . . . . . . . . 4 58 3.1. Extended Address Registration Option . . . . . . . . . . 4 59 3.2. Registering the Target Address . . . . . . . . . . . . . 5 60 3.3. Link-local Addresses and Registration . . . . . . . . . . 5 61 4. Applicability and Requirements Served . . . . . . . . . . . . 7 62 5. The Enhanced Address Registration Option (EARO) . . . . . . . 7 63 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 11 64 6.1. Legacy 6LoWPAN Node . . . . . . . . . . . . . . . . . . . 11 65 6.2. Legacy 6LoWPAN Router . . . . . . . . . . . . . . . . . . 11 66 6.3. Legacy 6LoWPAN Border Router . . . . . . . . . . . . . . 12 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 69 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 72 10.2. Informative References . . . . . . . . . . . . . . . . . 14 73 10.3. External Informative References . . . . . . . . . . . . 16 74 Appendix A. Requirements . . . . . . . . . . . . . . . . . . . . 17 75 A.1. Requirements Related to Mobility . . . . . . . . . . . . 17 76 A.2. Requirements Related to Routing Protocols . . . . . . . . 17 77 A.3. Requirements Related to the Variety of Low-Power Link 78 types . . . . . . . . . . . . . . . . . . . . . . . . . . 18 79 A.4. Requirements Related to Proxy Operations . . . . . . . . 19 80 A.5. Requirements Related to Security . . . . . . . . . . . . 20 81 A.6. Requirements Related to Scalability . . . . . . . . . . . 21 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 84 1. Introduction 86 The scope of this draft is an IPv6 Low Power Lossy Network (LLN), 87 which can be a simple star or a more complex mesh topology. The LLN 88 may be anchored at an IPv6 Backbone Router (6BBR). The Backbone 89 Routers interconnect the LLNs over a Backbone Link and emulate that 90 the LLN nodes are present on the Backbone using proxy-ND operations. 92 IPv6 Neighbor Discovery (ND) Optimization for IPv6 over Low-Power 93 Wireless Personal Area Networks(6LoWPANs) [RFC6775] introduced a 94 proactive registration mechanism to IPv6 ND services for nodes 95 belonging to a LLN. 97 This specification modifies and extends the behaviour and protocol 98 elements of [RFC6775] to enable additional capabilities, in 99 particular the registration to a 6BBR for proxy ND operations 100 [I-D.ietf-6lo-backbone-router]. 102 2. Terminology 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 Readers are expected to be familiar with all the terms and concepts 109 that are discussed in "Neighbor Discovery for IP version 6" 110 [RFC4861], "IPv6 Stateless Address Autoconfiguration" [RFC4862], 111 "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): 112 Overview, Assumptions, Problem Statement, and Goals" [RFC4919], 113 Neighbor Discovery Optimization for Low-power and Lossy Networks 114 [RFC6775] and "Multi-link Subnet Support in IPv6" 115 [I-D.ietf-ipv6-multilink-subnets]. 117 Additionally, this document uses terminology from "Terms Used in 118 Routing for Low-Power and Lossy Networks" [RFC7102] and 119 [I-D.ietf-6tisch-terminology], as well as this additional 120 terminology: 122 Backbone This is an IPv6 transit link that interconnects 2 or more 123 Backbone Routers. It is expected to be deployed as a high 124 speed backbone in order to federate a potentially large set of 125 LLNS. Also referred to as a LLN backbone or Backbone network. 127 Backbone Router An IPv6 router that federates the LLN using a 128 Backbone link as a backbone. A 6BBR acts as a 6LoWPAN Border 129 Routers (6LBR) and an Energy Aware Default Router (NEAR). 131 Extended LLN This is the aggregation of multiple LLNs as defined in 132 [RFC4919], interconnected by a Backbone Link via Backbone 133 Routers, and forming a single IPv6 MultiLink Subnet. 135 Registration The process during which a wireless Node registers its 136 address(es) with the Border Router so the 6BBR can proxy ND for 137 it over the backbone. 139 Binding The state in the 6BBR that associates an IP address with a 140 MAC address, a port and some other information about the node 141 that owns the IP address. 143 Registered Node The node for which the registration is performed, 144 which owns the fields in the EARO option. 146 Registering Node The node that performs the registration to the 147 6BBR, either for one of its own addresses, in which case it is 148 Registered Node and indicates its own MAC Address as SLLA in 149 the NS(ARO), or on behalf of a Registered Node that is 150 reachable over a LLN mesh. In the latter case, if the 151 Registered Node is reachable from the 6BBR over a Mesh-Under 152 mesh, the Registering Node indicates the MAC Address of the 153 Registered Node as SLLA in the NS(ARO). Otherwise, it is 154 expected that the Registered Device is reachable over a Route- 155 Over mesh from the Registering Node, in which case the SLLA in 156 the NS(ARO) is that of the Registering Node, which causes it to 157 attract the packets from the 6BBR to the Registered Node and 158 route them over the LLN. 160 Registered Address The address owned by the Registered Node node 161 that is being registered. 163 3. Updating RFC 6775 165 The support of this specification is signaled in Router Advertisement 166 (RA) messages by 6LoWPAN Router (6LR) (how: tbd). Support for this 167 specification can also be inferred from the update of the ARO option 168 in the ND exchanges 170 . A Registering Node that supports this specification will favor 171 registering to a 6LR that indicates support for this specification 172 over that of [RFC6775]. 174 3.1. Extended Address Registration Option 176 This specification extends the Address Registration Option (ARO) used 177 for the process of address registration. The new ARO is referred to 178 as Extended ARO (EARO), and its semantics are modified as follows: 180 The address that is being registered with a Neighbor Solicitation 181 (NS) with an EARO is now the Target Address, as opposed to the Source 182 Address as specified in [RFC6775]. This change enables a 6LBR to use 183 an address of his as source to the proxy-registration of an address 184 that belongs to a LLN Node to a 6BBR. This also limits the use of an 185 address as source address before it is registered and the associated 186 Duplicate Address Detection (DAD) is complete. 188 The Unique ID in the EARO option does no more have to be a MAC 189 address. A new TLV format is introduced and a IANA registry is 190 created for the type (TBD). This enables in particular the use of a 191 Provable Temporary UID (PT-UID) as opposed to burn-in MAC address, 192 the PT-UID providing a trusted anchor by the 6LR and 6LBR to protect 193 the state associated to the node. 195 The specification introduces a Transaction ID (TID) field in the 196 EARO. The TID MUST be provided by a node that supports this 197 specification and a new T flag MUST be set to indicate so. The T bit 198 can be used to determine whether the peer supports this 199 specification. 201 3.2. Registering the Target Address 203 One of the requirements that this specification serves is the 204 capability by a router such as a RPL root to proxy-register an 205 address to a 6BBR on behalf of a 6LN, as discussed in Appendix A.4. 206 In order to serve that requirement, this specification changes the 207 behaviour of the 6LN and the 6LR so that the Registered Address is 208 found in the Target Address field of the NS and NA messages as 209 opposed to the Source Address. 211 With this convention, a TLLA option would indicate the link-layer 212 address of the 6LN that owns the address, whereas the SLLA Option in 213 a NS message indicates that of the Registering Node, which can be the 214 owner device, or a proxy. 216 Since the Registering Node is the one that has reachability with the 217 6LR, and is the one expecting packets for the 6LN, it makes sense to 218 maintain compatibility with [RFC6775], and it is REQUIRED that an 219 SLLA Option is always placed in a registration NS(EARO) message. 221 3.3. Link-local Addresses and Registration 223 Considering that LLN nodes are often not wired and may move, there is 224 no guarantee that a link-local address stays unique between a 225 potentially variable and unbounded set of neighboring nodes. 226 Compared to [RFC6775], this specification only requires that a link- 227 local address is unique from the perspective of the peering nodes. 228 This simplifies the Duplicate Address Detection (DAD) for link-local 229 addresses, and there is no DAR/DAC exchange between the 6LR and a 230 6LBR for link-local addresses. 232 Additionally, [RFC6775] requires that a 6LoWPAN Node (6LN) uses an 233 address being registered as the source of the registration message. 234 This generates complexities in the 6LR to be able to cope with a 235 potential duplication, in particular for global addresses. To 236 simplify this, a 6LN and a 6LR that conform this specification always 237 use link-local addresses as source and destination addresses for the 238 registration NS/NA exchange. As a result, the registration is 239 globally faster, and some of the complexity is removed. 241 In more details: 243 An exchange between two nodes using link-local addresses implies that 244 they are reachable over one hop and that at least one of the 2 nodes 245 acts as a 6LR. A node MUST register a link-local address to a 6LR in 246 order to obtain reachability from that 6LR beyond the current 247 exchange, and in particular to use the link-local address as source 248 address to register other addresses, e.g. global addresses. If there 249 is no collision with an address previously registered to this 6LR by 250 another 6LN, then, from the standpoint of this 6LR, this link-local 251 address is unique and the registration is acceptable. Conversely, it 252 may possibly happen that two different 6LRs expose a same link-local 253 address but different link-layer addresses. In that case, a 6LN may 254 only interact with one of the 6LR so as to avoid confusion in the 6LN 255 neighbor cache. 257 The DAD process between the 6LR and a 6LoWPAN Border Router (6LBR), 258 which is based on a Duplicate Address Request (DAR) / Duplicate 259 Address Confirmation (DAC) exchange as described in [RFC6775], does 260 not need to take place for link-local addresses. 262 It is desired that a 6LR does not need to modify its state associated 263 to the Source Address of an NS(EARO) message. For that reason, when 264 possible, it is RECOMMENDED to use an address that is already 265 registered with a 6LR 267 When registering to a 6LR that conforms this specification, a node 268 MUST use a link-local address as the source address of the 269 registration, whatever the type of IPv6 address that is being 270 registered. That link-local Address MUST be either already 271 registrered, or the address that is being registered. 273 When a Registering Node does not have an already-registered address, 274 it MUST register a link-local address, using it as both the Source 275 and the Target Address of an NS(EARO) message. In that case, it is 276 RECOMMENDED to use a link-local address that is (expected to be) 277 globally unique, e.g. derived from a burn-in MAC address. An EARO 278 option in the response NA indicates that the 6LR supports this 279 specification. 281 Since there is no DAR/DAC exchange for link-local addresses, the 6LR 282 may answer immediately to the registration of a link-local address, 283 based solely on its existing state and the Source Link-Layer Option 284 that MUST be placed in the NS(EARO) message as required in [RFC6775]. 286 A node needs to register its IPv6 Global Unicast IPv6 Addresses (GUA) 287 to a 6LR in order to obtain a global reachability for these addresses 288 via that 6LR. As opposed to a node that complies to [RFC6775], a 289 Registering Node registering a GUA does use that GUA as Source 290 Address for the registration to a 6LR that conforms this 291 specification. The DAR/DAC exchange MUST take place for non-link- 292 local addresses as prescribed by [RFC6775]. 294 4. Applicability and Requirements Served 296 This specification extends 6LoWPAN ND to sequence the registration 297 and serves the requirements expressed Appendix A.1 by enabling the 298 mobility of devices from one LLN to the next based on the 299 complementary work in [I-D.ietf-6lo-backbone-router]. 301 In the context of the the TimeSlotted Channel Hopping (TSCH) mode of 302 [IEEE802154], the 6TiSCH architecture [I-D.ietf-6tisch-architecture] 303 introduces how a 6LoWPAN ND host could connect to the Internet via a 304 RPL mesh Network, but this requires additions to the 6LOWPAN ND 305 protocol to support mobility and reachability in a secured and 306 manageable environment. This specification details the new 307 operations that are required to implement the 6TiSCH architecture and 308 serves the requirements listed in Appendix A.2. 310 The term LLN is used loosely in this specification to cover multiple 311 types of WLANs and WPANs, including Low-Power Wi-Fi, BLUETOOTH(R) Low 312 Energy, IEEE802.11AH and IEEE802.15.4 wireless meshes, so as to 313 address the requirements discussed in Appendix A.3 315 This specification can be used by any wireless node to associate at 316 Layer-3 with a 6BBR and register its IPv6 addresses to obtain routing 317 services including proxy-ND operations over the backbone, effectively 318 providing a solution to the requirements expressed in Appendix A.4. 320 Efficiency aware IPv6 Neighbor Discovery Optimizations 321 [I-D.chakrabarti-nordmark-6man-efficient-nd] suggests that 6LoWPAN ND 322 [RFC6775] can be extended to other types of links beyond IEEE802.15.4 323 for which it was defined. The registration technique is beneficial 324 when the Link-Layer technique used to carry IPv6 multicast packets is 325 not sufficiently efficient in terms of delivery ratio or energy 326 consumption in the end devices, in particular to enable energy- 327 constrained sleeping nodes. The value of such extension is 328 especially apparent in the case of mobile wireless nodes, to reduce 329 the multicast operations that are related to classical ND ([RFC4861], 330 [RFC4862]) and plague the wireless medium. This serves scalability 331 requirements listed in Appendix A.6. 333 5. The Enhanced Address Registration Option (EARO) 335 With the ARO option defined in 6LoWPAN ND [RFC6775], the address 336 being registered and its owner can be uniquely identified and matched 337 with the Binding Table entries of each Backbone Router. 339 The Enhanced Address Registration Option (EARO) is intended to be 340 used as a replacement to the ARO option within Neighbor Discovery NS 341 and NA messages between a LLN node and its 6LoWPAN Router (6LR), as 342 well as in Duplicate Address Request (DAR) and the Duplicate Address 343 Confirmation (DAC) messages between 6LRs and 6LBRs in LLNs meshes 344 such as 6TiSCH networks. 346 An NS message with an EARO option is a registration if and only if it 347 also carries an SLLAO option. The AERO option also used in NS and NA 348 messages between Backbone Routers over the backbone link to sort out 349 the distributed registration state, and in that case, it does not 350 carry the SLLAO option and is not confused with a registration. 352 The EARO extends the ARO and is recognized by the setting of the TID 353 bit. A node that supports this specification MUST always use an EARO 354 as a replacement to an ARO in its registration to a router. This is 355 harmless since the TID bit and fields are reserved in [RFC6775] are 356 ignored by a legacy router. A router that supports this 357 specification answers to an ARO with an ARO and to an EARO with an 358 EARO. 360 This specification changes the behavior of the peers in a 361 registration flows. To enable backward compatibility, a node that 362 registers to a router that is not known to support this specification 363 MUST behave as prescribed by [RFC6775]. Once the router is known to 364 support this specification, the node MUST obey this specification. 366 When using the EARO option, the address being registered is found in 367 the Target Address field of the NS and NA messages. This differs 368 from 6LoWPAN ND [RFC6775] which specifies that the address being 369 registered is the source of the NS. 371 The reason for this change is to enable proxy-registrations on behalf 372 of other nodes in Route-Over meshes, for instance to enable that a 373 RPL root registers addresses on behalf LLN nodes that are deeper in a 374 6TiSCH mesh. In that case, the Registering Node MUST indicate its 375 own address as source of the ND message and its MAC address in the 376 Source Link-Layer Address Option (SLLAO), since it still expects to 377 get the packets and route them down the mesh. But the Registered 378 Address belongs to another node, the Registered Node, and that 379 address is indicated in the Target Address field of the NS message. 381 One way of achieving all the above is for a node to first register an 382 address that it owns in order to validate that the router supports 383 this specification, placing the same address in the Source and Target 384 Address fields of the NS message. The node may for instance register 385 an address that is based on EUI-64. For such address, DAD is not 386 required and using the SLLAO option in the NS is actually more 387 amenable with older ND specifications such as ODAD [RFC4429]. 389 Once that first registration is complete, the node knows from the 390 setting of the TID in the response whether the router supports this 391 specification. If this is verified, the node may register other 392 addresses that it owns, or proxy-register addresses on behalf some 393 another node, indicating those addresses being registered in the 394 Target Address field of the NS messages, while using one of its own, 395 already registered, addresses as source. 397 The format of the EARO option is as follows: 399 0 1 2 3 400 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 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Type | Length = 2 | Status | Reserved | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | Reserved |T| TID | Registration Lifetime | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | | 407 + Owner Unique ID (EUI-64 or equivalent) + 408 | | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 Figure 1: EARO 413 Option Fields 415 Type: 417 Length: 2 419 Status: 421 +-------+-----------------------------------------------------------+ 422 | Value | Description | 423 +-------+-----------------------------------------------------------+ 424 | 0..2 | See [RFC6775]. Note that a Status of 1 "Duplicate | 425 | | Address" applies to the Registered Address. If the Source | 426 | | Address conflicts with an existing registration, | 427 | | "Duplicate Source Address" should be used instead | 428 | | | 429 | 3 | Moved: The registration fails because it is not the | 430 | | freshest | 431 | | | 432 | 4 | Removed: The binding state was removed. This may be | 433 | | placed in an asynchronous NS(ARO) message, or as the | 434 | | rejection of a proxy registration to a Backbone Router | 435 | | | 436 | 5 | Proof requested: The registering node is challenged for | 437 | | owning the registered address or for being an acceptable | 438 | | proxy for the registration | 439 | | | 440 | 6 | Duplicate Source Address: The address used as source of | 441 | | the NS(ARO) conflicts with an existing registration. | 442 | | | 443 | 7 | Administrative Rejection: The address being registered is | 444 | | reserved for another use by an administrative decision | 445 | | (e.g. placed in a DHCPv6 pool); The Registering Node is | 446 | | requested to form a different address and retry | 447 | | | 448 | 8 | Invalid Registered Address: The address being registered | 449 | | is not usable on this link, e.g. it is not topologically | 450 | | correct | 451 | | | 452 | 9 | Invalid Source Address: The address used as source of the | 453 | | NS(ARO) is not usable on this link, e.g. it is not | 454 | | topologically correct | 455 +-------+-----------------------------------------------------------+ 457 Table 1 459 Reserved: This field is unused. It MUST be initialized to zero by 460 the sender and MUST be ignored by the receiver. 462 T: One bit flag. Set if the next octet is a used as a TID. 464 TID: 1-byte integer; a transaction id that is maintained by the node 465 and incremented with each transaction. it is recommended that the 466 node maintains the TID in a persistent storage. 468 Registration Lifetime: 16-bit integer; expressed in minutes. 0 469 means that the registration has ended and the state should be 470 removed. 472 Owner Unique Identifier (OUI): A globally unique identifier for the 473 node associated. This can be the EUI-64 derived IID of an 474 interface, or some provable ID obtained cryptographically. 476 New status values are introduced, their values to be confirmed by 477 IANA: 479 Moved: This status indicates that the registration is rejected 480 because another more recent registration was done, as indicated by 481 a same OUI and a more recent TID. One possible cause is a stale 482 registration that has progressed slowly in the network and was 483 passed by a more recent one. It could also indicate a OUI 484 collision. 486 Removed: This status is expected in asynchronous messages from a 487 registrar (6LR, 6LBR, 6BBR) to indicate that the registration 488 state is removed, for instance due to time out of a lifetime, or a 489 movement. It is used for instance by a 6BBR in a NA(ARO) message 490 to indicate that the ownership of the proxy state on the backbone 491 was transfered to another 6BBR, which is indicative of a movement 492 of the device. The receiver of the NA is the device that has 493 performed a registration that is now stale and it should clean up 494 its state. 496 6. Backward Compatibility 498 6.1. Legacy 6LoWPAN Node 500 A legacy 6LN will use the registered address as source and will not 501 use an EARO option. In order to be backward compatible, an updated 502 6LR needs to accept that registration if it is valid per [RFC3972], 503 and manage the binding cache accordingly. 505 The main difference with [RFC3972] is that DAR/DAC exchange for DAD 506 may be avoided for link-local addresses. Additionally, the 6LR 507 SHOULD use an EARO in the reply, and may use all the status codes 508 defined in this specification. 510 6.2. Legacy 6LoWPAN Router 512 The first registration by a an updated 6LN is for a link-local 513 address, using that link-local address as source. A legacy 6LN will 514 not makes a difference and accept -or reject- that registration as if 515 the 6LN was a legacy node. 517 An updated 6LN will always use an EARO option in the registration NS 518 message, whereas a legacy 6LN will always areply with an ARO option 519 in the NA message. So from that first registration, the updated 6LN 520 can figure whether the 6LR supports this specification or not. 522 When facing a legacy 6LR, an updated 6LN may attempt to find an 523 alternate 6LR that is updated. In order to be backward compatible, 524 based on the discovery that a 6LR is legacy, the 6LN needs to 525 fallback to legacy behaviour and source the packet with the 526 registrered address. 528 The main difference is that the updated 6LN SHOULD use an EARO in the 529 request regardless of the type of 6LN, legacy or updated 531 6.3. Legacy 6LoWPAN Border Router 533 With this specification, the DAR/DAC transports an EARO option as 534 opposed to an ARO option. As described for the NS/NA exchange, 535 devices that support this specification always use an EARO option and 536 all the associated behaviour. 538 7. Security Considerations 540 This specification expects that the link layer is sufficiently 541 protected, either by means of physical or IP security for the 542 Backbone Link or MAC sublayer cryptography. In particular, it is 543 expected that the LLN MAC provides secure unicast to/from the 544 Backbone Router and secure Broadcast from the Backbone Router in a 545 way that prevents tempering with or replaying the RA messages. 547 The use of EUI-64 for forming the Interface ID in the link-local 548 address prevents the usage of Secure ND ([RFC3971] and [RFC3972]) and 549 address privacy techniques. This specification RECOMMENDS the use of 550 additional protection against address theft such as provided by 551 [I-D.sarikaya-6lo-ap-nd], which guarantees the ownership of the OUID. 553 When the ownership of the OUID cannot be assessed, this specification 554 limits the cases where the OUID and the TID are multicasted, and 555 obfuscates them in responses to attempts to take over an address. 557 The LLN nodes depend on the 6LBR and the 6BBR for their operation. A 558 trust model must be put in place to ensure that the right devices are 559 acting in these roles, so as to avoid threats such as black-holing, 560 or bombing attack whereby an impersonated 6LBR would destroy state in 561 the network by using the "Removed" status code. 563 8. IANA Considerations 565 This document requires the following additions: 567 Address Registration Option Status Values Registry 569 +--------+--------------------------+ 570 | Status | Description | 571 +--------+--------------------------+ 572 | 3 | Moved | 573 | | | 574 | 4 | Removed | 575 | | | 576 | 5 | Proof requested | 577 | | | 578 | 6 | Invalid Source Address | 579 | | | 580 | 7 | Administrative Rejection | 581 +--------+--------------------------+ 583 IANA is required to change the registry accordingly 585 Table 2: New ARO Status values 587 9. Acknowledgments 589 Kudos to Eric Levy-Abegnoli who designed the First Hop Security 590 infrastructure at Cisco. 592 10. References 594 10.1. Normative References 596 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 597 Requirement Levels", BCP 14, RFC 2119, 598 DOI 10.17487/RFC2119, March 1997, 599 . 601 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 602 for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, 603 . 605 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 606 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 607 DOI 10.17487/RFC4861, September 2007, 608 . 610 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 611 Address Autoconfiguration", RFC 4862, 612 DOI 10.17487/RFC4862, September 2007, 613 . 615 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 616 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 617 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 618 Low-Power and Lossy Networks", RFC 6550, 619 DOI 10.17487/RFC6550, March 2012, 620 . 622 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 623 Bormann, "Neighbor Discovery Optimization for IPv6 over 624 Low-Power Wireless Personal Area Networks (6LoWPANs)", 625 RFC 6775, DOI 10.17487/RFC6775, November 2012, 626 . 628 10.2. Informative References 630 [I-D.chakrabarti-nordmark-6man-efficient-nd] 631 Chakrabarti, S., Nordmark, E., Thubert, P., and M. 632 Wasserman, "IPv6 Neighbor Discovery Optimizations for 633 Wired and Wireless Networks", draft-chakrabarti-nordmark- 634 6man-efficient-nd-07 (work in progress), February 2015. 636 [I-D.delcarpio-6lo-wlanah] 637 Vega, L., Robles, I., and R. Morabito, "IPv6 over 638 802.11ah", draft-delcarpio-6lo-wlanah-01 (work in 639 progress), October 2015. 641 [I-D.ietf-6lo-6lobac] 642 Lynn, K., Martocci, J., Neilson, C., and S. Donaldson, 643 "Transmission of IPv6 over MS/TP Networks", draft-ietf- 644 6lo-6lobac-05 (work in progress), June 2016. 646 [I-D.ietf-6lo-backbone-router] 647 Thubert, P., "IPv6 Backbone Router", draft-ietf-6lo- 648 backbone-router-02 (work in progress), September 2016. 650 [I-D.ietf-6lo-dect-ule] 651 Mariager, P., Petersen, J., Shelby, Z., Logt, M., and D. 652 Barthel, "Transmission of IPv6 Packets over DECT Ultra Low 653 Energy", draft-ietf-6lo-dect-ule-07 (work in progress), 654 October 2016. 656 [I-D.ietf-6lo-nfc] 657 Choi, Y., Youn, J., and Y. Hong, "Transmission of IPv6 658 Packets over Near Field Communication", draft-ietf-6lo- 659 nfc-05 (work in progress), October 2016. 661 [I-D.ietf-6tisch-architecture] 662 Thubert, P., "An Architecture for IPv6 over the TSCH mode 663 of IEEE 802.15.4", draft-ietf-6tisch-architecture-10 (work 664 in progress), June 2016. 666 [I-D.ietf-6tisch-terminology] 667 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 668 "Terminology in IPv6 over the TSCH mode of IEEE 669 802.15.4e", draft-ietf-6tisch-terminology-07 (work in 670 progress), March 2016. 672 [I-D.ietf-bier-architecture] 673 Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and 674 S. Aldrin, "Multicast using Bit Index Explicit 675 Replication", draft-ietf-bier-architecture-04 (work in 676 progress), July 2016. 678 [I-D.ietf-ipv6-multilink-subnets] 679 Thaler, D. and C. Huitema, "Multi-link Subnet Support in 680 IPv6", draft-ietf-ipv6-multilink-subnets-00 (work in 681 progress), July 2002. 683 [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks] 684 Popa, D. and J. Hui, "6LoPLC: Transmission of IPv6 Packets 685 over IEEE 1901.2 Narrowband Powerline Communication 686 Networks", draft-popa-6lo-6loplc-ipv6-over- 687 ieee19012-networks-00 (work in progress), March 2014. 689 [I-D.sarikaya-6lo-ap-nd] 690 Sethi, M., Thubert, P., and B. Sarikaya, "Address 691 Protected Neighbor Discovery for Low-power and Lossy 692 Networks", draft-sarikaya-6lo-ap-nd-04 (work in progress), 693 August 2016. 695 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 696 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 697 DOI 10.17487/RFC3810, June 2004, 698 . 700 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 701 "SEcure Neighbor Discovery (SEND)", RFC 3971, 702 DOI 10.17487/RFC3971, March 2005, 703 . 705 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 706 RFC 3972, DOI 10.17487/RFC3972, March 2005, 707 . 709 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 710 over Low-Power Wireless Personal Area Networks (6LoWPANs): 711 Overview, Assumptions, Problem Statement, and Goals", 712 RFC 4919, DOI 10.17487/RFC4919, August 2007, 713 . 715 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 716 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 717 DOI 10.17487/RFC6282, September 2011, 718 . 720 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 721 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 722 2014, . 724 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 725 Interface Identifiers with IPv6 Stateless Address 726 Autoconfiguration (SLAAC)", RFC 7217, 727 DOI 10.17487/RFC7217, April 2014, 728 . 730 [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets 731 over ITU-T G.9959 Networks", RFC 7428, 732 DOI 10.17487/RFC7428, February 2015, 733 . 735 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 736 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 737 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 738 . 740 10.3. External Informative References 742 [IEEE80211] 743 IEEE standard for Information Technology, "IEEE Standard 744 for Information technology-- Telecommunications and 745 information exchange between systems Local and 746 metropolitan area networks-- Specific requirements Part 747 11: Wireless LAN Medium Access Control (MAC) and Physical 748 Layer (PHY) Specifications". 750 [IEEE802151] 751 IEEE standard for Information Technology, "IEEE Standard 752 for Information Technology - Telecommunications and 753 Information Exchange Between Systems - Local and 754 Metropolitan Area Networks - Specific Requirements. - Part 755 15.1: Wireless Medium Access Control (MAC) and Physical 756 Layer (PHY) Specifications for Wireless Personal Area 757 Networks (WPANs)". 759 [IEEE802154] 760 IEEE standard for Information Technology, "IEEE Standard 761 for Local and metropolitan area networks-- Part 15.4: Low- 762 Rate Wireless Personal Area Networks (LR-WPANs)". 764 Appendix A. Requirements 766 This section lists requirements that were discussed at 6lo for an 767 update to 6LoWPAN ND. This specification meets most of them, but 768 those listed in Appendix A.5 which are deferred to a different 769 specification such as [I-D.sarikaya-6lo-ap-nd]. 771 A.1. Requirements Related to Mobility 773 Due to the unstable nature of LLN links, even in a LLN of immobile 774 nodes a 6LN may change its point of attachment to a 6LR, say 6LR-a, 775 and may not be able to notify 6LR-a. Consequently, 6LR-a may still 776 attract traffic that it cannot deliver any more. When links to a 6LR 777 change state, there is thus a need to identify stale states in a 6LR 778 and restore reachability in a timely fashion. 780 Req1.1: Upon a change of point of attachment, connectivity via a new 781 6LR MUST be restored timely without the need to de-register from the 782 previous 6LR. 784 Req1.2: For that purpose, the protocol MUST enable to differentiate 785 between multiple registrations from one 6LoWPAN Node and 786 registrations from different 6LoWPAN Nodes claiming the same address. 788 Req1.3: Stale states MUST be cleaned up in 6LRs. 790 Req1.4: A 6LoWPAN Node SHOULD also be capable to register its Address 791 to multiple 6LRs, and this, concurrently. 793 A.2. Requirements Related to Routing Protocols 795 The point of attachment of a 6LN may be a 6LR in an LLN mesh. IPv6 796 routing in a LLN can be based on RPL, which is the routing protocol 797 that was defined at the IETF for this particular purpose. Other 798 routing protocols than RPL are also considered by Standard Defining 799 Organizations (SDO) on the basis of the expected network 800 characteristics. It is required that a 6LoWPAN Node attached via ND 801 to a 6LR would need to participate in the selected routing protocol 802 to obtain reachability via the 6LR. 804 Next to the 6LBR unicast address registered by ND, other addresses 805 including multicast addresses are needed as well. For example a 806 routing protocol often uses a multicast address to register changes 807 to established paths. ND needs to register such a multicast address 808 to enable routing concurrently with discovery. 810 Multicast is needed for groups. Groups MAY be formed by device type 811 (e.g. routers, street lamps), location (Geography, RPL sub-tree), or 812 both. 814 The Bit Index Explicit Replication (BIER) Architecture 815 [I-D.ietf-bier-architecture] proposes an optimized technique to 816 enable multicast in a LLN with a very limited requirement for routing 817 state in the nodes. 819 Related requirements are: 821 Req2.1: The ND registration method SHOULD be extended in such a 822 fashion that the 6LR MAY advertise the Address of a 6LoWPAN Node over 823 the selected routing protocol and obtain reachability to that Address 824 using the selected routing protocol. 826 Req2.2: Considering RPL, the Address Registration Option that is used 827 in the ND registration SHOULD be extended to carry enough information 828 to generate a DAO message as specified in [RFC6550] section 6.4, in 829 particular the capability to compute a Path Sequence and, as an 830 option, a RPLInstanceID. 832 Req2.3: Multicast operations SHOULD be supported and optimized, for 833 instance using BIER or MPL. Whether ND is appropriate for the 834 registration to the 6BBR is to be defined, considering the additional 835 burden of supporting the Multicast Listener Discovery Version 2 836 [RFC3810] (MLDv2) for IPv6. 838 A.3. Requirements Related to the Variety of Low-Power Link types 840 6LoWPAN ND [RFC6775] was defined with a focus on IEEE802.15.4 and in 841 particular the capability to derive a unique Identifier from a 842 globally unique MAC-64 address. At this point, the 6lo Working Group 843 is extending the 6LoWPAN Header Compression (HC) [RFC6282] technique 844 to other link types ITU-T G.9959 [RFC7428], Master-Slave/Token- 845 Passing [I-D.ietf-6lo-6lobac], DECT Ultra Low Energy 847 [I-D.ietf-6lo-dect-ule], Near Field Communication [I-D.ietf-6lo-nfc], 848 IEEE802.11ah [I-D.delcarpio-6lo-wlanah], as well as IEEE1901.2 849 Narrowband Powerline Communication Networks 850 [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks] and BLUETOOTH(R) 851 Low Energy [RFC7668]. 853 Related requirements are: 855 Req3.1: The support of the registration mechanism SHOULD be extended 856 to more LLN links than IEEE 802.15.4, matching at least the LLN links 857 for which an "IPv6 over foo" specification exists, as well as Low- 858 Power Wi-Fi. 860 Req3.2: As part of this extension, a mechanism to compute a unique 861 Identifier should be provided, with the capability to form a Link- 862 Local Address that SHOULD be unique at least within the LLN connected 863 to a 6LBR discovered by ND in each node within the LLN. 865 Req3.3: The Address Registration Option used in the ND registration 866 SHOULD be extended to carry the relevant forms of unique Identifier. 868 Req3.4: The Neighbour Discovery should specify the formation of a 869 site-local address that follows the security recommendations from 870 [RFC7217]. 872 A.4. Requirements Related to Proxy Operations 874 Duty-cycled devices may not be able to answer themselves to a lookup 875 from a node that uses classical ND on a backbone and may need a 876 proxy. Additionally, the duty-cycled device may need to rely on the 877 6LBR to perform registration to the 6BBR. 879 The ND registration method SHOULD defend the addresses of duty-cycled 880 devices that are sleeping most of the time and not capable to defend 881 their own Addresses. 883 Related requirements are: 885 Req4.1: The registration mechanism SHOULD enable a third party to 886 proxy register an Address on behalf of a 6LoWPAN node that may be 887 sleeping or located deeper in an LLN mesh. 889 Req4.2: The registration mechanism SHOULD be applicable to a duty- 890 cycled device regardless of the link type, and enable a 6BBR to 891 operate as a proxy to defend the registered Addresses on its behalf. 893 Req4.3: The registration mechanism SHOULD enable long sleep 894 durations, in the order of multiple days to a month. 896 A.5. Requirements Related to Security 898 In order to guarantee the operations of the 6LoWPAN ND flows, the 899 spoofing of the 6LR, 6LBR and 6BBRs roles should be avoided. Once a 900 node successfully registers an address, 6LoWPAN ND should provide 901 energy-efficient means for the 6LBR to protect that ownership even 902 when the node that registered the address is sleeping. 904 In particular, the 6LR and the 6LBR then should be able to verify 905 whether a subsequent registration for a given Address comes from the 906 original node. 908 In a LLN it makes sense to base security on layer-2 security. During 909 bootstrap of the LLN, nodes join the network after authorization by a 910 Joining Assistant (JA) or a Commissioning Tool (CT). After joining 911 nodes communicate with each other via secured links. The keys for 912 the layer-2 security are distributed by the JA/CT. The JA/CT can be 913 part of the LLN or be outside the LLN. In both cases it is needed 914 that packets are routed between JA/CT and the joining node. 916 Related requirements are: 918 Req5.1: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for 919 the 6LR, 6LBR and 6BBR to authenticate and authorize one another for 920 their respective roles, as well as with the 6LoWPAN Node for the role 921 of 6LR. 923 Req5.2: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for 924 the 6LR and the 6LBR to validate new registration of authorized 925 nodes. Joining of unauthorized nodes MUST be impossible. 927 Req5.3: 6LoWPAN ND security mechanisms SHOULD lead to small packet 928 sizes. In particular, the NS, NA, DAR and DAC messages for a re- 929 registration flow SHOULD NOT exceed 80 octets so as to fit in a 930 secured IEEE802.15.4 frame. 932 Req5.4: Recurrent 6LoWPAN ND security operations MUST NOT be 933 computationally intensive on the LoWPAN Node CPU. When a Key hash 934 calculation is employed, a mechanism lighter than SHA-1 SHOULD be 935 preferred. 937 Req5.5: The number of Keys that the 6LoWPAN Node needs to manipulate 938 SHOULD be minimized. 940 Req5.6: The 6LoWPAN ND security mechanisms SHOULD enable CCM* for use 941 at both Layer 2 and Layer 3, and SHOULD enable the reuse of security 942 code that has to be present on the device for upper layer security 943 such as TLS. 945 Req5.7: Public key and signature sizes SHOULD be minimized while 946 maintaining adequate confidentiality and data origin authentication 947 for multiple types of applications with various degrees of 948 criticality. 950 Req5.8: Routing of packets should continue when links pass from the 951 unsecured to the secured state. 953 Req5.9: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for 954 the 6LR and the 6LBR to validate whether a new registration for a 955 given address corresponds to the same 6LoWPAN Node that registered it 956 initially, and, if not, determine the rightful owner, and deny or 957 clean-up the registration that is duplicate. 959 A.6. Requirements Related to Scalability 961 Use cases from Automatic Meter Reading (AMR, collection tree 962 operations) and Advanced Metering Infrastructure (AMI, bi-directional 963 communication to the meters) indicate the needs for a large number of 964 LLN nodes pertaining to a single RPL DODAG (e.g. 5000) and connected 965 to the 6LBR over a large number of LLN hops (e.g. 15). 967 Related requirements are: 969 Req6.1: The registration mechanism SHOULD enable a single 6LBR to 970 register multiple thousands of devices. 972 Req6.2: The timing of the registration operation should allow for a 973 large latency such as found in LLNs with ten and more hops. 975 Authors' Addresses 977 Pascal Thubert (editor) 978 Cisco Systems, Inc 979 Building D 980 45 Allee des Ormes - BP1200 981 MOUGINS - Sophia Antipolis 06254 982 FRANCE 984 Phone: +33 497 23 26 34 985 Email: pthubert@cisco.com 986 Erik Nordmark 987 Arista Networks 988 Santa Clara, CA 989 USA 991 Email: nordmark@arista.com 993 Samita Chakrabarti 994 Ericsson 995 San Jose, CA 996 USA 998 Email: samita.chakrabarti@ericsson.com