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