idnits 2.17.1 draft-thubert-6lo-unicast-lookup-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The abstract seems to indicate that this document updates RFC8505, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 237 has weird spacing: '...ss side o ...' -- The document date (8 November 2021) is 894 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.thubert-6man-ipv6-over-wireless' is defined on line 626, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-6lo-multicast-registration-01 == Outdated reference: A later version (-24) exists of draft-bi-savi-wlan-21 == Outdated reference: A later version (-15) exists of draft-thubert-6man-ipv6-over-wireless-09 Summary: 0 errors (**), 0 flaws (~~), 6 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 E.L.A. Levy-Abegnoli 4 Intended status: Standards Track Cisco Systems 5 Expires: 12 May 2022 8 November 2021 7 IPv6 Neighbor Discovery Unicast Lookup 8 draft-thubert-6lo-unicast-lookup-02 10 Abstract 12 This document updates RFC 8505 in order to enable unicast address 13 lookup from a 6LoWPAN Border Router acting as an Address Registrar. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on 12 May 2022. 32 Copyright Notice 34 Copyright (c) 2021 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 39 license-info) in effect on the date of publication of this document. 40 Please review these documents carefully, as they describe your rights 41 and restrictions with respect to this document. Code Components 42 extracted from this document must include Simplified BSD License text 43 as described in Section 4.e of the Trust Legal Provisions and are 44 provided without warranty as described in the Simplified BSD License. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 49 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 51 2.2. References . . . . . . . . . . . . . . . . . . . . . . . 4 52 2.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2.4. New Terms . . . . . . . . . . . . . . . . . . . . . . . . 5 54 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 4. Updating RFC 8505 . . . . . . . . . . . . . . . . . . . . . . 7 56 4.1. Extended Neighbor Discovery Options and Messages . . . . 7 57 4.1.1. Extending the Capability Indication Option . . . . . 7 58 4.1.2. New Code Prefix for Address Mapping Messages . . . . 8 59 4.1.3. New ARO Status . . . . . . . . . . . . . . . . . . . 8 60 4.2. Address Mapping Messages . . . . . . . . . . . . . . . . 9 61 4.3. IPv6 ND-based Address Lookup . . . . . . . . . . . . . . 10 62 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 10 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 65 7.1. ICMP Codes . . . . . . . . . . . . . . . . . . . . . . . 11 66 7.2. New ARO Status values . . . . . . . . . . . . . . . . . . 12 67 7.3. New 6LoWPAN Capability Bits . . . . . . . . . . . . . . . 12 68 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 69 9. Normative References . . . . . . . . . . . . . . . . . . . . 12 70 10. Informative References . . . . . . . . . . . . . . . . . . . 13 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 73 1. Introduction 75 [RFC8505] defines the Routing Registrar and extends [RFC6775] to use 76 a 6LoWPAN Border Router (6LBR) as a central service for Address 77 Registration and duplicate detection amongst Routing Registrars and 78 possibly individual Nodes that access it directly. 80 [RFC8929] introduces the Backbone Router (6BBR) as a Routing 81 Registrar that performs IPv6 ND [RFC4861] [RFC4862] proxy operation 82 between IPv6 Nodes on a federating Backbone Link and Registering 83 Nodes attached to a LowPower Lossy Networks (LLNs) that register 84 their addresses to the 6BBR. The federated links form a Multilink 85 Subnet (MLSN). 87 The 6BBRs may exchange Extended Duplicate Address Messages (EDAR and 88 EDAC) [RFC8505] to register the proxied addresses on behalf of the 89 Registering Nodes to the 6LBR. The Registration Ownership Verifier 90 (ROVR) field in the EDAR and EDAC messages is used to correlate 91 attempts to register the same address and to detect duplications. 92 The ROVR can also be used as a proof-of-ownership (see [RFC8928]) to 93 protect the Registered address against theft and impersonation 94 attacks (more in [I-D.bi-savi-wlan]). Conflicting registrations to 95 different 6BBRs for the same Registered address are resolved using 96 the TID field, which creates a temporal order and enables to 97 recognize the freshest registration. 99 With [RFC8929], the Link Layer address (LLA) that the 6BBR advertises 100 for a Registered address on behalf of the Registered Node over the 101 Backbone can belong to the Registering Node; in that case, the 6BBR 102 acts as a Bridging Proxy and bridges the unicast packets. 103 Alternatively, the LLA can be that of the 6BBR on the Backbone 104 interface, in which case the 6BBR acts as a Routing Proxy, that 105 receives the unicast packets at Layer-3 and routes them. The 6BBR 106 signals that LLA in a Source LLA Option (SLLAO) in the EDAR messages 107 to the 6LBR, and the 6LBR responds with a Target LLA Option (TLLAO) 108 that indicates the LLA associated to the current registration. 110 "IPv6 Neighbor Discovery Multicast Address Listener Registration" 111 [I-D.ietf-6lo-multicast-registration] extends [RFC8505] to register 112 anycast and multicast addresses. This entails accepting more than 113 one registration for the same address and the use of the ROVR field 114 as a complement to the index. In that case the 6LBR does not 115 consider multiple registrations as duplicate and retains a state for 116 the anycast addresses that it can use to reply a query. 118 It results that the 6LBR is capable of providing the LLA mapping for 119 any unicast and anycast address that was proactively registered with 120 an SLLAO. This draft defines the protocol elements and the 121 operations to try a unicast Layer-2 lookup with the 6LBR. This may 122 save a reactive IPv6 ND Neighbor Solicitation (NS) message, which is 123 based on multicast and may be problematic in extensive wireless 124 domains (see [I-D.ietf-mboned-ieee802-mcast-problems]) as well as in 125 large switched fabrics. In case of an anycast address, this draft 126 does not provide a policy/ logic to select between multiple 127 registrations. 129 The registration and lookup services that the 6LBR provides do not 130 have to be limited to 6BBRs and are available to any node that 131 supports [RFC8505] and [RFC8929] to register an address, and / or 132 this specification to resolve a mapping. The services are available 133 on-link using an IPv6 NDP NS and off-link using a new variation of 134 the Extended Duplicate Address messages called Address Mapping 135 Messages. The policy and security settings that allow the access to 136 the 6LBR are out of scope. 138 2. Terminology 139 2.1. Requirements Language 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 143 "OPTIONAL" in this document are to be interpreted as described in BCP 144 14 [RFC2119] [RFC8174] when, and only when, they appear in all 145 capitals, as shown here. 147 2.2. References 149 This document uses terms and concepts that are discussed in: 151 * "Neighbor Discovery for IP version 6" [RFC4861] and "IPv6 152 Stateless address Autoconfiguration" [RFC4862], 154 * Neighbor Discovery Optimization for Low-Power and Lossy Networks 155 [RFC6775], as well as 157 * "Registration Extensions for 6LoWPAN Neighbor Discovery" [RFC8505] 158 and "IPv6 Backbone Router" [RFC8929]. 160 2.3. Glossary 162 This document uses the following acronyms: 164 6BBR 6LoWPAN Backbone Router 165 6BBR 6LoWPAN Border Router 166 6LN 6LoWPAN Node 167 6LR 6LoWPAN Router 168 6CIO Capability Indication Option 169 AMC Address Mapping Confirmation 170 AMR Address Mapping Request 171 ARO Address Registration Option 172 DAC Duplicate Address Confirmation 173 DAD Duplicate Address Detection 174 DAR Duplicate Address Request 175 EARO Extended Address Registration Option 176 EDAC Extended Duplicate Address Confirmation 177 EDAR Extended Duplicate Address Request 178 DODAG Destination-Oriented Directed Acyclic Graph 179 LLN Low-Power and Lossy Network 180 NA Neighbor Advertisement 181 NCE Neighbor Cache Entry 182 ND Neighbor Discovery 183 NS Neighbor Solicitation 184 ROVR Registration Ownership Verifier 185 RA Router Advertisement 186 RS Router Solicitation 187 TID Transaction ID 189 2.4. New Terms 191 This document introduces the following terminology: 193 Address Mapping Request An ICMP message with an ICMP type of 157 194 (DAR) and a Code Prefix of 1. 196 Address Mapping Confirm An ICMP message with an ICMP type of 158 197 (DAC) and a Code Prefix of 1. 199 This document uses terminology defined in [RFC8505], in particular: 201 Address Registrar The Address Registrar is an abstract database that 202 is maintained by the 6LBR to store the state associated with its 203 registrations. 205 Address Registration An Address Registration is an abstract state 206 associated to one registration, in other words one entry in the 207 Address Registrar. 209 3. Overview 211 Figure 1 illustrates a Backbone Link that federates a collection of 212 LLNs as a single IPv6 Subnet, with a number of 6BBRs providing proxy- 213 ND services to their attached LLNs. 215 A collection of IPv6 Nodes are present on the Backbone and use IPv6 216 ND [RFC4861][RFC4862] procedures for DAD and Lookup. 218 The LLN may be a hub-and-spoke access link such as (Low-Power) Wi-Fi 219 [IEEE Std 802.11] and Bluetooth (Low Energy) [IEEE Std 802.15.1], or 220 a Route-Over LLN such as the Wi-SUN mesh 221 [I-D.heile-lpwan-wisun-overview] that leverages 6LoWPAN 222 [RFC4919][RFC6282] and RPL [RFC6550] over [IEEE Std 802.15.4]. 224 | 225 | 226 +-----+ +-----+ +-----+ 227 (default) | | 6LBR | | | | IPv6 228 Router | | | | | | Node 229 +-----+ +-----+ +-----+ 230 | Backbone side | | 231 ----+-------+-----------------+---+-------------+----+----- 232 | | | 233 +------+ +------+ +------+ 234 | 6BBR | | 6BBR | | 6BBR | 235 | | | | | | 236 +------+ +------+ +------+ 237 o Wireless side o o o o o 238 o o o o o o o o o o o o o o 239 o o o o o o o o o o o o o o o 240 o o o o o o o o o o 241 o o o o o o o 243 LLN LLN LLN 245 Figure 1: Backbone Link and 6LBR 247 A 6LBR provides registration services for the purpose of proactive 248 IPv6 ND and maintains a registry of the active registrations for 249 unicast and anycast IPv6 addresses as an abstract data structure 250 called an Address Registrar. An entry in the Address Registrar is 251 called an "Address Registration". 253 The Address Registration retains: 255 * the value for the ROVR associated to the registration, the current 256 value of the TID, and the remaining Lifetime. 258 * a list of LLAs that are associated with the IPv6 address and can 259 be used in a TLLAO as a response to a lookup. 261 Examples where more than one address may be available include the 262 case of an anycast address and the case of an LLN address that is 263 proxied by more than one 6BBR. 265 Unless otherwise configured, a 6LBR does the following: 267 * The 6LBR maintains an entry in the Address Registrar for any type 268 of unicast and anycast addresses including those with link-local 269 scope. 271 * Based on that entry, it provides duplicate avoidance services 272 within the scope of its Address Registrar. 274 * The 6LBR also provides address lookup services for the Registered 275 Address using unicast ICMPv6 DAR and DAC-based Address Mapping 276 messages. 278 The Address Mapping messages can be exchanged using global unicast 279 addresses as source and destination addresses, so they can be used 280 for both on-link and off-link queries. NS and NA messages may also 281 be used, but in that case the unicast source and destination 282 addresses are link-local addresses and the 6LBR must be on-link. 284 The 6LBR proactive operations may coexist on the Backbone with 285 reactive IPv6 ND [RFC4861][RFC4862] that rely on multicast for 286 Duplicate Address Detection (DAD) and Address Lookup. Nodes that 287 support this specification operate with the 6LBR before attempting 288 the reactive operation, which may be avoided if the 6LBR is 289 conclusive, either detecting a duplication or returning a mapping. 291 4. Updating RFC 8505 293 This specification leverages the capability to insert IPv6 ND options 294 in the EDAR and EDAC messages that was introduced in [RFC8929]. 296 It extends DAR and DAR ICMP messages for address lookup in 297 Section 4.1.2 that use the same ICMP types as EDAR and EDAC but a 298 different Code Prefix. 300 It also adds a new Status "Not Found" in Section 4.1.3) that 301 indicates that the address being searched is not present in the 302 Address Registrar. 304 A 6LBR signals itself by setting the "B" bit in the 6CIO of the RA 305 messages that it generates [RFC8505]. This specification adds a new 306 "A" bit in the 6CIO to indicate support of address mapping (see 307 Section 4.1.1). 309 4.1. Extended Neighbor Discovery Options and Messages 311 This specification does not introduce new options; it modifies 312 existing options and updates the associated behaviors. 314 4.1.1. Extending the Capability Indication Option 316 This specification defines a new capability bit for use in the 6CIO, 317 as defined by [RFC7400] and extended in[RFC8505] for use in IPv6 ND 318 messages. 320 The new "A" bit indicates that the 6LBR provides address mapping 321 services per this specification. 323 0 1 2 3 324 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 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Type | Length = 1 | Reserved |A|D|L|B|P|E|G| 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Reserved | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 Figure 2: New Capability Bits in the 6CIO 333 Option Fields: 335 Type 36 337 A The 6LBR provides address mapping services. 339 4.1.2. New Code Prefix for Address Mapping Messages 341 The Extended Duplicate Address messages share a common base format 342 defined in section 4.2 of [RFC8505], with the ICMP type respectively 343 set to 157 and 158 that is inherited from the DAR and DAC messages 344 defined in section 4.4 of [RFC6775]. The ICMP Code is split in two 345 4-bit fields, the Code Prefix and the Code Suffix, and the only Code 346 Prefix defined in [RFC8505] is 0, signaling a DAD. 348 The Address Mapping messages use the same values for the ICMP Type as 349 the corresponding Extended Duplicate Address messages. This 350 specification adds the Code Prefix of 1 to signal Address Mapping. 351 ICMP messages with the ICMP type set to 157 or 158, and a Code Prefix 352 of 1 are thus respectively an Address Mapping Request (AMR) and an 353 Address Mapping Confirm (AMC). 355 4.1.3. New ARO Status 357 The Extended Address Registration Option (EARO) is defined in section 358 4.1 of [RFC8505]. It contains a Status field that is common with 359 with the EDAR and EDAC messages defined in section 4.2 of [RFC8505]. 360 This specification defines a new Status "Not Found" as indicated in 361 Table 1 362 +-------+---------------------------------------------------+ 363 | Value | Description | 364 +-------+---------------------------------------------------+ 365 | 0..10 | As defined in [RFC6775] and [RFC8505] | 366 +-------+---------------------------------------------------+ 367 | 11 | Not Found: The address is not present in the | 368 | | Address Registrar (value to be confirmed by IANA) | 369 +-------+---------------------------------------------------+ 371 Table 1: EARO Status 373 The Status of "Not Found" can be used in an NA(EARO) and in an AMC 374 messages as a response to an address lookup operation. 376 4.2. Address Mapping Messages 378 A 6LBR signals that support by setting the "B" bit in the 6CIO of the 379 RA messages that it generates. A 6LBR that supports this 380 specification MUST also set the "A" bit, indicating support of the 381 Address Mapping messages for address lookup. 383 In the Address Mapping flow, the querier IPv6 Node uses an AMR 384 message, which is characterized by an ICMPv6 Type of 157 and a Code 385 Prefix of 1. When used on-link, the AMR message SHOULD carry a SLLAO 386 indicating the LLA of the querier. The Code Suffix MUST be set to 0 387 indicating a ROVR Length of 64 bits. The ROVR, TID and Lifetime 388 fields MUST be set to 0 and ignored by the receiver. 390 The 6LBR MUST respond with an AMC message, which is characterized by 391 an ICMPv6 Type of 158 and a Code Prefix of 1. 393 * If the address is not present in the Address Registrar then the 394 6LBR MUST set the status to "Not Found". The Code Suffix MUST be 395 set to 0 indicating a ROVR Length of 64 bits. The ROVR, TID and 396 Lifetime fields MUST be set to 0 and ignored by the receiver. 398 * Else if the address is present in the Address Registrar then the 399 AMC fields MUST be set from the ROVR, TID and remaining Lifetime 400 values in the Address Registration and the Status MUST be set to 401 0. 403 * If at least one LLA is found in the Address Registration, then the 404 6LBR MUST place one in a TLLAO option in the AMC message. 406 The AMC is sent unicast the 6LBR to the querier. 408 4.3. IPv6 ND-based Address Lookup 410 A 6LBR that is deployed on-link SHOULD provide NS/NA-based services. 411 It signals that support by setting the "L" bit in the 6CIO of the RA 412 messages that it generates, indicating that it is a 6LR [RFC8505]. 414 A 6LBR thus typically sets the "A", the "B", and the "L" bits when 415 attached to a Backbone Link that it serves, as illustrated in 416 Figure 1. In that case, the IPv6 Nodes and 6BBRs can use an NS/NA 417 exchange with the 6LBR for both duplicate detection and lookup 418 services. 420 The NS(Lookup) is sent unicast from link-local address of the querier 421 to the link-local address of the 6LBR. It carries a SLLAO [RFC4861] 422 and it MUST NOT carry an EARO option to avoid the confusion with a 423 registration. 425 The 6LBR MUST respond with an NA message that contains an EARO. 427 * If the address is not present in the Address Registrar then the 428 6LBR MUST set the status to "Not Found". The ROVR, TID and 429 Lifetime fields MUST be set to 0 and ignored by the receiver. 431 * Else if the address is present in the Address Registrar then the 432 EARO fields MUST be set from the ROVR, TID and remaining Lifetime 433 values in the Address Registration and the Status MUST be set to 434 0. 436 * If at least one LLA is found in the Address Registration, then the 437 6LBR MUST place one in a TLLAO option in the NA message. 439 The NA is sent unicast from link-local address of the 6LBR to the 440 link-local address of the querier. 442 5. Backward Compatibility 444 6. Security Considerations 446 This specification extends [RFC8505], and the security section of 447 that document also applies to this document. In particular, the link 448 layer SHOULD be sufficiently protected to prevent rogue access. 450 7. IANA Considerations 452 Note to RFC Editor, to be removed: please replace "This RFC" 453 throughout this document by the RFC number for this specification 454 once it is allocated. 456 IANA is requested to make a number of changes under the "Internet 457 Control Message Protocol version 6 (ICMPv6) Parameters" registry, as 458 follows. 460 7.1. ICMP Codes 462 IANA is requested to create 2 new subregistries of the ICMPv6 "Code" 463 Fields registry, which itself is a subregistry of the Internet 464 Control Message Protocol version 6 (ICMPv6) Parameters for the ICMP 465 codes. 467 The new subregistries relate to the ICMP type 157, Duplicate Address 468 Request (shown in Table 2), and 158, Duplicate Address Confirmation 469 (shown in Table 3), respectively. For those two ICMP types, the ICMP 470 Code field is split into 2 subfields, the "Code Prefix" and the "Code 471 Prefix". The new subregistries relate to the "Code Prefix" portion 472 of the ICMP Code. The range of "Code Prefix" is 0..15 in all cases. 473 The policy is "IETF Review" or "IESG Approval" [RFC8126] for both 474 subregistries. 476 The new subregistries are to be initialized as follows: 478 +-------------+-----------------------------+-------------------+ 479 | Code Prefix | Meaning | Reference | 480 +-------------+-----------------------------+-------------------+ 481 | 0 | Duplicate Address Detection | Duplicate Address | 482 | | | Detection | 483 +-------------+-----------------------------+-------------------+ 484 | 1 | Address Mapping | This RFC | 485 +-------------+-----------------------------+-------------------+ 486 | 2...15 | Duplicate Address Detection | | 487 +-------------+-----------------------------+-------------------+ 489 Table 2: New Code Prefixes for ICMP type 157 DAR message 491 +-------------+-----------------------------+-------------------+ 492 | Code Prefix | Meaning | Reference | 493 +-------------+-----------------------------+-------------------+ 494 | 0 | Duplicate Address Detection | Duplicate Address | 495 | | | Detection | 496 +-------------+-----------------------------+-------------------+ 497 | 1 | Address Mapping | This RFC | 498 +-------------+-----------------------------+-------------------+ 499 | 2...15 | Duplicate Address Detection | | 500 +-------------+-----------------------------+-------------------+ 502 Table 3: New Code Prefixes for ICMP type 158 DAC message 504 7.2. New ARO Status values 506 IANA is requested to make additions to the Address Registration 507 Option Status Values Registry as follows: 509 +----------------+-----------+-----------+ 510 | ARO Status | Meaning | Reference | 511 +----------------+-----------+-----------+ 512 | 11 (suggested) | Not Found | This RFC | 513 +----------------+-----------+-----------+ 515 Table 4: New ARO Status values 517 7.3. New 6LoWPAN Capability Bits 519 IANA is requested to make additions to the Subregistry for "6LoWPAN 520 Capability Bits" as follows: 522 +----------------+--------------------+-----------+ 523 | Capability Bit | Meaning | Reference | 524 +----------------+--------------------+-----------+ 525 | 9 (suggested) | AM Support (A bit) | This RFC | 526 +----------------+--------------------+-----------+ 528 Table 5: New 6LoWPAN Capability Bits 530 8. Acknowledgments 532 9. Normative References 534 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 535 Requirement Levels", BCP 14, RFC 2119, 536 DOI 10.17487/RFC2119, March 1997, 537 . 539 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 540 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 541 DOI 10.17487/RFC4861, September 2007, 542 . 544 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 545 Address Autoconfiguration", RFC 4862, 546 DOI 10.17487/RFC4862, September 2007, 547 . 549 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 550 Bormann, "Neighbor Discovery Optimization for IPv6 over 551 Low-Power Wireless Personal Area Networks (6LoWPANs)", 552 RFC 6775, DOI 10.17487/RFC6775, November 2012, 553 . 555 [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for 556 IPv6 over Low-Power Wireless Personal Area Networks 557 (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November 558 2014, . 560 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 561 Writing an IANA Considerations Section in RFCs", BCP 26, 562 RFC 8126, DOI 10.17487/RFC8126, June 2017, 563 . 565 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 566 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 567 May 2017, . 569 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 570 Perkins, "Registration Extensions for IPv6 over Low-Power 571 Wireless Personal Area Network (6LoWPAN) Neighbor 572 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 573 . 575 [I-D.ietf-6lo-multicast-registration] 576 Thubert, P., "IPv6 Neighbor Discovery Multicast Address 577 Listener Registration", Work in Progress, Internet-Draft, 578 draft-ietf-6lo-multicast-registration-01, 22 October 2021, 579 . 582 10. Informative References 584 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 585 over Low-Power Wireless Personal Area Networks (6LoWPANs): 586 Overview, Assumptions, Problem Statement, and Goals", 587 RFC 4919, DOI 10.17487/RFC4919, August 2007, 588 . 590 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 591 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 592 DOI 10.17487/RFC6282, September 2011, 593 . 595 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 596 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 597 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 598 Low-Power and Lossy Networks", RFC 6550, 599 DOI 10.17487/RFC6550, March 2012, 600 . 602 [RFC8928] Thubert, P., Ed., Sarikaya, B., Sethi, M., and R. Struik, 603 "Address-Protected Neighbor Discovery for Low-Power and 604 Lossy Networks", RFC 8928, DOI 10.17487/RFC8928, November 605 2020, . 607 [RFC8929] Thubert, P., Ed., Perkins, C.E., and E. Levy-Abegnoli, 608 "IPv6 Backbone Router", RFC 8929, DOI 10.17487/RFC8929, 609 November 2020, . 611 [I-D.ietf-mboned-ieee802-mcast-problems] 612 Perkins, C. E., McBride, M., Stanley, D., Kumari, W., and 613 J. C. Zuniga, "Multicast Considerations over IEEE 802 614 Wireless Media", Work in Progress, Internet-Draft, draft- 615 ietf-mboned-ieee802-mcast-problems-15, 28 July 2021, 616 . 619 [I-D.bi-savi-wlan] 620 Bi, J., Wu, J., Lin, T., and Y. Wang, "A SAVI Solution for 621 WLAN", Work in Progress, Internet-Draft, draft-bi-savi- 622 wlan-21, 10 May 2021, 623 . 626 [I-D.thubert-6man-ipv6-over-wireless] 627 Thubert, P., "IPv6 Neighbor Discovery on Wireless 628 Networks", Work in Progress, Internet-Draft, draft- 629 thubert-6man-ipv6-over-wireless-09, 17 May 2021, 630 . 633 [I-D.heile-lpwan-wisun-overview] 634 Heile, B., (Remy), B. L., Zhang, M., and C. E. Perkins, 635 "Wi-SUN FAN Overview", Work in Progress, Internet-Draft, 636 draft-heile-lpwan-wisun-overview-00, 3 July 2017, 637 . 640 [IEEE Std 802.15.4] 641 IEEE standard for Information Technology, "IEEE Std 642 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 643 and Physical Layer (PHY) Specifications for Low-Rate 644 Wireless Personal Area Networks". 646 [IEEE Std 802.11] 647 IEEE standard for Information Technology, "IEEE Standard 648 802.11 - IEEE Standard for Information Technology - 649 Telecommunications and information exchange between 650 systems Local and metropolitan area networks - Specific 651 requirements - Part 11: Wireless LAN Medium Access Control 652 (MAC) and Physical Layer (PHY) Specifications.", 653 . 655 [IEEE Std 802.15.1] 656 IEEE standard for Information Technology, "IEEE Standard 657 for Information Technology - Telecommunications and 658 Information Exchange Between Systems - Local and 659 Metropolitan Area Networks - Specific Requirements. - Part 660 15.1: Wireless Medium Access Control (MAC) and Physical 661 Layer (PHY) Specifications for Wireless Personal Area 662 Networks (WPANs)". 664 Authors' Addresses 666 Pascal Thubert (editor) 667 Cisco Systems, Inc 668 Building D 669 45 Allee des Ormes - BP1200 670 06254 Mougins - Sophia Antipolis 671 France 673 Phone: +33 497 23 26 34 674 Email: pthubert@cisco.com 676 Eric Levy-Abegnoli 677 Cisco Systems, Inc 678 Building D 679 45 Allee des Ormes - BP1200 680 06254 MOUGINS - Sophia Antipolis 681 France 683 Phone: +33 497 23 26 20 684 Email: elevyabe@cisco.com