idnits 2.17.1 draft-thubert-6man-unicast-lookup-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 254 has weird spacing: '...ss side o ...' -- The document date (July 29, 2019) is 1732 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) == Outdated reference: A later version (-24) exists of draft-bi-savi-wlan-17 == Outdated reference: A later version (-23) exists of draft-ietf-6lo-ap-nd-12 == Outdated reference: A later version (-20) exists of draft-ietf-6lo-backbone-router-11 == Outdated reference: A later version (-15) exists of draft-ietf-mboned-ieee802-mcast-problems-07 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6man P. Thubert, Ed. 3 Internet-Draft E. Levy-Abegnoli 4 Updates: 8505 (if approved) Cisco Systems 5 Intended status: Standards Track July 29, 2019 6 Expires: January 30, 2020 8 IPv6 Neighbor Discovery Unicast Lookup 9 draft-thubert-6man-unicast-lookup-00 11 Abstract 13 This document updates RFC 8505 in order to enable unicast address 14 lookup from a 6LoWPAN Border Router acting as an Address Registrar. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on January 30, 2020. 33 Copyright Notice 35 Copyright (c) 2019 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.2. References . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.3. New Terms . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2.4. Acronym Definitions . . . . . . . . . . . . . . . . . . . 4 56 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 4. Updating RFC 8505 . . . . . . . . . . . . . . . . . . . . . . 7 58 4.1. Extended Neighbor Discovery Options and Messages . . . . 7 59 4.1.1. Extending the Capability Indication Option . . . . . 8 60 4.1.2. New Code Prefix for Address Mapping Messages . . . . 8 61 4.1.3. New ARO Status . . . . . . . . . . . . . . . . . . . 8 62 4.2. Address Mapping Messages . . . . . . . . . . . . . . . . 9 63 4.3. IPv6 ND-based Address Lookup . . . . . . . . . . . . . . 10 64 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 10 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 67 7.1. ICMP Codes . . . . . . . . . . . . . . . . . . . . . . . 11 68 7.2. New ARO Status values . . . . . . . . . . . . . . . . . . 11 69 7.3. New 6LoWPAN Capability Bits . . . . . . . . . . . . . . . 12 70 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 73 9.2. Informative References . . . . . . . . . . . . . . . . . 13 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 76 1. Introduction 78 [RFC8505] defines the Routing Registrar and extends [RFC6775] to use 79 a 6LoWPAN Border Router (6LBR) as a central service for Address 80 Registration and duplicate detection amongst Routing Registrars and 81 possibly individual Nodes that access it directly. 83 [I-D.ietf-6lo-backbone-router] introduces the Backbone Router (6BBR) 84 as a Routing Registrar that performs IPv6 ND [RFC4861] [RFC4862] 85 proxy operation between IPv6 Nodes on a federating Backbone Link and 86 Registering Nodes attached to a LowPower Lossy Networks (LLNs) that 87 register their addresses to the 6BBR. The federated links form a 88 Multilink Subnet (MLSN). 90 The 6BBRs may exchange Extended Duplicate Address Messages (EDAR and 91 EDAC) [RFC8505] to register the proxied addresses on behalf of the 92 Registering Nodes to the 6LBR. The Registration Ownership Verifier 93 (ROVR) field in the EDAR and EDAC messages is used to correlate 94 attempts to register the same address and to detect duplications. 95 The ROVR can also be used as a proof-of-ownership (see 97 [I-D.ietf-6lo-ap-nd]) to protect the Registered address against theft 98 and impersonation attacks (more in [I-D.bi-savi-wlan]). Conflicting 99 registrations to different 6BBRs for the same Registered address are 100 resolved using the TID field, which creates a temporal order and 101 enables to recognize the freshest registration. 103 With [I-D.ietf-6lo-backbone-router], the Link Layer address (LLA) 104 that the 6BBR advertises for a Registered address on behalf of the 105 Registered Node over the Backbone can belong to the Registering Node; 106 in that case, the 6BBR acts as a Bridging Proxy and bridges the 107 unicast packets. Alternatively, the LLA can be that of the 6BBR on 108 the Backbone interface, in which case the 6BBR acts as a Routing 109 Proxy, that receives the unicast packets at Layer-3 and routes them. 110 The 6BBR signals that LLA in a Source LLA Option (SLLAO) in the EDAR 111 messages to the 6LBR, and the 6LBR responds with a Target LLA Option 112 (TLLAO) that indicates the LLA associated to the current 113 registration. 115 It results that the 6LBR is capable of providing the LLA mapping for 116 any address that was proactively registered with an SLLAO. This 117 draft defines the protocol elements and the operations to try a 118 unicast lookup with the 6LBR. This may save a reactive IPv6 ND 119 Neighbor Solicitation (NS) message, which is based on multicast and 120 may be problematic in extensive wireless domains (see 121 [I-D.ietf-mboned-ieee802-mcast-problems]) as well as in large 122 switched fabrics. 124 The registration and lookup services that the 6LBR provides do not 125 have to be limited to 6BBRs and are available to any node that 126 supports [RFC8505] and [I-D.ietf-6lo-backbone-router] to register an 127 address, and / or this specification to resolve a mapping. The 128 services are available on-link using an IPv6 NDP NS and off-link 129 using a new variation of the Extended Duplicate Address messages 130 called Address Mapping Messages. The policy and security settings 131 that allow the access to the 6LBR are out of scope. 133 2. Terminology 135 2.1. BCP 14 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 139 "OPTIONAL" in this document are to be interpreted as described in BCP 140 14 [RFC2119] [RFC8174] when, and only when, they appear in all 141 capitals, as shown here. 143 2.2. References 145 This document uses terms and concepts that are discussed in: 147 o "Neighbor Discovery for IP version 6" [RFC4861] and "IPv6 148 Stateless address Autoconfiguration" [RFC4862], 150 o Neighbor Discovery Optimization for Low-Power and Lossy Networks 151 [RFC6775], as well as 153 o "Registration Extensions for 6LoWPAN Neighbor Discovery" [RFC8505] 154 and "IPv6 Backbone Router" [I-D.ietf-6lo-backbone-router]. 156 2.3. New Terms 158 This document introduces the following terminology: 160 Address Mapping Request 162 An ICMP message with an ICMP type of 157 (DAR) and a Code 163 Prefix of 1. 165 Address Mapping Confirm 167 An ICMP message with an ICMP type of 158 (DAC) and a Code 168 Prefix of 1. 170 Address Registrar 172 The Address Registrar is an abstract database that is 173 maintained by the 6LBR to store the state associated with its 174 registrations. 176 Address Registration 178 An Address Registration is an abstract state associated to one 179 registration, in other words one entry in the Address 180 Registrar. 182 2.4. Acronym Definitions 184 This document uses the following acronyms: 186 6BBR: 6LoWPAN Backbone Router 188 6LBR: 6LoWPAN Border Router 190 6LR: 6LoWPAN Router 191 6CIO: Capability Indication Option 193 AMC: Address Mapping Confirmation 195 AMR: Address Mapping Request 197 ARO: Address Registration Option 199 DAC: Duplicate Address Confirmation 201 DAD: Duplicate Address Detection 203 DAR: Duplicate Address Request 205 EDAC: Extended Duplicate Address Confirmation 207 EDAR: Extended Duplicate Address Request 209 DODAG: Destination-Oriented Directed Acyclic Graph 211 LLN: Low-Power and Lossy Network 213 NA: Neighbor Advertisement 215 NCE: Neighbor Cache Entry 217 ND: Neighbor Discovery 219 NS: Neighbor Solicitation 221 ROVR: Registration Ownership Verifier 223 RA: Router Advertisement 225 RS: Router Solicitation 227 TID: Transaction ID 229 3. Overview 231 Figure 1 illustrates a Backbone Link that federates a collection of 232 LLNs as a single IPv6 Subnet, with a number of 6BBRs providing proxy- 233 ND services to their attached LLNs. 235 A collection of IPv6 Nodes are present on the Backbone and use IPv6 236 ND [RFC4861][RFC4862] procedures for DAD and Lookup. 238 The LLN may be a hub-and-spoke access link such as (Low-Power) IEEE 239 STD. 802.11 (Wi-Fi) [IEEEstd80211] and IEEE STD. 802.15.1 (Bluetooth) 240 [IEEEstd802151], or a Mesh-Under or a Route-Over network [RFC8505]. 242 | 243 +-----+ +-----+ +-----+ 244 (default) | | 6LBR | | | | IPv6 245 Router | | | | | | Node 246 +-----+ +-----+ +-----+ 247 | Backbone side | | 248 ----+-------+-----------------+---+-------------+----+----- 249 | | | 250 +------+ +------+ +------+ 251 | 6BBR | | 6BBR | | 6BBR | 252 | | | | | | 253 +------+ +------+ +------+ 254 o Wireless side o o o o o 255 o o o o o o o o o o o o o o 256 o o o o o o o o o o o o o o o 257 o o o o o o o o o o 258 o o o o o o o 260 LLN LLN LLN 262 Figure 1: Backbone Link and 6LBR 264 A 6LBR provides registration services for the purpose of proactive 265 IPv6 ND and maintains a registry of the active registrations as an 266 abstract data structure called an Address Registrar. An entry in the 267 Address Registrar is called an "Address Registration". 269 The Address Registration retains: 271 o the value for the ROVR associated to the registration, the current 272 value of the TID, and the remaining Lifetime. 274 o a list of LLAs that are associated with the IPv6 address and can 275 be used in a TLLAO as a response to a lookup. 277 Examples where more than one address may be available include the 278 case of an anycast address and the case of an LLN address that is 279 proxied by more than one 6BBR. 281 Unless otherwise configured, a 6LBR does the following: 283 o The 6LBR maintains an entry in the Address Registrar for any type 284 of unicast and anycast addresses including those with link-local 285 scope. 287 o Based on that entry, it provides duplicate avoidance services 288 within the scope of its Address Registrar. 290 o The 6LBR also provides address lookup services for the Registered 291 Address using unicast ICMPv6 DAR and DAC-based Address Mapping 292 messages. 294 The Address Mapping messages can be exchanged using global unicast 295 addresses as source and destination addresses, so they can be used 296 for both on-link and off-link queries. NS and NA messages may also 297 be used, but in that case the unicast source and destination 298 addresses are link-local addresses and the 6LBR must be on-link. 300 The 6LBR proactive operations may coexist on the Backbone with 301 reactive IPv6 ND [RFC4861][RFC4862] that rely on multicast for 302 Duplicate Address Detection (DAD) and Address Lookup. Nodes that 303 support this specification operate with the 6LBR before attempting 304 the reactive operation, which may be avoided if the 6LBR is 305 conclusive, either detecting a duplication or returning a mapping. 307 4. Updating RFC 8505 309 This specification leverages the capability to insert IPv6 ND options 310 in the EDAR and EDAC messages that was introduced in 311 [I-D.ietf-6lo-backbone-router]. 313 It extends DAR and DAR ICMP messages for address lookup in 314 Section 4.1.2 that use the same ICMP types as EDAR and EDAC but a 315 different Code Prefix. 317 It also adds a new Status "Not Found" in Section 4.1.3) that 318 indicates that the address being searched is not present in the 319 Address Registrar. 321 A 6LBR signals itself by setting the "B" bit in the 6CIO of the RA 322 messages that it generates [RFC8505]. This specification adds a new 323 "A" bit in the 6CIO to indicate support of address mapping (see 324 Section 4.1.1). 326 4.1. Extended Neighbor Discovery Options and Messages 328 This specification does not introduce new options; it modifies 329 existing options and updates the associated behaviors. 331 4.1.1. Extending the Capability Indication Option 333 This specification defines a new capability bit for use in the 6CIO, 334 as defined by [RFC7400] and extended in[RFC8505] for use in IPv6 ND 335 messages. 337 The new "A" bit indicates that the 6LBR provides address mapping 338 services per this specification. 340 0 1 2 3 341 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 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Type | Length = 1 | Reserved |A|D|L|B|P|E|G| 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Reserved | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 Figure 2: New Capability Bits in the 6CIO 350 Option Fields: 352 Type: 36 354 A: The 6LBR provides address mapping services. 356 4.1.2. New Code Prefix for Address Mapping Messages 358 The Extended Duplicate Address messages share a common base format 359 defined in section 4.2 of [RFC8505], with the ICMP type respectively 360 set to 157 and 158 that is inherited from the DAR and DAC messages 361 defined in section 4.4 of [RFC6775]. The ICMP Code is split in two 362 4-bit fields, the Code Prefix and the Code Suffix, and the only Code 363 Prefix defined in [RFC8505] is 0, signaling a DAD. 365 The Address Mapping messages use the same values for the ICMP Type as 366 the corresponding Extended Duplicate Address messages. This 367 specification adds the Code Prefix of 1 to signal Address Mapping. 368 ICMP messages with the ICMP type set to 157 or 158, and a Code Prefix 369 of 1 are thus respectively an Address Mapping Request (AMR) and an 370 Address Mapping Confirm (AMC). 372 4.1.3. New ARO Status 374 The Extended Address Registration Option (EARO) is defined in section 375 4.1 of [RFC8505]. It contains a Status field that is common with 376 with the EDAR and EDAC messages defined in section 4.2 of [RFC8505]. 378 This specification defines a new Status "Not Found" as indicated in 379 Table 1 381 +-------+-----------------------------------------------------------+ 382 | Value | Description | 383 +-------+-----------------------------------------------------------+ 384 | 0..10 | As defined in [RFC6775] and [RFC8505]. | 385 | 11 | Not Found: The address is not present in the Address | 386 | | Registrar (value to be confirmed by IANA) | 387 +-------+-----------------------------------------------------------+ 389 Table 1: EARO Status 391 The Status of "Not Found" can be used in an NA(EARO) and in an AMC 392 messages as a response to an address lookup operation. 394 4.2. Address Mapping Messages 396 A 6LBR signals that support by setting the "B" bit in the 6CIO of the 397 RA messages that it generates. A 6LBR that supports this 398 specification MUST also set the "A" bit, indicating support of the 399 Address Mapping messages for address lookup. 401 In the Address Mapping flow, the querier IPv6 Node uses an AMR 402 message, which is characterized by an ICMPv6 Type of 157 and a Code 403 Prefix of 1. When used on-link, the AMR message SHOULD carry a SLLAO 404 indicating the LLA of the querier. The Code Suffix MUST be set to 0 405 indicating a ROVR Length of 64 bits. The ROVR, TID and Lifetime 406 fields MUST be set to 0 and ignored by the receiver. 408 The 6LBR MUST respond with an AMC message, which is characterized by 409 an ICMPv6 Type of 158 and a Code Prefix of 1. 411 o If the address is not present in the Address Registrar then the 412 6LBR MUST set the status to "Not Found". The Code Suffix MUST be 413 set to 0 indicating a ROVR Length of 64 bits. The ROVR, TID and 414 Lifetime fields MUST be set to 0 and ignored by the receiver. 416 o Else if the address is present in the Address Registrar then the 417 AMC fields MUST be set from the ROVR, TID and remaining Lifetime 418 values in the Address Registration and the Status MUST be set to 419 0. 421 o If at least one LLA is found in the Address Registration, then the 422 6LBR MUST place one in a TLLAO option in the AMC message. 424 The AMC is sent unicast the 6LBR to the querier. 426 4.3. IPv6 ND-based Address Lookup 428 A 6LBR that is deployed on-link SHOULD provide NS/NA-based services. 429 It signals that support by setting the "L" bit in the 6CIO of the RA 430 messages that it generates, indicating that it is a 6LR [RFC8505]. 432 A 6LBR thus typically sets the "A", the "B", and the "L" bits when 433 attached to a Backbone Link that it serves, as illustrated in 434 Figure 1. In that case, the IPv6 Nodes and 6BBRs can use an NS/NA 435 exchange with the 6LBR for both duplicate detection and lookup 436 services. 438 The NS(Lookup) is sent unicast from link-local address of the querier 439 to the link-local address of the 6LBR. It carries a SLLAO [RFC4861] 440 and it MUST NOT carry an EARO option to avoid the confusion with a 441 registration. 443 The 6LBR MUST respond with an NA message that contains an EARO. 445 o If the address is not present in the Address Registrar then the 446 6LBR MUST set the status to "Not Found". The ROVR, TID and 447 Lifetime fields MUST be set to 0 and ignored by the receiver. 449 o Else if the address is present in the Address Registrar then the 450 EARO fields MUST be set from the ROVR, TID and remaining Lifetime 451 values in the Address Registration and the Status MUST be set to 452 0. 454 o If at least one LLA is found in the Address Registration, then the 455 6LBR MUST place one in a TLLAO option in the NA message. 457 The NA is sent unicast from link-local address of the 6LBR to the 458 link-local address of the querier. 460 5. Backward Compatibility 462 6. Security Considerations 464 This specification extends [RFC8505], and the security section of 465 that document also applies to this document. In particular, the link 466 layer SHOULD be sufficiently protected to prevent rogue access. 468 7. IANA Considerations 470 Note to RFC Editor, to be removed: please replace "This RFC" 471 throughout this document by the RFC number for this specification 472 once it is allocated. 474 IANA is requested to make a number of changes under the "Internet 475 Control Message Protocol version 6 (ICMPv6) Parameters" registry, as 476 follows. 478 7.1. ICMP Codes 480 IANA is requested to create 2 new subregistries of the ICMPv6 "Code" 481 Fields registry, which itself is a subregistry of the Internet 482 Control Message Protocol version 6 (ICMPv6) Parameters for the ICMP 483 codes. 485 The new subregistries relate to the ICMP type 157, Duplicate Address 486 Request (shown in Table 2), and 158, Duplicate Address Confirmation 487 (shown in Table 3), respectively. For those two ICMP types, the ICMP 488 Code field is split into 2 subfields, the "Code Prefix" and the "Code 489 Prefix". The new subregistries relate to the "Code Prefix" portion 490 of the ICMP Code. The range of "Code Prefix" is 0..15 in all cases. 491 The policy is "IETF Review" or "IESG Approval" [RFC8126] for both 492 subregistries. 494 The new subregistries are to be initialized as follows: 496 +--------------+-----------------------------+------------+ 497 | Code Prefix | Meaning | Reference | 498 +--------------+-----------------------------+------------+ 499 | 0 | Duplicate Address Detection | RFC 6775 | 500 | 1 | Address Mapping | This RFC | 501 | 2...15 | Unassigned | | 502 +--------------+-----------------------------+------------+ 504 Table 2: New Code Prefixes for ICMP type 157 DAR message 506 +--------------+-----------------------------+------------+ 507 | Code Prefix | Meaning | Reference | 508 +--------------+-----------------------------+------------+ 509 | 0 | Duplicate Address Detection | RFC 6775 | 510 | 1 | Address Mapping | This RFC | 511 | 2...15 | Unassigned | | 512 +--------------+-----------------------------+------------+ 514 Table 3: New Code Prefixes for ICMP type 158 DAC message 516 7.2. New ARO Status values 518 IANA is requested to make additions to the Address Registration 519 Option Status Values Registry as follows: 521 +-------------+--------------+-----------+ 522 | ARO Status | Description | Document | 523 +-------------+--------------+-----------+ 524 | 11 | Not Found | This RFC | 525 +-------------+--------------+-----------+ 527 Table 4: New ARO Status values 529 7.3. New 6LoWPAN Capability Bits 531 IANA is requested to make additions to the Subregistry for "6LoWPAN 532 Capability Bits" as follows: 534 +-----------------+---------------------+-----------+ 535 | Capability Bit | Description | Document | 536 +-----------------+---------------------+-----------+ 537 | 9 | AM Support (A bit) | This RFC | 538 +-----------------+---------------------+-----------+ 540 Table 5: New 6LoWPAN Capability Bits 542 8. Acknowledgments 544 9. References 546 9.1. Normative References 548 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 549 Requirement Levels", BCP 14, RFC 2119, 550 DOI 10.17487/RFC2119, March 1997, 551 . 553 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 554 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 555 DOI 10.17487/RFC4861, September 2007, 556 . 558 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 559 Address Autoconfiguration", RFC 4862, 560 DOI 10.17487/RFC4862, September 2007, 561 . 563 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 564 Bormann, "Neighbor Discovery Optimization for IPv6 over 565 Low-Power Wireless Personal Area Networks (6LoWPANs)", 566 RFC 6775, DOI 10.17487/RFC6775, November 2012, 567 . 569 [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for 570 IPv6 over Low-Power Wireless Personal Area Networks 571 (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November 572 2014, . 574 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 575 Writing an IANA Considerations Section in RFCs", BCP 26, 576 RFC 8126, DOI 10.17487/RFC8126, June 2017, 577 . 579 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 580 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 581 May 2017, . 583 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 584 Perkins, "Registration Extensions for IPv6 over Low-Power 585 Wireless Personal Area Network (6LoWPAN) Neighbor 586 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 587 . 589 9.2. Informative References 591 [I-D.bi-savi-wlan] 592 Bi, J., Wu, J., Wang, Y., and T. Lin, "A SAVI Solution for 593 WLAN", draft-bi-savi-wlan-17 (work in progress), May 2019. 595 [I-D.ietf-6lo-ap-nd] 596 Thubert, P., Sarikaya, B., Sethi, M., and R. Struik, 597 "Address Protected Neighbor Discovery for Low-power and 598 Lossy Networks", draft-ietf-6lo-ap-nd-12 (work in 599 progress), April 2019. 601 [I-D.ietf-6lo-backbone-router] 602 Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 603 Backbone Router", draft-ietf-6lo-backbone-router-11 (work 604 in progress), February 2019. 606 [I-D.ietf-mboned-ieee802-mcast-problems] 607 Perkins, C., McBride, M., Stanley, D., Kumari, W., and J. 608 Zuniga, "Multicast Considerations over IEEE 802 Wireless 609 Media", draft-ietf-mboned-ieee802-mcast-problems-07 (work 610 in progress), July 2019. 612 [IEEEstd80211] 613 IEEE standard for Information Technology, "IEEE Standard 614 for Information technology -- Telecommunications and 615 information exchange between systems Local and 616 metropolitan area networks-- Specific requirements Part 617 11: Wireless LAN Medium Access Control (MAC) and Physical 618 Layer (PHY) Specifications". 620 [IEEEstd802151] 621 IEEE standard for Information Technology, "IEEE Standard 622 for Information Technology - Telecommunications and 623 Information Exchange Between Systems - Local and 624 Metropolitan Area Networks - Specific Requirements. - Part 625 15.1: Wireless Medium Access Control (MAC) and Physical 626 Layer (PHY) Specifications for Wireless Personal Area 627 Networks (WPANs)". 629 Authors' Addresses 631 Pascal Thubert (editor) 632 Cisco Systems, Inc 633 Building D 634 45 Allee des Ormes - BP1200 635 MOUGINS - Sophia Antipolis 06254 636 FRANCE 638 Phone: +33 497 23 26 34 639 Email: pthubert@cisco.com 641 Eric Levy-Abegnoli 642 Cisco Systems, Inc 643 Building D 644 45 Allee des Ormes - BP1200 645 MOUGINS - Sophia Antipolis 06254 646 FRANCE 648 Phone: +33 497 23 26 20 649 Email: elevyabe@cisco.com