idnits 2.17.1 draft-ietf-6lo-rfc6775-update-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 : ---------------------------------------------------------------------------- -- 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 501 has weird spacing: '...on this link,...' -- The document date (January 10, 2017) is 2657 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: 'IEEEstd802154' is mentioned on line 964, but not defined == Outdated reference: A later version (-08) exists of draft-ietf-6lo-6lobac-06 == Outdated reference: A later version (-23) exists of draft-ietf-6lo-ap-nd-00 == Outdated reference: A later version (-20) exists of draft-ietf-6lo-backbone-router-02 == 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-08 == Outdated reference: A later version (-08) exists of draft-ietf-bier-architecture-05 Summary: 0 errors (**), 0 flaws (~~), 10 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: July 14, 2017 S. Chakrabarti 7 January 10, 2017 9 An Update to 6LoWPAN ND 10 draft-ietf-6lo-rfc6775-update-01 12 Abstract 14 This specification updates 6LoWPAN Neighbor Discovery (RFC6775), to 15 clarify the role of the protocol as a registration technique, 16 simplify the registration operation in 6LoWPAN routers, and provide 17 enhancements to the registration capabilities, in particular for the 18 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 July 14, 2017. 37 Copyright Notice 39 Copyright (c) 2017 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. Transaction ID . . . . . . . . . . . . . . . . . . . . . 4 58 3.2. Owner Unique ID . . . . . . . . . . . . . . . . . . . . . 5 59 3.3. Extended Address Registration Option . . . . . . . . . . 5 60 3.4. Registering the Target Address . . . . . . . . . . . . . 6 61 3.5. Link-local Addresses and Registration . . . . . . . . . . 6 62 4. Applicability and Requirements Served . . . . . . . . . . . . 8 63 5. The Enhanced Address Registration Option (EARO) . . . . . . . 8 64 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 12 65 6.1. Legacy 6LoWPAN Node . . . . . . . . . . . . . . . . . . . 12 66 6.2. Legacy 6LoWPAN Router . . . . . . . . . . . . . . . . . . 12 67 6.3. Legacy 6LoWPAN Border Router . . . . . . . . . . . . . . 13 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 70 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 73 10.2. Informative References . . . . . . . . . . . . . . . . . 15 74 10.3. External Informative References . . . . . . . . . . . . 17 75 Appendix A. Requirements . . . . . . . . . . . . . . . . . . . . 18 76 A.1. Requirements Related to Mobility . . . . . . . . . . . . 18 77 A.2. Requirements Related to Routing Protocols . . . . . . . . 18 78 A.3. Requirements Related to the Variety of Low-Power Link 79 types . . . . . . . . . . . . . . . . . . . . . . . . . . 19 80 A.4. Requirements Related to Proxy Operations . . . . . . . . 20 81 A.5. Requirements Related to Security . . . . . . . . . . . . 20 82 A.6. Requirements Related to Scalability . . . . . . . . . . . 22 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 85 1. Introduction 87 IPv6 Neighbor Discovery (ND) Optimization for IPv6 over Low-Power 88 Wireless Personal Area Networks(6LoWPANs) [RFC6775] introduced a 89 proactive registration mechanism to IPv6 ND services that is well 90 suited to nodes belonging to a LLN. 92 The scope of this draft is an IPv6 Low Power Lossy Network (LLN), 93 which can be a simple star or a more complex mesh topology. The LLN 94 may be anchored at an IPv6 Backbone Router (6BBR). The Backbone 95 Routers interconnect the LLNs over a Backbone Link and emulate that 96 the LLN nodes are present on the Backbone using proxy-ND operations. 98 This specification modifies and extends the behaviour and protocol 99 elements of [RFC6775] to enable additional capabilities, in 100 particular the registration to a 6BBR for proxy ND operations 101 [I-D.ietf-6lo-backbone-router]. 103 2. Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 Readers are expected to be familiar with all the terms and concepts 110 that are discussed in "Neighbor Discovery for IP version 6" 111 [RFC4861], "IPv6 Stateless Address Autoconfiguration" [RFC4862], 112 "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): 113 Overview, Assumptions, Problem Statement, and Goals" [RFC4919], 114 Neighbor Discovery Optimization for Low-power and Lossy Networks 115 [RFC6775] and "Multi-link Subnet Support in IPv6" 116 [I-D.ietf-ipv6-multilink-subnets]. 118 Additionally, this document uses terminology from "Terms Used in 119 Routing for Low-Power and Lossy Networks" [RFC7102] and 120 [I-D.ietf-6tisch-terminology], as well as this additional 121 terminology: 123 Backbone This is an IPv6 transit link that interconnects 2 or more 124 Backbone Routers. It is expected to be deployed as a high 125 speed backbone in order to federate a potentially large set of 126 LLNS. Also referred to as a LLN backbone or Backbone network. 128 Backbone Router An IPv6 router that federates the LLN using a 129 Backbone link as a backbone. A 6BBR acts as a 6LoWPAN Border 130 Routers (6LBR) and an Energy Aware Default Router (NEAR). 132 Extended LLN This is the aggregation of multiple LLNs as defined in 133 [RFC4919], interconnected by a Backbone Link via Backbone 134 Routers, and forming a single IPv6 MultiLink Subnet. 136 Registration The process during which a wireless Node registers its 137 address(es) with the Border Router so the 6BBR can proxy ND for 138 it over the backbone. 140 Binding The state in the 6BBR that associates an IP address with a 141 MAC address, a port and some other information about the node 142 that owns the IP address. 144 Registered Node The node for which the registration is performed, 145 which owns the fields in the EARO option. 147 Registering Node The node that performs the registration to the 148 6BBR, either for one of its own addresses, in which case it is 149 Registered Node and indicates its own MAC Address as SLLA in 150 the NS(ARO), or on behalf of a Registered Node that is 151 reachable over a LLN mesh. In the latter case, if the 152 Registered Node is reachable from the 6BBR over a Mesh-Under 153 mesh, the Registering Node indicates the MAC Address of the 154 Registered Node as SLLA in the NS(ARO). Otherwise, it is 155 expected that the Registered Device is reachable over a Route- 156 Over mesh from the Registering Node, in which case the SLLA in 157 the NS(ARO) is that of the Registering Node, which causes it to 158 attract the packets from the 6BBR to the Registered Node and 159 route them over the LLN. 161 Registered Address The address owned by the Registered Node node 162 that is being registered. 164 3. Updating RFC 6775 166 The support of this specification is signaled in Router Advertisement 167 (RA) messages by 6LoWPAN Router (6LR) (how: tbd). Support for this 168 specification can also be inferred from the update of the ARO option 169 in the ND exchanges. 171 A Registering Node that supports this specification will favor 172 registering to a 6LR that indicates support for this specification 173 over that of [RFC6775]. 175 3.1. Transaction ID 177 The specification expects that the Registered Node can provide a 178 sequence number called Transaction ID (TID) that is incremented with 179 each re-registration. The TID essentially obeys the same rules as 180 the Path Sequence field in the Transit Information Option (TIO) found 181 in RPL's Destination Advertisement Object (DAO). This way, the LLN 182 node can use the same counter for ND and RPL, and a 6LBR acting as 183 RPL root may easily maintain the registration on behalf of a RPL node 184 deep inside the mesh by simply using the RPL TIO Path Sequence as TID 185 for EARO. 187 When a Registered Node is registered to multiple BBRs in parallel, it 188 is expected that the same TID is used, to enable the 6BBRs to 189 correlate the registrations as being a single one, and differentiate 190 that situation from a movement. 192 If the TIDs are different, the resolution inherited from RPL sorts 193 out the most recent registration and other ones are removed. The 194 operation for computing and comparing the Path Sequence is detailed 195 in section 7 of [RFC6550] and applies to the TID in the exact same 196 fashion. 198 3.2. Owner Unique ID 200 The Owner Unique ID (OUID) enables to differentiate a real duplicate 201 address registration from a double registration or a movement. An ND 202 message from the 6BBR over the backbone that is proxied on behalf of 203 a Registered Node must carry the most recent EARO option seen for 204 that node. A NS/NA with an EARO and a NS/NA without a EARO thus 205 represent different nodes and if they relate to a same target then 206 they reflect an address duplication. The Owner Unique ID can be as 207 simple as a EUI-64 burn-in address, if duplicate EUI-64 addresses are 208 avoided. 210 Alternatively, the unique ID can be a cryptographic string that can 211 can be used to prove the ownership of the registration as discussed 212 in Address Protected Neighbor Discovery for Low-power and Lossy 213 Networks [I-D.ietf-6lo-ap-nd]. 215 In any fashion, it is recommended that the node stores the unique Id 216 or the keys used to generate that ID in persistent memory. 217 Otherwise, it will be prevented to re-register after a reboot that 218 would cause a loss of memory until the Backbone Router times out the 219 registration. 221 3.3. Extended Address Registration Option 223 This specification extends the Address Registration Option (ARO) used 224 for the process of address registration. The new ARO is referred to 225 as Extended ARO (EARO), and its semantics are modified as follows: 227 The address that is being registered with a Neighbor Solicitation 228 (NS) with an EARO is now the Target Address, as opposed to the Source 229 Address as specified in [RFC6775]. This change enables a 6LBR to use 230 an address of his as source to the proxy-registration of an address 231 that belongs to a LLN Node to a 6BBR. This also limits the use of an 232 address as source address before it is registered and the associated 233 Duplicate Address Detection (DAD) is complete. 235 The Unique ID in the EARO option does no more have to be a MAC 236 address. A new TLV format is introduced and a IANA registry is 237 created for the type (TBD). This enables in particular the use of a 238 Provable Temporary UID (PT-UID) as opposed to burn-in MAC address, 239 the PT-UID providing a trusted anchor by the 6LR and 6LBR to protect 240 the state associated to the node. 242 The specification introduces a Transaction ID (TID) field in the 243 EARO. The TID MUST be provided by a node that supports this 244 specification and a new T flag MUST be set to indicate so. The T bit 245 can be used to determine whether the peer supports this 246 specification. 248 3.4. Registering the Target Address 250 One of the requirements that this specification serves is the 251 capability by a router such as a RPL root to proxy-register an 252 address to a 6BBR on behalf of a 6LN, as discussed in Appendix A.4. 253 In order to serve that requirement, this specification changes the 254 behaviour of the 6LN and the 6LR so that the Registered Address is 255 found in the Target Address field of the NS and NA messages as 256 opposed to the Source Address. 258 With this convention, a TLLA option would indicate the link-layer 259 address of the 6LN that owns the address, whereas the SLLA Option in 260 a NS message indicates that of the Registering Node, which can be the 261 owner device, or a proxy. 263 Since the Registering Node is the one that has reachability with the 264 6LR, and is the one expecting packets for the 6LN, it makes sense to 265 maintain compatibility with [RFC6775], and it is REQUIRED that an 266 SLLA Option is always placed in a registration NS(EARO) message. 268 3.5. Link-local Addresses and Registration 270 Considering that LLN nodes are often not wired and may move, there is 271 no guarantee that a link-local address stays unique between a 272 potentially variable and unbounded set of neighboring nodes. 273 Compared to [RFC6775], this specification only requires that a link- 274 local address is unique from the perspective of the peering nodes. 275 This simplifies the Duplicate Address Detection (DAD) for link-local 276 addresses, and there is no DAR/DAC exchange between the 6LR and a 277 6LBR for link-local addresses. 279 Additionally, [RFC6775] requires that a 6LoWPAN Node (6LN) uses an 280 address being registered as the source of the registration message. 281 This generates complexities in the 6LR to be able to cope with a 282 potential duplication, in particular for global addresses. To 283 simplify this, a 6LN and a 6LR that conform this specification always 284 use link-local addresses as source and destination addresses for the 285 registration NS/NA exchange. As a result, the registration is 286 globally faster, and some of the complexity is removed. 288 In more details: 290 An exchange between two nodes using link-local addresses implies that 291 they are reachable over one hop and that at least one of the 2 nodes 292 acts as a 6LR. A node MUST register a link-local address to a 6LR in 293 order to obtain reachability from that 6LR beyond the current 294 exchange, and in particular to use the link-local address as source 295 address to register other addresses, e.g. global addresses. If there 296 is no collision with an address previously registered to this 6LR by 297 another 6LN, then, from the standpoint of this 6LR, this link-local 298 address is unique and the registration is acceptable. Conversely, it 299 may possibly happen that two different 6LRs expose a same link-local 300 address but different link-layer addresses. In that case, a 6LN may 301 only interact with one of the 6LR so as to avoid confusion in the 6LN 302 neighbor cache. 304 The DAD process between the 6LR and a 6LoWPAN Border Router (6LBR), 305 which is based on a Duplicate Address Request (DAR) / Duplicate 306 Address Confirmation (DAC) exchange as described in [RFC6775], does 307 not need to take place for link-local addresses. 309 It is desired that a 6LR does not need to modify its state associated 310 to the Source Address of an NS(EARO) message. For that reason, when 311 possible, it is RECOMMENDED to use an address that is already 312 registered with a 6LR 314 When registering to a 6LR that conforms this specification, a node 315 MUST use a link-local address as the source address of the 316 registration, whatever the type of IPv6 address that is being 317 registered. That link-local Address MUST be either already 318 registrered, or the address that is being registered. 320 When a Registering Node does not have an already-registered address, 321 it MUST register a link-local address, using it as both the Source 322 and the Target Address of an NS(EARO) message. In that case, it is 323 RECOMMENDED to use a link-local address that is (expected to be) 324 globally unique, e.g. derived from a burn-in MAC address. An EARO 325 option in the response NA indicates that the 6LR supports this 326 specification. 328 Since there is no DAR/DAC exchange for link-local addresses, the 6LR 329 may answer immediately to the registration of a link-local address, 330 based solely on its existing state and the Source Link-Layer Option 331 that MUST be placed in the NS(EARO) message as required in [RFC6775]. 333 A node needs to register its IPv6 Global Unicast IPv6 Addresses (GUA) 334 to a 6LR in order to obtain a global reachability for these addresses 335 via that 6LR. As opposed to a node that complies to [RFC6775], a 336 Registering Node registering a GUA does not use that GUA as Source 337 Address for the registration to a 6LR that conforms this 338 specification. The DAR/DAC exchange MUST take place for non-link- 339 local addresses as prescribed by [RFC6775]. 341 4. Applicability and Requirements Served 343 This specification extends 6LoWPAN ND to sequence the registration 344 and serves the requirements expressed Appendix A.1 by enabling the 345 mobility of devices from one LLN to the next based on the 346 complementary work in [I-D.ietf-6lo-backbone-router]. 348 In the context of the the TimeSlotted Channel Hopping (TSCH) mode of 349 [IEEEstd802154], the 6TiSCH architecture 350 [I-D.ietf-6tisch-architecture] introduces how a 6LoWPAN ND host could 351 connect to the Internet via a RPL mesh Network, but this requires 352 additions to the 6LOWPAN ND protocol to support mobility and 353 reachability in a secured and manageable environment. This 354 specification details the new operations that are required to 355 implement the 6TiSCH architecture and serves the requirements listed 356 in Appendix A.2. 358 The term LLN is used loosely in this specification to cover multiple 359 types of WLANs and WPANs, including Low-Power Wi-Fi, BLUETOOTH(R) Low 360 Energy, IEEE std 802.11AH and IEEE std 802.15.4 wireless meshes, so 361 as to address the requirements discussed in Appendix A.3 363 This specification can be used by any wireless node to associate at 364 Layer-3 with a 6BBR and register its IPv6 addresses to obtain routing 365 services including proxy-ND operations over the backbone, effectively 366 providing a solution to the requirements expressed in Appendix A.4. 368 Efficiency aware IPv6 Neighbor Discovery Optimizations 369 [I-D.chakrabarti-nordmark-6man-efficient-nd] suggests that 6LoWPAN ND 370 [RFC6775] can be extended to other types of links beyond IEEE std 371 802.15.4 for which it was defined. The registration technique is 372 beneficial when the Link-Layer technique used to carry IPv6 multicast 373 packets is not sufficiently efficient in terms of delivery ratio or 374 energy consumption in the end devices, in particular to enable 375 energy-constrained sleeping nodes. The value of such extension is 376 especially apparent in the case of mobile wireless nodes, to reduce 377 the multicast operations that are related to classical ND ([RFC4861], 378 [RFC4862]) and plague the wireless medium. This serves scalability 379 requirements listed in Appendix A.6. 381 5. The Enhanced Address Registration Option (EARO) 383 With the ARO option defined in 6LoWPAN ND [RFC6775], the address 384 being registered and its owner can be uniquely identified and matched 385 with the Binding Table entries of each Backbone Router. 387 The Enhanced Address Registration Option (EARO) is intended to be 388 used as a replacement to the ARO option within Neighbor Discovery NS 389 and NA messages between a LLN node and its 6LoWPAN Router (6LR), as 390 well as in Duplicate Address Request (DAR) and the Duplicate Address 391 Confirmation (DAC) messages between 6LRs and 6LBRs in LLNs meshes 392 such as 6TiSCH networks. 394 An NS message with an EARO option is a registration if and only if it 395 also carries an SLLAO option. The AERO option also used in NS and NA 396 messages between Backbone Routers over the backbone link to sort out 397 the distributed registration state, and in that case, it does not 398 carry the SLLAO option and is not confused with a registration. 400 The EARO extends the ARO and is recognized by the setting of the TID 401 bit. A node that supports this specification MUST always use an EARO 402 as a replacement to an ARO in its registration to a router. This is 403 harmless since the TID bit and fields are reserved in [RFC6775] are 404 ignored by a legacy router. A router that supports this 405 specification answers to an ARO with an ARO and to an EARO with an 406 EARO. 408 This specification changes the behavior of the peers in a 409 registration flows. To enable backward compatibility, a node that 410 registers to a router that is not known to support this specification 411 MUST behave as prescribed by [RFC6775]. Once the router is known to 412 support this specification, the node MUST obey this specification. 414 When using the EARO option, the address being registered is found in 415 the Target Address field of the NS and NA messages. This differs 416 from 6LoWPAN ND [RFC6775] which specifies that the address being 417 registered is the source of the NS. 419 The reason for this change is to enable proxy-registrations on behalf 420 of other nodes in Route-Over meshes, for instance to enable that a 421 RPL root registers addresses on behalf LLN nodes that are deeper in a 422 6TiSCH mesh. In that case, the Registering Node MUST indicate its 423 own address as source of the ND message and its MAC address in the 424 Source Link-Layer Address Option (SLLAO), since it still expects to 425 get the packets and route them down the mesh. But the Registered 426 Address belongs to another node, the Registered Node, and that 427 address is indicated in the Target Address field of the NS message. 429 One way of achieving all the above is for a node to first register an 430 address that it owns in order to validate that the router supports 431 this specification, placing the same address in the Source and Target 432 Address fields of the NS message. The node may for instance register 433 an address that is based on EUI-64. For such address, DAD is not 434 required and using the SLLAO option in the NS is actually more 435 amenable with older ND specifications such as ODAD [RFC4429]. 437 Once that first registration is complete, the node knows from the 438 setting of the TID in the response whether the router supports this 439 specification. If this is verified, the node may register other 440 addresses that it owns, or proxy-register addresses on behalf some 441 another node, indicating those addresses being registered in the 442 Target Address field of the NS messages, while using one of its own, 443 already registered, addresses as source. 445 The format of the EARO option is as follows: 447 0 1 2 3 448 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 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Type | Length = 2 | Status | Reserved | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Reserved |T| TID | Registration Lifetime | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | | 455 + Owner Unique ID (EUI-64 or equivalent) + 456 | | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 Figure 1: EARO 461 Option Fields 463 Type: 465 Length: 2 467 Status: 469 +-------+-----------------------------------------------------------+ 470 | Value | Description | 471 +-------+-----------------------------------------------------------+ 472 | 0..2 | See [RFC6775]. Note that a Status of 1 "Duplicate | 473 | | Address" applies to the Registered Address. If the Source | 474 | | Address conflicts with an existing registration, | 475 | | "Duplicate Source Address" should be used instead | 476 | | | 477 | 3 | Moved: The registration fails because it is not the | 478 | | freshest | 479 | | | 480 | 4 | Removed: The binding state was removed. This may be | 481 | | placed in an asynchronous NS(ARO) message, or as the | 482 | | rejection of a proxy registration to a Backbone Router | 483 | | | 484 | 5 | Proof requested: The registering node is challenged for | 485 | | owning the registered address or for being an acceptable | 486 | | proxy for the registration | 487 | | | 488 | 6 | Duplicate Source Address: The address used as source of | 489 | | the NS(ARO) conflicts with an existing registration. | 490 | | | 491 | 7 | Administrative Rejection: The address being registered is | 492 | | reserved for another use by an administrative decision | 493 | | (e.g. placed in a DHCPv6 pool); The Registering Node is | 494 | | requested to form a different address and retry | 495 | | | 496 | 8 | Invalid Registered Address: The address being registered | 497 | | is not usable on this link, e.g. it is not topologically | 498 | | correct | 499 | | | 500 | 9 | Invalid Source Address: The address used as source of the | 501 | | NS(ARO) is not usable on this link, e.g. it is not | 502 | | topologically correct | 503 +-------+-----------------------------------------------------------+ 505 Table 1 507 Reserved: This field is unused. It MUST be initialized to zero by 508 the sender and MUST be ignored by the receiver. 510 T: One bit flag. Set if the next octet is a used as a TID. 512 TID: 1-byte integer; a transaction id that is maintained by the node 513 and incremented with each transaction. it is recommended that the 514 node maintains the TID in a persistent storage. 516 Registration Lifetime: 16-bit integer; expressed in minutes. 0 517 means that the registration has ended and the state should be 518 removed. 520 Owner Unique Identifier (OUI): A globally unique identifier for the 521 node associated. This can be the EUI-64 derived IID of an 522 interface, or some provable ID obtained cryptographically. 524 New status values are introduced, their values to be confirmed by 525 IANA: 527 Moved: This status indicates that the registration is rejected 528 because another more recent registration was done, as indicated by 529 a same OUI and a more recent TID. One possible cause is a stale 530 registration that has progressed slowly in the network and was 531 passed by a more recent one. It could also indicate a OUI 532 collision. 534 Removed: This status is expected in asynchronous messages from a 535 registrar (6LR, 6LBR, 6BBR) to indicate that the registration 536 state is removed, for instance due to time out of a lifetime, or a 537 movement. It is used for instance by a 6BBR in a NA(ARO) message 538 to indicate that the ownership of the proxy state on the backbone 539 was transfered to another 6BBR, which is indicative of a movement 540 of the device. The receiver of the NA is the device that has 541 performed a registration that is now stale and it should clean up 542 its state. 544 6. Backward Compatibility 546 6.1. Legacy 6LoWPAN Node 548 A legacy 6LN will use the registered address as source and will not 549 use an EARO option. In order to be backward compatible, an updated 550 6LR needs to accept that registration if it is valid per [RFC3972], 551 and manage the binding cache accordingly. 553 The main difference with [RFC3972] is that DAR/DAC exchange for DAD 554 may be avoided for link-local addresses. Additionally, the 6LR 555 SHOULD use an EARO in the reply, and may use all the status codes 556 defined in this specification. 558 6.2. Legacy 6LoWPAN Router 560 The first registration by a an updated 6LN is for a link-local 561 address, using that link-local address as source. A legacy 6LN will 562 not makes a difference and accept -or reject- that registration as if 563 the 6LN was a legacy node. 565 An updated 6LN will always use an EARO option in the registration NS 566 message, whereas a legacy 6LN will always areply with an ARO option 567 in the NA message. So from that first registration, the updated 6LN 568 can figure whether the 6LR supports this specification or not. 570 When facing a legacy 6LR, an updated 6LN may attempt to find an 571 alternate 6LR that is updated. In order to be backward compatible, 572 based on the discovery that a 6LR is legacy, the 6LN needs to 573 fallback to legacy behaviour and source the packet with the 574 registrered address. 576 The main difference is that the updated 6LN SHOULD use an EARO in the 577 request regardless of the type of 6LN, legacy or updated 579 6.3. Legacy 6LoWPAN Border Router 581 With this specification, the DAR/DAC transports an EARO option as 582 opposed to an ARO option. As described for the NS/NA exchange, 583 devices that support this specification always use an EARO option and 584 all the associated behaviour. 586 7. Security Considerations 588 This specification expects that the link layer is sufficiently 589 protected, either by means of physical or IP security for the 590 Backbone Link or MAC sublayer cryptography. In particular, it is 591 expected that the LLN MAC provides secure unicast to/from the 592 Backbone Router and secure Broadcast from the Backbone Router in a 593 way that prevents tempering with or replaying the RA messages. 595 The use of EUI-64 for forming the Interface ID in the link-local 596 address prevents the usage of Secure ND ([RFC3971] and [RFC3972]) and 597 address privacy techniques. This specification RECOMMENDS the use of 598 additional protection against address theft such as provided by 599 [I-D.ietf-6lo-ap-nd], which guarantees the ownership of the OUID. 601 When the ownership of the OUID cannot be assessed, this specification 602 limits the cases where the OUID and the TID are multicasted, and 603 obfuscates them in responses to attempts to take over an address. 605 The LLN nodes depend on the 6LBR and the 6BBR for their operation. A 606 trust model must be put in place to ensure that the right devices are 607 acting in these roles, so as to avoid threats such as black-holing, 608 or bombing attack whereby an impersonated 6LBR would destroy state in 609 the network by using the "Removed" status code. 611 8. IANA Considerations 613 This document requires the following additions: 615 Address Registration Option Status Values Registry 617 +--------+--------------------------+ 618 | Status | Description | 619 +--------+--------------------------+ 620 | 3 | Moved | 621 | | | 622 | 4 | Removed | 623 | | | 624 | 5 | Proof requested | 625 | | | 626 | 6 | Invalid Source Address | 627 | | | 628 | 7 | Administrative Rejection | 629 +--------+--------------------------+ 631 IANA is required to change the registry accordingly 633 Table 2: New ARO Status values 635 9. Acknowledgments 637 Kudos to Eric Levy-Abegnoli who designed the First Hop Security 638 infrastructure at Cisco. 640 10. References 642 10.1. Normative References 644 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 645 Requirement Levels", BCP 14, RFC 2119, 646 DOI 10.17487/RFC2119, March 1997, 647 . 649 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 650 for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, 651 . 653 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 654 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 655 DOI 10.17487/RFC4861, September 2007, 656 . 658 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 659 Address Autoconfiguration", RFC 4862, 660 DOI 10.17487/RFC4862, September 2007, 661 . 663 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 664 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 665 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 666 Low-Power and Lossy Networks", RFC 6550, 667 DOI 10.17487/RFC6550, March 2012, 668 . 670 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 671 Bormann, "Neighbor Discovery Optimization for IPv6 over 672 Low-Power Wireless Personal Area Networks (6LoWPANs)", 673 RFC 6775, DOI 10.17487/RFC6775, November 2012, 674 . 676 10.2. Informative References 678 [I-D.chakrabarti-nordmark-6man-efficient-nd] 679 Chakrabarti, S., Nordmark, E., Thubert, P., and M. 680 Wasserman, "IPv6 Neighbor Discovery Optimizations for 681 Wired and Wireless Networks", draft-chakrabarti-nordmark- 682 6man-efficient-nd-07 (work in progress), February 2015. 684 [I-D.delcarpio-6lo-wlanah] 685 Vega, L., Robles, I., and R. Morabito, "IPv6 over 686 802.11ah", draft-delcarpio-6lo-wlanah-01 (work in 687 progress), October 2015. 689 [I-D.ietf-6lo-6lobac] 690 Lynn, K., Martocci, J., Neilson, C., and S. Donaldson, 691 "Transmission of IPv6 over MS/TP Networks", draft-ietf- 692 6lo-6lobac-06 (work in progress), October 2016. 694 [I-D.ietf-6lo-ap-nd] 695 Sarikaya, B., Thubert, P., and M. Sethi, "Address 696 Protected Neighbor Discovery for Low-power and Lossy 697 Networks", draft-ietf-6lo-ap-nd-00 (work in progress), 698 November 2016. 700 [I-D.ietf-6lo-backbone-router] 701 Thubert, P., "IPv6 Backbone Router", draft-ietf-6lo- 702 backbone-router-02 (work in progress), September 2016. 704 [I-D.ietf-6lo-dect-ule] 705 Mariager, P., Petersen, J., Shelby, Z., Logt, M., and D. 706 Barthel, "Transmission of IPv6 Packets over DECT Ultra Low 707 Energy", draft-ietf-6lo-dect-ule-09 (work in progress), 708 December 2016. 710 [I-D.ietf-6lo-nfc] 711 Choi, Y., Youn, J., and Y. Hong, "Transmission of IPv6 712 Packets over Near Field Communication", draft-ietf-6lo- 713 nfc-05 (work in progress), October 2016. 715 [I-D.ietf-6tisch-architecture] 716 Thubert, P., "An Architecture for IPv6 over the TSCH mode 717 of IEEE 802.15.4", draft-ietf-6tisch-architecture-10 (work 718 in progress), June 2016. 720 [I-D.ietf-6tisch-terminology] 721 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 722 "Terminology in IPv6 over the TSCH mode of IEEE 723 802.15.4e", draft-ietf-6tisch-terminology-08 (work in 724 progress), December 2016. 726 [I-D.ietf-bier-architecture] 727 Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and 728 S. Aldrin, "Multicast using Bit Index Explicit 729 Replication", draft-ietf-bier-architecture-05 (work in 730 progress), October 2016. 732 [I-D.ietf-ipv6-multilink-subnets] 733 Thaler, D. and C. Huitema, "Multi-link Subnet Support in 734 IPv6", draft-ietf-ipv6-multilink-subnets-00 (work in 735 progress), July 2002. 737 [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks] 738 Popa, D. and J. Hui, "6LoPLC: Transmission of IPv6 Packets 739 over IEEE 1901.2 Narrowband Powerline Communication 740 Networks", draft-popa-6lo-6loplc-ipv6-over- 741 ieee19012-networks-00 (work in progress), March 2014. 743 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 744 CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September 745 2003, . 747 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 748 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 749 DOI 10.17487/RFC3810, June 2004, 750 . 752 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 753 "SEcure Neighbor Discovery (SEND)", RFC 3971, 754 DOI 10.17487/RFC3971, March 2005, 755 . 757 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 758 RFC 3972, DOI 10.17487/RFC3972, March 2005, 759 . 761 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 762 over Low-Power Wireless Personal Area Networks (6LoWPANs): 763 Overview, Assumptions, Problem Statement, and Goals", 764 RFC 4919, DOI 10.17487/RFC4919, August 2007, 765 . 767 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 768 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 769 DOI 10.17487/RFC6282, September 2011, 770 . 772 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 773 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 774 2014, . 776 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 777 Interface Identifiers with IPv6 Stateless Address 778 Autoconfiguration (SLAAC)", RFC 7217, 779 DOI 10.17487/RFC7217, April 2014, 780 . 782 [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets 783 over ITU-T G.9959 Networks", RFC 7428, 784 DOI 10.17487/RFC7428, February 2015, 785 . 787 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 788 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 789 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 790 . 792 10.3. External Informative References 794 [IEEEstd802154] 795 IEEE standard for Information Technology, "IEEE Standard 796 for Local and metropolitan area networks-- Part 15.4: Low- 797 Rate Wireless Personal Area Networks (LR-WPANs)". 799 Appendix A. Requirements 801 This section lists requirements that were discussed at 6lo for an 802 update to 6LoWPAN ND. This specification meets most of them, but 803 those listed in Appendix A.5 which are deferred to a different 804 specification such as [I-D.ietf-6lo-ap-nd]. 806 A.1. Requirements Related to Mobility 808 Due to the unstable nature of LLN links, even in a LLN of immobile 809 nodes a 6LN may change its point of attachment to a 6LR, say 6LR-a, 810 and may not be able to notify 6LR-a. Consequently, 6LR-a may still 811 attract traffic that it cannot deliver any more. When links to a 6LR 812 change state, there is thus a need to identify stale states in a 6LR 813 and restore reachability in a timely fashion. 815 Req1.1: Upon a change of point of attachment, connectivity via a new 816 6LR MUST be restored timely without the need to de-register from the 817 previous 6LR. 819 Req1.2: For that purpose, the protocol MUST enable to differentiate 820 between multiple registrations from one 6LoWPAN Node and 821 registrations from different 6LoWPAN Nodes claiming the same address. 823 Req1.3: Stale states MUST be cleaned up in 6LRs. 825 Req1.4: A 6LoWPAN Node SHOULD also be capable to register its Address 826 to multiple 6LRs, and this, concurrently. 828 A.2. Requirements Related to Routing Protocols 830 The point of attachment of a 6LN may be a 6LR in an LLN mesh. IPv6 831 routing in a LLN can be based on RPL, which is the routing protocol 832 that was defined at the IETF for this particular purpose. Other 833 routing protocols than RPL are also considered by Standard Defining 834 Organizations (SDO) on the basis of the expected network 835 characteristics. It is required that a 6LoWPAN Node attached via ND 836 to a 6LR would need to participate in the selected routing protocol 837 to obtain reachability via the 6LR. 839 Next to the 6LBR unicast address registered by ND, other addresses 840 including multicast addresses are needed as well. For example a 841 routing protocol often uses a multicast address to register changes 842 to established paths. ND needs to register such a multicast address 843 to enable routing concurrently with discovery. 845 Multicast is needed for groups. Groups MAY be formed by device type 846 (e.g. routers, street lamps), location (Geography, RPL sub-tree), or 847 both. 849 The Bit Index Explicit Replication (BIER) Architecture 850 [I-D.ietf-bier-architecture] proposes an optimized technique to 851 enable multicast in a LLN with a very limited requirement for routing 852 state in the nodes. 854 Related requirements are: 856 Req2.1: The ND registration method SHOULD be extended in such a 857 fashion that the 6LR MAY advertise the Address of a 6LoWPAN Node over 858 the selected routing protocol and obtain reachability to that Address 859 using the selected routing protocol. 861 Req2.2: Considering RPL, the Address Registration Option that is used 862 in the ND registration SHOULD be extended to carry enough information 863 to generate a DAO message as specified in [RFC6550] section 6.4, in 864 particular the capability to compute a Path Sequence and, as an 865 option, a RPLInstanceID. 867 Req2.3: Multicast operations SHOULD be supported and optimized, for 868 instance using BIER or MPL. Whether ND is appropriate for the 869 registration to the 6BBR is to be defined, considering the additional 870 burden of supporting the Multicast Listener Discovery Version 2 871 [RFC3810] (MLDv2) for IPv6. 873 A.3. Requirements Related to the Variety of Low-Power Link types 875 6LoWPAN ND [RFC6775] was defined with a focus on IEEE std 802.15.4 876 and in particular the capability to derive a unique Identifier from a 877 globally unique MAC-64 address. At this point, the 6lo Working Group 878 is extending the 6LoWPAN Header Compression (HC) [RFC6282] technique 879 to other link types ITU-T G.9959 [RFC7428], Master-Slave/Token- 880 Passing [I-D.ietf-6lo-6lobac], DECT Ultra Low Energy 881 [I-D.ietf-6lo-dect-ule], Near Field Communication [I-D.ietf-6lo-nfc], 882 IEEE std 802.11ah [I-D.delcarpio-6lo-wlanah], as well as IEEE1901.2 883 Narrowband Powerline Communication Networks 884 [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks] and BLUETOOTH(R) 885 Low Energy [RFC7668]. 887 Related requirements are: 889 Req3.1: The support of the registration mechanism SHOULD be extended 890 to more LLN links than IEEE std 802.15.4, matching at least the LLN 891 links for which an "IPv6 over foo" specification exists, as well as 892 Low-Power Wi-Fi. 894 Req3.2: As part of this extension, a mechanism to compute a unique 895 Identifier should be provided, with the capability to form a Link- 896 Local Address that SHOULD be unique at least within the LLN connected 897 to a 6LBR discovered by ND in each node within the LLN. 899 Req3.3: The Address Registration Option used in the ND registration 900 SHOULD be extended to carry the relevant forms of unique Identifier. 902 Req3.4: The Neighbour Discovery should specify the formation of a 903 site-local address that follows the security recommendations from 904 [RFC7217]. 906 A.4. Requirements Related to Proxy Operations 908 Duty-cycled devices may not be able to answer themselves to a lookup 909 from a node that uses classical ND on a backbone and may need a 910 proxy. Additionally, the duty-cycled device may need to rely on the 911 6LBR to perform registration to the 6BBR. 913 The ND registration method SHOULD defend the addresses of duty-cycled 914 devices that are sleeping most of the time and not capable to defend 915 their own Addresses. 917 Related requirements are: 919 Req4.1: The registration mechanism SHOULD enable a third party to 920 proxy register an Address on behalf of a 6LoWPAN node that may be 921 sleeping or located deeper in an LLN mesh. 923 Req4.2: The registration mechanism SHOULD be applicable to a duty- 924 cycled device regardless of the link type, and enable a 6BBR to 925 operate as a proxy to defend the registered Addresses on its behalf. 927 Req4.3: The registration mechanism SHOULD enable long sleep 928 durations, in the order of multiple days to a month. 930 A.5. Requirements Related to Security 932 In order to guarantee the operations of the 6LoWPAN ND flows, the 933 spoofing of the 6LR, 6LBR and 6BBRs roles should be avoided. Once a 934 node successfully registers an address, 6LoWPAN ND should provide 935 energy-efficient means for the 6LBR to protect that ownership even 936 when the node that registered the address is sleeping. 938 In particular, the 6LR and the 6LBR then should be able to verify 939 whether a subsequent registration for a given Address comes from the 940 original node. 942 In a LLN it makes sense to base security on layer-2 security. During 943 bootstrap of the LLN, nodes join the network after authorization by a 944 Joining Assistant (JA) or a Commissioning Tool (CT). After joining 945 nodes communicate with each other via secured links. The keys for 946 the layer-2 security are distributed by the JA/CT. The JA/CT can be 947 part of the LLN or be outside the LLN. In both cases it is needed 948 that packets are routed between JA/CT and the joining node. 950 Related requirements are: 952 Req5.1: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for 953 the 6LR, 6LBR and 6BBR to authenticate and authorize one another for 954 their respective roles, as well as with the 6LoWPAN Node for the role 955 of 6LR. 957 Req5.2: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for 958 the 6LR and the 6LBR to validate new registration of authorized 959 nodes. Joining of unauthorized nodes MUST be impossible. 961 Req5.3: 6LoWPAN ND security mechanisms SHOULD lead to small packet 962 sizes. In particular, the NS, NA, DAR and DAC messages for a re- 963 registration flow SHOULD NOT exceed 80 octets so as to fit in a 964 secured IEEE std 802.15.4 [IEEEstd802154] frame. 966 Req5.4: Recurrent 6LoWPAN ND security operations MUST NOT be 967 computationally intensive on the LoWPAN Node CPU. When a Key hash 968 calculation is employed, a mechanism lighter than SHA-1 SHOULD be 969 preferred. 971 Req5.5: The number of Keys that the 6LoWPAN Node needs to manipulate 972 SHOULD be minimized. 974 Req5.6: The 6LoWPAN ND security mechanisms SHOULD enable the 975 variation of CCM [RFC3610] called CCM* for use at both Layer 2 and 976 Layer 3, and SHOULD enable the reuse of security code that has to be 977 present on the device for upper layer security such as TLS. 979 Req5.7: Public key and signature sizes SHOULD be minimized while 980 maintaining adequate confidentiality and data origin authentication 981 for multiple types of applications with various degrees of 982 criticality. 984 Req5.8: Routing of packets should continue when links pass from the 985 unsecured to the secured state. 987 Req5.9: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for 988 the 6LR and the 6LBR to validate whether a new registration for a 989 given address corresponds to the same 6LoWPAN Node that registered it 990 initially, and, if not, determine the rightful owner, and deny or 991 clean-up the registration that is duplicate. 993 A.6. Requirements Related to Scalability 995 Use cases from Automatic Meter Reading (AMR, collection tree 996 operations) and Advanced Metering Infrastructure (AMI, bi-directional 997 communication to the meters) indicate the needs for a large number of 998 LLN nodes pertaining to a single RPL DODAG (e.g. 5000) and connected 999 to the 6LBR over a large number of LLN hops (e.g. 15). 1001 Related requirements are: 1003 Req6.1: The registration mechanism SHOULD enable a single 6LBR to 1004 register multiple thousands of devices. 1006 Req6.2: The timing of the registration operation should allow for a 1007 large latency such as found in LLNs with ten and more hops. 1009 Authors' Addresses 1011 Pascal Thubert (editor) 1012 Cisco Systems, Inc 1013 Building D 1014 45 Allee des Ormes - BP1200 1015 MOUGINS - Sophia Antipolis 06254 1016 FRANCE 1018 Phone: +33 497 23 26 34 1019 Email: pthubert@cisco.com 1021 Erik Nordmark 1022 Arista Networks 1023 Santa Clara, CA 1024 USA 1026 Email: nordmark@arista.com 1028 Samita Chakrabarti 1029 San Jose, CA 1030 USA 1032 Email: samitac.ietf@gmail.com