idnits 2.17.1 draft-ietf-6lo-rfc6775-update-19.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 23, 2018) is 2195 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: 'RFC7102' is mentioned on line 1476, but not defined == Missing Reference: 'RFC7228' is mentioned on line 1480, but not defined == Missing Reference: 'RFC6606' is mentioned on line 1470, but not defined == Missing Reference: 'RFC4919' is mentioned on line 1464, but not defined == Missing Reference: 'Perlman83' is mentioned on line 1647, but not defined == Missing Reference: 'IEEEstd802154' is mentioned on line 1871, but not defined == Outdated reference: A later version (-05) exists of draft-hou-6lo-plc-03 == Outdated reference: A later version (-23) exists of draft-ietf-6lo-ap-nd-06 == Outdated reference: A later version (-20) exists of draft-ietf-6lo-backbone-router-06 == Outdated reference: A later version (-22) exists of draft-ietf-6lo-nfc-09 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-13 == Outdated reference: A later version (-15) exists of draft-ietf-mboned-ieee802-mcast-problems-01 == Outdated reference: A later version (-18) exists of draft-ietf-roll-efficient-npdao-03 == Outdated reference: A later version (-07) exists of draft-thubert-roll-unaware-leaves-04 -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 0 errors (**), 0 flaws (~~), 15 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6lo P. Thubert, Ed. 3 Internet-Draft Cisco 4 Updates: 6775 (if approved) E. Nordmark 5 Intended status: Standards Track Zededa 6 Expires: October 25, 2018 S. Chakrabarti 7 Verizon 8 C. Perkins 9 Futurewei 10 April 23, 2018 12 Registration Extensions for 6LoWPAN Neighbor Discovery 13 draft-ietf-6lo-rfc6775-update-19 15 Abstract 17 This specification updates RFC 6775 - 6LoWPAN Neighbor Discovery, to 18 clarify the role of the protocol as a registration technique, 19 simplify the registration operation in 6LoWPAN routers, as well as to 20 provide enhancements to the registration capabilities and mobility 21 detection for different network topologies including the backbone 22 routers performing proxy Neighbor Discovery in a low power network. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on October 25, 2018. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.2. References . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.3. New Terms . . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.4. Subset of a 6LoWPAN Glossary . . . . . . . . . . . . . . 6 64 3. Applicability of Address Registration Options . . . . . . . . 7 65 4. Extended ND Options and Messages . . . . . . . . . . . . . . 8 66 4.1. Extended Address Registration Option (EARO) . . . . . . . 8 67 4.2. Extended Duplicate Address Message Formats . . . . . . . 12 68 4.3. New 6LoWPAN Capability Bits in the Capability Indication 69 Option . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 5. Updating RFC 6775 . . . . . . . . . . . . . . . . . . . . . . 14 71 5.1. Extending the Address Registration Option . . . . . . . . 15 72 5.2. Transaction ID . . . . . . . . . . . . . . . . . . . . . 16 73 5.2.1. Comparing TID values . . . . . . . . . . . . . . . . 16 74 5.3. Registration Ownership Verifier . . . . . . . . . . . . . 18 75 5.4. Extended Duplicate Address Messages . . . . . . . . . . . 19 76 5.5. Registering the Target Address . . . . . . . . . . . . . 19 77 5.6. Link-Local Addresses and Registration . . . . . . . . . . 20 78 5.7. Maintaining the Registration States . . . . . . . . . . . 22 79 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 23 80 6.1. Signaling EARO Capability Support . . . . . . . . . . . . 24 81 6.2. RFC6775-only 6LoWPAN Node . . . . . . . . . . . . . . . . 24 82 6.3. RFC6775-only 6LoWPAN Router . . . . . . . . . . . . . . . 25 83 6.4. RFC6775-only 6LoWPAN Border Router . . . . . . . . . . . 25 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 85 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27 86 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 87 9.1. ARO Flags . . . . . . . . . . . . . . . . . . . . . . . . 28 88 9.2. ICMP Codes . . . . . . . . . . . . . . . . . . . . . . . 28 89 9.3. New ARO Status values . . . . . . . . . . . . . . . . . . 29 90 9.4. New 6LoWPAN capability Bits . . . . . . . . . . . . . . . 30 91 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 92 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 93 11.1. Normative References . . . . . . . . . . . . . . . . . . 31 94 11.2. Terminology Related References . . . . . . . . . . . . . 32 95 11.3. Informative References . . . . . . . . . . . . . . . . . 32 96 11.4. External Informative References . . . . . . . . . . . . 36 98 Appendix A. Applicability and Requirements Served (Not 99 Normative) . . . . . . . . . . . . . . . . . . . . . 36 100 Appendix B. Requirements (Not Normative) . . . . . . . . . . . . 37 101 B.1. Requirements Related to Mobility . . . . . . . . . . . . 37 102 B.2. Requirements Related to Routing Protocols . . . . . . . . 38 103 B.3. Requirements Related to the Variety of Low-Power Link 104 types . . . . . . . . . . . . . . . . . . . . . . . . . . 39 105 B.4. Requirements Related to Proxy Operations . . . . . . . . 39 106 B.5. Requirements Related to Security . . . . . . . . . . . . 40 107 B.6. Requirements Related to Scalability . . . . . . . . . . . 41 108 B.7. Requirements Related to Operations and Management . . . . 42 109 B.8. Matching Requirements with Specifications . . . . . . . . 42 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 112 1. Introduction 114 The scope of this draft is an IPv6 Low-Power Network including star 115 and mesh topologies. In that context, "Neighbor Discovery 116 Optimization for IPv6 over Low-Power Wireless Personal Area Networks" 117 (6LoWPAN ND) [RFC6775] defines a registration mechanism that 118 leverages a central registrar for the main purpose of Duplicate 119 Address Detection (DAD), with the intention to reduce the dependency 120 of the IPv6 Neighbor Discovery Protocol (IPv6 ND) [RFC4861][RFC4862] 121 on network-layer multicast and link-layer broadcast operations. 123 This specification updates 6LoWPAN ND to simplify the registration 124 operation in 6LoWPAN routers and to extend the protocol as a more 125 generic registration technique. The specified updates enable other 126 specifications to define new services such as Source Address 127 Validation (SAVI) with [I-D.ietf-6lo-ap-nd], participation as an 128 unaware leaf to an abstract routing protocol such as the "Routing 129 Protocol for Low Power and Lossy Networks" [RFC6550] (RPL) with 130 [I-D.thubert-roll-unaware-leaves], and registration to a backbone 131 routers performing proxy Neighbor Discovery in a Low-Power and Lossy 132 Network (LLN) with [I-D.ietf-6lo-backbone-router]. 134 In more details, this specification modifies and extends the behavior 135 and protocol elements of 6LoWPAN ND to enable the following new 136 capabilities: 138 o determining the freshest location in case of mobility (TID) 140 o Simplifying the registration flow for Link-Local Addresses 142 o Support of a Leaf Node in a Route-Over network 144 o Proxy registration in a Route-Over network 145 o Associating the registration with a variable-length Registration 146 Ownership Verifier (ROVR) 148 o Registration to a IPv6 ND proxy over a Backbone Link (6BBR) 150 o Clarification of support for privacy and temporary addresses 152 A more comprehensive set of requirements is provided in Appendix B. 154 2. Terminology 156 2.1. BCP 14 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 160 "OPTIONAL" in this document are to be interpreted as described in BCP 161 14 [RFC2119][RFC8174] when, and only when, they appear in all 162 capitals, as shown here. 164 2.2. References 166 The Terminology used in this document is consistent with and 167 incorporates that described in Terms Used in Routing for Low-Power 168 and Lossy Networks (LLNs). [RFC7102]. 170 Other terms in use in LLNs are found in Terminology for Constrained- 171 Node Networks [RFC7228]. 173 Readers are expected to be familiar with all the terms and concepts 174 that are discussed in 176 o "Neighbor Discovery for IP version 6" [RFC4861], 178 o "IPv6 Stateless Address Autoconfiguration" [RFC4862], 180 o "Problem Statement and Requirements for IPv6 over Low-Power 181 Wireless Personal Area Network (6LoWPAN) Routing" [RFC6606], 183 o "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): 184 Overview, Assumptions, Problem Statement, and Goals" [RFC4919] and 186 o "Neighbor Discovery Optimization for Low-power and Lossy Networks" 187 [RFC6775]. 189 2.3. New Terms 191 Backbone Link: An IPv6 transit link that interconnects two or more 192 Backbone Routers. It is expected to be of high speed compared 193 to the LLN in order to carry the traffic that is required to 194 federate multiple segments of the potentially large LLN into a 195 single IPv6 subnet. 197 Backbone Router: A logical network function in an IPv6 router that 198 federates an LLN over a Backbone Link. In order to do so, the 199 Backbone Router (6BBR) proxies the 6LoWPAN ND operations 200 detailed in this document onto the matching operations that run 201 over the backbone, typically IPv6 ND. Note that 6BBR is a 202 logical function, just like 6LR and 6LBR, and that the same 203 physical router may operate all three. 205 Extended LLN: Multiple LLNs as defined in [RFC6550], interconnected 206 by a Backbone Link via Backbone Routers, and forming a single 207 IPv6 Multi-Link Subnet. 209 Registration: The process during which a 6LN registers an IPv6 210 Address with a 6LR in order to obtain services such as DAD and 211 routing back. In a Route-Over network, a 6LBR may serve as 212 proxy for the registration of the 6LN to the 6BBR so the 6BBR 213 can provide IPv6 ND proxy services over the Backbone. 215 Binding: The association between an IP address, a MAC address, a 216 physical port on a switch, and other information about the node 217 that owns the IP Address. 219 Registered Node: The 6LN for which the registration is performed, 220 and which owns the fields in the Extended ARO option. 222 Registering Node: The node that performs the registration; this may 223 be the Registered Node, or a proxy such as a 6LBR performing a 224 registration to a 6BBR, on behalf of the Registered Node. 226 Registered Address: An address owned by the Registered Node that was 227 or is being registered. 229 RFC6775-only: Applied to an implementation, a type of node, or a 230 type of message, this adjective indicates a behavior that is 231 strictly as specified by [RFC6775] as opposed to updated with 232 this specification. 234 updated: Qualifies a 6LN, a 6LR, or a 6LBR that supports this 235 specification. 237 2.4. Subset of a 6LoWPAN Glossary 239 This document often uses the following acronyms: 241 6BBR: 6LoWPAN Backbone Router (proxy for the registration) 243 6LBR: 6LoWPAN Border Router (authoritative on DAD) 245 6LN: 6LoWPAN Node 247 6LR: 6LoWPAN Router (relay to the registration process) 249 6CIO: Capability Indication Option 251 (E)ARO: (Extended) Address Registration Option 253 (E)DAR: (Extended) Duplicate Address Request 255 (E)DAC: (Extended) Duplicate Address Confirmation 257 DAD: Duplicate Address Detection 259 DODAG: Destination-Oriented Directed Acyclic Graph 261 LLN: Low-Power and Lossy Network (a typical IoT network) 263 NA: Neighbor Advertisement 265 NCE: Neighbor Cache Entry 267 ND: Neighbor Discovery 269 NDP: Neighbor Discovery Protocol 271 NS: Neighbor Solicitation 273 ROVR: Registration Ownership Verifier (pronounced rover) 275 RPL: IPv6 Routing Protocol for LLNs (pronounced ripple) 277 RA: Router Advertisement 279 RS: Router Solicitation 281 TSCH: Timeslotted Channel Hopping 283 TID: Transaction ID (a sequence counter in the EARO) 285 3. Applicability of Address Registration Options 287 The purpose of the Address Registration Option (ARO) in [RFC6775] is 288 to facilitate duplicate address detection (DAD) for hosts as well as 289 to populate Neighbor Cache Entries (NCEs) [RFC4861] in the routers. 290 This reduces the reliance on multicast operations, which are often as 291 intrusive as broadcast, in IPv6 ND operations. 293 With this specification, a failed or useless registration can be 294 detected by a 6LR or a 6LBR for reasons other than address 295 duplication. Examples include: the router having run out of space; a 296 registration bearing a stale sequence number perhaps denoting a 297 movement of the host after the registration was placed; a host 298 misbehaving and attempting to register an invalid address such as the 299 unspecified address [RFC4291]; or a host using an address that is not 300 topologically correct on that link. 302 In such cases the host will receive an error to help diagnose the 303 issue and may retry, possibly with a different address, and possibly 304 registering to a different router, depending on the returned error. 305 The ability to return errors to address registrations is not intended 306 to be used to restrict the ability of hosts to form and use multiple 307 addresses. Rather, the intention is to conform to "Host Address 308 Availability Recommendations" [RFC7934]. 310 In particular, the freedom to form and register addresses is needed 311 for enhanced privacy; each host may register a number of addresses 312 using mechanisms such as "Privacy Extensions for Stateless Address 313 Autoconfiguration (SLAAC) in IPv6" [RFC4941]. 315 In IPv6 ND [RFC4861], a router needs enough storage to hold NCEs for 316 all directly connected addresses to which it is currently forwarding 317 packets (entries that do not appear to be in use may be flushed). In 318 contrast, a router serving the Address Registration mechanism needs 319 enough storage to hold NCEs for all the addresses that may be 320 registered to it, regardless of whether or not they are actively 321 communicating. The number of registrations supported by a 6LoWPAN 322 Router (6LR) or 6LoWPAN Border Router (6LBR) MUST be clearly 323 documented by the vendor and the dynamic use of associated resources 324 SHOULD be made available to the network operator, e.g., to a 325 management console. 327 In order to deploy this, network administrators need to ensure that 328 6LR/6LBRs in their network support the number and type of devices 329 that can register to them, based on the number of IPv6 addresses that 330 those devices require and their address renewal rate and behavior. 332 4. Extended ND Options and Messages 334 This specification does not introduce new options, but it modifies 335 existing ones and updates the associated behaviors as specified in 336 the following subsections. 338 4.1. Extended Address Registration Option (EARO) 340 The Address Registration Option (ARO) is defined in section 4.1 of 341 [RFC6775]. 343 This specification introduces the Extended Address Registration 344 Option (EARO) based on the ARO for use in NS and NA messages. The 345 EARO conveys additional information such as a sequence counter called 346 Transaction ID (TID) that is used to determine the latest location of 347 a registering mobile device. A new 'T' flag indicates that the TID 348 field is populated and that the option is an EARO. 350 The EARO also signals whether the 6LN expects routing or proxy 351 services from the 6LR using a new 'R' flag. 353 The EUI-64 field is overloaded and renamed ROVR in order to carry 354 different types of information, e.g., cryptographic information of 355 variable size. A larger ROVR size may be used if and only if 356 backward compatibility is not an issue in the particular deployment. 357 Note that the length of the ROVR field expressed in units of 8 bytes 358 is the Length of the option minus 1. 360 Section 5.1 discusses those changes in depth. 362 The format of the EARO is as follows: 364 0 1 2 3 365 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 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Type | Length | Status | Opaque | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Rsvd | I |R|T| TID | Registration Lifetime | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | | 372 ... Registration Ownership Verifier ... 373 | | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 Figure 1: EARO 378 Option Fields: 380 Type: 33 382 Length: 8-bit unsigned integer. The length of the whole 383 option in units of 8 bytes. It MUST be 2 when 384 operating in a backward-compatible mode with a ROVR 385 size of 64 bits. It MAY be 3, 4 or 5, denoting a 386 ROVR size of 128, 192 and 256 bits respectively. 388 Status: 8-bit unsigned integer. Indicates the status of a 389 registration in the NA response. MUST be set to 0 in 390 NS messages. See Table 1 below. 392 Rsvd (Reserved): This field is unused. It MUST be initialized to 393 zero by the sender and MUST be ignored by the 394 receiver. 396 Opaque: One-byte Opaque field; this is an octet is opaque to 397 ND but that the 6LN may wish to pass transparently to 398 another process. This field MUST be set to zero 399 unless the 6LN has a policy to set it otherwise. 401 I: Two-bit Integer: A value of zero indicates that the 402 Opaque field carries an abstract index that is used 403 to decide in which routing topology the address is 404 expected to be injected. In that case, the Opaque 405 field is passed to a routing process with the 406 indication that this is a topology information, and 407 the value of 0 indicates default. All other values 408 of "I" are reserved and MUST NOT be used. 410 R: One-bit flag. If the 'R' flag is set, the 411 Registering Node expects that the 6LR ensures 412 reachability for the registered address, e.g., by 413 injecting the address in a Route-Over routing 414 protocol or proxying ND over a Backbone Link. 416 T: One-bit flag. Set if the next octet is used as a 417 TID. 419 TID: One-byte integer; a Transaction ID that is maintained 420 by the node and incremented with each transaction of 421 one or more registrations performed at the same time 422 to one or more respective 6LRs. This field MUST be 423 ignored if the 'T' flag is not set. 425 Registration Lifetime: 16-bit integer; expressed in minutes. A 426 value of 0 indicates that the registration has ended 427 and that the associated state MUST be removed. 429 Registration Ownership Verifier (ROVR): Enables the correlation 430 between multiple attempts to register a same IPv6 431 Address. The ROVR is stored in the 6LR and the 6LBR 432 in the state associated to the registration. This 433 can be a unique ID of the Registering Node, such as 434 the EUI-64 address of an interface. This can also be 435 a token obtained with cryptographic methods which can 436 be used in additional protocol exchanges to associate 437 a cryptographic identity (key) with this registration 438 to ensure that only the owner can modify it later. 439 The scope of a ROVR is the registration of a 440 particular IPv6 Address and it must not be used to 441 correlate registrations of different addresses. 443 +-------+-----------------------------------------------------------+ 444 | Value | Description | 445 +-------+-----------------------------------------------------------+ 446 | 0..2 | See [RFC6775]. Note: a Status of 1 ("Duplicate Address") | 447 | | applies to the Registered Address. If the Source Address | 448 | | conflicts with an existing registration, "Duplicate | 449 | | Source Address" MUST be used. | 450 | | | 451 | 3 | Moved: The registration failed because it is not the | 452 | | freshest. This Status indicates that the registration is | 453 | | rejected because another more recent registration was | 454 | | done, as indicated by a same ROVR and a more recent TID. | 455 | | One possible cause is a stale registration that has | 456 | | progressed slowly in the network and was passed by a more | 457 | | recent one. It could also indicate a ROVR collision. | 458 | | | 459 | 4 | Removed: The binding state was removed. This status may | 460 | | be placed in an NA(EARO) message that is sent as the | 461 | | rejection of a proxy registration to a Backbone Router, | 462 | | or in an asynchronous NA(EARO) at any time. | 463 | | | 464 | 5 | Validation Requested: The Registering Node is challenged | 465 | | for owning the Registered Address or for being an | 466 | | acceptable proxy for the registration. This Status may | 467 | | be received in asynchronous DAC or NA messages from a | 468 | | registrar (6LR, 6LBR, 6BBR). | 469 | | | 470 | 6 | Duplicate Source Address: The address used as source of | 471 | | the NS(EARO) conflicts with an existing registration. | 472 | | | 473 | 7 | Invalid Source Address: The address used as source of the | 474 | | NS(EARO) is not a Link-Local Address. | 475 | | | 476 | 8 | Registered Address topologically incorrect: The address | 477 | | being registered is not usable on this link, e.g., it is | 478 | | not topologically correct | 479 | | | 480 | 9 | 6LBR Registry saturated: A new registration cannot be | 481 | | accepted because the 6LBR Registry is saturated. Note: | 482 | | this code is used by 6LBRs instead of Status 2 when | 483 | | responding to a Duplicate Address message exchange and is | 484 | | passed on to the Registering Node by the 6LR. | 485 | | | 486 | 10 | Validation Failed: The proof of ownership of the | 487 | | registered address is not correct. | 488 +-------+-----------------------------------------------------------+ 490 Table 1: EARO Status 492 4.2. Extended Duplicate Address Message Formats 494 The DAR and DAC messages are defined in section 4.4 of [RFC6775]. 495 Those messages follow a common base format, which enables information 496 from the ARO to be transported over multiple hops. 498 Those messages are extended to adapt to the new EARO format, as 499 follows: 501 0 1 2 3 502 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 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | Type | Code | Checksum | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Status | TID | Registration Lifetime | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | | 509 ... Registration Ownership Verifier ... 510 | | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | | 513 + + 514 | | 515 + Registered Address + 516 | | 517 + + 518 | | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 Figure 2: Duplicate Address Messages Format 523 Modified Message Fields: 525 Code: The ICMP Code as defined in [RFC4443]. The ICMP Code 526 MUST be set to 1 with this specification. An non- 527 null value of the ICMP Code indicates support for 528 this specification. 530 TID: 1-byte integer; same definition and processing as the 531 TID in the EARO as defined in Section 4.1. This 532 field MUST be ignored if the ICMP Code is null. 534 Registration Ownership Verifier (ROVR): The size of the ROVR is 535 computed from the overall size of the IPv6 packet. 536 This field has the same definition and processing as 537 the ROVR in the EARO option as defined in 538 Section 4.1. 540 4.3. New 6LoWPAN Capability Bits in the Capability Indication Option 542 This specification defines 5 new capability bits for use in the 6CIO, 543 which was introduced by [RFC7400] for use in IPv6 ND RA messages. 545 The new "E" flag indicates that EARO can be used in a registration. 546 A 6LR that supports this specification MUST set the "E" flag. 548 A similar "D" flag indicates the support of EDA Messages by the 6LBR; 549 A 6LBR that supports this specification MUST set the "D" flag. The 550 "D" flag is learned from advertisements by a 6LBR, and is propagated 551 down a graph of 6LRs as a node acting as 6LN registers to a 6LR 552 (which could be the 6LBR), and in turn becomes a 6LR to which other 553 6LNs will register. 555 The new "L", "B", and "P" flags, indicate whether a router is capable 556 of acting as 6LR, 6LBR, and 6BBR, respectively. These flags are not 557 mutually exclusive and a node MUST set all the flags that are 558 relevant to it. 560 0 1 2 3 561 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 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | Type | Length = 1 | Reserved |D|L|B|P|E|G| 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | Reserved | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 Figure 3: New capability Bits L, B, P, E in the 6CIO 570 Option Fields: 572 Type: 36 574 L: Node is a 6LR. 576 B: Node is a 6LBR. 578 P: Node is a 6BBR. 580 E: Node supports registrations based on EARO. 582 D: 6LBR supports EDA messages. 584 As an example, a 6LBR sets the "B" and "D" flags. If it acts as a 585 6LR, then it sets the "L" and "E" flags. If it is collocated with a 586 6BBR, then it also sets the "P" flag. 588 5. Updating RFC 6775 590 The Extended Address Registration Option (EARO) (see Section 4.1) 591 replaces the ARO used within Neighbor Discovery NS and NA messages 592 between a 6LN and its 6LR. Similarly, the EDA messages, EDAR and 593 EDAC, replace the DAR and DAC messages so as to transport the new 594 information between 6LRs and 6LBRs across an LLN mesh such as a 595 6TiSCH network. 597 The extensions to the ARO option are used in the Duplicate Address 598 messages, the Duplicate Address Request (DAR) and Duplicate Address 599 Confirmation (DAC), so as to convey the additional information all 600 the way to the 6LBR. In turn the 6LBR may proxy the registration 601 using IPv6 ND over a Backbone Link as illustrated in Figure 4. Note 602 that this specification avoids the Duplicate Address message flow for 603 Link-Local Addresses in a Route-Over [RFC6606] topology (see 604 Section 5.6). 606 6LN 6LR 6LBR 6BBR 607 | | | | 608 | NS(EARO) | | | 609 |--------------->| | | 610 | | Extended DAR | | 611 | |-------------->| | 612 | | | | 613 | | | proxy NS(EARO) | 614 | | |--------------->| 615 | | | | NS(DAD) 616 | | | | ------> 617 | | | | 618 | | | | 619 | | | proxy NA(EARO) | 620 | | |<---------------| 621 | | Extended DAC | | 622 | |<--------------| | 623 | NA(EARO) | | | 624 |<---------------| | | 625 | | | | 627 Figure 4: (Re-)Registration Flow 629 In order to support various types of link layers, this specification 630 allows multiple registrations, including for privacy / temporary 631 addresses and provides new mechanisms to help clean up stale 632 registration state as soon as possible, e.g., after a movement (see 633 Section 7). 635 Section 5 of [RFC6775] specifies how a 6LN bootstraps an interface 636 and locates available 6LRs. A Registering Node prefers registering 637 to a 6LR that is found to support this specification, as discussed in 638 Section 6.1, over an RFC6775-only one, and operates in a backward- 639 compatible fashion when attaching to an RFC6775-only 6LR. 641 5.1. Extending the Address Registration Option 643 The Extended ARO (EARO) replaces the ARO and is backward compatible 644 with the ARO if and only if the Length of the option is set to 2. 645 Its format is presented in Section 4.1. More details on backward 646 compatibility can be found in Section 6. 648 The semantics of the Neighbor Solicitation (NS) and the ARO are 649 modified as follows: 651 o The Target Address in the NS containing the EARO is now the field 652 that indicates the address that is being registered, as opposed to 653 the Source Address field as specified in [RFC6775] (see 654 Section 5.5). This change enables a 6LBR to use one of its 655 addresses as source of the proxy-registration of an address that 656 belongs to a LLN Node to a 6BBR. This also limits the use of an 657 address as source address before it is registered and the 658 associated DAD process is complete. 660 o The EUI-64 field in the ARO Option is renamed Registration 661 Ownership Verifier (ROVR) and is not required to be derived from a 662 MAC address (see Section 5.3). 664 o The option Length MAY be different than 2 and take a value between 665 3 and 5, in which case the EARO is not backward compatible with an 666 ARO. The increase of size corresponds to a larger ROVR field, so 667 the size of the ROVR is inferred from the option Length. 669 o A new Opaque field is introduced to carry opaque information in 670 case the registration is relayed to another process, e.g.; 671 injected in a routing protocol. A new "I" field provides an 672 abstract type for the opaque information, and from which the 6LN 673 derives to which other process the opaque is expected to be 674 passed. A value of Zero for I indicates an abstract topological 675 information to be passed to a routing process if the registration 676 is redistributed. In that case, a value of Zero for the Opaque 677 field is backward-compatible with the reserved fields that are 678 overloaded, and the meaning is to use the default topology. 680 o This document specifies a new flag in the EARO, the 'R' flag. If 681 the 'R' flag is set, the Registering Node expects that the 6LR 682 ensures reachability for the Registered Address, e.g., by means of 683 routing or proxying ND. Conversely, when it is not set, the 'R' 684 flag indicates that the Registering Node is a router, which for 685 instance participates to a Route-Over routing protocol such as RPL 686 [RFC6550] and that it will take care of injecting its Address over 687 the routing protocol by itself. A 6LN that acts only as a host, 688 when registering, MUST set the 'R' flag to indicate that it is not 689 a router and that it will not handle its own reachability. A 6LR 690 that manages its reachability SHOULD NOT set the 'R' flag; if it 691 does, routes towards this router may be installed on its behalf 692 and may interfere with those it injects. 694 o The specification introduces a Transaction ID (TID) field in the 695 EARO (see Section 5.2). The TID MUST be provided by a node that 696 supports this specification and another new flag, the 'T' flag, 697 MUST be set to indicate so. 699 o Finally, this specification introduces new status codes to help 700 diagnose the cause of a registration failure (see Table 1). 702 5.2. Transaction ID 704 The TID is a sequence number that is incremented by the 6LN with each 705 re-registration to a 6LR. The TID is used to detect the freshness of 706 the registration request and to detect one single registration by 707 multiple 6LoWPAN border routers (e.g., 6LBRs and 6BBRs) supporting 708 the same 6LoWPAN. The TID may also be used by the network to route 709 to the current (freshest known) location of a moving node by spotting 710 the most recent TID. 712 When a Registered Node is registered with multiple 6BBRs in parallel, 713 the same TID MUST be used. This enables the 6BBRs to determine that 714 the registrations are the same, and distinguish that situation from a 715 movement (see section 4 of [I-D.ietf-6lo-backbone-router] and 716 Section 5.7 below). 718 5.2.1. Comparing TID values 720 As a note to the implementer, the operation of the TID is fully 721 compatible with that of the RPL Path Sequence counter as described in 722 the "Sequence Counter Operation" section of the "IPv6 Routing 723 Protocol for Low-Power and Lossy Networks" [RFC6550] specification. 725 A TID is deemed to be fresher than another when its value is greater 726 per the operations detailed in this section. 728 The TID range is subdivided in a 'lollipop' fashion ([Perlman83]), 729 where the values from 128 and greater are used as a linear sequence 730 to indicate a restart and bootstrap the counter, and the values less 731 than or equal to 127 used as a circular sequence number space of size 732 128 as in [RFC1982]. Consideration is given to the mode of operation 733 when transitioning from the linear region to the circular region. 734 Finally, when operating in the circular region, if sequence numbers 735 are detected to be too far apart then they are not comparable, as 736 detailed below. 738 A window of comparison, SEQUENCE_WINDOW = 16, is configured based on 739 a value of 2^N, where N is defined to be 4 in this specification. 741 For a given sequence counter, 743 1. The sequence counter SHOULD be initialized to an implementation 744 defined value which is 128 or greater prior to use. A 745 recommended value is 240 (256 - SEQUENCE_WINDOW). 747 2. When a sequence counter increment would cause the sequence 748 counter to increment beyond its maximum value, the sequence 749 counter MUST wrap back to zero. When incrementing a sequence 750 counter greater than or equal to 128, the maximum value is 255. 751 When incrementing a sequence counter less than 128, the maximum 752 value is 127. 754 3. When comparing two sequence counters, the following rules MUST be 755 applied: 757 1. When a first sequence counter A is in the interval [128..255] 758 and a second sequence counter B is in [0..127]: 760 1. If (256 + B - A) is less than or equal to 761 SEQUENCE_WINDOW, then B is greater than A, A is less than 762 B, and the two are not equal. 764 2. If (256 + B - A) is greater than SEQUENCE_WINDOW, then A 765 is greater than B, B is less than A, and the two are not 766 equal. 768 For example, if A is 240, and B is 5, then (256 + 5 - 240) is 769 21. 21 is greater than SEQUENCE_WINDOW (16), thus 240 is 770 greater than 5. As another example, if A is 250 and B is 5, 771 then (256 + 5 - 250) is 11. 11 is less than SEQUENCE_WINDOW 772 (16), thus 250 is less than 5. 774 2. In the case where both sequence counters to be compared are 775 less than or equal to 127, and in the case where both 776 sequence counters to be compared are greater than or equal to 777 128: 779 1. If the absolute magnitude of difference between the two 780 sequence counters is less than or equal to 781 SEQUENCE_WINDOW, then a comparison as described in 782 [RFC1982] is used to determine the relationships greater 783 than, less than, and equal. 785 2. If the absolute magnitude of difference of the two 786 sequence counters is greater than SEQUENCE_WINDOW, then a 787 desynchronization has occurred and the two sequence 788 numbers are not comparable. 790 4. If two sequence numbers are determined to be not comparable, 791 i.e., the results of the comparison are not defined, then a node 792 should give precedence to the sequence number that was most 793 recently incremented. Failing this, the node should select the 794 sequence number in order to minimize the resulting changes to its 795 own state. 797 5.3. Registration Ownership Verifier 799 The ROVR field generalizes the EUI-64 field of the ARO defined in 800 [RFC6775]. It is scoped to a registration and enables recognizing 801 and blocking an attempt to register a duplicate address, which is 802 characterized by a different ROVR in the conflicting registrations. 803 It can also be used to protect the ownership of a Registered Address, 804 if the proof-of-ownership of the ROVR can be obtained (more in 805 Section 5.6). 807 The ROVR can be of different types, as long as the type is signaled 808 in the message that carries the new type. For instance, the type can 809 be a cryptographic string and used to prove the ownership of the 810 registration as specified in "Address Protected Neighbor Discovery 811 for Low-power and Lossy Networks" [I-D.ietf-6lo-ap-nd]. In order to 812 support the flows related to the proof-of-ownership, this 813 specification introduces new status codes "Validation Requested" and 814 "Validation Failed" in the EARO. 816 Note on ROVR collision: different techniques for forming the ROVR 817 will operate in different name-spaces. [RFC6775] operates on EUI- 818 64(TM) addresses. [I-D.ietf-6lo-ap-nd] generates cryptographic 819 tokens. While collisions are not expected in the EUI-64 name-space 820 only, they may happen in the case of [I-D.ietf-6lo-ap-nd] and in a 821 mixed situation. An implementation that understands the name-space 822 MUST consider that ROVRs from different name-spaces are different 823 even if they have the same value. An RFC6775-only 6LR or 6LBR will 824 confuse the name-spaces, which slightly increases the risk of a ROVR 825 collision. A collision of ROVR has no effect if the two Registering 826 Nodes register different addresses, since the ROVR is only 827 significant within the context of one registration. A ROVR is not 828 expected to be unique to one registration, as this specification 829 allows a node to use the same ROVR to register multiple IPv6 830 addresses. This is why the ROVR MUST NOT be used as a key to 831 identify the Registering Node, or as an index to the registration. 832 It is only used as a match to ensure that the node that updates a 833 registration for an IPv6 address is the node that made the original 834 registration for that IPv6 address. Also, when the ROVR is not an 835 EUI-64 address, then it MUST NOT be used as the interface ID of the 836 Registered Address. This way, a registration that uses that ROVR 837 will not collision with that of an IPv6 Address derived from EUI-64 838 and using the EUI-64 as ROVR per [RFC6775]. 840 The Registering Node SHOULD store the ROVR, or enough information to 841 regenerate it, in persistent memory. If this is not done and an 842 event such as a reboot causes a loss of state, re-registering the 843 same address could be impossible until the 6LRs and the 6LBR time out 844 the previous registration, or a management action is taken to clear 845 the relevant state in the network. 847 5.4. Extended Duplicate Address Messages 849 In order to map the new EARO content in the Extended Duplicate 850 Address (EDA) messages, a new TID field is added to the Extended DAR 851 (EDAR) and the Extended DAC (EDAC) messages as a replacement of the 852 Reserved field, and a non-null value of the ICMP Code indicates 853 support for this specification. The format of the EDA messages is 854 presented in Section 4.2. 856 As with the EARO, the Extended Duplicate Address messages are 857 backward compatible with the RFC6775-only versions as long as the 858 ROVR field is 64 bits long. Remarks concerning backwards 859 compatibility for the protocol between the 6LN and the 6LR apply 860 similarly between a 6LR and a 6LBR. 862 5.5. Registering the Target Address 864 An NS message with an EARO is a registration if and only if it also 865 carries an SLLA Option [RFC6775]. The EARO is also used in NS and NA 866 messages between Backbone Routers [I-D.ietf-6lo-backbone-router] over 867 the Backbone Link to sort out the distributed registration state; in 868 that case, it does not carry the SLLA Option and is not confused with 869 a registration. 871 The Registering Node is the node that performs the registration to 872 the 6BBR. As in [RFC6775], it may be the Registered Node as well, in 873 which case it registers one of its own addresses and indicates its 874 own MAC Address as Source Link Layer Address (SLLA) in the NS(EARO). 876 This specification adds the capability to proxy the registration 877 operation on behalf of a Registered Node that is reachable over an 878 LLN mesh. In that case, if the Registered Node is reachable from the 879 6BBR over a Mesh-Under mesh, the Registering Node indicates the MAC 880 Address of the Registered Node as the SLLA in the NS(EARO). If the 881 Registered Node is reachable over a Route-Over mesh from the 882 Registering Node, the SLLA in the NS(ARO) is that of the Registering 883 Node. This enables the Registering Node to attract the packets from 884 the 6BBR and route them over the LLN to the Registered Node. 886 In order to enable the latter operation, this specification changes 887 the behavior of the 6LN and the 6LR so that the Registered Address is 888 found in the Target Address field of the NS and NA messages as 889 opposed to the Source Address field. With this convention, a TLLA 890 option indicates the link-layer address of the 6LN that owns the 891 address. 893 If Registering Node expects packets for the 6LN, e.g., a 6LBR also 894 acting as RPL Root, then it MUST place its own Link Layer Address in 895 the SLLA Option that MUST always be placed in a registration NS(EARO) 896 message. This maintains compatibility with RFC6775-only 6LoWPAN ND 897 [RFC6775]. 899 5.6. Link-Local Addresses and Registration 901 Considering that LLN nodes are often not wired and may move, there is 902 no guarantee that a Link-Local Address stays unique between a 903 potentially variable and unbounded set of neighboring nodes. 905 Compared to [RFC6775], this specification only requires that a Link- 906 Local Address be unique from the perspective of the two nodes that 907 use it to communicate (e.g., the 6LN and the 6LR in an NS/NA 908 exchange). This simplifies the DAD process in a Route-Over topology 909 for Link-Local Addresses by avoiding an exchange of EDA messages 910 between the 6LR and a 6LBR for those addresses. 912 In more details: 914 An exchange between two nodes using Link-Local Addresses implies that 915 they are reachable over one hop. A node MUST register a Link-Local 916 Address to a 6LR in order to obtain reachability from that 6LR beyond 917 the current exchange, and in particular to use the Link-Local Address 918 as source address to register other addresses, e.g., global 919 addresses. 921 If there is no collision with an address previously registered to 922 this 6LR by another 6LN, then the Link-Local Address is unique from 923 the standpoint of this 6LR and the registration is not a duplicate. 925 Alternatively, two different 6LRs might expose the same Link-Local 926 Address but different link-layer addresses. In that case, a 6LN MUST 927 only interact with at most one of the 6LRs. 929 The exchange of EDA messages between the 6LR and a 6LBR, which 930 ensures that an address is unique across the domain covered by the 931 6LBR, does not need to take place for Link-Local Addresses. 933 When registering to a 6LR that conforms to this specification, a 6LN 934 MUST use a Link-Local Address as the source address of the 935 registration, whatever the type of IPv6 address that is being 936 registered. That Link-Local Address MUST be either an address that 937 is already registered to the 6LR, or the address that is being 938 registered. 940 A typical flow when a 6LN starts up is that it sends a multicast RS 941 and receives one or more unicast RA messages. If the 6LR can process 942 Extended ARO, then it places a 6CIO in its RA message back with the 943 "E" Flag set as required in Section 6.1. 945 When a Registering Node does not have an already-registered Address, 946 it MUST register a Link-Local Address, using it as both the Source 947 and the Target Address of an NS(EARO) message. In that case, it is 948 RECOMMENDED to use a Link-Local Address that is (expected to be) 949 globally unique, e.g., derived from a globally unique EUI-64 address. 950 For such an address, DAD is not required (see [RFC6775]) and using 951 the SLLA Option in the NS is actually more consistent with existing 952 ND specifications such as the "Optimistic Duplicate Address Detection 953 (ODAD) for IPv6" [RFC4429]. The 6LN MAY then use that address to 954 register one or more other addresses. 956 A 6LR that supports this specification replies with an NA(EARO), 957 setting the appropriate status. Since there is no exchange of EDA 958 messages for Link-Local Addresses, the 6LR may answer immediately to 959 the registration of a Link-Local Address, based solely on its 960 existing state and the Source Link-Layer Option that is placed in the 961 NS(EARO) message as required in [RFC6775]. 963 A node needs to register its IPv6 Global Unicast Addresses (GUAs) to 964 a 6LR in order to establish global reachability for these addresses 965 via that 6LR. When registering with an updated 6LR, a Registering 966 Node does not use a GUA as Source Address, in contrast to a node that 967 complies to [RFC6775]. For non-Link-Local Addresses, the exchange of 968 EDA messages MUST conform to [RFC6775], but the extended formats 969 described in this specification for the DAR and the DAC are used to 970 relay the extended information in the case of an EARO. 972 5.7. Maintaining the Registration States 974 This section discusses protocol actions that involve the Registering 975 Node, the 6LR, and the 6LBR. It must be noted that the portion that 976 deals with a 6LBR only applies to those addresses that are registered 977 to it; as discussed in Section 5.6, this is not the case for Link- 978 Local Addresses. The registration state includes all data that is 979 stored in the router relative to that registration, in particular, 980 but not limited to, an NCE. 6LBRs and 6BBRs may store additional 981 registration information in more complex abstract data structures and 982 use protocols that are out of scope of this document to keep them 983 synchronized when they are distributed. 985 When its resource available to store registration states are 986 exhausted, a 6LR cannot accept a new registration. In that 987 situation, the EARO is returned in an NA message with a Status Code 988 of "Neighbor Cache Full" (Table 1), and the Registering Node may 989 attempt to register to another 6LR. 991 If the registry in the 6LBR is saturated, then the 6LBR cannot decide 992 whether a registration for a new address is a duplicate. In that 993 case, the 6LBR replies to an EDAR message with an EDAC message that 994 carries a new Status Code indicating "6LBR Registry saturated" 995 (Table 1). Note: this code is used by 6LBRs instead of "Neighbor 996 Cache Full" when responding to a Duplicate Address message exchange 997 and is passed on to the Registering Node by the 6LR. There is no 998 point for the node to retry this registration immediately via another 999 6LR, since the problem is global to the network. The node may either 1000 abandon that address, de-register other addresses first to make room, 1001 or keep the address in TENTATIVE state and retry later. 1003 A node renews an existing registration by sending a new NS(EARO) 1004 message for the Registered Address. In order to refresh the 1005 registration state in the 6LBR, the registration MUST be reported to 1006 the 6LBR. 1008 A node that ceases to use an address SHOULD attempt to de-register 1009 that address from all the 6LRs to which it has registered the 1010 address. This is achieved using an NS(EARO) message with a 1011 Registration Lifetime of 0. If this is not done, the associated 1012 state will remain in the network till the current Registration 1013 Lifetime expires and this may lead to a situation where the 6LR 1014 resources become saturated, even if they are correctly planned to 1015 start with. The 6LR may then take defensive measures that may 1016 prevent this node or some other nodes from owning as many addresses 1017 as they would expect (see Section 7). 1019 A node that moves away from a particular 6LR SHOULD attempt to de- 1020 register all of its addresses registered to that 6LR and register to 1021 a new 6LR with an incremented TID. When/if the node shows up 1022 elsewhere, an asynchronous NA(EARO) or EDAC message with a Status 1023 Code of "Moved" SHOULD be used to clean up the state in the previous 1024 location. For instance, as described in 1025 [I-D.ietf-6lo-backbone-router], the "Moved" status can be used by a 1026 6BBR in an NA(EARO) message to indicate that the ownership of the 1027 proxy state on the Backbone Link was transferred to another 6BBR as 1028 the consequence of a movement of the device. If the receiver of the 1029 message has a state corresponding to the related address, it SHOULD 1030 propagate the status down the forwarding path to the Registered node 1031 (e.g., reversing an existing RPL [RFC6550] path as prescribed in 1032 [I-D.ietf-roll-efficient-npdao]). Whether it could do so or not, the 1033 receiver MUST clean up said state. 1035 Upon receiving an NS(EARO) message with a Registration Lifetime of 0 1036 and determining that this EARO is the freshest for a given NCE (see 1037 Section 5.2), a 6LR cleans up its NCE. If the address was registered 1038 to the 6LBR, then the 6LR MUST report to the 6LBR, through a 1039 Duplicate Address exchange with the 6LBR, indicating the null 1040 Registration Lifetime and the latest TID that this 6LR is aware of. 1042 Upon receiving the EDAR message, the 6LBR evaluates if this is the 1043 most recent TID it has received for that particular registry entry. 1044 If so, then the EDAR is answered with an EDAC message bearing a 1045 Status of "Success" and the entry is scheduled to be removed. 1046 Otherwise, a Status Code of "Moved" is returned instead, and the 1047 existing entry is maintained. 1049 When an address is scheduled to be removed, the 6LBR SHOULD keep its 1050 entry in a DELAY state for a configurable period of time, so as to 1051 protect a mobile node that de-registered from one 6LR and did not 1052 register yet to a new one, or the new registration did not yet reach 1053 the 6LBR due to propagation delays in the network. Once the DELAY 1054 time is passed, the 6LBR silently removes its entry. 1056 6. Backward Compatibility 1058 This specification changes the behavior of the peers in a 1059 registration flow. To enable backward compatibility, a 6LN that 1060 registers to a 6LR that is not known to support this specification 1061 MUST behave in a manner that is backward-compatible with [RFC6775]. 1062 On the contrary, if the 6LR is found to support this specification, 1063 then the 6LN MUST conform to this specification when communicating 1064 with that 6LR. 1066 A 6LN that supports this specification MUST always use an EARO as a 1067 replacement for an ARO in its registration to a router. This is 1068 backward-compatible since the 'T' flag and TID field are reserved in 1069 [RFC6775], and are ignored by an RFC6775-only router. A router that 1070 supports this specification MUST answer an NS(ARO) and an NS(EARO) 1071 with an NA(EARO). A router that does not support this specification 1072 will consider the ROVR as an EUI-64 address and treat it the same, 1073 which has no consequence if the Registered Addresses are different. 1075 6.1. Signaling EARO Capability Support 1077 "Generic Header Compression for IPv6 over 6LoWPANs" [RFC7400] 1078 introduces the 6LoWPAN Capability Indication Option (6CIO) to 1079 indicate a node's capabilities to its peers. The 6CIO MUST be 1080 present in both Router Solicitation (RS) and Router Advertisement 1081 (RA) messages, unless the information therein was already shared. 1082 This can have happened in recent exchanges. The information can also 1083 be implicit, or pre-configured in all nodes in a network. In any 1084 case, a 6CIO MUST be placed in an RA message that is sent in response 1085 to an RS with a 6CIO. 1087 Section 4.3 defines a new flag for the 6CIO to signal support for 1088 EARO by the issuer of the message. New flags are also added to the 1089 6CIO to signal the sender's capability to act as a 6LR, 6LBR, and 1090 6BBR (see Section 4.3). 1092 Section 4.3 also defines a new flag that indicates the support of EDA 1093 messages by the 6LBR. This flag is valid in RA messages but not in 1094 RS messages. More information on the 6LBR is found in a separate 1095 Authoritative Border Router Option (ABRO). The ABRO is placed in RA 1096 messages as prescribed by [RFC6775]; in particular, it MUST be placed 1097 in an RA message that is sent in response to an RS with a 6CIO 1098 indicating the capability to act as a 6LR, since the RA propagates 1099 information between routers. 1101 6.2. RFC6775-only 6LoWPAN Node 1103 An RFC6775-only 6LN will use the Registered Address as the source 1104 address of the NS message and will not use an EARO. An updated 6LR 1105 MUST accept that registration if it is valid per [RFC6775], and it 1106 MUST manage the binding cache accordingly. The updated 6LR MUST then 1107 use the RFC6775-only EDA messages as specified in [RFC6775] to 1108 indicate to the 6LBR that the TID is not present in the messages. 1110 The main difference from [RFC6775] is that the exchange of EDA 1111 messages for the purpose of DAD is avoided for Link-Local Addresses. 1112 In any case, the 6LR MUST use an EARO in the reply, and can use any 1113 of the Status codes defined in this specification. 1115 6.3. RFC6775-only 6LoWPAN Router 1117 An updated 6LN discovers the capabilities of the 6LR in the 6CIO in 1118 RA messages from that 6LR; if the 6CIO was not present in the RA, 1119 then the 6LR is assumed to be a RFC6775-only 6LoWPAN Router. 1121 An updated 6LN MUST use an EARO in the request regardless of the type 1122 of 6LR, RFC6775-only or updated, which implies that the 'T' flag is 1123 set. It MUST use a ROVR of 64 bits if the 6LR is an RFC6775-only 1124 6LoWPAN Router. 1126 If an updated 6LN moves from an updated 6LR to an RFC6775-only 6LR, 1127 the RFC6775-only 6LR will send an RFC6775-only DAR message, which 1128 cannot be compared with an updated one for freshness. Allowing 1129 RFC6775-only DAR messages to replace a state established by the 1130 updated protocol in the 6LBR would be an attack vector and that 1131 cannot be the default behavior. But if RFC6775-only and updated 6LRs 1132 coexist temporarily in a network, then it makes sense for an 1133 administrator to install a policy that allows this, and the 1134 capability to install such a policy should be configurable in a 6LBR 1135 though it is out of scope for this document. 1137 6.4. RFC6775-only 6LoWPAN Border Router 1139 With this specification, the Duplicate Address messages are extended 1140 to transport the EARO information. Similarly to the NS/NA exchange, 1141 an updated 6LBR MUST always use the EDA messages. 1143 Note that an RFC6775-only 6LBR will accept and process an EDAR 1144 message as if it were an RFC6775-only DAR, as long as the ROVR is 64 1145 bits long. An updated 6LR discovers the capabilities of the 6LBR in 1146 the 6CIO in RA messages from the 6LR; if the 6CIO was not present in 1147 any RA, then the 6LBR si assumed to be a RFC6775-only 6LoWPAN Border 1148 Router. 1150 If the 6LBR is RFC6775-only, and the ROVR in the NS(EARO) was more 1151 than 64 bits long, then the 6LR MUST truncate the ROVR to the 64 1152 leftmost bits and place the result in the EDAR message to maintain 1153 compatibility. This way, the support of DAD is preserved. 1155 7. Security Considerations 1157 This specification extends [RFC6775], and the security section of 1158 that document also applies to this as well. In particular, it is 1159 expected that the link layer is sufficiently protected to prevent 1160 rogue access, either by means of physical or IP security on the 1161 Backbone Link and link-layer cryptography on the LLN. 1163 [RFC6775] does not protect the content of its messages and expects a 1164 lower layer encryption to defeat potential attacks. This 1165 specification also expects that the LLN MAC provides secure unicast 1166 to/from the Backbone Router and secure Broadcast or Multicast from 1167 the Backbone Router in a way that prevents tampering with or 1168 replaying the Neighbor Discovery messages. 1170 This specification recommends using privacy techniques (see 1171 Section 8) and protecting against address theft such as provided by 1172 "Address Protected Neighbor Discovery for Low-power and Lossy 1173 Networks" [I-D.ietf-6lo-ap-nd], which guarantees the ownership of the 1174 Registered Address using a cryptographic ROVR. 1176 The registration mechanism may be used by a rogue node to attack the 1177 6LR or the 6LBR with a Denial-of-Service attack against the registry. 1178 It may also happen that the registry of a 6LR or a 6LBR is saturated 1179 and cannot take any more registrations, which effectively denies the 1180 requesting node the capability to use a new address. In order to 1181 alleviate those concerns, Section 5.7 provides a number of 1182 recommendations that ensure that a stale registration is removed as 1183 soon as possible from the 6LR and 6LBR. In particular, this 1184 specification recommends that: 1186 o A node that ceases to use an address SHOULD attempt to de-register 1187 that address from all the 6LRs to which it is registered. See 1188 Section 5.2 for the mechanism to avoid replay attacks and avoiding 1189 the use of stale registration information. 1191 o The Registration lifetimes SHOULD be individually configurable for 1192 each address or group of addresses. The nodes SHOULD be 1193 configured with a Registration Lifetime that reflects their 1194 expectation of how long they will use the address with the 6LR to 1195 which it is registered. In particular, use cases that involve 1196 mobility or rapid address changes SHOULD use lifetimes that are 1197 larger yet of a same order as the duration of the expectation of 1198 presence. 1200 o The router (6LR or 6LBR) SHOULD be configurable so as to limit the 1201 number of addresses that can be registered by a single node, but 1202 as a protective measure only. In any case, a router MUST be able 1203 to keep a minimum number of addresses per node. That minimum 1204 depends on the type of device and ranges between 3 for a very 1205 constrained LLN and 10 for a larger device. A node may be 1206 identified by its MAC address, as long as it is not obfuscated by 1207 privacy measures. A stronger identification (e.g., by security 1208 credentials) is RECOMMENDED. When the maximum is reached, the 1209 router should use a Least-Recently-Used (LRU) algorithm to clean 1210 up the addresses, keeping at least one Link-Local Address. The 1211 router SHOULD attempt to keep one or more stable addresses if 1212 stability can be determined, e.g., because they are used over a 1213 much longer time span than other (privacy, shorter-lived) 1214 addresses. 1216 o In order to avoid denial of registration for the lack of 1217 resources, administrators should take great care to deploy 1218 adequate numbers of 6LRs to cover the needs of the nodes in their 1219 range, so as to avoid a situation of starving nodes. It is 1220 expected that the 6LBR that serves an LLN is a more capable node 1221 than the average 6LR, but in a network condition where it may 1222 become saturated, a particular deployment should distribute the 1223 6LBR functionality, for instance by leveraging a high speed 1224 Backbone Link and Backbone Routers to aggregate multiple LLNs into 1225 a larger subnet. 1227 The LLN nodes depend on the 6LBR and the 6BBR for their operation. A 1228 trust model must be put in place to ensure that the right devices are 1229 acting in these roles so as to avoid threats such as black-holing or 1230 bombing attack whereby an impersonated 6LBR would destroy state in 1231 the network by using the "Removed" Status code. This trust model 1232 could be at a minimum based on a Layer-2 access control, or could 1233 provide role validation as well (see Req5.1 in Appendix B.5). 1235 8. Privacy Considerations 1237 As indicated in Section 3, this protocol does not inherently limit 1238 the number of IPv6 addresses that each device can form. However, to 1239 mitigate denial-of-service attacks, it can be useful as a protective 1240 measure to have a limit that is high enough not to interfere with the 1241 normal behavior of devices in the network. A host should be able to 1242 form and register any address that is topologically correct in the 1243 subnet(s) advertised by the 6LR/6LBR. 1245 This specification does not mandate any particular way for forming 1246 IPv6 addresses, but it discourages using EUI-64 for forming the 1247 Interface ID in the Link-Local Address because this method prevents 1248 the usage of "SEcure Neighbor Discovery (SEND)" [RFC3971], 1249 "Cryptographically Generated Addresses (CGA)" [RFC3972], and that of 1250 address privacy techniques. 1252 "Privacy Considerations for IPv6 Adaptation-Layer Mechanisms" 1253 [RFC8065] explains why privacy is important and how to form privacy- 1254 aware addresses. All implementations and deployments must consider 1255 the option of privacy addresses in their own environments. 1257 The IPv6 address of the 6LN in the IPv6 header can be compressed 1258 statelessly when the Interface Identifier in the IPv6 address can be 1259 derived from the Lower Layer address. When it is not critical to 1260 benefit from that compression, e.g., the address can be compressed 1261 statefully, or it is rarely used and/or it is used only over one hop, 1262 then privacy concerns should be considered. In particular, new 1263 implementations should follow the IETF "Recommendation on Stable IPv6 1264 Interface Identifiers" [RFC8064]. [RFC8064] recommends the use of "A 1265 Method for Generating Semantically Opaque Interface Identifiers with 1266 IPv6 Stateless Address Autoconfiguration (SLAAC)" [RFC7217] for 1267 generating Interface Identifiers to be used in SLAAC. 1269 9. IANA Considerations 1271 Note to RFC Editor, to be removed: please replace "This RFC" 1272 throughout this document by the RFC number for this specification 1273 once it is allocated. 1275 IANA is requested to make a number of changes under the "Internet 1276 Control Message Protocol version 6 (ICMPv6) Parameters" registry, as 1277 follows. 1279 9.1. ARO Flags 1281 IANA is requested to create a new subregistry for "ARO Flags". This 1282 specification defines 8 positions, bit 0 to bit 7, and assigns bit 6 1283 for the 'R' flag and bit 7 for the 'T' flag (see Section 4.1). The 1284 policy is "IETF Review" or "IESG Approval" [RFC8126]. The initial 1285 content of the registry is as shown in Table 2. 1287 New subregistry for ARO Flags under the "Internet Control Message 1288 Protocol version 6 (ICMPv6) [RFC4443] Parameters" 1290 +-------------+--------------+-----------+ 1291 | ARO Status | Description | Document | 1292 +-------------+--------------+-----------+ 1293 | 0..5 | Unassigned | | 1294 | | | | 1295 | 6 | 'R' Flag | This RFC | 1296 | | | | 1297 | 7 | 'T' Flag | This RFC | 1298 +-------------+--------------+-----------+ 1300 Table 2: new ARO Flags 1302 9.2. ICMP Codes 1304 IANA is requested to create 2 new subregistries of the ICMPv6 "Code" 1305 Fields registry, which itself is a subregistry of the Internet 1306 Control Message Protocol version 6 (ICMPv6) Parameters for the ICMP 1307 codes. The new subregistries relate to the ICMP type 157, Duplicate 1308 Address Request (shown in Table 3), and 158, Duplicate Address 1309 Confirmation (shown in Table 4), respectively. The range of an 1310 ICMPv6 "Code" Field is 0..255 in all cases. The policy is "IETF 1311 Review" or "IESG Approval" [RFC8126] for both subregistries. The new 1312 subregistries are initialized as follows: 1314 New entries for ICMP types 157 DAR message 1316 +---------+----------------------+------------+ 1317 | Code | Name | Reference | 1318 +---------+----------------------+------------+ 1319 | 0 | Original DAR message | RFC 6775 | 1320 | | | | 1321 | 1 | Extended DAR message | This RFC | 1322 | | | | 1323 | 2...255 | Unassigned | | 1324 +---------+----------------------+------------+ 1326 Table 3: new ICMPv6 Code Fields 1328 New entries for ICMP types 158 DAC message 1330 +---------+----------------------+------------+ 1331 | Code | Name | Reference | 1332 +---------+----------------------+------------+ 1333 | 0 | Original DAC message | RFC 6775 | 1334 | | | | 1335 | 1 | Extended DAC message | This RFC | 1336 | | | | 1337 | 2...255 | Unassigned | | 1338 +---------+----------------------+------------+ 1340 Table 4: new ICMPv6 Code Fields 1342 9.3. New ARO Status values 1344 IANA is requested to make additions to the Address Registration 1345 Option Status Values Registry as follows: 1347 Address Registration Option Status Values Registry 1349 +-------------+-----------------------------------------+-----------+ 1350 | ARO Status | Description | Document | 1351 +-------------+-----------------------------------------+-----------+ 1352 | 3 | Moved | This RFC | 1353 | | | | 1354 | 4 | Removed | This RFC | 1355 | | | | 1356 | 5 | Validation Requested | This RFC | 1357 | | | | 1358 | 6 | Duplicate Source Address | This RFC | 1359 | | | | 1360 | 7 | Invalid Source Address | This RFC | 1361 | | | | 1362 | 8 | Registered Address topologically | This RFC | 1363 | | incorrect | | 1364 | | | | 1365 | 9 | 6LBR Registry saturated | This RFC | 1366 | | | | 1367 | 10 | Validation Failed | This RFC | 1368 +-------------+-----------------------------------------+-----------+ 1370 Table 5: New ARO Status values 1372 9.4. New 6LoWPAN capability Bits 1374 IANA is requested to make additions to the Subregistry for "6LoWPAN 1375 capability Bits" as follows: 1377 Subregistry for "6LoWPAN capability Bits" under the "Internet Control 1378 Message Protocol version 6 (ICMPv6) Parameters" 1380 +-----------------+----------------------+-----------+ 1381 | Capability Bit | Description | Document | 1382 +-----------------+----------------------+-----------+ 1383 | 10 | EDA Support (D bit) | This RFC | 1384 | | | | 1385 | 11 | 6LR capable (L bit) | This RFC | 1386 | | | | 1387 | 12 | 6LBR capable (B bit) | This RFC | 1388 | | | | 1389 | 13 | 6BBR capable (P bit) | This RFC | 1390 | | | | 1391 | 14 | EARO support (E bit) | This RFC | 1392 +-----------------+----------------------+-----------+ 1394 Table 6: New 6LoWPAN capability Bits 1396 10. Acknowledgments 1398 Kudos to Eric Levy-Abegnoli who designed the First Hop Security 1399 infrastructure upon which the first backbone router was implemented. 1400 Many thanks to Sedat Gormus, Rahul Jadhav, Tim Chown, Juergen 1401 Schoenwaelder, Chris Lonvick, Dave Thaler, Adrian Farrel, Peter Yee, 1402 Warren Kumari, Benjamin Kaduk, Mirja Kuhlewind, Ben Campbell, Eric 1403 Rescorla, and Lorenzo Colitti for their various contributions and 1404 reviews. Also, many thanks to Thomas Watteyne for the world first 1405 implementation of a 6LN that was instrumental to the early tests of 1406 the 6LR, 6LBR and Backbone Router. 1408 11. References 1410 11.1. Normative References 1412 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1413 Requirement Levels", BCP 14, RFC 2119, 1414 DOI 10.17487/RFC2119, March 1997, 1415 . 1417 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1418 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 1419 2006, . 1421 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1422 Control Message Protocol (ICMPv6) for the Internet 1423 Protocol Version 6 (IPv6) Specification", STD 89, 1424 RFC 4443, DOI 10.17487/RFC4443, March 2006, 1425 . 1427 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1428 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1429 DOI 10.17487/RFC4861, September 2007, 1430 . 1432 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1433 Address Autoconfiguration", RFC 4862, 1434 DOI 10.17487/RFC4862, September 2007, 1435 . 1437 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 1438 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1439 DOI 10.17487/RFC6282, September 2011, 1440 . 1442 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 1443 Bormann, "Neighbor Discovery Optimization for IPv6 over 1444 Low-Power Wireless Personal Area Networks (6LoWPANs)", 1445 RFC 6775, DOI 10.17487/RFC6775, November 2012, 1446 . 1448 [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for 1449 IPv6 over Low-Power Wireless Personal Area Networks 1450 (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November 1451 2014, . 1453 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1454 Writing an IANA Considerations Section in RFCs", BCP 26, 1455 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1456 . 1458 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1459 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1460 May 2017, . 1462 11.2. Terminology Related References 1464 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 1465 over Low-Power Wireless Personal Area Networks (6LoWPANs): 1466 Overview, Assumptions, Problem Statement, and Goals", 1467 RFC 4919, DOI 10.17487/RFC4919, August 2007, 1468 . 1470 [RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem 1471 Statement and Requirements for IPv6 over Low-Power 1472 Wireless Personal Area Network (6LoWPAN) Routing", 1473 RFC 6606, DOI 10.17487/RFC6606, May 2012, 1474 . 1476 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 1477 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 1478 2014, . 1480 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1481 Constrained-Node Networks", RFC 7228, 1482 DOI 10.17487/RFC7228, May 2014, 1483 . 1485 11.3. Informative References 1487 [I-D.chakrabarti-nordmark-6man-efficient-nd] 1488 Chakrabarti, S., Nordmark, E., Thubert, P., and M. 1489 Wasserman, "IPv6 Neighbor Discovery Optimizations for 1490 Wired and Wireless Networks", draft-chakrabarti-nordmark- 1491 6man-efficient-nd-07 (work in progress), February 2015. 1493 [I-D.delcarpio-6lo-wlanah] 1494 Vega, L., Robles, I., and R. Morabito, "IPv6 over 1495 802.11ah", draft-delcarpio-6lo-wlanah-01 (work in 1496 progress), October 2015. 1498 [I-D.hou-6lo-plc] 1499 Hou, J., Hong, Y., and X. Tang, "Transmission of IPv6 1500 Packets over PLC Networks", draft-hou-6lo-plc-03 (work in 1501 progress), December 2017. 1503 [I-D.ietf-6lo-ap-nd] 1504 Thubert, P., Sarikaya, B., and M. Sethi, "Address 1505 Protected Neighbor Discovery for Low-power and Lossy 1506 Networks", draft-ietf-6lo-ap-nd-06 (work in progress), 1507 February 2018. 1509 [I-D.ietf-6lo-backbone-router] 1510 Thubert, P., "IPv6 Backbone Router", draft-ietf-6lo- 1511 backbone-router-06 (work in progress), February 2018. 1513 [I-D.ietf-6lo-nfc] 1514 Choi, Y., Hong, Y., Youn, J., Kim, D., and J. Choi, 1515 "Transmission of IPv6 Packets over Near Field 1516 Communication", draft-ietf-6lo-nfc-09 (work in progress), 1517 January 2018. 1519 [I-D.ietf-6tisch-architecture] 1520 Thubert, P., "An Architecture for IPv6 over the TSCH mode 1521 of IEEE 802.15.4", draft-ietf-6tisch-architecture-13 (work 1522 in progress), November 2017. 1524 [I-D.ietf-mboned-ieee802-mcast-problems] 1525 Perkins, C., McBride, M., Stanley, D., Kumari, W., and J. 1526 Zuniga, "Multicast Considerations over IEEE 802 Wireless 1527 Media", draft-ietf-mboned-ieee802-mcast-problems-01 (work 1528 in progress), February 2018. 1530 [I-D.ietf-roll-efficient-npdao] 1531 Jadhav, R., Thubert, P., Sahoo, R., and Z. Cao, "Efficient 1532 Route Invalidation", draft-ietf-roll-efficient-npdao-03 1533 (work in progress), March 2018. 1535 [I-D.perkins-intarea-multicast-ieee802] 1536 Perkins, C., Stanley, D., Kumari, W., and J. Zuniga, 1537 "Multicast Considerations over IEEE 802 Wireless Media", 1538 draft-perkins-intarea-multicast-ieee802-03 (work in 1539 progress), July 2017. 1541 [I-D.struik-lwip-curve-representations] 1542 Struik, R., "Alternative Elliptic Curve Representations", 1543 draft-struik-lwip-curve-representations-00 (work in 1544 progress), October 2017. 1546 [I-D.thubert-roll-unaware-leaves] 1547 Thubert, P., "Routing for RPL Leaves", draft-thubert-roll- 1548 unaware-leaves-04 (work in progress), March 2018. 1550 [RFC1958] Carpenter, B., Ed., "Architectural Principles of the 1551 Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996, 1552 . 1554 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 1555 DOI 10.17487/RFC1982, August 1996, 1556 . 1558 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 1559 CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September 1560 2003, . 1562 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 1563 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 1564 DOI 10.17487/RFC3810, June 2004, 1565 . 1567 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 1568 "SEcure Neighbor Discovery (SEND)", RFC 3971, 1569 DOI 10.17487/RFC3971, March 2005, 1570 . 1572 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1573 RFC 3972, DOI 10.17487/RFC3972, March 2005, 1574 . 1576 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 1577 for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, 1578 . 1580 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1581 Extensions for Stateless Address Autoconfiguration in 1582 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 1583 . 1585 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1586 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1587 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1588 Low-Power and Lossy Networks", RFC 6550, 1589 DOI 10.17487/RFC6550, March 2012, 1590 . 1592 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 1593 Interface Identifiers with IPv6 Stateless Address 1594 Autoconfiguration (SLAAC)", RFC 7217, 1595 DOI 10.17487/RFC7217, April 2014, 1596 . 1598 [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets 1599 over ITU-T G.9959 Networks", RFC 7428, 1600 DOI 10.17487/RFC7428, February 2015, 1601 . 1603 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 1604 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 1605 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 1606 . 1608 [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, 1609 "Host Address Availability Recommendations", BCP 204, 1610 RFC 7934, DOI 10.17487/RFC7934, July 2016, 1611 . 1613 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 1614 "Recommendation on Stable IPv6 Interface Identifiers", 1615 RFC 8064, DOI 10.17487/RFC8064, February 2017, 1616 . 1618 [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- 1619 Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, 1620 February 2017, . 1622 [RFC8105] Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt, 1623 M., and D. Barthel, "Transmission of IPv6 Packets over 1624 Digital Enhanced Cordless Telecommunications (DECT) Ultra 1625 Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May 1626 2017, . 1628 [RFC8163] Lynn, K., Ed., Martocci, J., Neilson, C., and S. 1629 Donaldson, "Transmission of IPv6 over Master-Slave/Token- 1630 Passing (MS/TP) Networks", RFC 8163, DOI 10.17487/RFC8163, 1631 May 2017, . 1633 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 1634 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 1635 Explicit Replication (BIER)", RFC 8279, 1636 DOI 10.17487/RFC8279, November 2017, 1637 . 1639 11.4. External Informative References 1641 [IEEEstd802154] 1642 IEEE, "IEEE Standard for Low-Rate Wireless Networks", 1643 IEEE Standard 802.15.4, DOI 10.1109/IEEE 1644 P802.15.4-REVd/D01, June 2017, 1645 . 1647 [Perlman83] 1648 Perlman, R., "Fault-Tolerant Broadcast of Routing 1649 Information", North-Holland Computer Networks 7: 395-405, 1650 1983, . 1653 Appendix A. Applicability and Requirements Served (Not Normative) 1655 This specification extends 6LoWPAN ND to provide a sequence number to 1656 the registration and serves the requirements expressed in 1657 Appendix B.1 by enabling the mobility of devices from one LLN to the 1658 next based on the complementary work in the "IPv6 Backbone Router" 1659 [I-D.ietf-6lo-backbone-router] specification. 1661 In the context of the Timeslotted Channel Hopping (TSCH) mode of IEEE 1662 Std. 802.15.4 [IEEEstd802154], the "6TiSCH architecture" 1663 [I-D.ietf-6tisch-architecture] introduces how a 6LoWPAN ND host could 1664 connect to the Internet via a RPL mesh network, but this requires 1665 additions to the 6LoWPAN ND protocol to support mobility and 1666 reachability in a secured and manageable environment. This 1667 specification details the new operations that are required to 1668 implement the 6TiSCH architecture and serves the requirements listed 1669 in Appendix B.2. 1671 The term LLN is used loosely in this specification to cover multiple 1672 types of WLANs and WPANs, including Low-Power IEEE Std. 802.11 1673 networking, Bluetooth Low Energy, IEEE Std. 802.11ah, and IEEE Std. 1674 802.15.4 wireless meshes, so as to address the requirements discussed 1675 in Appendix B.3. 1677 This specification can be used by any wireless node to associate at 1678 Layer-3 with a 6BBR and register its IPv6 addresses to obtain routing 1679 services including proxy-ND operations over a Backbone Link, 1680 effectively providing a solution to the requirements expressed in 1681 Appendix B.4. 1683 This specification is extended by "Address Protected Neighbor 1684 Discovery for Low-power and Lossy Networks" [I-D.ietf-6lo-ap-nd] to 1685 providing a solution to some of the security-related requirements 1686 expressed in Appendix B.5. 1688 "Efficiency aware IPv6 Neighbor Discovery Optimizations" 1689 [I-D.chakrabarti-nordmark-6man-efficient-nd] suggests that 6LoWPAN ND 1690 [RFC6775] can be extended to other types of links beyond IEEE Std. 1691 802.15.4 for which it was defined. The registration technique is 1692 beneficial when the Link-Layer technique used to carry IPv6 multicast 1693 packets is not sufficiently efficient in terms of delivery ratio or 1694 energy consumption in the end devices, in particular to enable 1695 energy-constrained sleeping nodes. The value of such extension is 1696 especially apparent in the case of mobile wireless nodes, to reduce 1697 the multicast operations that are related to IPv6 ND ([RFC4861], 1698 [RFC4862]) and affect the operation of the wireless medium 1699 [I-D.ietf-mboned-ieee802-mcast-problems] 1700 [I-D.perkins-intarea-multicast-ieee802]. This serves the scalability 1701 requirements listed in Appendix B.6. 1703 Appendix B. Requirements (Not Normative) 1705 This section lists requirements that were discussed by the 6lo WG for 1706 an update to 6LoWPAN ND. How those requirements are matched with 1707 existing specifications at the time of this writing is shown in 1708 Appendix B.8. 1710 B.1. Requirements Related to Mobility 1712 Due to the unstable nature of LLN links, even in an LLN of immobile 1713 nodes, a 6LN may change its point of attachment from 6LR-a to 6LR-b, 1714 and may not be able to notify 6LR-a. Consequently, 6LR-a may still 1715 attract traffic that it cannot deliver any more. When links to a 6LR 1716 change state, there is thus a need to identify stale states in a 6LR 1717 and restore reachability in a timely fashion, e.g., by using some 1718 signaling upon the detection of the movement, or using a keep-alive 1719 mechanism with a period that is consistent with the application 1720 needs. 1722 Req1.1: Upon a change of point of attachment, connectivity via a new 1723 6LR MUST be restored in a timely fashion without the need to de- 1724 register from the previous 6LR. 1726 Req1.2: For that purpose, the protocol MUST enable differentiating 1727 between multiple registrations from one 6LoWPAN Node and 1728 registrations from different 6LoWPAN Nodes claiming the same address. 1730 Req1.3: Stale states MUST be cleaned up in 6LRs. 1732 Req1.4: A 6LoWPAN Node SHOULD also be able to register its Address 1733 concurrently to multiple 6LRs. 1735 B.2. Requirements Related to Routing Protocols 1737 The point of attachment of a 6LN may be a 6LR in an LLN mesh. IPv6 1738 routing in an LLN can be based on RPL, which is the routing protocol 1739 that was defined by the IETF for this particular purpose. Other 1740 routing protocols are also considered by Standards Development 1741 Organizations (SDO) on the basis of the expected network 1742 characteristics. It is required that a 6LN attached via ND to a 6LR 1743 indicates whether it participates in the selected routing protocol to 1744 obtain reachability via the 6LR, or whether it expects the 6LR to 1745 manage its reachability. 1747 Beyond the 6LBR unicast address registered by ND, other addresses 1748 including multicast addresses are needed as well. For example, a 1749 routing protocol often uses a multicast address to register changes 1750 to established paths. ND needs to register such a multicast address 1751 to enable routing concurrently with discovery. 1753 Multicast is needed for groups. Groups may be formed by device type 1754 (e.g., routers, street lamps), location (Geography, RPL sub-tree), or 1755 both. 1757 The Bit Index Explicit Replication (BIER) Architecture [RFC8279] 1758 proposes an optimized technique to enable multicast in an LLN with a 1759 very limited requirement for routing state in the nodes. 1761 Related requirements are: 1763 Req2.1: The ND registration method SHOULD be extended so that the 6LR 1764 is instructed whether to advertise the Address of a 6LN over the 1765 selected routing protocol and obtain reachability to that Address 1766 using the selected routing protocol. 1768 Req2.2: Considering RPL, the Address Registration Option that is used 1769 in the ND registration SHOULD be extended to carry enough information 1770 to generate a DAO message as specified in section 6.4 of [RFC6550], 1771 in particular the capability to compute a Path Sequence and, as an 1772 option, a RPLInstanceID. 1774 Req2.3: Multicast operations SHOULD be supported and optimized, for 1775 instance, using BIER or MPL. Whether ND is appropriate for the 1776 registration to the 6BBR is to be defined, considering the additional 1777 burden of supporting the Multicast Listener Discovery Version 2 1778 [RFC3810] (MLDv2) for IPv6. 1780 B.3. Requirements Related to the Variety of Low-Power Link types 1782 6LoWPAN ND [RFC6775] was defined with a focus on IEEE Std.802.15.4 1783 and in particular the capability to derive a unique identifier from a 1784 globally unique EUI-64 address. At this point, the 6lo Working Group 1785 is extending the 6LoWPAN Header Compression (HC) [RFC6282] technique 1786 to other link types including ITU-T G.9959 [RFC7428], Master-Slave/ 1787 Token-Passing [RFC8163], DECT Ultra Low Energy [RFC8105], Near Field 1788 Communication [I-D.ietf-6lo-nfc], IEEE Std. 802.11ah 1789 [I-D.delcarpio-6lo-wlanah], as well as Bluetooth(R) Low Energy 1790 [RFC7668], and Power Line Communication (PLC) [I-D.hou-6lo-plc] 1791 Networks. 1793 Related requirements are: 1795 Req3.1: The support of the registration mechanism SHOULD be extended 1796 to more LLN links than IEEE Std.802.15.4, matching at least the LLN 1797 links for which an "IPv6 over foo" specification exists, as well as 1798 Low-Power Wi-Fi. 1800 Req3.2: As part of this extension, a mechanism to compute a unique 1801 identifier should be provided, with the capability to form a Link- 1802 Local Address that SHOULD be unique at least within the LLN connected 1803 to a 6LBR discovered by ND in each node within the LLN. 1805 Req3.3: The Address Registration Option used in the ND registration 1806 SHOULD be extended to carry the relevant forms of unique Identifier. 1808 Req3.4: The Neighbor Discovery should specify the formation of a 1809 site-local address that follows the security recommendations from 1810 [RFC7217]. 1812 B.4. Requirements Related to Proxy Operations 1814 Duty-cycled devices may not be able to answer themselves to a lookup 1815 from a node that uses IPv6 ND on a Backbone Link and may need a 1816 proxy. Additionally, the duty-cycled device may need to rely on the 1817 6LBR to perform registration to the 6BBR. 1819 The ND registration method SHOULD defend the addresses of duty-cycled 1820 devices that are sleeping most of the time and not capable to defend 1821 their own addresses. 1823 Related requirements are: 1825 Req4.1: The registration mechanism SHOULD enable a third party to 1826 proxy register an address on behalf of a 6LoWPAN node that may be 1827 sleeping or located deeper in an LLN mesh. 1829 Req4.2: The registration mechanism SHOULD be applicable to a duty- 1830 cycled device regardless of the link type and SHOULD enable a 6BBR to 1831 operate as a proxy to defend the Registered Addresses on its behalf. 1833 Req4.3: The registration mechanism SHOULD enable long sleep 1834 durations, on the order of multiple days to a month. 1836 B.5. Requirements Related to Security 1838 In order to guarantee the operations of the 6LoWPAN ND flows, the 1839 spoofing of the 6LR, 6LBR, and 6BBRs roles should be avoided. Once a 1840 node successfully registers an address, 6LoWPAN ND should provide 1841 energy-efficient means for the 6LBR to protect that ownership even 1842 when the node that registered the address is sleeping. 1844 In particular, the 6LR and the 6LBR then should be able to verify 1845 whether a subsequent registration for a given address comes from the 1846 original node. 1848 In an LLN it makes sense to base security on Layer-2 security. 1849 During bootstrap of the LLN, nodes join the network after 1850 authorization by a Joining Assistant (JA) or a Commissioning Tool 1851 (CT). After joining, nodes communicate with each other via secured 1852 links. The keys for the Layer-2 security are distributed by the JA/ 1853 CT. The JA/CT can be part of the LLN or be outside the LLN. In both 1854 cases it is needed that packets are routed between JA/CT and the 1855 joining node. 1857 Related requirements are: 1859 Req5.1: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for 1860 the 6LR, 6LBR, and 6BBR to authenticate and authorize one another for 1861 their respective roles, as well as with the 6LoWPAN Node for the role 1862 of 6LR. 1864 Req5.2: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for 1865 the 6LR and the 6LBR to validate new registration of authorized 1866 nodes. Joining of unauthorized nodes MUST be prevented. 1868 Req5.3: 6LoWPAN ND security mechanisms SHOULD NOT lead to large 1869 packet sizes. In particular, the NS, NA, DAR, and DAC messages for a 1870 re-registration flow SHOULD NOT exceed 80 octets so as to fit in a 1871 secured IEEE Std.802.15.4 [IEEEstd802154] frame. 1873 Req5.4: Recurrent 6LoWPAN ND security operations MUST NOT be 1874 computationally intensive on the LoWPAN Node CPU. When a Key hash 1875 calculation is employed, a mechanism lighter than SHA-1 SHOULD be 1876 preferred. 1878 Req5.5: The number of Keys that the 6LoWPAN Node needs to manipulate 1879 SHOULD be minimized. 1881 Req5.6: The 6LoWPAN ND security mechanisms SHOULD enable the 1882 variation of CCM [RFC3610] called CCM* for use at both Layer 2 and 1883 Layer 3, and SHOULD enable the reuse of security code that has to be 1884 present on the device for upper layer security such as TLS. 1885 Algorithm agility and support for large keys (e.g., 256-bit key 1886 sizes) is also desirable, following at Layer-3 the introduction of 1887 those capabilities at Layer-2. 1889 Req5.7: Public key and signature sizes SHOULD be minimized while 1890 maintaining adequate confidentiality and data origin authentication 1891 for multiple types of applications with various degrees of 1892 criticality. 1894 Req5.8: Routing of packets should continue when links pass from the 1895 unsecured to the secured state. 1897 Req5.9: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for 1898 the 6LR and the 6LBR to validate whether a new registration for a 1899 given address corresponds to the same 6LN that registered it 1900 initially, and, if not, determine the rightful owner and deny or 1901 clean up the registration that is duplicate. 1903 B.6. Requirements Related to Scalability 1905 Use cases from Automatic Meter Reading (AMR, collection tree 1906 operations) and Advanced Metering Infrastructure (AMI, bi-directional 1907 communication to the meters) indicate the needs for a large number of 1908 LLN nodes pertaining to a single RPL DODAG (e.g., 5000) and connected 1909 to the 6LBR over a large number of LLN hops (e.g., 15). 1911 Related requirements are: 1913 Req6.1: The registration mechanism SHOULD enable a single 6LBR to 1914 register multiple thousands of devices. 1916 Req6.2: The timing of the registration operation should allow for a 1917 large latency such as found in LLNs with ten to more hops. 1919 B.7. Requirements Related to Operations and Management 1921 Section 3.8 of "Architectural Principles of the Internet" [RFC1958] 1922 recommends to: "avoid options and parameters whenever possible. Any 1923 options and parameters should be configured or negotiated dynamically 1924 rather than manually". This is especially true in LLNs where the 1925 number of devices may be large and manual configuration is 1926 infeasible. Capabilities for a dynamic configuration of LLN devices 1927 can also be constrained by the network and power limitation. 1929 A Network Administrator should be able to validate that the network 1930 is operating within capacity, and that in particular a 6LBR does not 1931 get overloaded with an excessive amount of registration, so the 1932 administrator can take actions such as adding a Backbone Link with 1933 additional 6LBRs and 6BBRs to the network. 1935 Related requirements are: 1937 Req7.1: A management model SHOULD be provided that enables access to 1938 the 6LBR, monitor its usage vs. capacity, and alert in case of 1939 congestion. It is recommended that the 6LBR be reachable over a non- 1940 LLN link. 1942 Req7.2: A management model SHOULD be provided that enables access to 1943 the 6LR and its capacity to host additional NCE. This management 1944 model SHOULD avoid polling individual 6LRs in a way that could 1945 disrupt the operation of the LLN. 1947 Req7.3: Information on successful and failed registration SHOULD be 1948 provided, including information such as the ROVR of the 6LN, the 1949 Registered Address, the address of the 6LR, and the duration of the 1950 registration flow. 1952 Req7.4: In case of a failed registration, information on the failure 1953 including the identification of the node that rejected the 1954 registration and the status in the EARO SHOULD be provided. 1956 B.8. Matching Requirements with Specifications 1958 I-drafts/RFCs addressing requirements 1960 +-------------+-----------------------------------------+ 1961 | Requirement | Document | 1962 +-------------+-----------------------------------------+ 1963 | Req1.1 | [I-D.ietf-6lo-backbone-router] | 1964 | | | 1965 | Req1.2 | [RFC6775] | 1966 | | | 1967 | Req1.3 | [RFC6775] | 1968 | | | 1969 | Req1.4 | This RFC | 1970 | | | 1971 | Req2.1 | This RFC | 1972 | | | 1973 | Req2.2 | This RFC | 1974 | | | 1975 | Req2.3 | | 1976 | | | 1977 | Req3.1 | Technology Dependent | 1978 | | | 1979 | Req3.2 | Technology Dependent | 1980 | | | 1981 | Req3.3 | Technology Dependent | 1982 | | | 1983 | Req3.4 | Technology Dependent | 1984 | | | 1985 | Req4.1 | This RFC | 1986 | | | 1987 | Req4.2 | This RFC | 1988 | | | 1989 | Req4.3 | [RFC6775] | 1990 | | | 1991 | Req5.1 | | 1992 | | | 1993 | Req5.2 | [I-D.ietf-6lo-ap-nd] | 1994 | | | 1995 | Req5.3 | | 1996 | | | 1997 | Req5.4 | | 1998 | | | 1999 | Req5.5 | [I-D.ietf-6lo-ap-nd] | 2000 | | | 2001 | Req5.6 | [I-D.struik-lwip-curve-representations] | 2002 | | | 2003 | Req5.7 | [I-D.ietf-6lo-ap-nd] | 2004 | | | 2005 | Req5.8 | | 2006 | | | 2007 | Req5.9 | [I-D.ietf-6lo-ap-nd] | 2008 | | | 2009 | Req6.1 | This RFC | 2010 | | | 2011 | Req6.2 | This RFC | 2012 | | | 2013 | Req7.1 | | 2014 | | | 2015 | Req7.2 | | 2016 | | | 2017 | Req7.3 | | 2018 | | | 2019 | Req7.4 | | 2020 +-------------+-----------------------------------------+ 2022 Table 7: Work Addressing requirements 2024 Authors' Addresses 2026 Pascal Thubert (editor) 2027 Cisco Systems, Inc 2028 Building D (Regus) 45 Allee des Ormes 2029 Mougins - Sophia Antipolis 2030 France 2032 Phone: +33 4 97 23 26 34 2033 Email: pthubert@cisco.com 2035 Erik Nordmark 2036 Zededa 2037 Santa Clara, CA 2038 United States of America 2040 Email: nordmark@sonic.net 2042 Samita Chakrabarti 2043 Verizon 2044 San Jose, CA 2045 United States of America 2047 Email: samitac.ietf@gmail.com 2049 Charles E. Perkins 2050 Futurewei 2051 2330 Central Expressway 2052 Santa Clara 95050 2053 United States of America 2055 Email: charliep@computer.org