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