idnits 2.17.1 draft-thubert-6man-ipv6-over-wireless-11.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 (15 December 2021) is 863 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-21) exists of draft-ietf-rift-rift-13 == Outdated reference: A later version (-24) exists of draft-bi-savi-wlan-22 == Outdated reference: A later version (-18) exists of draft-ietf-6lo-multicast-registration-03 Summary: 0 errors (**), 0 flaws (~~), 4 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 Cisco Systems 4 Intended status: Informational 15 December 2021 5 Expires: 18 June 2022 7 IPv6 Neighbor Discovery on Wireless Networks 8 draft-thubert-6man-ipv6-over-wireless-11 10 Abstract 12 This document describes how the original IPv6 Neighbor Discovery and 13 Wireless ND (WiND) can be applied on various abstractions of wireless 14 media. 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 18 June 2022. 33 Copyright Notice 35 Copyright (c) 2021 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 (https://trustee.ietf.org/ 40 license-info) in effect on the date of publication of this document. 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. Code Components 43 extracted from this document must include Revised BSD License text as 44 described in Section 4.e of the Trust Legal Provisions and are 45 provided without warranty as described in the Revised BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 2.1. IP Links . . . . . . . . . . . . . . . . . . . . . . . . 4 52 2.2. IP Subnets . . . . . . . . . . . . . . . . . . . . . . . 5 53 2.3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 6 54 3. ND-Classic, Wireless ND and ND-Proxies . . . . . . . . . . . 6 55 4. IP Models . . . . . . . . . . . . . . . . . . . . . . . . . . 8 56 4.1. Physical Broadcast Domain . . . . . . . . . . . . . . . . 8 57 4.2. link-layer Broadcast Emulations . . . . . . . . . . . . . 9 58 4.3. Mapping the IPv6 link Abstraction . . . . . . . . . . . . 11 59 4.4. Mapping the IPv6 subnet Abstraction . . . . . . . . . . . 12 60 5. Wireless Neighbor Discovery . . . . . . . . . . . . . . . . . 13 61 5.1. Introduction to Stateful Address Autoconfiguration . . . 13 62 5.2. links and Link-Local Addresses . . . . . . . . . . . . . 14 63 5.3. Subnets and Global Addresses . . . . . . . . . . . . . . 15 64 5.4. Anycast and Multicast Addresses . . . . . . . . . . . . . 15 65 6. WiND Applicability . . . . . . . . . . . . . . . . . . . . . 16 66 6.1. Case of LPWANs . . . . . . . . . . . . . . . . . . . . . 17 67 6.2. Case of Infrastructure BSS and ESS . . . . . . . . . . . 17 68 6.3. Case of Mesh Under Technologies . . . . . . . . . . . . . 18 69 6.4. Case of DMB radios . . . . . . . . . . . . . . . . . . . 18 70 6.4.1. Using ND-Classic only . . . . . . . . . . . . . . . . 19 71 6.4.2. Using Wireless ND . . . . . . . . . . . . . . . . . . 19 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 74 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 75 10. Normative References . . . . . . . . . . . . . . . . . . . . 22 76 11. Informative References . . . . . . . . . . . . . . . . . . . 23 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26 79 1. Introduction 81 IEEE Std. 802.1 [IEEE Std. 802.1] Ethernet Bridging provides an 82 efficient and reliable broadcast service for wired networks; 83 applications and protocols have been built that heavily depend on 84 that feature for their core operation. Unfortunately, Low-Power 85 Lossy Networks (LLNs) and Wireless Local Area Networks (WLANs) 86 generally do not benefit from the same reliable and cheap broadcast 87 capabilities as Ethernet links. 89 As opposed to unicast transmissions, the broadcast transmissions over 90 wireless links are not subject to automatic retries (ARQ) and can be 91 very unreliable. Reducing the speed at the physical (PHY) layer for 92 broadcast transmissions can increase the reliability, at the expense 93 of a higher relative cost of broadcast on the overall available 94 bandwidth. As a result, protocols designed for bridged networks that 95 rely on broadcast transmissions often exhibit disappointing 96 behaviours when employed unmodified on a local wireless medium (see 97 [MCAST PROBLEMS]). 99 Like Transparent Bridging, the IPv6 [RFC8200] Neighbor Discovery 100 [RFC4861] [RFC4862] Protocol (ND-Classic) is reactive, and relies on 101 on-demand Network Layer multicast to locate an on-link correspondent 102 (Address Resolution, AR) and ensure the uniqueness of an IPv6 address 103 (Duplicate Address Detection, aka DAD) in the case of Stateless 104 Address Autoconfiguration (SLAAC). On Ethernet LANs and most WLANs 105 and Low-Power Personal Area Networks (LoWPANs), the Network Layer 106 multicast operation is typically implemented as a link-layer 107 broadcast for the lack of an adapted and scalable link-layer 108 multicast operation. 110 It results that on wireless, an ND-Classic multicast message is 111 typically broadcasted. So even though there are very few nodes 112 subscribed to the Network Layer multicast group, and there is at most 113 one intended Target, the broadcast is received by many wireless nodes 114 over the whole subnet (e.g., the ESS fabric). And yet, the broadcast 115 transmission being unreliable, the intended Target may effectively 116 have missed the packet. 118 On paper, a Wi-Fi station must keep its radio turned on to listen to 119 the periodic series of broadcast frames, which for the most part will 120 be dropped when they reach Network Layer. In order to avoid this 121 waste of energy and increase its battery life, a typical battery- 122 operated device such as an IoT sensor or a smartphone will blindly 123 ignore a ratio of the broadcasts, making ND-Classic operations even 124 less reliable. 126 Wi-Fi [IEEE Std. 802.11] Access Points (APs) deployed in an Extended 127 Service Set (ESS) act as [IEEE Std. 802.1] bridges between the 128 wireless stations (STA) and the wired backbone. As opposed to the 129 classical Transparent (aka Learning) Bridge operation that installs 130 the forwarding state reactively to traffic, the bridging state in the 131 AP is established proactively, at the time of association. This 132 protects the wireless medium against broadcast-intensive Transparent 133 Bridging lookups. The association process registers the link-layer 134 (MAC) Address (LLA) of the STA to the AP proactively, i.e., before it 135 is needed. The AP maintains the list of the associated addresses and 136 blocks the lookups for destinations that are not registered. This 137 solves the broadcast issue for the link-layer lookups, but the 138 Network Layer problem remains. 140 Though ND-Classic was the state of the art when designed for an 141 Ethernet wire at the end of the twentieth century, it must be 142 reevaluated for the new technologies, such as wireless and overlays, 143 that evolved since then. This document discusses the applicability 144 of ND-Classic over wireless links, as compared with routing-based 145 alternatives such as prefix-per node and multi-link subnets (MLSN), 146 and with Wireless ND (WiND), that is similar to the Wi-Fi association 147 and reduces the need for Network Layer multicast. 149 2. Terminology 151 2.1. IP Links 153 For a long time, the term link has been used to refer to the layer 2 154 communication medium that can be leveraged at layer 3 to instantiate 155 one IP hop. In this document we conserve that term but differentiate 156 it from an IP link, which is a layer 3 abstraction that represents 157 the layer 2 link but is not the layer 2 link, like the map is not the 158 country. 160 With IPv6, IP has moved to layer 3 abstractions for its operations, 161 e.g., with the use of link local address (LLA), and that of IP 162 multicast for link-scoped operations. At the same time, the concept 163 of an IP link emerged as an abstraction that represents how IP layer 164 considers the layer 2 link: 166 * An IP link connects an IP node to one or more other IP nodes using 167 a lower layer subnetwork. The lower layer subnetwork may comprise 168 multiple lower layer links, e.g., in the case of a switched fabric 169 or a mesh-under LLN. 171 * an IP link defines the scope of an LLA, and defines the domain in 172 which the LLA must be unique 174 * an IP link provides a subset of the connectivity that is offered 175 by the lower layer; if the IP link is narrower than the layer 2 176 reachable domain, then layer 3 filters must restrict the link- 177 scoped communication to remain between peers on a same IP link, 178 and more than one IP link may be installed on the same physical 179 interface to connect to different peers. 181 * an IP link can be Point to Point (P2P), Point to Point (P2MP, 182 forming a partial mesh), NBMA (non-broadcast multi-access, fully 183 meshed), or transit (broadcast-capable and any-to-any). 185 It is a network design decision to use one IP link model or another 186 over a given lower layer network, e.g., to map a Frame Relay network 187 as a P2MP IP link, or as a collection of P2P IP links. As another 188 example, an Ethernet fabric may be bridged, in which case the nodes 189 that interconnect the layer 2 links are L2 switches, and the fabric 190 can be abstracted as a single transit IP link; or the fabric can be 191 routed, in which case the P2P IP links are congruent with the layer 2 192 links, and the nodes that interconnect the links are routers. 194 2.2. IP Subnets 196 IPv6 builds another abstraction, the IP subnet, over one shared IP 197 link or over a collection IP links, forming a MLSN in the latter 198 case. An MLSN is formed over IP links (e.g., P2P or P2MP) that are 199 interconnected by routers that either inject hosts routes in an IGP, 200 in which case the topology can be anything, or perform ND proxy 201 operations, in which case the structure of links must be strictly 202 hierarchical to avoid loops. 204 [RFC8929] defines bridging and routing IPv6 ND proxies. Both forms 205 of ND proxies interconnect IP links and enable to isolate the layer 2 206 broadcast domains. But in the case of a bridging proxy, the layer 2 207 unicast communication can still exist between the layer 2 domains 208 that are coverered by the layer 3 links, whereas in the base of a 209 routing proxy, they are isolated and packets must be routed back and 210 forth. Bridging proxies are possible between compatible technologies 211 and translational bridges (e.g., Wi-Fi to Ethernet), whereas routing 212 proxies are required between non-bridgeable technologies and 213 desirable to avoid exposing the layer 2 addresses across, e.g., for 214 reasons of stability and scalability. 216 It is another network design decision to use one IP subnet model or 217 another over a given lower layer network. A switched fabric can host 218 one or more IP subnets, in which case the IP links can reach all and 219 beyond one subnet. On the other hand, a subnet can encompass a 220 collection of links; in that case, the scope of the link local 221 addresses, which is the IP Link, is narrower than the span of the 222 subnet. 224 A subnet prefix is associated with the IP subnet, and a node is a 225 member of an IP subnet when it has an IP address that derives from 226 that prefix. The IP address is either a Unique Local (ULA) or a 227 Global Unicast Address (GUA), and as opposed to the case of LLAs, the 228 scope of the address is not limited to the IP subnet. 230 The switched and routed fabric above could be the exact same network 231 of physical links and boxes, what changes is the way the networking 232 abstractions are mapped onto the system, and the implication of such 233 decision include the capability to reach another node at layer-2, and 234 the size of the broadcast domain and related broadcast storms. 236 2.3. Acronyms 238 This document uses the following abbreviations: 240 6BBR: 6LoWPAN Backbone Router 241 6LN: 6LoWPAN Node 242 6LR: 6LoWPAN Router 243 ARO: Address Registration Option 244 DAC: Duplicate Address Confirmation 245 DAD: Duplicate Address Detection 246 DAR: Duplicate Address Request 247 EDAC: Extended Duplicate Address Confirmation 248 EDAR: Extended Duplicate Address Request 249 MLSN: Multi-link subnet 250 LLN: Low-Power and Lossy Network 251 LoWPAN: Low-Power Wireless Personal Area Network 252 NA: Neighbor Advertisement 253 NBMA: Non-Broadcast Multi-Access 254 NCE: Neighbor Cache Entry 255 ND: Neighbor Discovery 256 NDP: Neighbor Discovery Protocol 257 NS: Neighbor Solicitation 258 RPL: IPv6 Routing Protocol for LLNs 259 RA: Router Advertisement 260 RS: Router Solicitation 261 VLAN: Virtual Local Area Network 262 WiND: Wireless Neighbor Discovery 263 WLAN: Wireless Local Area Network 264 WPAN: Wireless Personal Area Network 266 3. ND-Classic, Wireless ND and ND-Proxies 268 The ND-Classic Neighbor Solicitation (NS) [RFC4861] message is used 269 as a multicast IP packet for Address Resolution (AR) and Duplicate 270 Address Detection (DAD) [RFC4862]. In those cases, the NS message is 271 sent at the Network Layer to a Solicited-Node Multicast Address 272 (SNMA) [RFC4291] and should in theory only reach a very small group 273 of nodes. It is intended for one Target, that may or may not be 274 present in the network, but it is often turned into a MAC-Layer 275 broadcast and effectively reaches most of the nodes that are attached 276 to the layer 2 link. 278 DAD was designed for the efficient broadcast operation of Ethernet. 279 Experiments show that DAD often fails to discover the duplication of 280 IPv6 addresses in large wireless access networks [DAD ISSUES]. In 281 practice, IPv6 addresses very rarely conflict, not because the 282 address duplications are detected and resolved by the DAD operation, 283 but thanks to the entropy of the 64-bit Interface IDs (IIDs) that 284 makes a collision quasi-impossible for randomized IIDs. 286 Multicast NS transmissions may occur when a node joins the network, 287 moves, or wakes up and reconnects to the network. Over a very large 288 fabric, this can generate hundreds of broadcasts per second. If the 289 broadcasts were blindly copied over Wi-Fi, the MAC-layer broadcast 290 traffic associated to ND IP-layer multicast could consume enough 291 bandwidth to cause a substantial degradation to the unicast service 292 [MCAST EFFICIENCY]. To protect their bandwidth, some networks 293 throttle ND-related broadcasts, which reduces the capability for the 294 ND protocol to operate as expected. 296 This problem can be alleviated by reducing the size of the broadcast 297 domain that encompasses wireless access links. This has been done in 298 the art of IP subnetting by partitioning the subnets and by routing 299 between them, at the extreme by assigning a /64 prefix to each 300 wireless node (see [RFC8273]). 302 Another way to split the broadcast domain within a subnet is to proxy 303 at the boundary of the wired and wireless domains the Network Layer 304 protocols that rely on link-layer broadcast operations. [IEEE Std. 305 802.11] recommends to deploy proxies for the IPv4 Address Resolution 306 Protocol (ARP) and IPv6 ND at the APs. This requires the exhaustive 307 list of the IP addresses for which proxying is provided. Forming and 308 maintaining that knowledge a hard problem in the general case of 309 radio connectivity, which keeps changing with movements and 310 variations in the environment that alter the range of transmissions. 312 [SAVI] suggests to discover the addresses by snooping the ND-Classic 313 protocol, but that can also be unreliable. An IPv6 address may not 314 be discovered immediately due to a packet loss. It may never be 315 discovered in the case of a "silent" node that is not currently using 316 one of its addresses, e.g., a printer that waits in wake-on-lan 317 state. A change of anchor, e.g. due to a movement, may be missed or 318 misordered, leading to unreliable connectivity and an incomplete list 319 of addresses. 321 Wireless ND (WiND) introduces a new approach to IPv6 Neighbor 322 Discovery that is designed to apply to the WLANs and LoWPANs types of 323 networks, as well as other Non-Broadcast Multi-Access (NBMA) networks 324 such as Data-Center overlays. WiND applies routing inside the 325 subnets, which enables to form potentially large MLSNs without 326 creating a large broadcast domain at the link-layer. In a fashion 327 similar to a Wi-Fi Association, IPv6 Hosts register their addresses 328 to their serving router(s), using [RFC8505]. With the registration, 329 the routers have a complete knowledge of the hosts they serve and in 330 return, hosts obtain routing services for their registered addresses. 331 The registration is abstract to the routing service, and it can be 332 protected to prevent impersonation attacks with [RFC8928]. 334 The routing service can be a simple reflexion in a Hub-and-Spoke 335 subnet that emulates an IEEE Std. 802.11 Infrastructure BSS at the 336 Network Layer. It can also be a full-fledge routing protocol, in 337 particular RPL [RFC6550], which is designed to adapt to various LLNs 338 such as WLAN and WPAN radio meshes. Finally, the routing service can 339 also be an ND proxy that emulates an IEEE Std. 802.11 Infrastructure 340 ESS at the Network Layer, as specified in the IPv6 Backbone Router 341 [RFC8929]. 343 On the one hand, WiND avoids the use of broadcast operation for DAD 344 and AR, and on the other hand, WiND supports use cases where subnet 345 and link-layer domains are not congruent, which is common in wireless 346 networks unless a specific link-layer emulation is provided. More 347 details on WiND can be found in Section 5.1. 349 4. IP Models 351 4.1. Physical Broadcast Domain 353 At the physical (PHY) Layer, a broadcast domain is the set of nodes 354 that may receive a transmission that one sends over an interface, in 355 other words the set of nodes in range of the radio transmission. 356 This set can comprise a single peer on a serial cable used as point- 357 to-point link. It may also comprise multiple peer nodes on a 358 broadcast radio or a shared physical resource such as the Ethernet 359 wires and hubs for which ND-Classic was initially designed. 361 On WLAN and LoWPAN radios, the physical broadcast domain is defined 362 relative to a particular transmitter, as the set of nodes that can 363 receive what this transmitter is sending. Literally every frame 364 defines its own broadcast domain since the chances of reception of a 365 given frame are statistical. In average and in stable conditions, 366 the broadcast domain of a particular node can be still be seen as 367 mostly constant and can be used to define a closure of nodes on which 368 an upper Layer abstraction can be built. 370 A PHY Layer communication can be established between two nodes if the 371 physical broadcast domains of their unicast transmissions overlap. 372 On WLAN and LoWPAN radios, that relation is usually not reflexive, 373 since nodes disable the reception when they transmit; still they may 374 retain a copy of the transmitted frame, so it can be seen as 375 reflexive at the MAC Layer. It is often symmetric, meaning that if B 376 can receive a frame from A, then A can receive a frame from B. But 377 there can be asymmetries due to power levels, interferers near one of 378 the receivers, or differences in the quality of the hardware (e.g., 379 crystals, PAs and antennas) that may affect the balance to the point 380 that the connectivity becomes mostly uni-directional, e.g., A to B 381 but practically not B to A. 383 It takes a particular effort to place a set of devices in a fashion 384 that all their physical broadcast domains fully overlap, and that 385 specific situation can not be assumed in the general case. In other 386 words, the relation of radio connectivity is generally not 387 transitive, meaning that A in range with B and B in range with C does 388 not necessarily imply that A is in range with C. 390 4.2. link-layer Broadcast Emulations 392 We call Direct MAC Broadcast (DMB) the transmission mode where the 393 broadcast domain that is usable at the MAC layer is directly the 394 physical broadcast domain. IEEE Std. 802.15.4 [IEEE Std. 802.15.4] 395 and IEEE Std. 802.11 [IEEE Std. 802.11] OCB (for Out of the Context 396 of a BSS) are examples of DMB radios. DMB networks provide mostly 397 symmetric and non-transitive transmission. This contrasts with a 398 number of link-layer Broadcast Emulation (LLBE) schemes that are 399 described in this section. 401 In the case of Ethernet, while a physical broadcast domain is 402 constrained to a single shared wire, the IEEE Std. 802.1 [IEEE Std. 403 802.1] bridging function emulates the broadcast properties of that 404 wire over a whole physical mesh of Ethernet links. For the upper 405 layer, the qualities of the shared wire are essentially conserved, 406 with a reliable and cheap broadcast operation over a transitive 407 closure of nodes defined by their connectivity to the emulated wire. 409 In large switched fabrics, overlay techniques enable a limited 410 connectivity between nodes that are known to a Map Resolver. The 411 emulated broadcast domain is configured to the system, e.g., with a 412 VXLAN network identifier (VNID). Broadcast operations on the overlay 413 can be emulated but can become very expensive, and it makes sense to 414 proactively install the relevant state in the mapping server as 415 opposed to rely on reactive broadcast lookups to do so. 417 An IEEE Std. 802.11 [IEEE Std. 802.11] Infrastructure Basic Service 418 Set (BSS) also provides a transitive closure of nodes as defined by 419 the broadcast domain of a central AP. The AP relays both unicast and 420 broadcast packets and provides the symmetric and transitive emulation 421 of a shared wire between the associated nodes, with the capability to 422 signal link-up/link-down to the upper layer. Within a BSS, the 423 physical broadcast domain of the AP serves as emulated broadcast 424 domain for all the nodes that are associated to the AP. Broadcast 425 packets are relayed by the AP and are not acknowledged. To increase 426 the chances that all nodes in the BSS receive the broadcast 427 transmission, AP transmits at the slowest PHY speed. This translates 428 into maximum co-channel interferences for others and the longest 429 occupancy of the medium, for a duration that can be a hundred times 430 that of the unicast transmission of a frame of the same size. 432 For that reason, upper layer protocols should tend to avoid the use 433 of broadcast when operating over Wi-Fi. To cope with this problems, 434 APs may implement strategies such as turn a broadcast into a series 435 of unicast transmissions, or drop the message altogether, which may 436 impact the upper layer protocols. For instance, some APs may not 437 copy Router Solicitation (RS) messages under the assumption that 438 there is no router across the wireless interface. This assumption 439 may be correct at some point of time and may become incorrect in the 440 future. Another strategy used in Wi-Fi APS is to proxy protocols 441 that heavily rely on broadcast, such as the Address Resolution in ARP 442 and ND-Classic, and either respond on behalf or preferably forward 443 the broadcast frame as a unicast to the intended Target. 445 In an IEEE Std. 802.11 [IEEE Std. 802.11] Infrastructure Extended 446 Service Set (ESS), infrastructure BSSes are interconnected by a 447 bridged network, typically running Transparent Bridging and the 448 Spanning tree Protocol or a more advanced Layer 2 Routing (L2R) 449 scheme. In the original model of learning bridges, the forwarding 450 state is set by observing the source MAC address of the frames. When 451 a state is missing for a destination MAC address, the frame is 452 broadcasted with the expectation that the response will populate the 453 state on the reverse path. This is a reactive operation, meaning 454 that the state is populated reactively to the need to reach a 455 destination. It is also possible in the original model to broadcast 456 a gratuitous frame to advertise self throughout the bridged network, 457 and that is also a broadcast. 459 The process of the Wi-Fi association prepares a bridging state 460 proactively at the AP, which avoids the need for a reactive broadcast 461 lookup over the wireless access. In an ESS, the AP may also generate 462 a gratuitous broadcast sourced at the MAC address of the STA to 463 prepare or update the state in the learning bridges so they point 464 towards the AP for the MAC address of the STA. WiND emulates that 465 proactive method at the Network Layer for the operations of AR, DAD 466 and ND proxy. 468 In some instances of WLANs and LoWPANs, a Mesh-Under technology 469 (e.g., a IEEE Std. 802.11s or IEEE Std. 802.15.10) provides meshing 470 services that are similar to bridging, and the broadcast domain is 471 well-defined by the membership of the mesh. Mesh-Under emulates a 472 broadcast domain by flooding the broadcast packets at the link-layer. 473 When operating on a single frequency, this operation is known to 474 interfere with itself, and requires inter-frame gaps to dampen the 475 collisions, which reduces further the amount of available bandwidth. 477 As the cost of broadcast transmissions becomes increasingly 478 expensive, there is a push to rethink the upper Layer protocols to 479 reduce the dependency on broadcast operations. 481 4.3. Mapping the IPv6 link Abstraction 483 As introduced in Section 2.1, IPv6 defines a concept of link, link 484 scope and Link-Local Addresses (LLA), an LLA being unique and usable 485 only within the Scope of a Link. The ND-Classic [RFC4861] DAD 486 [RFC4862] process uses a multicast transmission to detect a duplicate 487 address, which requires that the owner of the address is connected to 488 the link-layer broadcast domain of the sender. 490 On a wired medium, the IP link is often confused with the physical 491 broadcast domain because both are determined by the serial cable or 492 the Ethernet shared wire. Ethernet Bridging reinforces that illusion 493 with a link-layer broadcast domain that emulates a physical broadcast 494 domain over the mesh of wires. But the difference shows on legacy 495 P2MP and NBMA networks such as ATM and Frame-Relay, on shared links 496 and on newer types of NBMA networks such as radio and composite 497 radio-wires networks. It also shows when private VLANs or link-layer 498 cryptography restrict the capability to read a frame to a subset of 499 the connected nodes. 501 In Mesh-Under and Infrastructure BSS, the IP link extends beyond the 502 physical broadcast domain to the emulated link-layer broadcast 503 domain. Relying on Multicast for the ND operation remains feasible 504 but becomes highly detrimental to the unicast traffic, and becomes 505 less and less energy-efficient and reliable as the network grows. 507 On DMB radios, IP links between peers come and go as the individual 508 physical broadcast domains of the transmitters meet and overlap. The 509 DAD operation cannot provide once and for all guarantees over the 510 broadcast domain defined by one radio transmitter if that transmitter 511 keeps meeting new peers on the go. 513 The scope on which the uniqueness of an LLA must be checked is each 514 new pair of nodes for the duration of their conversation. As long as 515 there's no conflict, a node may use the same LLA with multiple peers 516 but it has to perform DAD again with each new peer. A node may need 517 to form a new LLA to talk to a new peer, and multiple LLAs may be 518 present in the same radio interface to talk to different peers. In 519 practice, each pair of nodes defines a temporary P2P link, which can 520 be modeled as a sub-interface of the radio interface. 522 The DAD and AR procedures in ND-Classic expect that a node in a 523 subnet is reachable within the broadcast domain of any other node in 524 the subnet when that other node attempts to form an address that 525 would be a duplicate or attempts to resolve the MAC address of this 526 node. This is why ND is applicable for P2P and transit links, but 527 requires extensions for more complex topologies. 529 4.4. Mapping the IPv6 subnet Abstraction 531 As introduced in Section 2.2, IPv6 also defines the concept of a 532 subnet for Global and Unique Local Addresses (GLA and ULA). All the 533 addresses in a subnet share the same prefix, and by extension, a node 534 belongs to a subnet if it has an address that derives from the prefix 535 of the subnet. That address must be topologically correct, meaning 536 that it must be installed on an interface that is connected to the 537 subnet. 539 Unless intently replicated in different locations for very specific 540 purposes, a subnet prefix is unique within a routing system; for 541 ULAs, the routing system is typically a limited domain, whereas for 542 GLAs, it is the whole Internet. 544 For that reason, it is sufficient to validate that an address that is 545 formed from a subnet prefix is unique within the scope of that subnet 546 to guarantee that it is globally unique within the whole routing 547 system. Note that a subnet may become partitioned due to the loss of 548 a wired or wireless link, so even that operation is not necessarily 549 obvious, more in [DAD APPROACHES]. 551 The IPv6 aggregation model relies on the property that a packet from 552 the outside of a subnet can be routed to any router that belongs to 553 the subnet, and that this router will be able to either resolve the 554 destination link-layer address and deliver the packet, or, in the 555 case of an MLSN, route the packet to the destination within the 556 subnet. 558 If the subnet is known as on-link, then any node may also resolve the 559 destination link-layer address and deliver the packet, but if the 560 subnet is not on-link, then a host in the subnet that does not have a 561 Neighbor Cache Entry (NCE) for the destination will also need to pass 562 the packet to a router, more in [RFC5942]. 564 On Ethernet, an IP subnet is often congruent with an IP link because 565 both are determined by the physical attachment to a shared wire or an 566 IEEE Std. 802.1 bridged domain. In that case, the connectivity over 567 the IP link is both symmetric and transitive, the subnet can appear 568 as on-link, and any node can resolve a destination MAC address of any 569 other node directly using ND-Classic. 571 But an IP link and an IP subnet are not always congruent. In the 572 case of a Shared Link, individual subnets may each encompass only a 573 subset of the nodes connected to the link. Conversely, in Route-Over 574 Multi-link subnets (MLSN) [RFC4903], routers federate the links 575 between nodes that belong to the subnet, the subnet is not on-link 576 and it extends beyond any of the federated links. 578 5. Wireless Neighbor Discovery 580 5.1. Introduction to Stateful Address Autoconfiguration 582 Stateful Address Autoconfiguration (SFAAC) 583 [RFC6775][RFC8505][RFC8929][RFC8928] defines a new operation for ND 584 that is based on 2 major paradigm changes, proactive address 585 registration by hosts to their attachment routers and routing to host 586 routes (/128) within the subnet. This allows ND to avoid the 587 expectations of transit links and subnet-wide broadcast domains. 589 SFAAC is agnostic to the method used for Address Assignment, e.g., 590 Manual, Semantically Opaque Autoconfiguration [RFC7217], randomized 591 [RFC8981], or DHCPv6 [RFC8415]. It does not change the IPv6 592 addressing [RFC4291] or the current practices of assigning prefixes, 593 typically a /64, to a subnet. But the DAD operation is performed as 594 a unicast exchange with a central registrar, using new ND Extended 595 Duplicate Address messages (EDAR and EDAC) [RFC6775][RFC8505]. This 596 modernizes ND for application in overlays with Map Resolvers and 597 enables unicast lookups [UNICAST AR] for addresses registered to the 598 resolver. 600 The proactive address registration is performed with a new option in 601 NS/NA messages, the Extended Address Registration Option (EARO) 602 defined in [RFC8505]. This method allows to prepare and maintain the 603 host routes in the routers and avoids the reactive Address Resolution 604 in ND-Classic and the associated link-layer broadcasts transmissions. 606 The EARO provides information to the router that is independent to 607 the routing protocol and routing can take multiple forms, from a 608 traditional IGP to a collapsed Hub-and-Spoke model where only one 609 router owns and advertises the prefix. [RFC8505] is already 610 referenced as the registration interface to "RIFT: Routing in Fat 611 Trees" [I-D.ietf-rift-rift] and "RPL: IPv6 Routing Protocol for 612 Low-Power and Lossy Networks" [RFC6550] with [RPL UNAWARE LEAVES]. 614 Wireless ND (WiND) combines SFAAC with the not-onlink model on the 615 wireless interfaces, and a Backbone Router (6BBR) ND proxy function 616 (more in [RFC8929]) operating as a Layer-3 AP. Multiple 6BBRs placed 617 along the wireless edge of a Backbone link handle IPv6 Neighbor 618 Discovery and forward packets over the backbone on behalf of the 619 registered nodes on the wireless edge. This enables to span a subnet 620 over an MLSN that federates edge wireless links with a high-speed, 621 typically Ethernet, backbone (as a Layer-3 ESS). The ND proxy 622 maintains the reachability for Global Unicast and Link-LOcal 623 Addresses within the federated MLSN, either as a routing proxy where 624 it replies with its own MAC address or as a bridging proxy that 625 typically forwards the multicast ND messages as unicast Layer-2 626 frames to their target. The wireless nodes can form any address they 627 want and move freely from a wireless edge link to another, without 628 renumbering. 630 5.2. links and Link-Local Addresses 632 For Link-Local Addresses, DAD is typically performed between 633 communicating pairs of nodes and an NCE can be populated with a 634 single unicast exchange. In the case of a bridging proxies, though, 635 the Link-Local traffic is bridged over the backbone and the DAD must 636 proxied there as well. 638 For instance, in the case of Bluetooth Low Energy (BLE) 639 [RFC7668][IEEEstd802151], the uniqueness of Link-Local Addresses 640 needs only to be verified between the pair of communicating nodes, 641 the central router and the peripheral host. In that example, 2 642 peripheral hosts connected to the same central router can not have 643 the same Link-Local Address because the addresses would collision at 644 the central router which could not talk to both over the same 645 interface. The DAD operation from SFAAC is appropriate for that use 646 case, but the one from ND is not, because the peripheral hosts are 647 not on the same broadcast domain. 649 On the other hand, the uniqueness of Global and Unique-Local 650 Addresses is validated at the subnet Level, using a logical registrar 651 that is global to the subnet. 653 5.3. Subnets and Global Addresses 655 SFAAC extends ND-Classic for Hub-and-Spoke (e.g., BLE) and Route-Over 656 (e.g., RPL) Multi-link subnets (MLSNs). 658 In the Hub-and-Spoke case, each Hub-Spoke pair is a distinct IP Link, 659 and a subnet can be mapped on a collection of links that are 660 connected to the Hub. The subnet prefix is associated to the Hub. 662 Acting as a router, the Hub advertises the prefix as not-on-link to 663 the spokes in RA messages Prefix Information Options (PIO). Acting 664 as hosts, the Spokes autoconfigure addresses from that prefix and 665 register them to the Hub with a corresponding lifetime. 667 Acting as a registrar, the Hub maintains a binding table of all the 668 registered IP addresses and rejects duplicate registrations, thus 669 ensuring a DAD protection for a registered address even if the 670 registering node is sleeping. 672 The Hub also maintains an NCE for the registered addresses and can 673 deliver a packet to any of them during their respective lifetimes. 674 It can be observed that this design builds a form of Network Layer 675 Infrastructure BSS. 677 A Route-Over MLSN is considered as a collection of Hub-and-Spoke 678 where the Hubs form a connected dominating set of the member nodes of 679 the subnet, and IPv6 routing takes place between the Hubs within the 680 subnet. A single logical registrar is deployed to serve the whole 681 mesh. 683 The registration in [RFC8505] is abstract to the routing protocol and 684 provides enough information to feed a routing protocol such as RPL as 685 specified in [RPL UNAWARE LEAVES]. In a degraded mode, all the Hubs 686 are connected to a same high speed backbone such as an Ethernet 687 bridging domain where ND-Classic is operated. In that case, it is 688 possible to federate the Hub, Spoke and Backbone nodes as a single 689 subnet, operating ND proxy operations [RFC8929] at the Hubs, acting 690 as 6BBRs. It can be observed that this latter design builds a form 691 of Network Layer Infrastructure ESS. 693 5.4. Anycast and Multicast Addresses 695 While IPv6 ND is defined for unicast addresses only, 696 [I-D.ietf-6lo-multicast-registration] extends [RFC8505] for anycast 697 and multicast IPv6 addresses. 699 [I-D.ietf-6lo-multicast-registration] can be used as a replacement 700 for MLDv2 [RFC3810] for use cases where broadcast are not desirable, 701 and when a device push model such as SFAAC is preferred over a 702 network pull such as MDv2 and classical ND. With [RFC8505], the host 703 does not need to define SNMAs for its unicast addresses and does not 704 perform the associated MLDv2 operation. With 705 [I-D.ietf-6lo-multicast-registration], MLDv2 and its extensive use of 706 broadcast can be totally eliminated. 708 In the case of anycast, the signal enables the 6BBRs to accept more 709 than one registration for the same address, and collectively elect 710 the registering host receives a packet for a given anycast address. 712 6. WiND Applicability 714 WiND applies equally to P2P links, P2MP Hub-and-Spoke, link-layer 715 Broadcast Domain Emulation such as Mesh-Under and Wi-Fi BSS, and 716 Route-Over meshes. 718 There is an intersection where The IP link and the IP subnet are 719 congruent and where both ND and WiND could apply. These includes 720 P2P, the MAC emulation of a PHY broadcast domain, and the particular 721 case of always on, fully overlapping physical radio broadcast domain. 722 But even in those cases where both are possible, WiND is preferable 723 vs. ND because it reduces the need of broadcast. 725 This is discussed in more details in the introduction of [RFC8929]. 727 There are also a number of practical use cases in the wireless world 728 where links and subnets are not congruent: 730 * The IEEE Std. 802.11 infrastructure BSS enables one subnet per AP, 731 and emulates a broadcast domain at the link-layer. The 732 Infrastructure ESS extends that model over a backbone and 733 recommends the use of an ND proxy [IEEE Std. 802.11] to 734 interoperate with Ethernet-connected nodes. WiND incorporates an 735 ND proxy to serve that need, which was missing so far. 737 * BlueTooth is Hub-and-Spoke at the link-layer. It would make 738 little sense to configure a different subnet between the central 739 and each individual peripheral node (e.g., sensor). Rather, 740 [RFC7668] allocates a prefix to the central node acting as router, 741 and each peripheral host (acting as a host) forms one or more 742 address(es) from that same prefix and registers it. 744 * A typical Smartgrid networks puts together Route-Over MLSNs that 745 comprise thousands of IPv6 nodes. The 6TiSCH architecture 746 [I-D.ietf-6tisch-architecture] presents the Route-Over model over 747 an IEEE Std. 802.15.4 Time-Slotted Channel-Hopping (TSCH) 748 [IEEEstd802154] mesh, and generalizes it for multiple other 749 applications. 751 Each node in a Smartgrid network may have tens to a hundred others 752 nodes in range. A key problem for the routing protocol is which 753 other node(s) should this node peer with, because most of the 754 possible peers do not provide added routing value. When both 755 energy and bandwidth are constrained, talking to them is a waste 756 of resources and most of the possible P2P links are not even used. 757 Peerings that are actually used come and go with the dynamics of 758 radio signal propagation. It results that allocating prefixes to 759 all the possible P2P links and maintain as many addresses in all 760 nodes is not even considered. 762 6.1. Case of LPWANs 764 LPWANs are by nature so constrained that the addresses and subnets 765 are fully pre-configured and operate as P2P or Hub-and-Spoke. This 766 saves the steps of neighbor Discovery and enables a very efficient 767 stateful compression of the IPv6 header. 769 6.2. Case of Infrastructure BSS and ESS 771 In contrast to IPv4, IPv6 enables a node to form multiple addresses, 772 some of them temporary to elusive, and with a particular attention 773 paid to privacy. Addresses may be formed and deprecated 774 asynchronously to the association. 776 Snooping protocols such as ND-Classic and DHCPv6 and observing data 777 traffic sourced at the STA provides an imperfect knowledge of the 778 state of the STA at the AP. Missing a state or a transition may 779 result in the loss of connectivity for some of the addresses, in 780 particular for an address that is rarely used, belongs to a sleeping 781 node, or one in a situation of mobility. This may also result in 782 undesirable remanent state in the AP when the STA ceases to use an 783 IPv6 address while remaining associated. It results that snooping 784 protocols is not a recommended technique and that it should only be 785 used as last resort, when the WiND registration is not available to 786 populate the state. 788 The recommended alternative method is to use the WiND Registration 789 for IPv6 Addresses. This way, the AP exposes its capability to proxy 790 ND to the STA in Router Advertisement messages. In turn, the STA may 791 request proxy ND services from the AP for all of its IPv6 addresses, 792 using the Extended Address Registration Option, which provides the 793 following elements: 795 * The registration state has a lifetime that limits unwanted state 796 remanence in the network. 798 * The registration is optionally secured using [RFC8928] to prevent 799 address theft and impersonation. 801 * The registration carries a sequence number, which enables to 802 figure the order of events in a fast mobility scenario without 803 loss of connectivity. 805 The ESS mode requires a proxy ND operation at the AP. The proxy ND 806 operation must cover Duplicate Address Detection, Neighbor 807 Unreachability Detection, Address Resolution and Address Mobility to 808 transfer a role of ND proxy to the AP where a STA is associated 809 following the mobility of the STA. 811 The WiND proxy ND specification that associated to the Address 812 Registration is [RFC8929]. With that specification, the AP 813 participates to the protocol as a Backbone Router, typically 814 operating as a bridging proxy though the routing proxy operation is 815 also possible. As a bridging proxy, the backbone router either 816 replies to NS lookups with the MAC address of the STA, or preferably 817 forwards the lookups to the STA as link-layer unicast frames to let 818 the STA answer. For the data plane, the backbone router acts as a 819 normal AP and bridges the packets to the STA as usual. As a routing 820 proxy, the backbone router replies with its own MAC address and then 821 routes to the STA at the IP layer. The routing proxy reduces the 822 need to expose the MAC address of the STA on the wired side, for a 823 better stability and scalability of the bridged fabric. 825 6.3. Case of Mesh Under Technologies 827 The Mesh-Under provides a broadcast domain emulation with symmetric 828 and Transitive properties and defines a transit link for IPv6 829 operations. It results that the model for IPv6 operation is similar 830 to that of a BSS, with the root of the mesh operating as an Access 831 Point does in a BSS/ESS. 833 While it is still possible to operate ND-Classic, the inefficiencies 834 of the flooding operation make the associated operations even less 835 desirable than in a BSS, and the use of WiND is highly recommended. 837 6.4. Case of DMB radios 839 IPv6 over DMB radios uses P2P links that can be formed and maintained 840 when a pair of DMB radios transmitters are in range from one another. 842 6.4.1. Using ND-Classic only 844 DMB radios do not provide MAC level broadcast emulation. An example 845 of that is IEEE Std. 802.11 OCB which uses IEEE Std. 802.11 MAC/PHYs 846 but does not provide the BSS functions. 848 It is possible to form P2P IP links between each individual pairs of 849 nodes and operate ND-Classic over those links with Link-Local 850 addresses. DAD must be performed for all addresses on all P2P IP 851 links. 853 If special deployment care is taken so that the physical broadcast 854 domains of a collection of the nodes fully overlap, then it is also 855 possible to build an IP subnet within that collection of nodes and 856 operate ND-Classic. 858 If an external mechanism avoids duplicate addresses and if the 859 deployment ensures the connectivity between peers, a non-transit Hub- 860 and-Spoke deployment is also possible where the Hub is the only 861 router in the subnet and the Prefix is advertised as not on-link. 863 6.4.2. Using Wireless ND 865 Though this can be achieved with ND-Classic, WiND is the recommended 866 approach since it uses unicast communications which are more reliable 867 and less impacting for other users of the medium. 869 The routers send RAs with a SLLAO at a regular period. The period 870 can be indicated in the RA-Interval Option [RFC6275]. If available, 871 the message can be transported in a compressed form in a beacon, 872 e.g., in OCB Basic Safety Messages (BSM) that are nominally sent 873 every 100ms. 875 An active beaconing mode is possible whereby the Host sends broadcast 876 RS messages to which a router can answer with a unicast RA. 878 A router that has Internet connectivity and is willing to serve as an 879 Internet Access may advertise itself as a default router [RFC4191] in 880 its RA messages. The RA is sent over an unspecified IP link where it 881 does not conflict to anyone, so DAD is not necessary at that stage. 883 The host instantiates an IP link where the router's address is not a 884 duplicate. To achieve this, it forms an LLA that does not conflict 885 with that of the router and registers to the router using [RFC8505]. 886 If the router sent an RA(PIO), the host can also autoconfigure an 887 address from the advertised prefix and register it. 889 (host) (router) 890 | | 891 | DMB link | 892 | | 893 | IPv6 ND RS | 894 |-------------->| 895 |-----------> | 896 |------------------> 897 | IPv6 ND RA | 898 |<--------------| 899 | | 900 | NS(EARO) | 901 |-------------->| 902 | | 903 | NA(EARO) | 904 |<--------------| 905 | | 907 Figure 1: Initial Registration Flow 909 The lifetime in the registration should start with a small value 910 (X=RMin, TBD), and exponentially grow with each re-registration to a 911 larger value (X=Rmax, TBD). The IP link is considered down when 912 (X=NbBeacons, TDB) expected messages are not received in a row. It 913 must be noted that the physical link flapping does not affect the 914 state of the registration and when a physical link comes back up, the 915 active registrations (i.e., registrations for which lifetime is not 916 elapsed) are still usable. Packets should be held or destroyed when 917 the IP link is down. 919 P2P links may be federated in Hub-and-Spoke and then in Route-Over 920 MLSNs as illustrated in Figure 2. More details on the operation of 921 WiND and RPL over the MLSN can be found in section 3.1, 3.2, 4.1 and 922 4.2.2 of [I-D.ietf-6tisch-architecture]. 924 6LoWPAN Node 6LR 6LBR 6BBR 925 (RPL leaf) (router) (root) 926 | | | | 927 | 6LoWPAN ND |6LoWPAN ND+RPL | 6LoWPAN ND | ND-Classic 928 | LLN link |Route-Over mesh|Ethernet/serial| Backbone 929 | | | | 930 | IPv6 ND RS | | | 931 |-------------->| | | 932 |-----------> | | | 933 |------------------> | | 934 | IPv6 ND RA | | | 935 |<--------------| | | 936 | | | | 937 | NS(EARO) | | | 938 |-------------->| | | 939 | 6LoWPAN ND | Extended DAR | | 940 | |-------------->| | 941 | | | NS(EARO) | 942 | | |-------------->| 943 | | | | NS-DAD 944 | | | |------> 945 | | | | (EARO) 946 | | | | 947 | | | NA(EARO) | 948 | | |<--------------| 949 | | Extended DAC | | 950 | |<--------------| | 951 | NA(EARO) | | | 952 |<--------------| | | 953 | | | | 955 Figure 2: Initial Registration Flow over Multi-link subnet 957 An example Hub-and-Spoke is an OCB Road-Side Unit (RSU) that owns a 958 prefix, provides Internet connectivity using that prefix to On-Board 959 Units (OBUs) within its physical broadcast domain. An example of 960 Route-Over MLSN is a collection of cars in a parking lot operating 961 RPL to extend the connectivity provided by the RSU beyond its 962 physical broadcast domain. Cars may then operate NEMO [RFC3963] for 963 their own prefix using their address derived from the prefix of the 964 RSU as CareOf Address. 966 7. IANA Considerations 968 This specification does not require IANA action. 970 8. Security Considerations 972 This specification refers to the security sections of ND-Classic and 973 WiND, respectively. 975 9. Acknowledgments 977 Many thanks to the participants of the 6lo WG where a lot of the work 978 discussed here happened. Also ROLL, 6TiSCH, and 6LoWPAN. 980 10. Normative References 982 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 983 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 984 RFC 3963, DOI 10.17487/RFC3963, January 2005, 985 . 987 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 988 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 989 November 2005, . 991 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 992 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 993 DOI 10.17487/RFC4861, September 2007, 994 . 996 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 997 Address Autoconfiguration", RFC 4862, 998 DOI 10.17487/RFC4862, September 2007, 999 . 1001 [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet 1002 Model: The Relationship between Links and Subnet 1003 Prefixes", RFC 5942, DOI 10.17487/RFC5942, July 2010, 1004 . 1006 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 1007 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 1008 2011, . 1010 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1011 (IPv6) Specification", STD 86, RFC 8200, 1012 DOI 10.17487/RFC8200, July 2017, 1013 . 1015 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 1016 Perkins, "Registration Extensions for IPv6 over Low-Power 1017 Wireless Personal Area Network (6LoWPAN) Neighbor 1018 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 1019 . 1021 [RFC8928] Thubert, P., Ed., Sarikaya, B., Sethi, M., and R. Struik, 1022 "Address-Protected Neighbor Discovery for Low-Power and 1023 Lossy Networks", RFC 8928, DOI 10.17487/RFC8928, November 1024 2020, . 1026 [RFC8929] Thubert, P., Ed., Perkins, C.E., and E. Levy-Abegnoli, 1027 "IPv6 Backbone Router", RFC 8929, DOI 10.17487/RFC8929, 1028 November 2020, . 1030 11. Informative References 1032 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 1033 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 1034 DOI 10.17487/RFC3810, June 2004, 1035 . 1037 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1038 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 1039 2006, . 1041 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 1042 DOI 10.17487/RFC4903, June 2007, 1043 . 1045 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1046 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1047 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1048 Low-Power and Lossy Networks", RFC 6550, 1049 DOI 10.17487/RFC6550, March 2012, 1050 . 1052 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 1053 Bormann, "Neighbor Discovery Optimization for IPv6 over 1054 Low-Power Wireless Personal Area Networks (6LoWPANs)", 1055 RFC 6775, DOI 10.17487/RFC6775, November 2012, 1056 . 1058 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 1059 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 1060 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 1061 . 1063 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 1064 Interface Identifiers with IPv6 Stateless Address 1065 Autoconfiguration (SLAAC)", RFC 7217, 1066 DOI 10.17487/RFC7217, April 2014, 1067 . 1069 [RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix 1070 per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017, 1071 . 1073 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 1074 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 1075 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 1076 RFC 8415, DOI 10.17487/RFC8415, November 2018, 1077 . 1079 [RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves, 1080 "Temporary Address Extensions for Stateless Address 1081 Autoconfiguration in IPv6", RFC 8981, 1082 DOI 10.17487/RFC8981, February 2021, 1083 . 1085 [I-D.ietf-rift-rift] 1086 Sharma, A., Thubert, P., Rijsman, B., and D. Afanasiev, 1087 "RIFT: Routing in Fat Trees", Work in Progress, Internet- 1088 Draft, draft-ietf-rift-rift-13, 12 July 2021, 1089 . 1092 [RPL UNAWARE LEAVES] 1093 Thubert, P. and M. C. Richardson, "Routing for RPL 1094 (Routing Protocol for Low-Power and Lossy Networks) 1095 Leaves", Work in Progress, Internet-Draft, draft-ietf- 1096 roll-unaware-leaves-30, 22 January 2021, 1097 . 1100 [DAD ISSUES] 1101 Yourtchenko, A. and E. Nordmark, "A survey of issues 1102 related to IPv6 Duplicate Address Detection", Work in 1103 Progress, Internet-Draft, draft-yourtchenko-6man-dad- 1104 issues-01, 3 March 2015, 1105 . 1108 [MCAST EFFICIENCY] 1109 Vyncke, E., Thubert, P., Levy-Abegnoli, E., and A. 1110 Yourtchenko, "Why Network-Layer Multicast is Not Always 1111 Efficient At Datalink Layer", Work in Progress, Internet- 1112 Draft, draft-vyncke-6man-mcast-not-efficient-01, 14 1113 February 2014, . 1116 [I-D.ietf-6tisch-architecture] 1117 Thubert, P., "An Architecture for IPv6 over the Time- 1118 Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)", 1119 Work in Progress, Internet-Draft, draft-ietf-6tisch- 1120 architecture-30, 26 November 2020, 1121 . 1124 [MCAST PROBLEMS] 1125 Perkins, C. E., McBride, M., Stanley, D., Kumari, W., and 1126 J. C. Zuniga, "Multicast Considerations over IEEE 802 1127 Wireless Media", Work in Progress, Internet-Draft, draft- 1128 ietf-mboned-ieee802-mcast-problems-15, 28 July 2021, 1129 . 1132 [SAVI] Bi, J., Wu, J., Lin, T., Wang, Y., and L. He, "A SAVI 1133 Solution for WLAN", Work in Progress, Internet-Draft, 1134 draft-bi-savi-wlan-22, 10 November 2021, 1135 . 1138 [UNICAST AR] 1139 Thubert, P. and E. Levy-Abegnoli, "IPv6 Neighbor Discovery 1140 Unicast Lookup", Work in Progress, Internet-Draft, draft- 1141 thubert-6lo-unicast-lookup-02, 8 November 2021, 1142 . 1145 [DAD APPROACHES] 1146 Nordmark, E., "Possible approaches to make DAD more robust 1147 and/or efficient", Work in Progress, Internet-Draft, 1148 draft-nordmark-6man-dad-approaches-02, 19 October 2015, 1149 . 1152 [I-D.ietf-6lo-multicast-registration] 1153 Thubert, P., "IPv6 Neighbor Discovery Multicast Address 1154 Listener Registration", Work in Progress, Internet-Draft, 1155 draft-ietf-6lo-multicast-registration-03, 13 December 1156 2021, . 1159 [IEEE Std. 802.15.4] 1160 IEEE standard for Information Technology, "IEEE Std. 1161 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 1162 and Physical Layer (PHY) Specifications for Low-Rate 1163 Wireless Personal Area Networks". 1165 [IEEE Std. 802.11] 1166 IEEE standard for Information Technology, "IEEE Standard 1167 for Information technology -- Telecommunications and 1168 information exchange between systems Local and 1169 metropolitan area networks-- Specific requirements Part 1170 11: Wireless LAN Medium Access Control (MAC) and Physical 1171 Layer (PHY) Specifications". 1173 [IEEEstd802151] 1174 IEEE standard for Information Technology, "IEEE Standard 1175 for Information Technology - Telecommunications and 1176 Information Exchange Between Systems - Local and 1177 Metropolitan Area Networks - Specific Requirements. - Part 1178 15.1: Wireless Medium Access Control (MAC) and Physical 1179 Layer (PHY) Specifications for Wireless Personal Area 1180 Networks (WPANs)". 1182 [IEEEstd802154] 1183 IEEE standard for Information Technology, "IEEE Standard 1184 for Local and metropolitan area networks -- Part 15.4: 1185 Low-Rate Wireless Personal Area Networks (LR-WPANs)". 1187 [IEEE Std. 802.1] 1188 IEEE standard for Information Technology, "IEEE Standard 1189 for Information technology -- Telecommunications and 1190 information exchange between systems Local and 1191 metropolitan area networks Part 1: Bridging and 1192 Architecture". 1194 Author's Address 1196 Pascal Thubert (editor) 1197 Cisco Systems, Inc 1198 Building D 1199 45 Allee des Ormes - BP1200 1200 06254 Mougins - Sophia Antipolis 1201 France 1203 Phone: +33 497 23 26 34 1204 Email: pthubert@cisco.com