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