idnits 2.17.1 draft-thubert-6man-ipv6-over-wireless-05.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 (31 March 2020) is 1458 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-23) exists of draft-ietf-6lo-ap-nd-20 == Outdated reference: A later version (-20) exists of draft-ietf-rift-rift-11 == Outdated reference: A later version (-30) exists of draft-ietf-roll-unaware-leaves-13 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-28 == Outdated reference: A later version (-15) exists of draft-ietf-mboned-ieee802-mcast-problems-11 == Outdated reference: A later version (-24) exists of draft-bi-savi-wlan-18 == Outdated reference: A later version (-02) exists of draft-thubert-6lo-unicast-lookup-00 Summary: 0 errors (**), 0 flaws (~~), 8 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: Standards Track 31 March 2020 5 Expires: 2 October 2020 7 IPv6 Neighbor Discovery on Wireless Networks 8 draft-thubert-6man-ipv6-over-wireless-05 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 2 October 2020. 33 Copyright Notice 35 Copyright (c) 2020 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. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 3. IPv6 ND, Wireless ND and ND-Proxies . . . . . . . . . . . . . 4 52 4. IP Models . . . . . . . . . . . . . . . . . . . . . . . . . . 6 53 4.1. Physical Broadcast Domain . . . . . . . . . . . . . . . . 6 54 4.2. Link-Layer Broadcast Emulations . . . . . . . . . . . . . 7 55 4.3. Mapping the IPv6 link Abstraction . . . . . . . . . . . . 8 56 4.4. Mapping the IPv6 subnet Abstraction . . . . . . . . . . . 9 57 5. Wireless Neighbor Discovery . . . . . . . . . . . . . . . . . 10 58 5.1. Introduction to Wireless ND . . . . . . . . . . . . . . . 10 59 5.2. links and Link-Local Addresses . . . . . . . . . . . . . 11 60 5.3. subnets and Global Addresses . . . . . . . . . . . . . . 11 61 6. WiND Applicability . . . . . . . . . . . . . . . . . . . . . 12 62 6.1. Case of LPWANs . . . . . . . . . . . . . . . . . . . . . 13 63 6.2. Case of Infrastructure BSS and ESS . . . . . . . . . . . 13 64 6.3. Case of Mesh Under Technologies . . . . . . . . . . . . . 15 65 6.4. Case of DMB radios . . . . . . . . . . . . . . . . . . . 15 66 6.4.1. Using IPv6 ND only . . . . . . . . . . . . . . . . . 15 67 6.4.2. Using Wireless ND . . . . . . . . . . . . . . . . . . 15 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 70 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 71 10. Normative References . . . . . . . . . . . . . . . . . . . . 18 72 11. Informative References . . . . . . . . . . . . . . . . . . . 19 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 75 1. Introduction 77 IEEE STD. 802.1 [IEEEstd8021] Ethernet Bridging provides an efficient 78 and reliable broadcast service for wired networks; applications and 79 protocols have been built that heavily depend on that feature for 80 their core operation. 82 Unfortunately, Low-Power Lossy Networks (LLNs) and Wireless Local 83 Area Networks (WLANs) generally do not benefit from the same reliable 84 and cheap broadcast capabilities as Ethernet links. As opposed to 85 unicast transmissions, the broadcast transmissions over wireless 86 links are not subject to automatic retries (ARQ) and can be very 87 unreliable. Reducing the speed at the PHY layer for broadcast 88 transmissions can increase the reliability, at the expense of a 89 higher relative cost of broadcast on the overall available bandwidth. 91 As a result, protocols designed for bridged networks that rely on 92 broadcast transmissions often exhibit disappointing behaviours when 93 employed unmodified on a local wireless medium (see 94 [MCAST-PROBLEMS]). 96 Wi-Fi [IEEEstd80211] Access Points (APs) deployed in an Extended 97 Service Set (ESS) act as Ethernet Bridges [IEEEstd8021] between the 98 wireless stations (STA) and the wired backbone. As opposed to the 99 classical Transparent (aka Learning) Bridge operation that installs 100 the forwarding state reactively to traffic, the bridging state in the 101 AP is established proactively, at the time of association. This 102 protects the wireless medium against broadcast-intensive Transparent 103 Bridging lookups. In other words, the association process registers 104 the Link-Layer (MAC) Address of the STA to the AP. The AP maintains 105 the full list of associated addresses and does not forward over the 106 radio the broadcast lookups for destinations that are not there. 108 In the case of Ethernet LANs as well as most WLANs and Low-Power 109 Personal Area Networks (LoWPANs), the Network-Layer multicast 110 operation is typically implemented as a Link-Layer broadcast for the 111 lack of an adapted Link-Layer multicast operation. That Link-Layer 112 multicast operation would need to handle a possibly very large number 113 of groups and it was easier to simply broadcast all the Network-Layer 114 multicast packets. 116 Like Transparent Bridging, the IPv6 [RFC8200] Neighbor Discovery 117 [RFC4861] [RFC4862] Protocol (IPv6 ND) is reactive, based on on- 118 demand multicast transmissions to locate an on-link correspondent and 119 ensure the uniqueness of an IPv6 address. On wireless, the packets 120 are broadcasted, meaning that they are both expensive and unreliable. 122 On paper, a Wi-Fi station must keep its radio turned on to listen to 123 the periodic series of broadcast frames, which for the most part will 124 be dropped when they reach Network-Layer. In order to avoid this 125 waste of energy and increase its battery life, a typical battery- 126 operated device such as an IoT sensor or a smartphone will blindly 127 ignore a ratio of the broadcasts, making IPv6 ND operations even less 128 reliable. 130 It results that an IPv6 ND multicast message is processed by many of 131 the wireless nodes over the whole subnet (e.g., the ESS fabric) 132 though there are very few nodes subscribed to the multicast group, 133 and at most one intended target. Yet, the packet may be missed by 134 the intended target. 136 Though IPv6 ND was the state of the art when designed for an Ethernet 137 wire at the end of the twentieth century, it must be reevaluated for 138 the new technologies, such as wireless and overlays, that evolved 139 since then. This document discusses the applicability of IPv6 ND 140 over wireless links, as compared with routing-based alternatives such 141 as prefix-per node and multi-link subnets (MLSN), and with Wireless 142 ND (WiND), that is similar to the Wi-Fi association and reduces the 143 need for Network-Layer multicast. 145 2. Acronyms 147 This document uses the following abbreviations: 149 6BBR: 6LoWPAN Backbone Router 150 6LN: 6LoWPAN Node 151 6LR: 6LoWPAN Router 152 ARO: Address Registration Option 153 DAC: Duplicate Address Confirmation 154 DAD: Duplicate Address Detection 155 DAR: Duplicate Address Request 156 EDAC: Extended Duplicate Address Confirmation 157 EDAR: Extended Duplicate Address Request 158 MLSN: Multi-link subnet 159 LLN: Low-Power and Lossy Network 160 LoWPAN: Low-Power Wireless Personal Area Network 161 NA: Neighbor Advertisement 162 NBMA: Non-Broadcast Multi-Access 163 NCE: Neighbor Cache Entry 164 ND: Neighbor Discovery 165 NDP: Neighbor Discovery Protocol 166 NS: Neighbor Solicitation 167 RPL: IPv6 Routing Protocol for LLNs 168 RA: Router Advertisement 169 RS: Router Solicitation 170 VLAN: Virtual Local Area Network 171 WiND: Wireless Neighbor Discovery 172 WLAN: Wireless Local Area Network 173 WPAN: Wireless Personal Area Network 175 3. IPv6 ND, Wireless ND and ND-Proxies 177 The IPv6 ND Neighbor Solicitation (NS) [RFC4861] message is used as a 178 multicast IP packet for Address Resolution (AR) and Duplicate Address 179 Setection (DAD) [RFC4862]. In those cases, the NS message is sent at 180 the Network Layer to a Solicited-Node Multicast Address (SNMA) 181 [RFC4291] and should in theory only reach a very small group of 182 nodes. Those messages are generated individually for each address, 183 and may occur when a node joins the network, moves, or wakes up and 184 reconnects to the network. 186 DAD was designed for the efficient broadcast operation of Ethernet. 187 Experiments show that DAD often fails to discover the duplication of 188 IPv6 addresses in large wireless access networks [DAD-ISSUES]. In 189 practice, IPv6 addresses very rarely conflict, not because the 190 address duplications are detected and resolved by the DAD operation, 191 but thanks to the entropy of the 64-bit Interface IDs (IIDs) that 192 makes a collision quasi-impossible for randomized IIDs. 194 IPv6 ND Address Lookups and DADs over a very large fabric can 195 generate hundreds of broadcasts per second. If the broadcasts were 196 blindly copied over Wi-Fi, the ND-related multicast traffic could 197 consume enough bandwidth to cause a substantial degradation to the 198 unicast service [MCAST-EFFICIENCY]. To protect their bandwidth, some 199 networks throttle ND-related broadcasts, which reduces the capability 200 for the ND protocol to operate as expected. 202 This problem can be alleviated by reducing the size of the broadcast 203 domain that encompasses wireless access links. This has been done in 204 the art of IP subnetting by partitioning the subnets and by routing 205 between them, at the extreme by assigning a /64 prefix to each 206 wireless node (see [RFC8273]). 208 Another way to split the broadcast domain within a subnet is to proxy 209 at the boundary of the wired and wireless domains the Network-Layer 210 protocols that rely on Link-Layer broadcast operations. For 211 instance, IEEE 802.11 [IEEEstd80211] recommends to deploy proxy-ARP 212 (IPv4) and proxy-ND (IPv6) functions at the Access Points (APs). But 213 proxying ND requires the full list of the IPv6 addresses for which 214 proxying is provided. Forming and maintaining that knowledge a hard 215 problem in the general case of radio connectivity, which keeps 216 changing with movements and other variations in the environment. 218 [SAVI] suggests to discover the addresses by snooping the IPV6 ND 219 protocol, but that can also be unreliable. An IPv6 address may not 220 be discovered immediately due to a packet loss. It may never be 221 discovered in the case of a "silent" node that is not currently using 222 one of its addresses, e.g., a printer that waits in wake-on-lan 223 state. A change of anchor, e.g. due to a movement, may be missed or 224 misordered, leading to unreliable connectivity and an incomplete list 225 of IPv6 addresses to be proxied for. 227 Wireless ND (WiND) introduces a new approach to IPv6 ND that is 228 designed to apply to the WLANs and LoWPANs types of networks. On the 229 one hand, WiND avoids the use of broadcast operation for DAD and AR, 230 and on the other hand, WiND supports use cases where subnet and Link- 231 Layer domains are not congruent, which is common in those types of 232 networks unless a specific Link-Layer emulation is provided. 234 WiND applies routing inside the subnets, which enables Multilink 235 subnets. Hosts register their addresses to their serving routers 236 with [RFC8505]. With the registration, routers have a complete 237 knowledge of the hosts they serve and in return, hosts obtain routing 238 services for their registered addresses. The registration is 239 abstract to the routing protocol, and it can be protected to prevent 240 impersonation attacks with [ADDR-PROTECT]. 242 The routing service can be a simple reflexion in a Hub-and-Spoke 243 subnet that emulates an IEEE Std. 802.11 Infrastructure BSS at the 244 Network Layer. It can also be a full-fledge routing protocol, in 245 particular RPL [RFC6550] that was designed to adapt to various LLNs 246 such as WLAN and WPAN radio meshes with the concept of Objective 247 Function. Finally, the routing service can also be ND proxy that 248 emulates an IEEE Std. 802.11 Infrastructure ESS at the Network Layer, 249 as specified in the IPv6 Backbone Router [BB-ROUTER]. 251 More details on WiND can be found in Section 5.1. 253 4. IP Models 255 4.1. Physical Broadcast Domain 257 At the physical (PHY) Layer, a broadcast domain is the set of nodes 258 that may receive a datagram that one sends over an interface, in 259 other words the set of nodes in range of radio transmission. This 260 set can comprise a single peer on a serial cable used as point-to- 261 point (P2P) link. It may also comprise multiple peer nodes on a 262 broadcast radio or a shared physical resource such as the legacy 263 Ethernet yellow wire for which IPv6 ND was initially designed. 265 On WLAN and LoWPAN radios, the physical broadcast domain is defined 266 by a particular transmitter, as the set of nodes that can receive 267 what this transmitter is sending. Literally every datagram defines 268 its own broadcast domain since the chances of reception of a given 269 datagram are statistical. In average and in stable conditions, the 270 broadcast domain of a particular node can be still be seen as mostly 271 constant and can be used to define a closure of nodes on which an 272 upper-layer abstraction can be built. 274 A PHY-layer communication can be established between 2 nodes if their 275 physical broadcast domains overlap. On WLAN and LoWPAN radios, MC 276 property is usually reflexive, meaning that if B can receive a 277 datagram from A, then A can receive a datagram from B. But there can 278 be asymmetries due to power levels, interferers near one of the 279 receivers, or differences in the quality of the hardware (e.g., 280 crystals, PAs and antennas) that may affect the balance to the point 281 that the connectivity becomes mostly uni-directional, e.g., A to B 282 but practically not B to A. 284 It takes a particular effort to place a set of devices in a fashion 285 that all their physical broadcast domains fully overlap, and that 286 situation can not be assumed in the general case. In other words, 287 the property of radio connectivity is generally not transitive, 288 meaning that A in range with B and B in range with C does not 289 necessarily imply that A is in range with C. 291 4.2. Link-Layer Broadcast Emulations 293 We call Direct MAC Broadcast (DMB) the transmission mode where the 294 broadcast domain that is usable at the MAC layer is directly the 295 physical broadcast domain. IEEE Std. 802.15.4 [IEEE802154] and IEEE 296 Std. 802.11 OCB [IEEEstd80211] (for Out of the Context of a BSS) are 297 examples of DMB radios. This contrasts with a number of Link-Layer 298 Broadcast Emulation (LLBE) schemes that are described in this 299 section. 301 While a physical broadcast domain is constrained to a single shared 302 wire, Ethernet Bridging emulates the broadcast properties of that 303 wire over a whole physical mesh of Ethernet links. For the upper 304 layer, the qualities of the shared wire are essentially conserved, 305 with a reliable and cheap broadcast operation over a closure of nodes 306 defined by their connectivity to the emulated wire. 308 In large switched fabrics, overlay techniques enable a limited 309 connectivity between nodes that are known to a Map Resolver. The 310 emulated broadcast domain is configured to the system, e.g., with a 311 VXLAN network identifier (VNID). Broadcast operations on the overlay 312 can be emulated but can become very expensive, and it makes sense to 313 proactively install the relevant state in the mapping server as 314 opposed to rely on reactive broadcast lookups. 316 An IEEE Std. 802.11 Infrastructure Basic Service Set (BSS) also 317 provides a closure of nodes as defined by the broadcast domain of a 318 central AP. The AP relays both unicast and broadcast packets and 319 ensures a reflexive and transitive emulation of the shared wire 320 between the associated nodes, with the capability to signal link-up/ 321 link-down to the upper layer. Within an Infrastructure BSS, the 322 physical broadcast domain of the AP serves as emulated broadcast 323 domain for all the nodes that are associated to the AP. Broadcast 324 packets are relayed by the AP and are not acknowledged. To increase 325 the chances that all nodes in the BSS receive the broadcast 326 transmission, AP transmits at the slowest PHY speed. This translates 327 into maximum co-channel interferences for others and the longest 328 occupancy of the medium, for a duration that can be a hundred times 329 that of the unicast transmission of a frame of the same size. For 330 that reason, upper layer protocols should tend to avoid the use of 331 broadcast when operating over Wi-Fi. 333 In an IEEE Std. 802.11 Infrastructure Extended Service Set (ESS), 334 infrastructure BSSes are interconnected by a bridged network, 335 typically running Transparent Bridging and the Spanning tree 336 Protocol. In the original model of learning bridges, the forwarding 337 state is set by observing the source MAC address of the frames. When 338 a state is missing for a destination MAC address, the frame is 339 broadcasted with the expectation that the response will populate the 340 state on the reverse path. This is a reactive operation, meaning 341 that the state is populated reactively to the need for to reach a 342 destination. It is also possible in the original model to broadcast 343 a gratuitous frame to advertise self throughout the bridged network, 344 and that is also a broadcast. 346 The process of the Wi-Fi association prepares a bridging state 347 proactively at the AP, which avoids the need for a reactive broadcast 348 lookup over the wireless access. In an ESS, the AP may also generate 349 a gratuitous broadcast sourced at the MAC address of the STA to 350 prepare or update the state in the learning bridges so they point 351 towards the AP for the MAC address of the STA. WiND emulates that 352 proactive method at the Network-Layer for the operations of AR, DAD 353 and IPv6 ND proxy. 355 In some instances of WLANs and LoWPANs, a Mesh-Under technology 356 (e.g., a IEEE Std. 802.11s or IEEE Std. 802.15.10) provides meshing 357 services that are similar to bridging, and the broadcast domain is 358 well-defined by the membership of the mesh. Mesh-Under emulates a 359 broadcast domain by flooding the broadcast packets at the Link-Layer. 360 When operating on a single frequency, this operation is known to 361 interfere with itself, and requires inter-frame gaps to dampen the 362 collisions, which reduces further the amount of available bandwidth. 364 Going down the list of cases above, the cost of a broadcast 365 transmissions becomes increasingly expensive, and there is a push to 366 rethink the upper-layer protocols so as to reduce the depency on 367 broadcast operations. 369 There again, a Link-Layer communication can be established between 2 370 nodes if their Link-Layer broadcast domains overlap. In the absence 371 of a Link-Layer emulation such as a Mesh-Under or an Infrastructure 372 BSS, the Link-Layer broadcast domain is congruent with that of the 373 PHY-layer and inherits its properties for reflexivity and 374 transitivity. The IEEE Std. 802.11 OCB, which operates without a 375 BSS, is an example of a network that does not have a Link-Layer 376 broadcast domain emulation, which means that it will exhibit mostly 377 reflexive and mostly non-transitive transmission properties. 379 4.3. Mapping the IPv6 link Abstraction 381 IPv6 defines a concept of Link, link Scope and Link-Local Addresses 382 (LLA), an LLA being unique and usable only within the Scope of a 383 Link. The IPv6 ND [RFC4861] DAD [RFC4862] process uses a multicast 384 transmission to detect a duplicate address, which requires that the 385 owner of the address is connected to the Link-Layer broadcast domain 386 of the sender. 388 On wired media, the link is often confused with the physical 389 broadcast domain because both are determined by the serial cable or 390 the Ethernet shared wire. Ethernet Bridging reinforces that illusion 391 with a Link-Layer broadcast domain that emulates a physical broadcast 392 domain over the mesh of wires. But the difference shows on legacy 393 Non-Broadcast Multi-Access (NBMA) networks such as ATM and Frame- 394 Relay, on shared links and on newer types of NBMA networks such as 395 radio and composite radio-wires networks. It also shows when private 396 VLANs or Link-Layer cryptography restrict the capability to read a 397 frame to a subset of the connected nodes. 399 In Mesh-Under and Infrastructure BSS, the IP link extends beyond the 400 physical broadcast domain to the emulated Link-Layer broadcast 401 domain. Relying on Multicast for the ND operation remains feasible 402 but becomes highly detrimental to the unicast traffic, and more 403 energy-inefficient and unreliable as the network grows. 405 On DMB radios, IP links between peers come and go as the individual 406 physical broadcast domains of the transmitters meet and overlap. The 407 DAD operation cannot provide once and for all guarantees on the 408 broadcast domain defined by one radio transmitter if that transmitter 409 keeps meeting new peers on the go. The nodes may need to form new 410 Link-Local Addresses (LLAs) to talk to one another and the scope on 411 which the uniqueness of an LLA must be checked is that pair of nodes. 412 As long as there's no conflict, a node may use the same LLA with 413 multiple peers but it has to perform DAD with each new peer node. In 414 practice, each pair of nodes defines a temporary P2P link, which can 415 be modeled as a sub-interface of the radio interface. 417 4.4. Mapping the IPv6 subnet Abstraction 419 IPv6 also defines the concept of a subnet for Glocal and Unique Local 420 Addresses. All the addresses in a subnet share the same prefix, and 421 by extension, a node belongs to a subnet if it has with an address in 422 that subnet. A subnet prefix is Globally Unique so it is sufficient 423 to validate that an address that is formed from a subnet prefix is 424 unique within that subnet to guarantee that it is globally unique. 426 The IPv6 aggregation model relies on the property that a packet from 427 the outside of a subnet can be routed to any router that belongs to 428 the subnet, and that this router will be able to either resolve the 429 destination Link-Layer address and deliver the packet, or route the 430 packet to the destination within the subnet. If the subnet is known 431 as on-link, then any node may also resolve the destination Link-Layer 432 address and deliver the packet, but if the subnet is not on-link, 433 then a host in the subnet that does not have a Neighbor Cache Entry 434 (NCE) for the destination will also need to pass the packet to a 435 router. 437 On IEEE Std. 802.3, a subnet is often congruent with an IP link 438 because both are determined by the physical attachment to an Ethernet 439 shared wire or an IEEE Std. 802.1 bridged broadcast domain. In that 440 case, the connectivity over the link is transitive, the subnet can 441 appear as on-link, and any node can resolve a destination MAC address 442 of any other node directly using IPv6 Neighbor Discovery. 444 But an IP link and an IP subnet are not always congruent. In the 445 case of a Shared Link, individual subnets may each encompass only a 446 subset of the nodes connected to the link. In Route-Over Multi-link 447 subnets (MLSN) [RFC4903], routers federate the links between nodes 448 that belong to the subnet, the subnet is not on-link and it extends 449 beyond any of the federated links. 451 5. Wireless Neighbor Discovery 453 5.1. Introduction to Wireless ND 455 The DAD and AR procedures in IPv6 ND expect that a node in a subnet 456 is reachable within the broadcast domain of any other node in the 457 subnet when that other node attempts to form an address that would be 458 a duplicate or attempts to resolve the MAC address of this node. 459 This is why ND is only applicable for P2P and transit links, and 460 requires extensions for other topologies. 462 WiND [RFC6775][RFC8505][BB-ROUTER][ADDR-PROTECT] defines a new 463 operation for Neighbor Discovery that is based on 2 major paradigm 464 changes, proactive address registration by hosts to their attachment 465 routers and routing to host routes (/128) within the subnet. This 466 allows WiND to avoid the expectations of transit links and subnet- 467 wide broadcast domains. 469 WiND is agnostic to the method used for Address Assignment, e.g., 470 Stateless Address Autoconfiguration (SLAAC) [RFC4862] or DHCPv6 471 [RFC8415]. It does not change the IPv6 addressing [RFC4291] or the 472 current practices of assigning prefixes, typically a /64, to a 473 subnet. But the DAD operation is performed as a unicast exchange 474 with a central registrar, using new ND Extended Duplicate Address 475 messages (EDAR and EDAC) [RFC6775][RFC8505]. This operation 476 modernizes ND for application in overlays with Map Resolvers and 477 enables unicast lookups [UNICAST-AR] for addresses registered to the 478 resolver. 480 The proactive address registration is performed with a new option in 481 NS/NA messages, the Extended Address Registration Option (EARO) 482 defined in [RFC8505]. This method allows to prepare and maintain the 483 host routes in the routers and avoids the reactive Address Resolution 484 in IPv6 ND and the associated Link-Layer broadcasts transmissions. 486 The EARO provides information to the router that is independent to 487 the routing protocol and routing can take multiple forms, from a 488 traditional IGP to a collapsed Hub-and-Spoke model where only one 489 router owns and advertises the prefix. [RFC8505] is already 490 referenced as the registrtaion interface to "RIFT: Routing in Fat 491 Trees" [I-D.ietf-rift-rift] and "RPL: IPv6 Routing Protocol for 492 Low-Power and Lossy Networks" [RFC6550] with [RPL-UNAWARE-LEAVES]. 494 WiND also enables to span a subnet over an MLSN that federates edge 495 wireless links with a high-speed, typically Ethernet, backbone. This 496 way, nodes can form any address they want and move freely from a 497 wireless edge link to another, without renumbering. Backbone Routers 498 (6BBRs) placed along the wireless edge of the Backbone handle IPv6 499 Neighbor Discovery and forward packets over the backbone on behalf of 500 the registered nodes on the wireless edge. For instance, a 6BBR in 501 bridging proxy mode (more in [BB-ROUTER]) can operate as a Layer-3 AP 502 to serve wireless IPv6 hosts that are Wi-Fi STAs and maintain the 503 reachability for Global Unicast and Link-LOcal Addresses within the 504 federated MLSN. 506 5.2. links and Link-Local Addresses 508 For Link-Local Addresses, DAD is typically performed between 509 communicating pairs of nodes and an NCE can be populated with a 510 single unicast exchange. In the case of a bridging proxies, though, 511 the Link-Local traffic is bridged over the backbone and the DAD must 512 proxied there as well. 514 For instance, in the case of Bluetooth Low Energy (BLE) 515 [RFC7668][IEEEstd802151], the uniqueness of Link-Local Addresses 516 needs only to be verified between the pair of communicating nodes, 517 the central router and the peripheral host. In that example, 2 518 peripheral hosts connected to the same central router can not have 519 the same Link-Local Address because the addresses would collision at 520 the central router which could not talk to both over the same 521 interface. The DAD operation from WiND is appropriate for that use 522 case, but the one from ND is not, because the peripheral hosts are 523 not on the same broadcast domain. 525 On the other hand, the uniqueness of Global and Unique-Local 526 Addresses is validated at the subnet Level, using a logical registrar 527 that is global to the subnet. 529 5.3. subnets and Global Addresses 531 WiND extends IPv6 ND for Hub-and-Spoke (e.g., BLE) and Route-Over 532 (e.g., RPL) Multi-link subnets (MLSNs). 534 In the Hub-and-Spoke case, each Hub-Spoke pair is a distinct IP Link, 535 and a subnet can be mapped on a collection of links that are 536 connected to the Hub. The subnet prefix is associated to the Hub. 538 Acting as routers, the Hub advertises the prefix as not-on-link to 539 the spokes in RA messages Prefix Information Options (PIO). Acting 540 as hosts, the Spokes autoconfigure addresses from that prefix and 541 register them to the Hub with a corresponding lifetime. Acting as a 542 registrar, the Hub maintains a binding table of all the registered IP 543 addresses and rejects duplicate registrations, thus ensuring a DAD 544 protection for a registered address even if the registering node is 545 sleeping. The Hub also maintains an NCE for the registered addresses 546 and can deliver a packet to any of them during their respective 547 lifetimes. It can be observed that this design builds a form of 548 Network-Layer Infrastructure BSS. 550 A Route-Over MLSN is considered as a collection of Hub-and-Spoke 551 where the Hubs form a connected dominating set of the member nodes of 552 the subnet, and IPv6 routing takes place between the Hubs within the 553 subnet. A single logical registrar is deployed to serve the whole 554 mesh. 556 The registration in [RFC8505] is abstract to the routing protocol and 557 provides enough information to feed a routing protocol such as RPL as 558 specified in [RPL-UNAWARE-LEAVES]. In a degraded mode, all the Hubs 559 are connected to a same high speed backbone such as an Ethernet 560 bridging domain where IPv6 ND is operated. In that case, it is 561 possible to federate the Hub, Spoke and Backbone nodes as a single 562 subnet, operating IPv6 ND proxy operations [BB-ROUTER] at the Hubs, 563 acting as 6BBRs. It can be observed that this latter design builds a 564 form of Network-Layer Infrastructure ESS. 566 6. WiND Applicability 568 WiND applies equally to P2P links, P2MP Hub-and-Spoke, Link-Layer 569 Broadcast Domain Emulation such as Mesh-Under and Wi-Fi BSS, and 570 Route-Over meshes. 572 There is an intersection where link and subnet are congruent and 573 where both ND and WiND could apply. These includes P2P, the MAC 574 emulation of a PHY broadcast domain, and the particular case of 575 always on, fully overlapping physical radio broadcast domain. But 576 even in those cases where both are possible, WiND is preferable vs. 577 ND because it reduces the need of broadcast. 579 This is discussed in more details in the introduction of [BB-ROUTER]. 581 There are also a number of practical use cases in the wireless world 582 where links and subnets are not congruent: 584 * The IEEE Std. 802.11 infrastructure BSS enables one subnet per AP, 585 and emulates a broadcast domain at the Link-Layer. The 586 Infrastructure ESS extends that model over a backbone and 587 recommends the use of an IPv6 ND proxy [IEEEstd80211] to 588 interoperate with Ethernet-connected nodes. WiND incorporates an 589 ND proxy to serve that need, which was missing so far. 591 * BlueTooth is Hub-and-Spoke at the Link-Layer. It would make 592 little sense to configure a different subnet between the central 593 and each individual peripheral node (e.g., sensor). Rather, 594 [RFC7668] allocates a prefix to the central node acting as router, 595 and each peripheral host (acting as a host) forms one or more 596 address(es) from that same prefix and registers it. 598 * A typical Smartgrid networks puts together Route-Over MLSNs that 599 comprise thousands of IPv6 nodes. The 6TiSCH architecture 600 [I-D.ietf-6tisch-architecture] presents the Route-Over model over 601 an IEEE Std. 802.15.4 Time-Slotted Channel-Hopping (TSCH) 602 [IEEEstd802154] mesh, and generalizes it for multiple other 603 applications. 605 Each node in a Smartgrid network may have tens to a hundred others 606 nodes in range. A key problem for the routing protocol is which 607 other node(s) should this node peer with, because most of the 608 possible peers do not provide added routing value. When both 609 energy and bandwidth are constrained, talking to them is a waste 610 of resources and most of the possible P2P links are not even used. 611 Peerings that are actually used come and go with the dynamics of 612 radio signal propagation. It results that allocating prefixes to 613 all the possible P2P links and maintain as many addresses in all 614 nodes is not even considered. 616 6.1. Case of LPWANs 618 LPWANs are by nature so constrained that the addresses and subnets 619 are fully pre-configured and operate as P2P or Hub-and-Spoke. This 620 saves the steps of neighbor Discovery and enables a very efficient 621 stateful compression of the IPv6 header. 623 6.2. Case of Infrastructure BSS and ESS 625 In contrast to IPv4, IPv6 enables a node to form multiple addresses, 626 some of them temporary to elusive, and with a particular attention 627 paid to privacy. Addresses may be formed and deprecated 628 asynchronously to the association. 630 Snooping protocols such as IPv6 ND and DHCPv6 and observing data 631 traffic sourced at the STA provides an imperfect knowledge of the 632 state of the STA at the AP. Missing a state or a transition may 633 result in the loss of connectivity for some of the addresses, in 634 particular for an address that is rarely used, belongs to a sleeping 635 node, or one in a situation of mobility. This may also result in 636 undesirable remanent state in the AP when the STA ceases to use an 637 IPv6 address while remaining associated. It results that snooping 638 protocols is not a recommended technique and that it should only be 639 used as last resort, when the WiND registration is not available to 640 populate the state. 642 The recommended alternative method is to use the WiND Registration 643 for IPv6 Addresses. This way, the AP exposes its capability to proxy 644 ND to the STA in Router Advertisement messages. In turn, the STA may 645 request proxy ND services from the AP for all of its IPv6 addresses, 646 using the Extended Address Registration Option, which provides the 647 following elements: 649 * The registration state has a lifetime that limits unwanted state 650 remanence in the network. 652 * The registration is optionally secured using [ADDR-PROTECT] to 653 prevent address theft and impersonation. 655 * The registration carries a sequence number, which enables to 656 figure the order of events in a fast mobility scenario without 657 loss of connectivity. 659 The ESS mode requires a proxy ND operation at the AP. The proxy ND 660 operation must cover Duplicate Address Detection, Neighbor 661 Unreachability Detection, Address Resolution and Address Mobility to 662 transfer a role of ND proxy to the AP where a STA is associated 663 following the mobility of the STA. 665 The WiND proxy ND specification that associated to the Address 666 Registration is [BB-ROUTER]. With that specification, the AP 667 participates to the protocol as a Backbone Router, typically 668 operating as a bridging proxy though the routing proxy operation is 669 also possible. As a bridging proxy, the backbone router either 670 replies to NS lookups with the MAC address of the STA, or preferably 671 forwards the lookups to the STA as Link-Layer unicast frames to let 672 the STA answer. For the data plane, the backbone router acts as a 673 normal AP and bridges the packets to the STA as usual. As a routing 674 proxy, the backbone router replies with its own MAC address and then 675 routes to the STA at the IP layer. The routing proxy reduces the 676 need to expose the MAC address of the STA on the wired side, for a 677 better stability and scalability of the bridged fabric. 679 6.3. Case of Mesh Under Technologies 681 The Mesh-Under provides a broadcast domain emulation with reflexive 682 and Transitive properties and defines a transit link for IPv6 683 operations. It results that the model for IPv6 operation is similar 684 to that of a BSS, with the root of the mesh operating as an Access 685 Point does in a BSS/ESS. 687 While it is still possible to operate IPv6 ND, the inefficiencies of 688 the flooding operation make the IPv6 ND operations even less 689 desirable than in a BSS, and the use of WiND is highly recommended. 691 6.4. Case of DMB radios 693 IPv6 over DMB radios uses P2P links that can be formed and maintained 694 when a pair of DMB radios transmitters are in range from one another. 696 6.4.1. Using IPv6 ND only 698 DMB radios do not provide MAC level broadcast emulation. An example 699 of that is IEEE Std. 802.11 OCB which uses IEEE Std. 802.11 MAC/PHYs 700 but does not provide the BSS functions. 702 It is possible to form P2P IP links between each individual pairs of 703 nodes and operate IPv6 ND over those links with Link-Local addresses. 704 DAD must be performed for all addresses on all P2P IP links. 706 If special deployment care is taken so that the physical broadcast 707 domains of a collection of the nodes fully overlap, then it is also 708 possible to build an IP subnet within that collection of nodes and 709 operate IPv6 ND. 711 If an external mechanism avoids duplicate addresses and if the 712 deployment ensures the connectivity between peers, a non-transit Hub- 713 and-Spoke deployment is also possible where the Hub is the only 714 router in the subnet and the Prefix is advertised as not on-link. 716 6.4.2. Using Wireless ND 718 Though this can be achieved with IPv6 ND, WiND is the recommended 719 approach since it uses unicast communications which are more reliable 720 and less impacting for other users of the medium. 722 The routers send RAs with a SLLAO at a regular period. The period 723 can be indicated in the RA-Interval Option [RFC6275]. If available, 724 the message can be transported in a compressed form in a beacon, 725 e.g., in OCB Basic Safety Messages (BSM) that are nominally sent 726 every 100ms. 728 An active beaconing mode is possible whereby the Host sends broadcast 729 RS messages to which a router can answer with a unicast RA. 731 A router that has Internet connectivity and is willing to serve as an 732 Internet Access may advertise itself as a default router [RFC4191] in 733 its RA messages. The RA is sent over an unspecified link where it 734 does not conflict to anyone, so DAD is not necessary at that stage. 736 The host instantiates a link where the router's address is not a 737 duplicate. To achieve this, it forms an LLA that does not conflict 738 with that of the router and registers to the router using [RFC8505]. 739 If the router sent an RA(PIO), the host can also autoconfigure an 740 address from the advertised prefix and register it. 742 (host) (router) 743 | | 744 | DMB link | 745 | | 746 | IPv6 ND RS | 747 |-------------->| 748 |-----------> | 749 |------------------> 750 | IPv6 ND RA | 751 |<--------------| 752 | | 753 | NS(EARO) | 754 |-------------->| 755 | | 756 | NA(EARO) | 757 |<--------------| 758 | | 760 Figure 1: Initial Registration Flow 762 The lifetime in the registration should start with a small value 763 (X=RMin, TBD), and exponentially grow with each re-registration to a 764 larger value (X=Rmax, TBD). The IP link is considered down when 765 (X=NbBeacons, TDB) expected messages are not received in a row. It 766 must be noted that the link flapping does not affect the state of the 767 registration and when a link comes back up, the active registrations 768 (i.e., registrations for which lifetime is not elapsed) are still 769 usable. Packets should be held or destroyed when the link is down. 771 P2P links may be federated in Hub-and-Spoke and then in Route-Over 772 MLSNs as illustrated in Figure 2. More details on the operation of 773 WiND and RPL over the MLSN can be found in section 3.1, 3.2, 4.1 and 774 4.2.2 of [I-D.ietf-6tisch-architecture]. 776 6LoWPAN Node 6LR 6LBR 6BBR 777 (RPL leaf) (router) (root) 778 | | | | 779 | 6LoWPAN ND |6LoWPAN ND+RPL | 6LoWPAN ND | IPv6 ND 780 | LLN link |Route-Over mesh|Ethernet/serial| Backbone 781 | | | | 782 | IPv6 ND RS | | | 783 |-------------->| | | 784 |-----------> | | | 785 |------------------> | | 786 | IPv6 ND RA | | | 787 |<--------------| | | 788 | | | | 789 | NS(EARO) | | | 790 |-------------->| | | 791 | 6LoWPAN ND | Extended DAR | | 792 | |-------------->| | 793 | | | NS(EARO) | 794 | | |-------------->| 795 | | | | NS-DAD 796 | | | |------> 797 | | | | (EARO) 798 | | | | 799 | | | NA(EARO) | 800 | | |<--------------| 801 | | Extended DAC | | 802 | |<--------------| | 803 | NA(EARO) | | | 804 |<--------------| | | 805 | | | | 807 Figure 2: Initial Registration Flow over Multi-link subnet 809 An example Hub-and-Spoke is an OCB Road-Side Unit (RSU) that owns a 810 prefix, provides Internet connectivity using that prefix to On-Board 811 Units (OBUs) within its physical broadcast domain. An example of 812 Route-Over MLSN is a collection of cars in a parking lot operating 813 RPL to extend the connectivity provided by the RSU beyond its 814 physical broadcast domain. Cars may then operate NEMO [RFC3963] for 815 their own prefix using their address derived from the prefix of the 816 RSU as CareOf Address. 818 7. IANA Considerations 820 This specification does not require IANA action. 822 8. Security Considerations 824 This specification refers to the security sections of IPv6 ND and 825 WiND, respectively. 827 9. Acknowledgments 829 Many thanks to the participants of the 6lo WG where a lot of the work 830 discussed here happened. Also ROLL, 6TiSCH, and 6LoWPAN. 832 10. Normative References 834 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 835 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 836 RFC 3963, DOI 10.17487/RFC3963, January 2005, 837 . 839 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 840 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 841 November 2005, . 843 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 844 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 845 DOI 10.17487/RFC4861, September 2007, 846 . 848 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 849 Address Autoconfiguration", RFC 4862, 850 DOI 10.17487/RFC4862, September 2007, 851 . 853 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 854 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 855 2011, . 857 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 858 (IPv6) Specification", STD 86, RFC 8200, 859 DOI 10.17487/RFC8200, July 2017, 860 . 862 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 863 Perkins, "Registration Extensions for IPv6 over Low-Power 864 Wireless Personal Area Network (6LoWPAN) Neighbor 865 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 866 . 868 [ADDR-PROTECT] 869 Thubert, P., Sarikaya, B., Sethi, M., and R. Struik, 870 "Address Protected Neighbor Discovery for Low-power and 871 Lossy Networks", Work in Progress, Internet-Draft, draft- 872 ietf-6lo-ap-nd-20, 9 March 2020, 873 . 875 [BB-ROUTER] 876 Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 877 Backbone Router", Work in Progress, Internet-Draft, draft- 878 ietf-6lo-backbone-router-20, 23 March 2020, 879 . 882 11. Informative References 884 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 885 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 886 2006, . 888 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 889 DOI 10.17487/RFC4903, June 2007, 890 . 892 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 893 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 894 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 895 Low-Power and Lossy Networks", RFC 6550, 896 DOI 10.17487/RFC6550, March 2012, 897 . 899 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 900 Bormann, "Neighbor Discovery Optimization for IPv6 over 901 Low-Power Wireless Personal Area Networks (6LoWPANs)", 902 RFC 6775, DOI 10.17487/RFC6775, November 2012, 903 . 905 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 906 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 907 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 908 . 910 [RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix 911 per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017, 912 . 914 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 915 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 916 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 917 RFC 8415, DOI 10.17487/RFC8415, November 2018, 918 . 920 [I-D.ietf-rift-rift] 921 Przygienda, T., Sharma, A., Thubert, P., Rijsman, B., and 922 D. Afanasiev, "RIFT: Routing in Fat Trees", Work in 923 Progress, Internet-Draft, draft-ietf-rift-rift-11, 10 924 March 2020, 925 . 927 [RPL-UNAWARE-LEAVES] 928 Thubert, P. and M. Richardson, "Routing for RPL Leaves", 929 Work in Progress, Internet-Draft, draft-ietf-roll-unaware- 930 leaves-13, 17 March 2020, . 933 [DAD-ISSUES] 934 Yourtchenko, A. and E. Nordmark, "A survey of issues 935 related to IPv6 Duplicate Address Detection", Work in 936 Progress, Internet-Draft, draft-yourtchenko-6man-dad- 937 issues-01, 3 March 2015, . 940 [MCAST-EFFICIENCY] 941 Vyncke, E., Thubert, P., Levy-Abegnoli, E., and A. 942 Yourtchenko, "Why Network-Layer Multicast is Not Always 943 Efficient At Datalink Layer", Work in Progress, Internet- 944 Draft, draft-vyncke-6man-mcast-not-efficient-01, 14 945 February 2014, . 948 [I-D.ietf-6tisch-architecture] 949 Thubert, P., "An Architecture for IPv6 over the TSCH mode 950 of IEEE 802.15.4", Work in Progress, Internet-Draft, 951 draft-ietf-6tisch-architecture-28, 29 October 2019, 952 . 955 [MCAST-PROBLEMS] 956 Perkins, C., McBride, M., Stanley, D., Kumari, W., and J. 957 Zuniga, "Multicast Considerations over IEEE 802 Wireless 958 Media", Work in Progress, Internet-Draft, draft-ietf- 959 mboned-ieee802-mcast-problems-11, 11 December 2019, 960 . 963 [SAVI] Bi, J., Wu, J., Wang, Y., and T. Lin, "A SAVI Solution for 964 WLAN", Work in Progress, Internet-Draft, draft-bi-savi- 965 wlan-18, 17 November 2019, 966 . 968 [UNICAST-AR] 969 Thubert, P. and E. Levy-Abegnoli, "IPv6 Neighbor Discovery 970 Unicast Lookup", Work in Progress, Internet-Draft, draft- 971 thubert-6lo-unicast-lookup-00, 25 January 2019, 972 . 975 [IEEE802154] 976 IEEE standard for Information Technology, "IEEE Std. 977 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 978 and Physical Layer (PHY) Specifications for Low-Rate 979 Wireless Personal Area Networks". 981 [IEEEstd80211] 982 IEEE standard for Information Technology, "IEEE Standard 983 for Information technology -- Telecommunications and 984 information exchange between systems Local and 985 metropolitan area networks-- Specific requirements Part 986 11: Wireless LAN Medium Access Control (MAC) and Physical 987 Layer (PHY) Specifications". 989 [IEEEstd802151] 990 IEEE standard for Information Technology, "IEEE Standard 991 for Information Technology - Telecommunications and 992 Information Exchange Between Systems - Local and 993 Metropolitan Area Networks - Specific Requirements. - Part 994 15.1: Wireless Medium Access Control (MAC) and Physical 995 Layer (PHY) Specifications for Wireless Personal Area 996 Networks (WPANs)". 998 [IEEEstd802154] 999 IEEE standard for Information Technology, "IEEE Standard 1000 for Local and metropolitan area networks -- Part 15.4: 1001 Low-Rate Wireless Personal Area Networks (LR-WPANs)". 1003 [IEEEstd8021] 1004 IEEE standard for Information Technology, "IEEE Standard 1005 for Information technology -- Telecommunications and 1006 information exchange between systems Local and 1007 metropolitan area networks Part 1: Bridging and 1008 Architecture". 1010 Author's Address 1011 Pascal Thubert (editor) 1012 Cisco Systems, Inc 1013 Building D 1014 45 Allee des Ormes - BP1200 1015 06254 Mougins - Sophia Antipolis 1016 France 1018 Phone: +33 497 23 26 34 1019 Email: pthubert@cisco.com