idnits 2.17.1 draft-thubert-6man-ipv6-over-wireless-04.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 (September 26, 2019) is 1674 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-23) exists of draft-ietf-6lo-ap-nd-12 == Outdated reference: A later version (-20) exists of draft-ietf-6lo-backbone-router-13 == Outdated reference: A later version (-24) exists of draft-bi-savi-wlan-17 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-26 == Outdated reference: A later version (-15) exists of draft-ietf-mboned-ieee802-mcast-problems-08 == Outdated reference: A later version (-21) exists of draft-ietf-rift-rift-08 == 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: Informational September 26, 2019 5 Expires: March 29, 2020 7 IPv6 Neighbor Discovery on Wireless Networks 8 draft-thubert-6man-ipv6-over-wireless-04 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 March 29, 2020. 33 Copyright Notice 35 Copyright (c) 2019 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 5 52 3. IP Models . . . . . . . . . . . . . . . . . . . . . . . . . . 6 53 3.1. Physical Broadcast Domain . . . . . . . . . . . . . . . . 6 54 3.2. MAC-Layer Broadcast Emulations . . . . . . . . . . . . . 7 55 3.3. Mapping the IPv6 Link Abstraction . . . . . . . . . . . . 8 56 3.4. Mapping the IPv6 Subnet Abstraction . . . . . . . . . . . 9 57 4. Wireless ND . . . . . . . . . . . . . . . . . . . . . . . . . 10 58 4.1. Introduction to WiND . . . . . . . . . . . . . . . . . . 10 59 4.2. Links and Link-Local Addresses . . . . . . . . . . . . . 11 60 4.3. Subnets and Global Addresses . . . . . . . . . . . . . . 12 61 5. WiND Applicability . . . . . . . . . . . . . . . . . . . . . 12 62 5.1. Case of LPWANs . . . . . . . . . . . . . . . . . . . . . 13 63 5.2. Case of Infrastructure BSS and ESS . . . . . . . . . . . 13 64 5.3. Case of Mesh Under Technologies . . . . . . . . . . . . . 14 65 5.4. Case of DMC radios . . . . . . . . . . . . . . . . . . . 15 66 5.4.1. Using IPv6 ND only . . . . . . . . . . . . . . . . . 15 67 5.4.2. Using Wireless ND . . . . . . . . . . . . . . . . . . 15 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 70 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 72 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 73 9.2. Informative References . . . . . . . . . . . . . . . . . 19 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 76 1. Introduction 78 IEEE STD. 802.1 [IEEEstd8021] Ethernet Bridging provides an efficient 79 and reliable broadcast service for wired networks; applications and 80 protocols have been built that heavily depend on that feature for 81 their core operation. Unfortunately, Low-Power Lossy Networks (LLNs) 82 and local wireless networks generally do not provide the broadcast 83 capabilities of Ethernet Bridging in an economical fashion. 85 As a result, protocols designed for bridged networks that rely on 86 multicast and broadcast often exhibit disappointing behaviours when 87 employed unmodified on a local wireless medium (see 88 [I-D.ietf-mboned-ieee802-mcast-problems]). 90 Wi-Fi [IEEEstd80211] Access Points (APs) deployed in an Extended 91 Service Set (ESS) act as Ethernet Bridges [IEEEstd8021], with the 92 property that the bridging state is established at the time of 93 association. This ensures connectivity to the node (STA) and 94 protects the wireless medium against broadcast-intensive Transparent 95 Bridging reactive Lookups. 97 In other words, the association process is used to register the MAC 98 Address of the STA to the AP. The AP subsequently proxies the 99 bridging operation and does not need to forward the broadcast Lookups 100 over the radio. 102 Like Transparent Bridging, IPv6 [RFC8200] Neighbor Discovery 103 [RFC4861] [RFC4862] Protocol (IPv6 ND) is a reactive protocol, based 104 on multicast transmissions to locate an on-link correspondent and 105 ensure the uniqueness of an IPv6 address. The mechanism for 106 Duplicate Address Detection (DAD) [RFC4862] was designed for the 107 efficient broadcast operation of Ethernet Bridging. Since broadcast 108 can be unreliable over wireless media, DAD often fails to discover 109 duplications [I-D.yourtchenko-6man-dad-issues]. In practice, IPv6 110 addresses very rarely conflict because of the entropy of the 64-bit 111 Interface IDs, not because address duplications are detected and 112 resolved. 114 The IPv6 ND Neighbor Solicitation (NS) [RFC4861] message is used for 115 DAD and Address Resolution (AR) when a node moves, or wakes up and 116 reconnects to the wireless network. The NS message is targeted to a 117 Solicited-Node Multicast Address (SNMA) [RFC4291] and should in 118 theory only reach a very small group of nodes. It must be noted that 119 in the the case of Ethernet LANs as well as most WLANs and LPWANs, 120 the Layer-3 multicast operation becomes a MAC_Layer broadcast for the 121 lack of a Layer-2 multicast operation that could handle a possibly 122 very large number of groups in order to make the unicast efficient. 123 It results that IPv6 ND messages are processed by most of the 124 wireless nodes over the subnet (e.g., the ESS fabric) regardless of 125 how few of the nodes are subscribed to the SNMA. 127 IPv6 ND address Lookups and DADs over a large fabric can generate 128 hnudreds of broadcasts per second. If the broadcasts were blindly 129 copied over Wi-Fi and/or over a LowPower Lossy Network (LLN), the ND- 130 related multicast could consume enough bandwidth to cause a 131 substantial degradation to the unicast traffic service 132 [I-D.vyncke-6man-mcast-not-efficient]. To protect their bandwidth, 133 some networks throttle ND-related broadcasts, which reduces the 134 capability of the protocol to perform as expected. 136 Conversely, a Wi-Fi station must keep its radio turned on to listen 137 to the periodic series of broadcast frames, which for the most part 138 will be dropped when they reach Layer-3. In order to avoid this 139 waste of energy and increase its battery life, a typical battery- 140 operated device such as an IoT sensor or a smartphone will blindly 141 ignore a ratio of the broadcasts, making IPv6 ND operations even less 142 reliable. 144 These problems can be alleviated by reducing the IPv6 ND broadcasts 145 over wireless access links. This has been done by splitting the 146 broadcast domains and by routing between subnets, at the extreme by 147 assigning a /64 prefix to each wireless node (see [RFC8273]). 149 Another way is to proxy at the boundary of the wired and wireless 150 domains the Layer-3 protocols that rely on MAC Layer broadcast 151 operations. For instance, IEEE 802.11 [IEEEstd80211] situates proxy- 152 ARP (IPv4) and proxy-ND (IPv6) functions at the Access Points (APs). 154 But proxying ND requires a perfect knowledge of the peer IPv6 155 addresses for which proxying is provided. In a generic fashion, 156 radio connectivity changes with movements and variations in the 157 environment, which makes forming and maintaining that knowledge a 158 hard problem in the general case. 160 Discovering peer addresses by snooping the IPV6 ND protocol as 161 proposed for SAVI [I-D.bi-savi-wlan] was found to be unreliable. An 162 IPv6 address may not be discovered immediately due to a packet loss, 163 or if a "silent" node is not currently using one of its addresses, 164 e.g., a node that waits in wake-on-lan state. A change of state, 165 e.g. due to a movement, may be missed or misordered, leading to 166 unreliable connectivity and an incomplete knowledge of the set of 167 peers. 169 Wireless ND (WiND) introduces a new approach to IPv6 ND that is 170 designed to apply to the WLANs and WPANs types of networks. On the 171 one hand, WiND avoids the use of broadcast operation for DAD and AR, 172 and on the other hand, WiND supports use cases where Subnet and MAC- 173 level domains are not congruent, which is common in those types of 174 networks unless a specific MAC-Level emulation is provided. WiND 175 applies routing inside the Subnets, which enables MultiLink Subnets. 176 Hosts register their addresses to their serving routers with 177 [RFC8505]. With the registration, routers have a complete knowledge 178 of the hosts they serve and in return, hosts obtain routing services 179 for their registered addresses. The registration is abstract to the 180 routing protocol, and it can be protected to prevent impersonation 181 attacks with [I-D.ietf-6lo-ap-nd]. 183 The routing service can be a simple reflexion in a Hub-and-Spoke 184 Subnet that emulates an IEEE Std 802.11 Infrastructure BSS at Layer 185 3. It can also be a full-fledge routing protocol, in particular RPL 186 [RFC6550] that was designed to adapt to various LLNs such as WLAN and 187 WPAN radio meshes with the concept of Objective Function. Finally, 188 the routing service can also be ND proxy that emulates an IEEE Std 189 802.11 Infrastructure ESS at Layer 3. WiND specifies the IPv6 190 Backbone Router for that purpose in [I-D.ietf-6lo-backbone-router]. 191 More details on WiND can be found in Section 4.1. 193 2. Acronyms 195 This document uses the following abbreviations: 197 6BBR: 6LoWPAN Backbone Router 199 6LBR: 6LoWPAN Border Router 201 6LN: 6LoWPAN Node 203 6LR: 6LoWPAN Router 205 ARO: Address Registration Option 207 DAC: Duplicate Address Confirmation 209 DAD: Duplicate Address Detection 211 DAR: Duplicate Address Request 213 EDAC: Extended Duplicate Address Confirmation 215 EDAR: Extended Duplicate Address Request 217 MLSN: Multi-Link Subnet 219 LLN: Low-Power and Lossy Network 221 NA: Neighbor Advertisement 223 NBMA: Non-Broadcast Multi-Access 225 NCE: Neighbor Cache Entry 227 ND: Neighbor Discovery 229 NDP: Neighbor Discovery Protocol 231 NS: Neighbor Solicitation 233 RPL: IPv6 Routing Protocol for LLNs 235 RA: Router Advertisement 237 RS: Router Solicitation 239 WiND: Wireless Neighbor Discovery 240 WLAN: Wireless Local Area Network 242 WPAN: Wireless Personal Area Network 244 3. IP Models 246 3.1. Physical Broadcast Domain 248 At the physical (PHY) Layer, a broadcast domain is the set of nodes 249 that may receive a datagram that one sends over an interface, in 250 other words the set of nodes in range of radio transmission. This 251 set can comprise a single peer on a serial cable used as point-to- 252 point (P2P) link. It may also comprise multiple peer nodes on a 253 broadcast radio or a shared physical resource such as the legacy 254 Ethernet shared wire. 256 On WLAN and WPAN radios, the physical broadcast domain is defined by 257 a particular transmitter, as the set of nodes that can receive what 258 this transmitter is sending. Literally every datagram defines its 259 own broadcast domain since the chances of reception of a given 260 datagram are statistical. In average and in stable conditions, the 261 broadcast domain of a particular node can be still be seen as mostly 262 constant and can be used to define a closure of nodes on which an 263 upper-layer abstraction can be built. 265 A PHY-layer communication can be established between 2 nodes if their 266 physical broadcast domains overlap. 268 On WLAN and WPAN radios, this property is usually reflexive, meaning 269 that if B can receive a datagram from A, then A can receive a 270 datagram from B. But there can be asymmetries due to power levels, 271 interferers near one of the receivers, or differences in the quality 272 of the hardware (e.g., crystals, PAs and antennas) that may affect 273 the balance to the point that the connectivity becomes mostly uni- 274 directional, e.g., A to B but practically not B to A. It takes a 275 particular effort to place a set of devices in a fashion that all 276 their physical broadcast domains fully overlap, and it can not be 277 assumed in the general case. In other words, the property of radio 278 connectivity is generally not transitive, meaning that A may be in 279 range with B and B may be in range with C does not necessarily imply 280 that A is in range with C. 282 We define Direct MAC-Layer Broadcast (DMC) a transmission mode where 283 the broadcast domain that is usable at the MAC layer is directly the 284 physical broadcast domain. IEEE 802.15.4 [IEEE802154] and IEEE 285 802.11 OCB [IEEEstd80211] (for Out of the Context of a BSS) are 286 examples of DMC radios. This contrasts with a number of MAC-layer 287 Broadcast Emulation schemes that are described in the next section. 289 3.2. MAC-Layer Broadcast Emulations 291 While a physical broadcast domain is constrained to a single shared 292 wire, Ethernet Bridging emulates the broadcast properties of that 293 wire over a whole physical mesh of Ethernet links. For the upper 294 layer, the qualities of the shared wire are essentially conserved, 295 with a reliable and cheap broadcast operation over a closure of nodes 296 defined by their connectivity to the emulated wire. 298 In large switched fabrics, overlay techniques enable a limited 299 connectivity between nodes that are known to a mapping server. The 300 emulated broadcast domain is configured to the system, e.g., with a 301 VXLAN network identifier (VNID). Broadcast operations on the overlay 302 can be emulated but can become very expensive, and it makes sense to 303 proactively install the relevant state in the mapping server as 304 opposed to rely on reactive broadcast lookups. 306 An IEEE Std 802.11 Infrastructure Basic Service Set (BSS) also 307 provides a closure of nodes as defined by the broadcast domain of a 308 central Access Point (AP). The AP relays both unicast and broadcast 309 packets and ensures a reflexive and transitive emulation of the 310 shared wire between the associated nodes, with the capability to 311 signal link-up/link-down to the upper layer. Within an 312 Infrastructure BSS, the physical broadcast domain of the AP serves as 313 emulated broadcast domain for all the nodes that are associated to 314 the AP. Broadcast packets are relayed by the AP and are not 315 acknowledged. To ensure that all nodes in the BSS receive the 316 broadcast transmission, AP transmits at the slowest PHY speed. This 317 translates into maximum co-channel interferences for others and 318 longest occupancy of the medium, for a duration that can be 100 times 319 that of a unicast. For that reason, upper layer protocols should 320 tend to avoid the use of broadcast when operating over Wi-Fi. 322 In an IEEE Std 802.11 Infrastructure Extended Service Set (ESS), 323 infrastructure BSSes are interconnected by a bridged network, 324 typically running Transparent Bridging and Spanning tree Protocol. 325 In the original model of learning bridges, the state in the 326 Transparent Bridge is set by observing the source MAC address of the 327 frames. When a state is missing for a destination MAC address, the 328 frame is broadcasted with the expectation that the response will 329 populate the state. This is a reactive operation, meaning that the 330 state is populated reactively to a need for forwarding. It is also 331 possible in the original model to send a gratuitous frame to 332 advertise self throughout the bridged network, and that is also a 333 broadcast. 335 In contrast, the process of the Wi-Fi association prepares a bridging 336 state proactively at the AP, which avoids the need for a reactive 337 broadcast lookup over the wireless access. The AP may also generate 338 a gratuitous broadcast sourced at the MAC address of the STA to 339 prepare or update the state in the learning bridges so they point 340 towards the AP for the MAC address of the STA. With WiND, IPv6 ND 341 evolves towards similar proactive methods at Layer-3 for its 342 operation of address discovery (AD) and duplicate address detection 343 (DAD). 345 In some cases of WLAN and WPAN radios, a mesh-under technology (e.g., 346 a IEEE 802.11s or IEEE 802.15.10) provides meshing services that are 347 similar to bridging, and the broadcast domain is well defined by the 348 membership of the mesh. Mesh-Under emulates a broadcast domain by 349 flooding the broadcast packets at Layer-2. When operating on a 350 single frequency, this operation is known to interfere with itself, 351 forcing deployment to introduce delays that dampen the collisions. 352 All in all, the mechanism is slow, inefficient and expensive. 354 Going down the list of cases above, the cost of a broadcast 355 transmissions becomes increasingly expensive, and there is a push to 356 rethink the upper-layer protocols so as to reduce the depency on 357 broadcast operations. 359 There again, a MAC-layer communication can be established between 2 360 nodes if their MAC-layer broadcast domains overlap. In the absence 361 of a MAC-layer emulation such as a mesh-under or an Infrastructure 362 BSS, the MAC-layer broadcast domain is congruent with that of the 363 PHY-layer and inherits its properties for reflexivity and 364 transitivity. IEEE 802.11 OCB, which operates Out of the Context of 365 a BSS (DMC radios) is an example of a network that does not have a 366 MAC-Layer broadcast domain emulation, which means that it will 367 exhibit mostly reflexive and mostly non-transitive transmission 368 properties. 370 3.3. Mapping the IPv6 Link Abstraction 372 IPv6 defines a concept of Link, Link Scope and Link-Local Addresses 373 (LLA), an LLA being unique and usable only within the Scope of a 374 Link. The IPv6 Neighbor Discovery (ND) [RFC4861][RFC4862] Duplicate 375 Adress Detection (DAD) process leverages a multicast transmission to 376 ensure that an IPv6 address is unique as long as the owner of the 377 address is connected to the broadcast domain. It must be noted that 378 in all the cases in this specification, the Layer-3 multicast 379 operation is always a MAC_Layer broadcast for the lack of a Layer-2 380 multicast operation that could handle a possibly very large number of 381 groups in order to make the unicast efficient. This means that for 382 every multicast packet regardless of the destination group, all nodes 383 will receive the packet and process it all the way to Layer-3. 385 On wired media, the Link is often confused with the physical 386 broadcast domain because both are determined by the serial cable or 387 the Ethernet shared wire. Ethernet Bridging reinforces that illusion 388 by provising a MAC-Layer broadcast domain that emulates a physical 389 broadcast domain over the mesh of wires. But the difference shows on 390 legacy Non-Broadcast Multi-Access (NBMA) such as ATM and Frame-Relay, 391 on shared links and on newer types of NBMA networks such as radio and 392 composite radio-wires networks. It also shows when private VLANs or 393 Layer-2 cryptography restrict the capability to read a frame to a 394 subset of the connected nodes. 396 In mesh-under and Infrastructure BSS, the IP Link extends beyond the 397 physical broadcast domain to the emulated MAC-Layer broadcast domain. 398 Relying on Multicast for the ND operation remains feasible but 399 becomes detrimental to unicast traffic, energy-inefficient and 400 unreliable, and its use is discouraged. 402 On DMC radios, IP Links between peers come and go as the individual 403 physical broadcast domains of the transmitters meet and overlap. The 404 DAD operation cannot provide once and for all guarantees on the 405 broadcast domain defined by one radio transmitter if that transmitter 406 keeps meeting new peers on the go. The nodes may need to form new 407 LLAs to talk to one another and the scope where LLA uniqueness can be 408 dynamically checked is that pair of nodes. As long as there's no 409 conflict a node may use the same LLA with multiple peers but it has 410 to revalidate DAD with every new peer node. In practice, each pair 411 of nodes defines a temporary P2P link, which can be modeled as a sub- 412 interface of the radio interface. 414 3.4. Mapping the IPv6 Subnet Abstraction 416 IPv6 also defines a concept of Subnet for Glocal and Unique Local 417 Addresses. Addresses in a same Subnet share a same prefix and by 418 extension, a node belongs to a Subnet if it has an interface with an 419 address on that Subnet. A Subnet prefix is Globally Unique so it is 420 sufficient to validate that an address that is formed from a Subnet 421 prefix is unique within that Subnet to guarantee that it is globally 422 unique. IPv6 aggregation relies on the property that a packet from 423 the outside of a Subnet can be routed to any router that belongs to 424 the Subnet, and that this router will be able to either resolve the 425 destination MAC address and deliver the packet, or route the packet 426 to the destination within the Subnet. If the Subnet is known as 427 onlink, then any node may also resolve the destination MAC address 428 and deliver the packet, but if the Subnet is not onlink, then a host 429 that does not have an NCE for the destination will need to pass the 430 packet to a router. 432 On IEEE Std. 802.3, a Subnet is often congruent with an IP Link 433 because both are determined by the physical attachment to an Ethernet 434 shared wire or an IEEE Std. 802.1 bridged broadcast domain. In that 435 case, the connectivity over the Link is transitive, the Subnet can 436 appear as onlink, and any node can resolve a destination MAC address 437 of any other node directly using IPv6 Neighbor Discovery. 439 But an IP Link and an IP Subnet are not always congruent. In a 440 shared Link situation, a Subnet may encompass only a subset of the 441 nodes connected to the Link. In Route-Over Multi-Link Subnets (MLSN) 442 [RFC4903], routers federate the Links between nodes that belong to 443 the Subnet, the Subnet is not onlink and it extends beyond any of the 444 federated Links. 446 The DAD and lookup procedures in IPv6 ND expects that a node in a 447 Subnet is reachable within the broadcast domain of any other node in 448 the Subnet when that other node attempts to form an address that 449 would be a duplicate or attempts to resolve the MAC address of this 450 node. This is why ND is only applicable for P2P and transit links, 451 and requires extensions for other topologies. 453 4. Wireless ND 455 4.1. Introduction to WiND 457 Wireless Neighbor Discovery (WiND) 458 [RFC6775][RFC8505][I-D.ietf-6lo-backbone-router][I-D.ietf-6lo-ap-nd] 459 defines a new ND operation that is based on 2 major paradigm changes, 460 proactive address registration by hosts to their attachment routers 461 and routing to host routes (/128) within the subnet. This allows 462 WiND to avoid the classical ND expectations of transit links and 463 Subnet-wide broadcast domains. 465 The proactive address registration is performed with a new option in 466 NS/NA messages, the Extended Address Registration Option (EARO) 467 defiend in [RFC8505]. This method allows to prepare and maintain the 468 host routes in the routers and avoids the reactive NS(Lookup) found 469 in IPv6 ND. This is a direct benefit for wireless Links since it 470 avoids the MAC level broadcasts that are associated to NS(Lookup). 472 The EARO provides information to the router that is independent to 473 the routing protocol and routing can take multiple forms, from a 474 traditional IGP to a collapsed ub-and-Spoke model where only one 475 router owns and advertises the prefix. [RFC8505] is already 476 referenced for RIFT [I-D.ietf-rift-rift], RPL [RFC6550] with 477 [I-D.thubert-roll-unaware-leaves] and IPv6 ND proxy 478 [I-D.ietf-6lo-backbone-router]. 480 WiND does not change IPv6 addressing [RFC4291] or the current 481 practices of assigning prefixes to subnets. It is still typical to 482 assign a /64 to a subnet and to use interface IDs of 64 bits. 483 Duplicate Address detection within the Subnet is performed with a 484 central registrar, using new ND Extended Duplicate Address messages 485 (EDAR and EDAC) [RFC8505]. This operation modernizes ND for 486 application in overlays with Map Resolvers and enables unicast 487 lookups [I-D.thubert-6lo-unicast-lookup] for addresses registered to 488 the resolver. 490 WiND also enables to extend a legacy /64 on Ethernet with ND proxy 491 over the wireless. This way nodes can form any address the want and 492 move freely from an L3-AP (that is really a backbone router in 493 bridging mode, more in [I-D.ietf-6lo-backbone-router]) to another, 494 without renumbering. Backbone Routers federate multiple LLNs over a 495 Backbone Link to form a MultiLink Subnet (MLSN). Backbone Routers 496 placed along the LLN edge of the Backbone handle IPv6 Neighbor 497 Discovery, and forward packets on behalf of registered nodes. 499 An LLN node (6LN) registers all its IPv6 Addresses using an NS(EARO) 500 as specified in [RFC8505] to the 6BBR. The 6BBR is also a Border 501 Router that performs IPv6 Neighbor Discovery (IPv6 ND) operations on 502 its Backbone interface on behalf of the 6LNs that have registered 503 addresses on its LLN interfaces without the need of a broadcast over 504 the wireless medium. 506 WiND is also compatible with DHCPv6 and other forms of address 507 assignment in which case it can still be used for DAD. 509 4.2. Links and Link-Local Addresses 511 For Link-Local Addresses, DAD is performed between communicating 512 pairs of nodes. It is carried out as part of a registration process 513 that is based on a NS/NA exchange that transports an EARO. During 514 that process, the DAD is validated and a Neighbor Cache Entry (NCE) 515 is populated with a single unicast exchange. 517 For instance, in the case of a Bluetooth Low Energy (BLE) 518 [RFC7668][IEEEstd802151] Hub-and Spoke configuration, Uniqueness of 519 Link local Addresses need only to be verified between the pairs of 520 communicating nodes, a central router and a peripheral host. In that 521 example, 2 peripheral hosts connected to the same central router can 522 not have the same Link Local Address because the Binding Cache 523 Entries (BCEs) would collide at the central router which could not 524 talk to both over the same interface. The WiND operation is 525 appropriate for that DAD operation, but the one from ND is not, 526 because peripheral hosts are not on the same broadcast domain. On 527 the other hand, Global and ULA DAD is validated at the Subnet Level, 528 using a registrar hosted by the central router. 530 4.3. Subnets and Global Addresses 532 WiND extends IPv6 ND for Hub-and-Spoke (e.g., BLE) and Route-Over 533 (e.g., RPL) Multi-Link Subnets (MLSNs). 535 In the Hub-and-Spoke case, each Hub-Spoke pair is a distinct IP Link, 536 and a Subnet can be mapped on a collection of Links that are 537 connected to the Hub. The Subnet prefix is associated to the Hub. 538 Acting as 6LR, the Hub advertises the prefix as not-onlink to the 539 spokes in RA messages Prefix Information Options (PIO). Acting as 540 6LNs, the Spokes autoconfigure addresses from that prefix and 541 register them to the Hub with a corresponding lifetime. Acting as a 542 6LBR, 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. Acting as 6LR, the Hub also maintains an NCE for the 546 registered addresses and can deliver a packet to any of them for 547 their respective lifetimes. It can be observed that this design 548 builds a form of Layer-3 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 6LBR is deployed to serve the whole mesh. 554 The registration in [RFC8505] is abstract to the routing protocol and 555 provides enough information to feed a routing protocol such as RPL as 556 specified in [I-D.thubert-roll-unaware-leaves]. In a degraded mode, 557 all the Hubs are connected to a same high speed backbone such as an 558 Ethernet bridging domain where IPv6 ND is operated. In that case, it 559 is possible to federate the Hub, Spoke and Backbone nodes as a single 560 Subnet, operating IPv6 ND proxy operations 561 [I-D.ietf-6lo-backbone-router] at the Hubs, acting as 6BBRs. It can 562 be observed that this latter design builds a form of Layer-3 563 Infrastructure ESS. 565 5. WiND Applicability 567 WiND allows P2P, P2MP hub-and spoke, MAC-level broadcast domain 568 emulation such as mesh-under and Wi-Fi BSS, and Route-Over meshes. 570 There is an intersection where Link and Subnet are congruent and 571 where both ND and WiND could apply. These includes P2P, the MAC 572 emulation of a PHY broadcast domain, and the particular case of 573 always on, fully overlapping physical radio broadcast domain. But 574 even in those cases where both are possible, WiND is preferable vs. 576 ND because it reduces the need of broadcast ( this is discussed in 577 the introduction of [I-D.ietf-6lo-backbone-router]). 579 There are also numerous practical use cases in the wireless world 580 where Links and Subnets are not P2P and not congruent: 582 o IEEE std 802.11 infrastructure BSS enables one subnet per AP, and 583 emulates a broadcast domain at L2. Infra ESS extends that and 584 recommends to use an IPv6 ND proxy [IEEEstd80211] to coexist with 585 Ethernet connected nodes. WiND incorporates an ND proxy to serve 586 that need and that was missing so far. 588 o BlueTooth is Hub-and-Spoke at the MAC layer. It would make little 589 sense to configure a different subnet between the central and each 590 individual peripheral node (e.g., sensor). Rather, [RFC7668] 591 allocates a prefix to the central node acting as router (6LR), and 592 each peripheral host (acting as a host (6LR) forms one or more 593 address(es) from that same prefix and registers it. 595 o A typical Smartgrid networks puts together Route-Over MLSNs that 596 comprise thousands of IPv6 nodes. The 6TiSCH architecture 597 [I-D.ietf-6tisch-architecture] presents the Route-Over model over 598 a [IEEEstd802154] Time-Slotted Channel-Hopping mesh, and 599 generalizes it for multiple other applications. Each node in a 600 Smartgrid network may have tens to a hundred others nodes in 601 range. A key problem for the routing protocol is which other 602 node(s) should this node peer with, because most of the possible 603 peers do not provide added routing value. When both energy and 604 bandwidth are constrained,talking to them is a bad idea and most 605 of the possible P2P links are not even used. Peerings that are 606 actually used come and go with the dynamics of radio signal 607 propagation. It results that allocating prefixes to all the 608 possible P2P Links and maintain as many addresses in all nodes is 609 not even considered. 611 5.1. Case of LPWANs 613 LPWANs are by nature so constrained that the addresses and Subnets 614 are fully pre-configured and operate as P2P or Hub-and-Spoke. This 615 saves the steps of neighbor Discovery and enables a very efficient 616 stateful compression of the IPv6 header. 618 5.2. Case of Infrastructure BSS and ESS 620 In contrast to IPv4, IPv6 enables a node to form multiple addresses, 621 some of them temporary to elusive, and with a particular attention 622 paid to privacy. Addresses may be formed and deprecated 623 asynchronously to the association. Even if the knowledge of IPv6 624 addresses used by a STA can be obtained by snooping protocols such as 625 IPv6 ND and DHCPv6, or by observing data traffic sourced at the STA, 626 such methods provide only an imperfect knowledge of the state of the 627 STA at the AP. This may result in a loss of connectivity for some 628 IPv6 addresses, in particular for addresses rarely used and in a 629 situation of mobility. This may also result in undesirable remanent 630 state in the AP when a STA ceases to use an IPv6 address. It results 631 that snooping protocols is not a recommended technique and that it 632 should only be used as last resort. 634 The recommended alternate is to use the IPv6 Registration method 635 speficied in p. By that method, the AP exposes its capability to 636 proxy ND to the STA in Router Advertisement messages. In turn, the 637 STA may request proxy ND services from the AP for one or more IPv6 638 addresses, using an Address Registration Option. The Registration 639 state has a lifetime that limits unwanted state remanence in the 640 network. The registration is optionally secured using 641 [I-D.ietf-6lo-ap-nd] to prevent address theft and impersonation. The 642 registration carries a sequence number, which enables a fast mobility 643 without a loss of connectivity. 645 The ESS mode requires a proxy ND operation at the AP. The proxy ND 646 operation must cover Duplicate Address Detection, Neighbor 647 Unreachability Detection, Address Resolution and Address Mobility to 648 transfer a role of ND proxy to the AP where a STA is associated 649 following the mobility of the STA. The proxy ND specification 650 associated to the address registration is 651 [I-D.ietf-6lo-backbone-router]. With that specification, the AP 652 participates to the protocol as a Backbone Router, typically 653 operating as a bridging proxy though the routing proxy operation is 654 also possible. As a bridging proxy, the proxy replies to NS lookups 655 with the MAC address of the STA, and then bridges packets to the STA 656 normally; as a routing proxy, it replies with its own MAC address and 657 then routes to the STA at the IP layer. The routing proxy reduces 658 the need to expose the MAC address of the STA on the wired side, for 659 a better stability and scalability of the bridged fabric. 661 5.3. Case of Mesh Under Technologies 663 The Mesh-Under provides a broadcast domain emulation with reflexive 664 and Transitive properties and defines a transit Link for IPv6 665 operations. It results that the model for IPv6 operation is similar 666 to that of a BSS, with the root of the mesh operating an Access Point 667 does in a BSS/ESS. While it is still possible to operate IPv6 ND, 668 the inefficiencies of the flooding operation make the IPv6 ND 669 operations even less desirable than in a BSS, and the use of WiND is 670 highly recommended. 672 5.4. Case of DMC radios 674 IPv6 over DMC radios uses P2P Links that can be formed and maintained 675 when a pair of DMC radios transmitters are in range from one another. 677 5.4.1. Using IPv6 ND only 679 DMC radios do not provide MAC level broadcast emulation. An example 680 of that is IEEE Std. 802.11 OCB which uses IEEE Std. 802.11 MAC/PHYs 681 but does not provide the BSS functions. 683 It is possible to form P2P IP Links between each individual pairs of 684 nodes and operate IPv6 ND over those Links with Link Local addresses. 685 DAD must be performed for all addresses on all P2P IP Links. 687 If special deployment care is taken so that the physical broadcast 688 domains of a collection of the nodes fully overlap, then it is also 689 possible to build an IP Subnet within that collection of nodes and 690 operate IPv6 ND. 692 The model can be stretched beyond the scope of IPv6 ND if an external 693 mechanism avoids duplicate addresses and if the deployment ensures 694 the connectivity between peers. This can be achieved for instance in 695 a Hub-and-Spoke deployment if the Hub is the only router in the 696 Subnet and the Prefix is advertised as not onlink. 698 5.4.2. Using Wireless ND 700 Though this can be achieved with IPv6 ND, WiND is the recommended 701 approach since it uses more unicast communications which are more 702 reliable and less impacting for other users of the medium. 704 Router and Hosts respectively send a compressed RA/NA with a SLLAO at 705 a regular period. The period can be indicated in a RA as in an RA- 706 Interval Option [RFC6275]. If available, the message can be 707 transported in a compressed form in a beacon, e.g., in OCB Basic 708 Safety Messages (BSM) that are nominally sent every 100ms. An active 709 beaconing mode is possible whereby the Host sends broadcast RS 710 messages to which a router can answer with a unicast RA. 712 A router that has Internet connectivity and is willing to serve as an 713 Internet Access may advertise itself as a default router [RFC4191] in 714 its RA. The NA/RA is sent over an Unspecified Link where it does not 715 conflict to anyone, so DAD is not necessary at that stage. 717 The receiver instantiates a Link where the sender's address is not a 718 duplicate. To achieve this, it forms an LLA that does not conflict 719 with that of the sender and registers to the sender using [RFC8505]. 721 If the sender sent an RA(PIO) the receiver can also autoconfigure an 722 address from the advertised prefix and register it. 724 6LoWPAN Node 6LR 725 (RPL leaf) (router) 726 | | 727 | LLN link | 728 | | 729 | IPv6 ND RS | 730 |-------------->| 731 |-----------> | 732 |------------------> 733 | IPv6 ND RA | 734 |<--------------| 735 | | 736 | NS(EARO) | 737 |-------------->| 738 | | 739 | NA(EARO) | 740 |<--------------| 741 | | 743 Figure 1: Initial Registration Flow 745 The lifetime in the registration should start with a small value 746 (X=RMin, TBD), and exponentially grow with each reregistration to a 747 mlarger value (X=Rmax, TBD). The IP Link is considered down when 748 (X=NbBeacons, TDB) expected messages are not received in a row. It 749 must be noted that the Link flapping does not affect the state of the 750 registration and when a Link comes back up, the active -lifetime not 751 elapsed- registrations are still usable. Packets should be held or 752 destroyed when the Link is down. 754 P2P Links may be federated in Hub-and-Spoke and then in Route-Over 755 MLSNs as described above. More details on the operation of WiND and 756 RPL over the MLSN can be found in section 3.1, 3.2, 4.1 and 4.2.2 of 757 [I-D.ietf-6tisch-architecture]. 759 6LoWPAN Node 6LR 6LBR 6BBR 760 (RPL leaf) (router) (root) 761 | | | | 762 | 6LoWPAN ND |6LoWPAN ND+RPL | 6LoWPAN ND | IPv6 ND 763 | LLN link |Route-Over mesh|Ethernet/serial| Backbone 764 | | | | 765 | IPv6 ND RS | | | 766 |-------------->| | | 767 |-----------> | | | 768 |------------------> | | 769 | IPv6 ND RA | | | 770 |<--------------| | | 771 | | | | 772 | NS(EARO) | | | 773 |-------------->| | | 774 | 6LoWPAN ND | Extended DAR | | 775 | |-------------->| | 776 | | | NS(EARO) | 777 | | |-------------->| 778 | | | | NS-DAD 779 | | | |------> 780 | | | | (EARO) 781 | | | | 782 | | | NA(EARO) | 783 | | |<--------------| 784 | | Extended DAC | | 785 | |<--------------| | 786 | NA(EARO) | | | 787 |<--------------| | | 788 | | | | 790 Figure 2: Initial Registration Flow over Multi-Link Subnet 792 An example Hub-and-Spoke is an OCB Road-Side Unit (RSU) that owns a 793 prefix, provides Internet connectivity using that prefix to On-Board 794 Units (OBUs) within its physical broadcast domain. An example of 795 Route-Over MLSN is a collection of cars in a parking lot operating 796 RPL to extend the connectivity provided by the RSU beyond its 797 physical broadcast domain. Cars may then operate NEMO [RFC3963] for 798 their own prefix using their address derived from the prefix of the 799 RSU as CareOf Address. 801 6. IANA Considerations 803 This specification does not require IANA action. 805 7. Security Considerations 807 This specification refers to the security sections of IPv6 ND and 808 WiND, respectively. 810 8. Acknowledgments 812 Many thanks to the participants of the 6lo WG where a lot of the work 813 discussed here happened. Also ROLL, 6TiSCH, and 6LoWPAN. 815 9. References 817 9.1. Normative References 819 [I-D.ietf-6lo-ap-nd] 820 Thubert, P., Sarikaya, B., Sethi, M., and R. Struik, 821 "Address Protected Neighbor Discovery for Low-power and 822 Lossy Networks", draft-ietf-6lo-ap-nd-12 (work in 823 progress), April 2019. 825 [I-D.ietf-6lo-backbone-router] 826 Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 827 Backbone Router", draft-ietf-6lo-backbone-router-13 (work 828 in progress), September 2019. 830 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 831 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 832 RFC 3963, DOI 10.17487/RFC3963, January 2005, 833 . 835 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 836 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 837 November 2005, . 839 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 840 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 841 DOI 10.17487/RFC4861, September 2007, 842 . 844 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 845 Address Autoconfiguration", RFC 4862, 846 DOI 10.17487/RFC4862, September 2007, 847 . 849 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 850 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 851 2011, . 853 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 854 (IPv6) Specification", STD 86, RFC 8200, 855 DOI 10.17487/RFC8200, July 2017, 856 . 858 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 859 Perkins, "Registration Extensions for IPv6 over Low-Power 860 Wireless Personal Area Network (6LoWPAN) Neighbor 861 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 862 . 864 9.2. Informative References 866 [I-D.bi-savi-wlan] 867 Bi, J., Wu, J., Wang, Y., and T. Lin, "A SAVI Solution for 868 WLAN", draft-bi-savi-wlan-17 (work in progress), May 2019. 870 [I-D.ietf-6tisch-architecture] 871 Thubert, P., "An Architecture for IPv6 over the TSCH mode 872 of IEEE 802.15.4", draft-ietf-6tisch-architecture-26 (work 873 in progress), August 2019. 875 [I-D.ietf-mboned-ieee802-mcast-problems] 876 Perkins, C., McBride, M., Stanley, D., Kumari, W., and J. 877 Zuniga, "Multicast Considerations over IEEE 802 Wireless 878 Media", draft-ietf-mboned-ieee802-mcast-problems-08 (work 879 in progress), August 2019. 881 [I-D.ietf-rift-rift] 882 Przygienda, T., Sharma, A., Thubert, P., and D. Afanasiev, 883 "RIFT: Routing in Fat Trees", draft-ietf-rift-rift-08 884 (work in progress), September 2019. 886 [I-D.thubert-6lo-unicast-lookup] 887 Thubert, P. and E. Levy-Abegnoli, "IPv6 Neighbor Discovery 888 Unicast Lookup", draft-thubert-6lo-unicast-lookup-00 (work 889 in progress), January 2019. 891 [I-D.thubert-roll-unaware-leaves] 892 Thubert, P., "Routing for RPL Leaves", draft-thubert-roll- 893 unaware-leaves-07 (work in progress), April 2019. 895 [I-D.vyncke-6man-mcast-not-efficient] 896 Vyncke, E., Thubert, P., Levy-Abegnoli, E., and A. 897 Yourtchenko, "Why Network-Layer Multicast is Not Always 898 Efficient At Datalink Layer", draft-vyncke-6man-mcast-not- 899 efficient-01 (work in progress), February 2014. 901 [I-D.yourtchenko-6man-dad-issues] 902 Yourtchenko, A. and E. Nordmark, "A survey of issues 903 related to IPv6 Duplicate Address Detection", draft- 904 yourtchenko-6man-dad-issues-01 (work in progress), March 905 2015. 907 [IEEE802154] 908 IEEE standard for Information Technology, "IEEE Std. 909 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 910 and Physical Layer (PHY) Specifications for Low-Rate 911 Wireless Personal Area Networks". 913 [IEEEstd8021] 914 IEEE standard for Information Technology, "IEEE Standard 915 for Information technology -- Telecommunications and 916 information exchange between systems Local and 917 metropolitan area networks Part 1: Bridging and 918 Architecture". 920 [IEEEstd80211] 921 IEEE standard for Information Technology, "IEEE Standard 922 for Information technology -- Telecommunications and 923 information exchange between systems Local and 924 metropolitan area networks-- Specific requirements Part 925 11: Wireless LAN Medium Access Control (MAC) and Physical 926 Layer (PHY) Specifications". 928 [IEEEstd802151] 929 IEEE standard for Information Technology, "IEEE Standard 930 for Information Technology - Telecommunications and 931 Information Exchange Between Systems - Local and 932 Metropolitan Area Networks - Specific Requirements. - Part 933 15.1: Wireless Medium Access Control (MAC) and Physical 934 Layer (PHY) Specifications for Wireless Personal Area 935 Networks (WPANs)". 937 [IEEEstd802154] 938 IEEE standard for Information Technology, "IEEE Standard 939 for Local and metropolitan area networks -- Part 15.4: 940 Low-Rate Wireless Personal Area Networks (LR-WPANs)". 942 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 943 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 944 2006, . 946 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 947 DOI 10.17487/RFC4903, June 2007, 948 . 950 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 951 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 952 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 953 Low-Power and Lossy Networks", RFC 6550, 954 DOI 10.17487/RFC6550, March 2012, 955 . 957 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 958 Bormann, "Neighbor Discovery Optimization for IPv6 over 959 Low-Power Wireless Personal Area Networks (6LoWPANs)", 960 RFC 6775, DOI 10.17487/RFC6775, November 2012, 961 . 963 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 964 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 965 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 966 . 968 [RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix 969 per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017, 970 . 972 Author's Address 974 Pascal Thubert (editor) 975 Cisco Systems, Inc 976 Building D 977 45 Allee des Ormes - BP1200 978 MOUGINS - Sophia Antipolis 06254 979 FRANCE 981 Phone: +33 497 23 26 34 982 Email: pthubert@cisco.com