idnits 2.17.1 draft-thubert-6man-ipv6-over-wireless-07.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 (24 November 2020) is 1250 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-21) exists of draft-ietf-rift-rift-12 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-29 == Outdated reference: A later version (-15) exists of draft-ietf-mboned-ieee802-mcast-problems-12 == Outdated reference: A later version (-24) exists of draft-bi-savi-wlan-20 == Outdated reference: A later version (-02) exists of draft-thubert-6lo-unicast-lookup-00 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6MAN P. Thubert, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track 24 November 2020 5 Expires: 28 May 2021 7 IPv6 Neighbor Discovery on Wireless Networks 8 draft-thubert-6man-ipv6-over-wireless-07 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 28 May 2021. 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 . . . . . . . . . . . . . . . . . 11 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 Detection (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. It is intended for one Target, that may or may not be 182 present in the network, but it is often turned into a MAC-Layer 183 broadcast and effectively reaches most of the nodes on link. 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 Multicast NS transmissions may occur when a node joins the network, 194 moves, or wakes up and reconnects to the network. Over a very large 195 fabric, this can generate hundreds of broadcasts per second. If the 196 broadcasts were blindly copied over Wi-Fi, the MAC-layer broadcast 197 traffic associated to ND IP-layer multicast could consume enough 198 bandwidth to cause a substantial degradation to the unicast service 199 [MCAST EFFICIENCY]. To protect their bandwidth, some networks 200 throttle ND-related broadcasts, which reduces the capability for the 201 ND protocol to operate as expected. 203 This problem can be alleviated by reducing the size of the broadcast 204 domain that encompasses wireless access links. This has been done in 205 the art of IP subnetting by partitioning the subnets and by routing 206 between them, at the extreme by assigning a /64 prefix to each 207 wireless node (see [RFC8273]). 209 Another way to split the broadcast domain within a subnet is to proxy 210 at the boundary of the wired and wireless domains the Network Layer 211 protocols that rely on Link Layer broadcast operations. [IEEE Std. 212 802.11] recommends to deploy proxies for the IPv4 Address Resolution 213 Protocol (ARP) and IPv6 ND at the APs. This requires the exhaustive 214 list of the IP addresses for which proxying is provided. Forming and 215 maintaining that knowledge a hard problem in the general case of 216 radio connectivity, which keeps changing with movements and 217 variations in the environment that alter the range of transmissions. 219 [SAVI] suggests to discover the addresses by snooping the ND-Classic 220 protocol, but that can also be unreliable. An IPv6 address may not 221 be discovered immediately due to a packet loss. It may never be 222 discovered in the case of a "silent" node that is not currently using 223 one of its addresses, e.g., a printer that waits in wake-on-lan 224 state. A change of anchor, e.g. due to a movement, may be missed or 225 misordered, leading to unreliable connectivity and an incomplete list 226 of addresses. 228 Wireless ND (WiND) introduces a new approach to IPv6 Neighbor 229 Discovery that is designed to apply to the WLANs and LoWPANs types of 230 networks, as well as other Non-Broadcast Multi-Access (NBMA) networks 231 such as Data-Center overlays. WiND applies routing inside the 232 subnets, which enables to form potentially large MLSNs without 233 creating a large broadcast domain at the Link Layer. In a fashion 234 similar to a Wi-Fi Association, IPv6 Hosts register their addresses 235 to their serving router(s), using [RFC8505]. With the registration, 236 the routers have a complete knowledge of the hosts they serve and in 237 return, hosts obtain routing services for their registered addresses. 238 The registration is abstract to the routing service, and it can be 239 protected to prevent impersonation attacks with [RFC8928]. 241 The routing service can be a simple reflexion in a Hub-and-Spoke 242 subnet that emulates an IEEE Std. 802.11 Infrastructure BSS at the 243 Network Layer. It can also be a full-fledge routing protocol, in 244 particular RPL [RFC6550], which is designed to adapt to various LLNs 245 such as WLAN and WPAN radio meshes. Finally, the routing service can 246 also be an ND proxy that emulates an IEEE Std. 802.11 Infrastructure 247 ESS at the Network Layer, as specified in the IPv6 Backbone Router 248 [RFC8929]. 250 On the one hand, WiND avoids the use of broadcast operation for DAD 251 and AR, and on the other hand, WiND supports use cases where subnet 252 and Link Layer domains are not congruent, which is common in wireless 253 networks unless a specific Link Layer emulation is provided. More 254 details on WiND can be found in Section 5.1. 256 4. IP Models 258 4.1. Physical Broadcast Domain 260 At the physical (PHY) Layer, a broadcast domain is the set of nodes 261 that may receive a transmission that one sends over an interface, in 262 other words the set of nodes in range of the radio transmission. 263 This set can comprise a single peer on a serial cable used as point- 264 to-point (P2P) link. It may also comprise multiple peer nodes on a 265 broadcast radio or a shared physical resource such as the Ethernet 266 wires and hubs for which ND-Classic was initially designed. 268 On WLAN and LoWPAN radios, the physical broadcast domain is defined 269 relative to a particular transmitter, as the set of nodes that can 270 receive what this transmitter is sending. Literally every frame 271 defines its own broadcast domain since the chances of reception of a 272 given frame are statistical. In average and in stable conditions, 273 the broadcast domain of a particular node can be still be seen as 274 mostly constant and can be used to define a closure of nodes on which 275 an upper Layer abstraction can be built. 277 A PHY Layer communication can be established between two nodes if the 278 physical broadcast domains of their unicast transmissions overlap. 279 On WLAN and LoWPAN radios, that relation is usually not reflexive, 280 since nodes disable the reception when they transmit; still they may 281 retain a copy of the transmitted frame, so it can be seen as 282 reflexive at the MAC Layer. It is often symmetric, meaning that if B 283 can receive a frame from A, then A can receive a frame from B. But 284 there can be asymmetries due to power levels, interferers near one of 285 the receivers, or differences in the quality of the hardware (e.g., 286 crystals, PAs and antennas) that may affect the balance to the point 287 that the connectivity becomes mostly uni-directional, e.g., A to B 288 but practically not B to A. 290 It takes a particular effort to place a set of devices in a fashion 291 that all their physical broadcast domains fully overlap, and that 292 specific situation can not be assumed in the general case. In other 293 words, the relation of radio connectivity is generally not 294 transitive, meaning that A in range with B and B in range with C does 295 not necessarily imply that A is in range with C. 297 4.2. Link Layer Broadcast Emulations 299 We call Direct MAC Broadcast (DMB) the transmission mode where the 300 broadcast domain that is usable at the MAC layer is directly the 301 physical broadcast domain. [IEEE Std. 802.15.4] and [IEEE Std. 302 802.11] OCB (for Out of the Context of a BSS) are examples of DMB 303 radios. DMB networks provide mostly symmetric and non-transitive 304 transmission. This contrasts with a number of Link Layer Broadcast 305 Emulation (LLBE) schemes that are described in this section. 307 In the case of Ethernet, while a physical broadcast domain is 308 constrained to a single shared wire, the [IEEE Std. 802.1] bridging 309 function emulates the broadcast properties of that wire over a whole 310 physical mesh of Ethernet links. For the upper layer, the qualities 311 of the shared wire are essentially conserved, with a reliable and 312 cheap broadcast operation over a transitive closure of nodes defined 313 by their connectivity to the emulated wire. 315 In large switched fabrics, overlay techniques enable a limited 316 connectivity between nodes that are known to a Map Resolver. The 317 emulated broadcast domain is configured to the system, e.g., with a 318 VXLAN network identifier (VNID). Broadcast operations on the overlay 319 can be emulated but can become very expensive, and it makes sense to 320 proactively install the relevant state in the mapping server as 321 opposed to rely on reactive broadcast lookups to do so. 323 An [IEEE Std. 802.11] Infrastructure Basic Service Set (BSS) also 324 provides a transitive closure of nodes as defined by the broadcast 325 domain of a central AP. The AP relays both unicast and broadcast 326 packets and provides the symmetric and transitive emulation of a 327 shared wire between the associated nodes, with the capability to 328 signal link-up/link-down to the upper layer. Within a BSS, the 329 physical broadcast domain of the AP serves as emulated broadcast 330 domain for all the nodes that are associated to the AP. Broadcast 331 packets are relayed by the AP and are not acknowledged. To increase 332 the chances that all nodes in the BSS receive the broadcast 333 transmission, AP transmits at the slowest PHY speed. This translates 334 into maximum co-channel interferences for others and the longest 335 occupancy of the medium, for a duration that can be a hundred times 336 that of the unicast transmission of a frame of the same size. 338 For that reason, upper layer protocols should tend to avoid the use 339 of broadcast when operating over Wi-Fi. To cope with this problems, 340 APs may implement strategies such as turn a broadcast into a series 341 of unicast transmissions, or drop the message altogether, which may 342 impact the upper layer protocols. For instance, some APs may not 343 copy Router Solicitation (RS) messages under the assumption that 344 there is no router across the wireless interface. This assumption 345 may be correct at some point of time and may become incorrect in the 346 future. Another strategy used in Wi-Fi APS is to proxy protocols 347 that heavily rely on broadcast, such as the Address Resolution in ARP 348 and ND-Classic, and either respond on behalf or preferably forward 349 the broadcast frame as a unicast to the intended Target. 351 In an [IEEE Std. 802.11] Infrastructure Extended Service Set (ESS), 352 infrastructure BSSes are interconnected by a bridged network, 353 typically running Transparent Bridging and the Spanning tree Protocol 354 or a more advanced Layer 2 Routing (L2R) scheme. In the original 355 model of learning bridges, the forwarding state is set by observing 356 the source MAC address of the frames. When a state is missing for a 357 destination MAC address, the frame is broadcasted with the 358 expectation that the response will populate the state on the reverse 359 path. This is a reactive operation, meaning that the state is 360 populated reactively to the need to reach a destination. It is also 361 possible in the original model to broadcast a gratuitous frame to 362 advertise self throughout the bridged network, and that is also a 363 broadcast. 365 The process of the Wi-Fi association prepares a bridging state 366 proactively at the AP, which avoids the need for a reactive broadcast 367 lookup over the wireless access. In an ESS, the AP may also generate 368 a gratuitous broadcast sourced at the MAC address of the STA to 369 prepare or update the state in the learning bridges so they point 370 towards the AP for the MAC address of the STA. WiND emulates that 371 proactive method at the Network Layer for the operations of AR, DAD 372 and ND proxy. 374 In some instances of WLANs and LoWPANs, a Mesh-Under technology 375 (e.g., a IEEE Std. 802.11s or IEEE Std. 802.15.10) provides meshing 376 services that are similar to bridging, and the broadcast domain is 377 well-defined by the membership of the mesh. Mesh-Under emulates a 378 broadcast domain by flooding the broadcast packets at the Link Layer. 379 When operating on a single frequency, this operation is known to 380 interfere with itself, and requires inter-frame gaps to dampen the 381 collisions, which reduces further the amount of available bandwidth. 383 As the cost of broadcast transmissions becomes increasingly 384 expensive, there is a push to rethink the upper Layer protocols to 385 reduce the dependency on broadcast operations. 387 4.3. Mapping the IPv6 link Abstraction 389 IPv6 defines a concept of Link, link Scope and Link-Local Addresses 390 (LLA), an LLA being unique and usable only within the Scope of a 391 Link. The ND-Classic [RFC4861] DAD [RFC4862] process uses a 392 multicast transmission to detect a duplicate address, which requires 393 that the owner of the address is connected to the Link Layer 394 broadcast domain of the sender. 396 On wired media, the link is often confused with the physical 397 broadcast domain because both are determined by the serial cable or 398 the Ethernet shared wire. Ethernet Bridging reinforces that illusion 399 with a Link Layer broadcast domain that emulates a physical broadcast 400 domain over the mesh of wires. But the difference shows on legacy 401 Non-Broadcast Multi-Access (NBMA) networks such as ATM and Frame- 402 Relay, on shared links and on newer types of NBMA networks such as 403 radio and composite radio-wires networks. It also shows when private 404 VLANs or Link Layer cryptography restrict the capability to read a 405 frame to a subset of the connected nodes. 407 In Mesh-Under and Infrastructure BSS, the IP link extends beyond the 408 physical broadcast domain to the emulated Link Layer broadcast 409 domain. Relying on Multicast for the ND operation remains feasible 410 but becomes highly detrimental to the unicast traffic, and becomes 411 less and less energy-efficient and reliable as the network grows. 413 On DMB radios, IP links between peers come and go as the individual 414 physical broadcast domains of the transmitters meet and overlap. The 415 DAD operation cannot provide once and for all guarantees over the 416 broadcast domain defined by one radio transmitter if that transmitter 417 keeps meeting new peers on the go. 419 The scope on which the uniqueness of an LLA must be checked is each 420 new pair of nodes for the duration of their conversation. As long as 421 there's no conflict, a node may use the same LLA with multiple peers 422 but it has to perform DAD again with each new peer. A node may need 423 to form a new LLA to talk to a new peer, and multiple LLAs may be 424 present in the same radio interface to talk to different peers. In 425 practice, each pair of nodes defines a temporary P2P link, which can 426 be modeled as a sub-interface of the radio interface. 428 The DAD and AR procedures in ND-Classic expect that a node in a 429 subnet is reachable within the broadcast domain of any other node in 430 the subnet when that other node attempts to form an address that 431 would be a duplicate or attempts to resolve the MAC address of this 432 node. This is why ND is applicable for P2P and transit links, but 433 requires extensions for more complex topologies. 435 4.4. Mapping the IPv6 subnet Abstraction 437 IPv6 also defines the concept of a subnet for Global and Unique Local 438 Addresses (GLA and ULA). All the addresses in a subnet share the 439 same prefix, and by extension, a node belongs to a subnet if it has 440 an address that derives from the prefix of the subnet. That address 441 must be topologically correct, meaning that it must be installed on 442 an interface that is connected to the subnet. 444 Unless intently replicated in different locations for very specific 445 purposes, a subnet prefix is unique within a routing system; for 446 ULAs, the routing system is typically a limited domain, whereas for 447 GLAs, it is the whole Internet. 449 For that reason, it is sufficient to validate that an address that is 450 formed from a subnet prefix is unique within the scope of that subnet 451 to guarantee that it is globally unique within the whole routing 452 system. Note that a subnet may become partitioned due to the loss of 453 a wired or wireless link, so even that operation is not necessarily 454 obvious, more in [DAD APPROACHES]. 456 The IPv6 aggregation model relies on the property that a packet from 457 the outside of a subnet can be routed to any router that belongs to 458 the subnet, and that this router will be able to either resolve the 459 destination Link Layer address and deliver the packet, or, in the 460 case of an MLSN, route the packet to the destination within the 461 subnet. 463 If the subnet is known as on-link, then any node may also resolve the 464 destination Link Layer address and deliver the packet, but if the 465 subnet is not on-link, then a host in the subnet that does not have a 466 Neighbor Cache Entry (NCE) for the destination will also need to pass 467 the packet to a router, more in [RFC5942]. 469 On Ethernet, an IP subnet is often congruent with an IP link because 470 both are determined by the physical attachment to a shared wire or an 471 IEEE Std. 802.1 bridged domain. In that case, the connectivity over 472 the link is both symmetric and transitive, the subnet can appear as 473 on-link, and any node can resolve a destination MAC address of any 474 other node directly using ND-Classic. 476 But an IP link and an IP subnet are not always congruent. In the 477 case of a Shared Link, individual subnets may each encompass only a 478 subset of the nodes connected to the link. Conversely, in Route-Over 479 Multi-link subnets (MLSN) [RFC4903], routers federate the links 480 between nodes that belong to the subnet, the subnet is not on-link 481 and it extends beyond any of the federated links. 483 5. Wireless Neighbor Discovery 485 5.1. Introduction to Wireless ND 487 WiND [RFC6775][RFC8505][RFC8929][RFC8928] defines a new operation for 488 ND that is based on 2 major paradigm changes, proactive address 489 registration by hosts to their attachment routers and routing to host 490 routes (/128) within the subnet. This allows WiND to avoid the 491 expectations of transit links and subnet-wide broadcast domains. 493 WiND is agnostic to the method used for Address Assignment, e.g., 494 Stateless Address Autoconfiguration (SLAAC) [RFC4862] or DHCPv6 495 [RFC8415]. It does not change the IPv6 addressing [RFC4291] or the 496 current practices of assigning prefixes, typically a /64, to a 497 subnet. But the DAD operation is performed as a unicast exchange 498 with a central registrar, using new ND Extended Duplicate Address 499 messages (EDAR and EDAC) [RFC6775][RFC8505]. This modernizes ND for 500 application in overlays with Map Resolvers and enables unicast 501 lookups [UNICAST AR] for addresses registered to the resolver. 503 The proactive address registration is performed with a new option in 504 NS/NA messages, the Extended Address Registration Option (EARO) 505 defined in [RFC8505]. This method allows to prepare and maintain the 506 host routes in the routers and avoids the reactive Address Resolution 507 in ND-Classic and the associated Link Layer broadcasts transmissions. 509 The EARO provides information to the router that is independent to 510 the routing protocol and routing can take multiple forms, from a 511 traditional IGP to a collapsed Hub-and-Spoke model where only one 512 router owns and advertises the prefix. [RFC8505] is already 513 referenced as the registrtaion interface to "RIFT: Routing in Fat 514 Trees" [I-D.ietf-rift-rift] and "RPL: IPv6 Routing Protocol for 515 Low-Power and Lossy Networks" [RFC6550] with [RPL UNAWARE LEAVES]. 517 WiND also enables to span a subnet over an MLSN that federates edge 518 wireless links with a high-speed, typically Ethernet, backbone. This 519 way, nodes can form any address they want and move freely from a 520 wireless edge link to another, without renumbering. Backbone Routers 521 (6BBRs) placed along the wireless edge of the Backbone handle IPv6 522 Neighbor Discovery and forward packets over the backbone on behalf of 523 the registered nodes on the wireless edge. 525 For instance, a 6BBR in bridging proxy mode (more in [RFC8929]) can 526 operate as a Layer-3 AP to serve wireless IPv6 hosts that are Wi-Fi 527 STAs and maintain the reachability for Global Unicast and Link-LOcal 528 Addresses within the federated MLSN. 530 5.2. links and Link-Local Addresses 532 For Link-Local Addresses, DAD is typically performed between 533 communicating pairs of nodes and an NCE can be populated with a 534 single unicast exchange. In the case of a bridging proxies, though, 535 the Link-Local traffic is bridged over the backbone and the DAD must 536 proxied there as well. 538 For instance, in the case of Bluetooth Low Energy (BLE) 539 [RFC7668][IEEEstd802151], the uniqueness of Link-Local Addresses 540 needs only to be verified between the pair of communicating nodes, 541 the central router and the peripheral host. In that example, 2 542 peripheral hosts connected to the same central router can not have 543 the same Link-Local Address because the addresses would collision at 544 the central router which could not talk to both over the same 545 interface. The DAD operation from WiND is appropriate for that use 546 case, but the one from ND is not, because the peripheral hosts are 547 not on the same broadcast domain. 549 On the other hand, the uniqueness of Global and Unique-Local 550 Addresses is validated at the subnet Level, using a logical registrar 551 that is global to the subnet. 553 5.3. subnets and Global Addresses 555 WiND extends ND-Classic for Hub-and-Spoke (e.g., BLE) and Route-Over 556 (e.g., RPL) Multi-link subnets (MLSNs). 558 In the Hub-and-Spoke case, each Hub-Spoke pair is a distinct IP Link, 559 and a subnet can be mapped on a collection of links that are 560 connected to the Hub. The subnet prefix is associated to the Hub. 562 Acting as a router, the Hub advertises the prefix as not-on-link to 563 the spokes in RA messages Prefix Information Options (PIO). Acting 564 as hosts, the Spokes autoconfigure addresses from that prefix and 565 register them to the Hub with a corresponding lifetime. 567 Acting as a registrar, the Hub maintains a binding table of all the 568 registered IP addresses and rejects duplicate registrations, thus 569 ensuring a DAD protection for a registered address even if the 570 registering node is sleeping. 572 The Hub also maintains an NCE for the registered addresses and can 573 deliver a packet to any of them during their respective lifetimes. 574 It can be observed that this design builds a form of Network Layer 575 Infrastructure BSS. 577 A Route-Over MLSN is considered as a collection of Hub-and-Spoke 578 where the Hubs form a connected dominating set of the member nodes of 579 the subnet, and IPv6 routing takes place between the Hubs within the 580 subnet. A single logical registrar is deployed to serve the whole 581 mesh. 583 The registration in [RFC8505] is abstract to the routing protocol and 584 provides enough information to feed a routing protocol such as RPL as 585 specified in [RPL UNAWARE LEAVES]. In a degraded mode, all the Hubs 586 are connected to a same high speed backbone such as an Ethernet 587 bridging domain where ND-Classic is operated. In that case, it is 588 possible to federate the Hub, Spoke and Backbone nodes as a single 589 subnet, operating ND proxy operations [RFC8929] at the Hubs, acting 590 as 6BBRs. It can be observed that this latter design builds a form 591 of Network Layer Infrastructure ESS. 593 6. WiND Applicability 595 WiND applies equally to P2P links, P2MP Hub-and-Spoke, Link Layer 596 Broadcast Domain Emulation such as Mesh-Under and Wi-Fi BSS, and 597 Route-Over meshes. 599 There is an intersection where link and subnet are congruent and 600 where both ND and WiND could apply. These includes P2P, the MAC 601 emulation of a PHY broadcast domain, and the particular case of 602 always on, fully overlapping physical radio broadcast domain. But 603 even in those cases where both are possible, WiND is preferable vs. 604 ND because it reduces the need of broadcast. 606 This is discussed in more details in the introduction of [RFC8929]. 608 There are also a number of practical use cases in the wireless world 609 where links and subnets are not congruent: 611 * The IEEE Std. 802.11 infrastructure BSS enables one subnet per AP, 612 and emulates a broadcast domain at the Link Layer. The 613 Infrastructure ESS extends that model over a backbone and 614 recommends the use of an ND proxy [IEEE Std. 802.11] to 615 interoperate with Ethernet-connected nodes. WiND incorporates an 616 ND proxy to serve that need, which was missing so far. 618 * BlueTooth is Hub-and-Spoke at the Link Layer. It would make 619 little sense to configure a different subnet between the central 620 and each individual peripheral node (e.g., sensor). Rather, 621 [RFC7668] allocates a prefix to the central node acting as router, 622 and each peripheral host (acting as a host) forms one or more 623 address(es) from that same prefix and registers it. 625 * A typical Smartgrid networks puts together Route-Over MLSNs that 626 comprise thousands of IPv6 nodes. The 6TiSCH architecture 627 [I-D.ietf-6tisch-architecture] presents the Route-Over model over 628 an IEEE Std. 802.15.4 Time-Slotted Channel-Hopping (TSCH) 629 [IEEEstd802154] mesh, and generalizes it for multiple other 630 applications. 632 Each node in a Smartgrid network may have tens to a hundred others 633 nodes in range. A key problem for the routing protocol is which 634 other node(s) should this node peer with, because most of the 635 possible peers do not provide added routing value. When both 636 energy and bandwidth are constrained, talking to them is a waste 637 of resources and most of the possible P2P links are not even used. 638 Peerings that are actually used come and go with the dynamics of 639 radio signal propagation. It results that allocating prefixes to 640 all the possible P2P links and maintain as many addresses in all 641 nodes is not even considered. 643 6.1. Case of LPWANs 645 LPWANs are by nature so constrained that the addresses and subnets 646 are fully pre-configured and operate as P2P or Hub-and-Spoke. This 647 saves the steps of neighbor Discovery and enables a very efficient 648 stateful compression of the IPv6 header. 650 6.2. Case of Infrastructure BSS and ESS 652 In contrast to IPv4, IPv6 enables a node to form multiple addresses, 653 some of them temporary to elusive, and with a particular attention 654 paid to privacy. Addresses may be formed and deprecated 655 asynchronously to the association. 657 Snooping protocols such as ND-Classic and DHCPv6 and observing data 658 traffic sourced at the STA provides an imperfect knowledge of the 659 state of the STA at the AP. Missing a state or a transition may 660 result in the loss of connectivity for some of the addresses, in 661 particular for an address that is rarely used, belongs to a sleeping 662 node, or one in a situation of mobility. This may also result in 663 undesirable remanent state in the AP when the STA ceases to use an 664 IPv6 address while remaining associated. It results that snooping 665 protocols is not a recommended technique and that it should only be 666 used as last resort, when the WiND registration is not available to 667 populate the state. 669 The recommended alternative method is to use the WiND Registration 670 for IPv6 Addresses. This way, the AP exposes its capability to proxy 671 ND to the STA in Router Advertisement messages. In turn, the STA may 672 request proxy ND services from the AP for all of its IPv6 addresses, 673 using the Extended Address Registration Option, which provides the 674 following elements: 676 * The registration state has a lifetime that limits unwanted state 677 remanence in the network. 679 * The registration is optionally secured using [RFC8928] to prevent 680 address theft and impersonation. 682 * The registration carries a sequence number, which enables to 683 figure the order of events in a fast mobility scenario without 684 loss of connectivity. 686 The ESS mode requires a proxy ND operation at the AP. The proxy ND 687 operation must cover Duplicate Address Detection, Neighbor 688 Unreachability Detection, Address Resolution and Address Mobility to 689 transfer a role of ND proxy to the AP where a STA is associated 690 following the mobility of the STA. 692 The WiND proxy ND specification that associated to the Address 693 Registration is [RFC8929]. With that specification, the AP 694 participates to the protocol as a Backbone Router, typically 695 operating as a bridging proxy though the routing proxy operation is 696 also possible. As a bridging proxy, the backbone router either 697 replies to NS lookups with the MAC address of the STA, or preferably 698 forwards the lookups to the STA as Link Layer unicast frames to let 699 the STA answer. For the data plane, the backbone router acts as a 700 normal AP and bridges the packets to the STA as usual. As a routing 701 proxy, the backbone router replies with its own MAC address and then 702 routes to the STA at the IP layer. The routing proxy reduces the 703 need to expose the MAC address of the STA on the wired side, for a 704 better stability and scalability of the bridged fabric. 706 6.3. Case of Mesh Under Technologies 708 The Mesh-Under provides a broadcast domain emulation with symmetric 709 and Transitive properties and defines a transit link for IPv6 710 operations. It results that the model for IPv6 operation is similar 711 to that of a BSS, with the root of the mesh operating as an Access 712 Point does in a BSS/ESS. 714 While it is still possible to operate ND-Classic, the inefficiencies 715 of the flooding operation make the associated operations even less 716 desirable than in a BSS, and the use of WiND is highly recommended. 718 6.4. Case of DMB radios 720 IPv6 over DMB radios uses P2P links that can be formed and maintained 721 when a pair of DMB radios transmitters are in range from one another. 723 6.4.1. Using ND-Classic only 725 DMB radios do not provide MAC level broadcast emulation. An example 726 of that is IEEE Std. 802.11 OCB which uses IEEE Std. 802.11 MAC/PHYs 727 but does not provide the BSS functions. 729 It is possible to form P2P IP links between each individual pairs of 730 nodes and operate ND-Classic over those links with Link-Local 731 addresses. DAD must be performed for all addresses on all P2P IP 732 links. 734 If special deployment care is taken so that the physical broadcast 735 domains of a collection of the nodes fully overlap, then it is also 736 possible to build an IP subnet within that collection of nodes and 737 operate ND-Classic. 739 If an external mechanism avoids duplicate addresses and if the 740 deployment ensures the connectivity between peers, a non-transit Hub- 741 and-Spoke deployment is also possible where the Hub is the only 742 router in the subnet and the Prefix is advertised as not on-link. 744 6.4.2. Using Wireless ND 746 Though this can be achieved with ND-Classic, WiND is the recommended 747 approach since it uses unicast communications which are more reliable 748 and less impacting for other users of the medium. 750 The routers send RAs with a SLLAO at a regular period. The period 751 can be indicated in the RA-Interval Option [RFC6275]. If available, 752 the message can be transported in a compressed form in a beacon, 753 e.g., in OCB Basic Safety Messages (BSM) that are nominally sent 754 every 100ms. 756 An active beaconing mode is possible whereby the Host sends broadcast 757 RS messages to which a router can answer with a unicast RA. 759 A router that has Internet connectivity and is willing to serve as an 760 Internet Access may advertise itself as a default router [RFC4191] in 761 its RA messages. The RA is sent over an unspecified link where it 762 does not conflict to anyone, so DAD is not necessary at that stage. 764 The host instantiates a link where the router's address is not a 765 duplicate. To achieve this, it forms an LLA that does not conflict 766 with that of the router and registers to the router using [RFC8505]. 767 If the router sent an RA(PIO), the host can also autoconfigure an 768 address from the advertised prefix and register it. 770 (host) (router) 771 | | 772 | DMB link | 773 | | 774 | IPv6 ND RS | 775 |-------------->| 776 |-----------> | 777 |------------------> 778 | IPv6 ND RA | 779 |<--------------| 780 | | 781 | NS(EARO) | 782 |-------------->| 783 | | 784 | NA(EARO) | 785 |<--------------| 786 | | 788 Figure 1: Initial Registration Flow 790 The lifetime in the registration should start with a small value 791 (X=RMin, TBD), and exponentially grow with each re-registration to a 792 larger value (X=Rmax, TBD). The IP link is considered down when 793 (X=NbBeacons, TDB) expected messages are not received in a row. It 794 must be noted that the link flapping does not affect the state of the 795 registration and when a link comes back up, the active registrations 796 (i.e., registrations for which lifetime is not elapsed) are still 797 usable. Packets should be held or destroyed when the link is down. 799 P2P links may be federated in Hub-and-Spoke and then in Route-Over 800 MLSNs as illustrated in Figure 2. More details on the operation of 801 WiND and RPL over the MLSN can be found in section 3.1, 3.2, 4.1 and 802 4.2.2 of [I-D.ietf-6tisch-architecture]. 804 6LoWPAN Node 6LR 6LBR 6BBR 805 (RPL leaf) (router) (root) 806 | | | | 807 | 6LoWPAN ND |6LoWPAN ND+RPL | 6LoWPAN ND | ND-Classic 808 | LLN link |Route-Over mesh|Ethernet/serial| Backbone 809 | | | | 810 | IPv6 ND RS | | | 811 |-------------->| | | 812 |-----------> | | | 813 |------------------> | | 814 | IPv6 ND RA | | | 815 |<--------------| | | 816 | | | | 817 | NS(EARO) | | | 818 |-------------->| | | 819 | 6LoWPAN ND | Extended DAR | | 820 | |-------------->| | 821 | | | NS(EARO) | 822 | | |-------------->| 823 | | | | NS-DAD 824 | | | |------> 825 | | | | (EARO) 826 | | | | 827 | | | NA(EARO) | 828 | | |<--------------| 829 | | Extended DAC | | 830 | |<--------------| | 831 | NA(EARO) | | | 832 |<--------------| | | 833 | | | | 835 Figure 2: Initial Registration Flow over Multi-link subnet 837 An example Hub-and-Spoke is an OCB Road-Side Unit (RSU) that owns a 838 prefix, provides Internet connectivity using that prefix to On-Board 839 Units (OBUs) within its physical broadcast domain. An example of 840 Route-Over MLSN is a collection of cars in a parking lot operating 841 RPL to extend the connectivity provided by the RSU beyond its 842 physical broadcast domain. Cars may then operate NEMO [RFC3963] for 843 their own prefix using their address derived from the prefix of the 844 RSU as CareOf Address. 846 7. IANA Considerations 848 This specification does not require IANA action. 850 8. Security Considerations 852 This specification refers to the security sections of ND-Classic and 853 WiND, respectively. 855 9. Acknowledgments 857 Many thanks to the participants of the 6lo WG where a lot of the work 858 discussed here happened. Also ROLL, 6TiSCH, and 6LoWPAN. 860 10. Normative References 862 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 863 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 864 RFC 3963, DOI 10.17487/RFC3963, January 2005, 865 . 867 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 868 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 869 November 2005, . 871 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 872 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 873 DOI 10.17487/RFC4861, September 2007, 874 . 876 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 877 Address Autoconfiguration", RFC 4862, 878 DOI 10.17487/RFC4862, September 2007, 879 . 881 [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet 882 Model: The Relationship between Links and Subnet 883 Prefixes", RFC 5942, DOI 10.17487/RFC5942, July 2010, 884 . 886 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 887 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 888 2011, . 890 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 891 (IPv6) Specification", STD 86, RFC 8200, 892 DOI 10.17487/RFC8200, July 2017, 893 . 895 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 896 Perkins, "Registration Extensions for IPv6 over Low-Power 897 Wireless Personal Area Network (6LoWPAN) Neighbor 898 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 899 . 901 [RFC8928] Thubert, P., Ed., Sarikaya, B., Sethi, M., and R. Struik, 902 "Address-Protected Neighbor Discovery for Low-Power and 903 Lossy Networks", RFC 8928, DOI 10.17487/RFC8928, November 904 2020, . 906 [RFC8929] Thubert, P., Ed., Perkins, C.E., and E. Levy-Abegnoli, 907 "IPv6 Backbone Router", RFC 8929, DOI 10.17487/RFC8929, 908 November 2020, . 910 11. Informative References 912 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 913 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 914 2006, . 916 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 917 DOI 10.17487/RFC4903, June 2007, 918 . 920 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 921 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 922 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 923 Low-Power and Lossy Networks", RFC 6550, 924 DOI 10.17487/RFC6550, March 2012, 925 . 927 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 928 Bormann, "Neighbor Discovery Optimization for IPv6 over 929 Low-Power Wireless Personal Area Networks (6LoWPANs)", 930 RFC 6775, DOI 10.17487/RFC6775, November 2012, 931 . 933 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 934 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 935 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 936 . 938 [RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix 939 per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017, 940 . 942 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 943 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 944 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 945 RFC 8415, DOI 10.17487/RFC8415, November 2018, 946 . 948 [I-D.ietf-rift-rift] 949 Przygienda, T., Sharma, A., Thubert, P., Rijsman, B., and 950 D. Afanasiev, "RIFT: Routing in Fat Trees", Work in 951 Progress, Internet-Draft, draft-ietf-rift-rift-12, 26 May 952 2020, 953 . 955 [RPL UNAWARE LEAVES] 956 Thubert, P. and M. Richardson, "Routing for RPL Leaves", 957 Work in Progress, Internet-Draft, draft-ietf-roll-unaware- 958 leaves-23, 10 November 2020, . 961 [DAD ISSUES] 962 Yourtchenko, A. and E. Nordmark, "A survey of issues 963 related to IPv6 Duplicate Address Detection", Work in 964 Progress, Internet-Draft, draft-yourtchenko-6man-dad- 965 issues-01, 3 March 2015, . 968 [MCAST EFFICIENCY] 969 Vyncke, E., Thubert, P., Levy-Abegnoli, E., and A. 970 Yourtchenko, "Why Network-Layer Multicast is Not Always 971 Efficient At Datalink Layer", Work in Progress, Internet- 972 Draft, draft-vyncke-6man-mcast-not-efficient-01, 14 973 February 2014, . 976 [I-D.ietf-6tisch-architecture] 977 Thubert, P., "An Architecture for IPv6 over the TSCH mode 978 of IEEE 802.15.4", Work in Progress, Internet-Draft, 979 draft-ietf-6tisch-architecture-29, 27 August 2020, 980 . 983 [MCAST PROBLEMS] 984 Perkins, C., McBride, M., Stanley, D., Kumari, W., and J. 985 Zuniga, "Multicast Considerations over IEEE 802 Wireless 986 Media", Work in Progress, Internet-Draft, draft-ietf- 987 mboned-ieee802-mcast-problems-12, 26 October 2020, 988 . 991 [SAVI] Bi, J., Wu, J., Wang, Y., and T. Lin, "A SAVI Solution for 992 WLAN", Work in Progress, Internet-Draft, draft-bi-savi- 993 wlan-20, 14 November 2020, 994 . 996 [UNICAST AR] 997 Thubert, P. and E. Levy-Abegnoli, "IPv6 Neighbor Discovery 998 Unicast Lookup", Work in Progress, Internet-Draft, draft- 999 thubert-6lo-unicast-lookup-00, 25 January 2019, 1000 . 1003 [DAD APPROACHES] 1004 Nordmark, E., "Possible approaches to make DAD more robust 1005 and/or efficient", Work in Progress, Internet-Draft, 1006 draft-nordmark-6man-dad-approaches-02, 19 October 2015, 1007 . 1010 [IEEE Std. 802.15.4] 1011 IEEE standard for Information Technology, "IEEE Std. 1012 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 1013 and Physical Layer (PHY) Specifications for Low-Rate 1014 Wireless Personal Area Networks". 1016 [IEEE Std. 802.11] 1017 IEEE standard for Information Technology, "IEEE Standard 1018 for Information technology -- Telecommunications and 1019 information exchange between systems Local and 1020 metropolitan area networks-- Specific requirements Part 1021 11: Wireless LAN Medium Access Control (MAC) and Physical 1022 Layer (PHY) Specifications". 1024 [IEEEstd802151] 1025 IEEE standard for Information Technology, "IEEE Standard 1026 for Information Technology - Telecommunications and 1027 Information Exchange Between Systems - Local and 1028 Metropolitan Area Networks - Specific Requirements. - Part 1029 15.1: Wireless Medium Access Control (MAC) and Physical 1030 Layer (PHY) Specifications for Wireless Personal Area 1031 Networks (WPANs)". 1033 [IEEEstd802154] 1034 IEEE standard for Information Technology, "IEEE Standard 1035 for Local and metropolitan area networks -- Part 15.4: 1036 Low-Rate Wireless Personal Area Networks (LR-WPANs)". 1038 [IEEE Std. 802.1] 1039 IEEE standard for Information Technology, "IEEE Standard 1040 for Information technology -- Telecommunications and 1041 information exchange between systems Local and 1042 metropolitan area networks Part 1: Bridging and 1043 Architecture". 1045 Author's Address 1047 Pascal Thubert (editor) 1048 Cisco Systems, Inc 1049 Building D 1050 45 Allee des Ormes - BP1200 1051 06254 Mougins - Sophia Antipolis 1052 France 1054 Phone: +33 497 23 26 34 1055 Email: pthubert@cisco.com