idnits 2.17.00 (12 Aug 2021) /tmp/idnits5795/draft-thubert-6man-ipv6-over-wireless-01.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 (April 30, 2019) is 1117 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == 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: draft-ietf-6tisch-architecture has been published as RFC 9030 == Outdated reference: A later version (-15) exists of draft-ietf-rift-rift-05 == Outdated reference: A later version (-02) exists of draft-thubert-6lo-unicast-lookup-00 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6MAN P. Thubert, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Informational April 30, 2019 5 Expires: November 1, 2019 7 IPv6 Neighbor Discovery on Wireless Networks 8 draft-thubert-6man-ipv6-over-wireless-01 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 November 1, 2019. 33 Copyright Notice 35 Copyright (c) 2019 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. IP Models . . . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2.1. Physical Broadcast Domain . . . . . . . . . . . . . . . . 2 53 2.2. MAC-Layer Broadcast Emulations . . . . . . . . . . . . . 3 54 2.3. Mapping the IPv6 Link Abstraction . . . . . . . . . . . . 5 55 2.4. Mapping the IPv6 Subnet Abstraction . . . . . . . . . . . 6 56 3. Wireless ND . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 3.1. Introduction to WiND . . . . . . . . . . . . . . . . . . 6 58 3.2. Links and Link-Local Addresses . . . . . . . . . . . . . 7 59 3.3. Subnets and Global Addresses . . . . . . . . . . . . . . 8 60 4. WiND Applicability . . . . . . . . . . . . . . . . . . . . . 9 61 4.1. Case of LPWANs . . . . . . . . . . . . . . . . . . . . . 10 62 4.2. Case of Infrastructure BSS and ESS . . . . . . . . . . . 10 63 4.3. Case of Mesh Under Technologies . . . . . . . . . . . . . 11 64 4.4. Case of DMC radios . . . . . . . . . . . . . . . . . . . 11 65 4.4.1. Using IPv6 ND only . . . . . . . . . . . . . . . . . 11 66 4.4.2. Using Wireless ND . . . . . . . . . . . . . . . . . . 11 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 69 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 72 8.2. Informative References . . . . . . . . . . . . . . . . . 15 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 75 1. Introduction 77 2. IP Models 79 2.1. Physical Broadcast Domain 81 At the physical (PHY) Layer, a broadcast domain is the set of all 82 peers that may receive a datagram that one sends over an interface. 83 This set can comprise a single peer on a serial cable used as point- 84 to-point (P2P) link. It may also comprise multiple peer nodes on a 85 broadcast radio or a shared physical resource such as the legacy 86 Ethernet shared wire. 88 On WLAN and WPAN radios, the physical broadcast domain is defined by 89 a particular transmitter, as the set of nodes that can receive what 90 this transmitter is sending. Litterally every datagram defines its 91 own broadcast domain since the chances of reception of a given 92 datagram are statistical. In average and in stable conditions, the 93 broadcast domain of a particular node can be still be seen as mostly 94 constant and can be used to define a closure of nodes on which an 95 upper-layer abstraction can be built. 97 A PHY-layer communication can be established between 2 nodes if their 98 physical broadcast domains overlap. 100 On WLAN and WPAN radios, this property is usually reflexive, meaning 101 that if B can receive a datagram from A, then A can receive a 102 datagram from B. But there can be asymmetries due to power levels, 103 interferers near one of the receivers, or differences in the quality 104 of the hardware (e.g., cristals, PAs and antennas) that may affect 105 the balance to the point that the connectivity becomes mostly uni- 106 directional, e.g., A to B but not practically not B to A. It takes a 107 particular effort to place a set of devices in a fashion that all 108 their physical broadcast domains fully overlap, and it can not be 109 assumed in the general case. In other words, the property of radio 110 connectivity is generally not transitive, meaning that A may talk to 111 B and B may talk to C does not necessarily imply that A can talk to 112 C. 114 We define MAC-Layer Direct Broadcast (DMC) a transmission mode where 115 the broadcast domain that is usable at the MAC layer is directly the 116 physical broadcast domain. IEEE 802.15.4 [IEEE802154] and IEEE 117 802.11 [IEEE80211] OCB (for Out of the Context of a BSS) are examples 118 of DMC radios. This constrasts with a number of MAC-layer Broadcast 119 Emulation schemes that are described in the next section. 121 2.2. MAC-Layer Broadcast Emulations 123 While a physical broadcast domain is constrained to a single shared 124 wire, Ethernet Briging emulates the broadcast properties of that wire 125 over a whole physical mesh of Ethernet links. For the upper layer, 126 the qualities of the shared wire are essentially conserved, with a 127 reliable and cheap broadcast operation over a closure of nodes 128 defined by their connectivity to the emulated wire. 130 In large switched fabrics, overlay techniques enable a limited 131 connectivity between nodes that are known to a mapping server. The 132 emulated broadcast domain is configured to the system, e.g., with a 133 VXLAN network identifier (VNID). Broadcast operations on the overlay 134 can be emulated but can become very expensive, and it makes sense to 135 proactively install the relevant state in the mapping server as 136 opposed to rely on reactive broadcast lookups. 138 An IEEE Std 802.11 Infrastructure Basic Service Set (BSS) also 139 provides a closure of nodes as defined by the broadcast domain of a 140 central Access Point (AP). The AP relays both unicast and broadcast 141 packets and ensures a reflexive and transitive emulation of the 142 shared wire between the associated nodes, with the capability to 143 signal link-up/link-down to the upper layer. Within an 144 Infrastructure BSS, the physical broadcast domain of the AP serves as 145 emulated broadcast domain for all the nodes that are associated to 146 the AP. Broadcast packets are relayed by the AP and are not 147 acknowledged. For that reason, special efforts are made to ensure 148 that all nodes in the BSS receive the broadcast transmission. To 149 achieve this, the transmission is sent at the highest power and 150 slowest PHY speed. This translates into maximum co-channel 151 interferences for others and longest occupancy of the medium, for a 152 duration that can be 100 times that of a unicast. For that reason, 153 upper layer protocols should tend to avoid the use of broadcast when 154 operating over Wi-Fi. 156 In an IEEE Std 802.11 Infrastructure Extended Service Set (ESS), the 157 process of the association also prepares a bridging state proactively 158 at the AP, so as to avoid the reactive broadcast lookup that takes 159 place in the process of transparent bridging over a spanning tree. 160 This model provides a more reliable operation than the reactive 161 transparent bridging and avoid the need of multicast, and it is only 162 logical that IPv6 [RFC8200] Neighbor Discovery (ND) 163 [RFC4861][RFC4862] evolved towards proposes similar methods at 164 Layer-3 for its operation. 166 in some cases of WLAN and WPAN radios, a mesh-under technology (e.g., 167 a IEEE 802.11s or IEEE 802.15.10) provides meshing services that are 168 similar to bridgeing, and the broadcast domain is well defined by the 169 membership of the mesh. Mesh-Under emulates a broadcast domain by 170 flooding the broadcast packets at Layer-2. When operating on a 171 single frequency, this operation is known to interfere with itself, 172 forcing deployment to introduce delays that dampen the collisions. 173 All in all, the mechanism is slow, inefficient and expensive. 175 Going down the list of cases above, the cost of a broadcast 176 transmissions becomes increasingly expensive, and there is a push to 177 rethink the upper-layer protocols so as to reduce the depency on 178 broadcast operations. 180 There again, a MAC-layer communication can be established between 2 181 nodes if their MAC-layer broadcast domains overlap. In the absence 182 of a MAC-layer emulation such as a mesh-under or an Infrastructure 183 BSS, the MAC-layer broadcast domain is congruent with that of the 184 PHY-layer and inherits its properties for reflexivity and 185 transitivity. IEEE 802.11p, which operates Out of the Context of a 186 BSS (DMC radios) is an example of a network that does not have a MAC- 187 Layer broadcast domain emulation, which means that it will exhibit 188 mostly reflexive and mostly non-transitive transmission properties. 190 2.3. Mapping the IPv6 Link Abstraction 192 IPv6 defines a concept of Link, Link Scope and Link-Local Addresses 193 (LLA), an LLA being unique and usable only within the Scope of a 194 Link. The IPv6 Neighbor Discovery (ND) [RFC4861][RFC4862] Duplicate 195 Adress Detection (DAD) process leverages a multicast transmission to 196 ensure that an IPv6 address is unique as long as the owner of the 197 address is connected to the broadcast domain. It must be noted that 198 in all the cases in this specification, the Layer-3 multicast 199 operation is always a MAC_Layer broadcast for the lack of a Layer-2 200 multicast operation that could handle a possibly very large number of 201 groups in order to make the unicast efficient. This means that for 202 every multicast packet regardless of the destination group, all nodes 203 will receive the packet and process it all the way to Layer-3. 205 On wired media, the Link is often confused with the physical 206 broadcast domain because both are determined by the serial cable or 207 the Ethernet shared wire. Ethernet Bridging reinforces that illusion 208 by provising a MAC-Layer broadcast domain that emulates a physical 209 broadcast domain over the mesh of wires. But the difference shows on 210 legacy Non-Broadcast Multi-Access (NBMA) such as ATM and Frame-Relay, 211 on shared links and on newer types of NBMA networks such as radio and 212 composite radio-wires networks. It also shows when private VLANs or 213 Layer-2 cryptography restrict the capability to read a frame to a 214 subset of the connected nodes. 216 In mesh-under and Infrastructure BSS, the IP Link extends beyond the 217 physical broadcast domain to the emulated MAC-Layer broadcast domain. 218 Relying on Multicast for the ND operation remains feasible but 219 becomes detrimental to unicast traffic, energy-inefficient and 220 unreliable, and its use is discouraged. 222 On DMC radios, IP Links between peers come and go as the individual 223 physical broadcast domains of the transmitters meet and overlap. The 224 DAD operation cannot provide once and for all guarantees on the 225 broadcast domain defined by one radio transmitter if that transmitter 226 keeps meeting new peers on the go. The nodes may need to form new 227 LLAs to talk to one another and the scope where LLA uniqueness can be 228 dynamically checked is that pair of nodes. As long as there's no 229 conflict a node may use the same LLA with multiple peers but it has 230 to revalidate DAD with every new peer node. In practice, each pair 231 of nodes defines a temporary P2P link, which can be modeled as a sub- 232 interface of the radio interface. 234 2.4. Mapping the IPv6 Subnet Abstraction 236 IPv6 also defines a concept of Subnet for Glocal and Unique Local 237 Addresses. Addresses in a same Subnet share a same prefix and by 238 extension, a node belongs to a Subnet if it has an interface with an 239 address on that Subnet. A Subnet prefix is Globally Unique so it is 240 sufficient to validate that an address that is formed from a Subnet 241 prefix is unique within that Subnet to guarantee that it is globally 242 unique. IPv6 aggregation relies on the property that a packet from 243 the outside of a Subnet can be routed to any router that belongs to 244 the Subnet, and that this router will be able to either resolve the 245 destination MAC address and deliver the packet, or route the packet 246 to the destination within the Subnet. If the Subnet is known as 247 onlink, then any node may also resolve the destination MAC address 248 and deliver the packet, but if the Subnet is not onlink, then a host 249 that does not have an NCE for the destination will need to pass the 250 packet to a router. 252 On IEEE Std. 802.3, a Subnet is often congruent with an IP Link 253 because both are determined by the physical attachment to an Ethernet 254 shared wire or an IEEE Std. 802.1 bridged broadcast domain. In that 255 case, the connectivity over the Link is transitive, the Subnet can 256 appear as onlink, and any node can resolve a destination MAC address 257 of any other node directly using IPv6 Neighbor Discovery. 259 But an IP Link and an IP Subnet are not always congruent. In a 260 shared Link situation, a Subnet may encompass only a subset of the 261 nodes connected to the Link. In Route-Over Multi-Link Subnets (MLSN) 262 [RFC4903], routers federate the Links between nodes that belong to 263 the Subnet, the Subnet is not onlink and it extends beyond any of the 264 federated Links. 266 The DAD and lookup procedures in IPv6 ND expects that a node in a 267 Subnet is reachable within the broadcast domain of any other node in 268 the Subnet when that other node attempts to form an address that 269 would be a duplicate or attempts to resolve the MAC address of this 270 node. This is why ND is only applicable for P2P and transit links, 271 and requires extensions for other topologies. 273 3. Wireless ND 275 3.1. Introduction to WiND 277 Wireless Neighbor Discovery (WiND) 278 [RFC6775][RFC8505][I-D.ietf-6lo-backbone-router][I-D.ietf-6lo-ap-nd] 279 defines a new ND operation that is based on 2 major paradigm changes, 280 proactive address registration by hosts to their attachment routers 281 and routing to host routes (/128) within the subnet. This allows 282 WiND to avoid the classical ND expectations of transit links and 283 Subnet-wide broadcast domains. 285 The proactive address registration is performed with a new option in 286 NS/NA messages, the Extended Address Registration Option (EARO) 287 defiend in [RFC8505]. This method allows to prepare and maintain the 288 host routes in the routers and avoids the reactive NS(Lookup) found 289 in IPv6 ND. This is a direct benefit for wireless Links since it 290 avoids the MAC level broadcasts that are associated to NS(Lookup). 292 The EARO provides information to the router that is independent to 293 the routing protocol and routing can take multiple forms, from a 294 traditional IGP to a collapsed ub-and-Spoke model where only one 295 router owns and advertises the prefix. [RFC8505] is already 296 referenced for RIFT [I-D.ietf-rift-rift], RPL [RFC6550] with 297 [I-D.thubert-roll-unaware-leaves] and IPv6 ND proxy 298 [I-D.ietf-6lo-backbone-router]. 300 WiND does not change IPv6 addressing [RFC4291] or the current 301 practices of assigning prefixes to subnets. It is still typical to 302 assign a /64 to a subnet and to use interface IDs of 64 bits. 303 Duplicate Address detection within the Subnet is performed with a 304 central registrar, using new ND Extended Duplicate Address messages 305 (EDAR and EDAC) [RFC8505]. This operation modernizes ND for 306 application in overlays with Map Resolvers and enables unicast 307 lookups [I-D.thubert-6lo-unicast-lookup] for addresses registered to 308 the resolver. 310 WiND also enables to extend a legacy /64 on Ethernet with ND proxy 311 over the wireless. This way nodes can form any address the want and 312 move freely from an L3-AP (that is really a backbone router in 313 bridging mode, more in [I-D.ietf-6lo-backbone-router]) to another, 314 without renumbering. 316 WiND is also compatible with DHCPv6 and other forms of address 317 assignment in which case it can still be used for DAD. 319 3.2. Links and Link-Local Addresses 321 For Link-Local Addresses, DAD is performed between communicating 322 pairs of nodes. It is carried out as part of a registration process 323 that is based on a NS/NA exchange that transports an EARO. During 324 that process, the DAD is validated and a Neighbor Cache Entry (NCE) 325 is populated with a single unicast exchange. 327 Ior instance, in the case of a Bluetooth Low Energy (BLE) [RFC7668] 328 Hub-and Spoke configuration, Uniqueness of Link local Addresses need 329 only to be verified between the pairs of communicating nodes, a 330 central router and a peripheral host. In that example, 2 peripheral 331 hosts connected to the same central router can not have the same Link 332 Local Address because the Binding Cache Entries (BCEs) would collide 333 at the central router which could not talk to both over the same 334 interface. The WiND operation is appropriate for that DAD operation, 335 but the one from ND is not, because peripheral hosts are not on the 336 same broadcast domain. On the other hand, Global and ULA DAD is 337 validated at the Subnet Level, using a registrar hosted by the 338 central router. 340 3.3. Subnets and Global Addresses 342 WiND extends IPv6 ND for Hub-and-Spoke (e.g., BLE) and Route-Over 343 (e.g., RPL) Multi-Link Subnets (MLSNs). 345 In the Hub-and-Spoke case, each Hub-Spoke pair is a distinct IP Link, 346 and a Subnet can be mapped on a collection of Links that are 347 connected to the Hub. The Subnet prefix is associated to the Hub. 348 Acting as 6LR, the Hub advertises the prefix as not-onlink to the 349 spokes in RA messages Prefix Information Options (PIO). Acting as 350 6LNs, the Spokes autoconfigure addresses from that prefix and 351 register them to the Hub with a corresponding lifetime. Acting as a 352 6LBR, the Hub maintains a binding table of all the registered IP 353 addresses and rejects duplicate registrations, thus ensuring a DAD 354 protection for a registered address even if the registering node is 355 sleeping. Acting as 6LR, the Hub also maintains an NCE for the 356 registered addresses and can deliver a packet to any of them for 357 their respective lifetimes. It can be observed that this design 358 builds a form of Layer-3 Infrastructure BSS. 360 A Route-Over MLSN is considered as a collection of Hub-and-Spoke 361 where the Hubs form a connected dominating set of the member nodes of 362 the Subnet, and IPv6 routing takes place between the Hubs within the 363 Subnet. A single logical 6LBR is deployed to serve the whole mesh. 364 The registration in [RFC8505] is abstract to the routing protocol and 365 provides enough information to feed a routing protocol such as RPL 366 [draft unaware leaf]. In a degraded mode, all the Hubs are connected 367 to a same high speed backbone such as an Ethernet bridging domain 368 where IPv6 ND is operated. In that case, it is possible to federate 369 the Hub, Spoke and Backbone nodes as a single Subnet, operating IPv6 370 ND proxy operations [I-D.ietf-6lo-backbone-router] at the Hubs, 371 acting as 6BBRs. It can be observed that this latter design builds a 372 form of Layer-3 Infrastructure ESS. 374 4. WiND Applicability 376 WiND allows P2P, P2MP hub-and spoke, MAC-level broadcast domain 377 emulation such as mesh-under and Wi-Fi BSS, and route over meshes.^ 379 There is an intersection where Link and Subnet are congruent and 380 where both ND and WiND could apply. These includes P2P, the MAC 381 emulation of a PHY broadcast domain, and the particular case of 382 always on, fully overlapping physical radio broadcast domain. But 383 even in those cases where both are possible, WiND is preferable vs. 384 ND because it reduces the need of broadcast ( this is discussed in 385 the introduction of [I-D.ietf-6lo-backbone-router]). 387 There are also numerous practical use cases in the wireless world 388 where Links and Subnets are not P2P and not congruent: 390 o IEEE std 802.11 infrastructure BSS enables one subnet per AP, and 391 emulates a broadcast domain at L2. Infra ESS extends that and 392 recommends to use an IPv6 ND proxy [IEEE80211] to coexist with 393 Ethernet connected nodes. WiND incorporates an ND proxy to serve 394 that need and that was missing so far. 396 o BlueTooth is Hub-and-Spoke at the MAC layer. It would make little 397 sense to configure a different subnet between the central and each 398 individual peripheral node (e.g., sensor). Rather, [RFC7668] 399 allocates a prefix to the central node acting as router (6LR), and 400 each peripheral host (acting as a host (6LR) forms one or more 401 address(es) from that same prefix and registers it. 403 o A typical Smartgrid networks puts together Route-Over MLSNs that 404 comprise thousands of IPv6 nodes. The 6TiSCH architecture 405 [I-D.ietf-6tisch-architecture] reflects the Route-Over model, and 406 generalizes it for multiple other applications. Each node in a 407 Smartgrid network may have tens to a hundred others nodes in 408 range. A key problem for the routing protocol is which other 409 node(s) should this node peer with, because most of the possible 410 peers do not provide added routing value. When both energy and 411 bandwidth are constrained,talking to them is a bad idea and most 412 of the possible P2P links are not even used. Peerings that are 413 actually used come and go with the dynamics of radio signal 414 propagation. It results that allocating prefixes to all the 415 possible P2P Links and maintain as many addresses in all nodes is 416 not even considered. 418 4.1. Case of LPWANs 420 LPWANs are by nature so constrained that the addresses and Subnets 421 are fully pre-configured and operate as P2P or Hub-and-Spoke. This 422 saves the steps of neighbor Discovery and enables a very efficient 423 stateful compression of the IPv6 header. 425 4.2. Case of Infrastructure BSS and ESS 427 In contrast to IPv4, IPv6 enables a node to form multiple addresses, 428 some of them temporary to elusive, and with a particular attention 429 paid to privacy. Addresses may be formed and deprecated 430 asynchronously to the association. Even if the knowledge of IPv6 431 addresses used by a STA can be obtained by snooping protocols such as 432 IPv6 ND and DHCPv6, or by observing data traffic sourced at the STA, 433 such methods provide only an imperfect knowledge of the state of the 434 STA at the AP. This may result in a loss of connectivity for some 435 IPv6 addresses, in particular for addresses rarely used and in a 436 situation of mobility. This may also result in undesirable remanent 437 state in the AP when a STA ceases to use an IPv6 address. It results 438 that snooping protocols is not a recommended technique and that it 439 should only be used as last resort. 441 The recommended alternate is to use the IPv6 Registration method 442 speficied in p. By that method, the AP exposes its capability to 443 proxy ND to the STA in Router Advertisement messages. In turn, the 444 STA may request proxy ND services from the AP for one or more IPv6 445 addresses, using an Address Registration Option. The Registration 446 state has a lifetime that limits unwanted state remanence in the 447 network. The registration is optionally secured using 448 [I-D.ietf-6lo-ap-nd] to prevent address theft and impersonation. The 449 registration carries a sequence number, which enables a fast mobility 450 without a loss of connectivity. 452 The ESS mode requires a proxy ND operation at the AP. The proxy ND 453 operation must cover Duplicate Address Detection, Neighbor 454 Unreachability Detection, Address Resolution and Address Mobility to 455 transfer a role of ND proxy to the AP where a STA is associated 456 following the mobility of the STA. The proxy ND specification 457 associated to the address registration is 458 [I-D.ietf-6lo-backbone-router]. With that specification, the AP 459 participates to the protocol as a Backbone Router, typically 460 operating as a bridging proxy though the routing proxy operation is 461 also possible. As a bridging proxy, the proxy replies to NS lookups 462 with the MAC address of the STA, and then bridges packets to the STA 463 normally; as a routing proxy, it replies with its own MAC address and 464 then routes to the STA at the IP layer. The routing proxy reduces 465 the need to expose the MAC address of the STA on the wired side, for 466 a better stability and scalability of the bridged fabric. 468 4.3. Case of Mesh Under Technologies 470 The Mesh-Under provides a broadcast domain emulation with reflexive 471 and Transitive properties and defines a transit Link for IPv6 472 operations. It results that the model for IPv6 operation is similar 473 to that of a BSS, with the root of the mesh operating an Access Point 474 does in a BSS/ESS. While it is still possible to operate IPv6 ND, 475 the inefficiencies of the flooding operation make the IPv6 ND 476 operations even less desirable than in a BSS, and the use of WiND is 477 highly recommended. 479 4.4. Case of DMC radios 481 IPv6 over DMC radios uses P2P Links that can be formed and maintained 482 when a pair of DMC radios transmitters are in range from one another. 484 4.4.1. Using IPv6 ND only 486 DMC radios do not provide MAC level broadcast emulation. An example 487 of that is OCB (outside the context of a BSS), which uses IEEE Std. 488 802.11 transmissions but does not provide the BSS functions. 490 It is possible to form P2P IP Links between each individual pairs of 491 nodes and operate IPv6 ND over those Links with Link Local addresses. 492 DAD must be performed for all addresses on all P2P IP Links. 494 If special deployment care is taken so that the physical broadcast 495 domains of a collection of the nodes fully overlap, then it is also 496 possible to build an IP Subnet within that collection of nodes and 497 operate IPv6 ND. 499 The model can be stretched beyond the scope of IPv6 ND if an external 500 mechanism avoids duplicate addresses and if the deployment ensures 501 the connectivity between peers. This can be achieved for instance in 502 a Hub-and-Spoke deployment if the Hub is the only router in the 503 Subnet and the Prefix is advertised as not onlink. 505 4.4.2. Using Wireless ND 507 Though this can be achieved with IPv6 ND, WiND is the recommended 508 approach since it uses more unicast communications which are more 509 reliable and less impacting for other users of the medium. 511 Router and Hosts respectively send a compressed RA/NA with a SLLAO at 512 a regular period. The period can be indicated in a RA as in an RA- 513 Interval Option [RFC6275]. If available, the message can be 514 transported in a compressed form in a beacon, e.g., in OCB Basic 515 Safety Messages (BSM) that are nominally sent every 100ms. An active 516 beaconing mode is possible whereby the Host sends broadcast RS 517 messages to which a router can answer with a unicast RA. 519 A router that has Internet connectivity and is willing to serve as an 520 Internet Access may advertise itself as a default router [RFC4191] in 521 its RA. The NA/RA is sent over an Unspecified Link where it does not 522 conflict to anyone, so DAD is not necessary at that stage. 524 The receiver instantiates a Link where the sender's address is not a 525 duplicate. To achieve this, it forms an LLA that does not conflict 526 with that of the sender and registers to the sender using [RFC8505]. 527 If the sender sent an RA(PIO) the receiver can also autoconfigure an 528 address from the advertised prefix and register it. 530 6LoWPAN Node 6LR 531 (RPL leaf) (router) 532 | | 533 | LLN link | 534 | | 535 | IPv6 ND RS | 536 |-------------->| 537 |-----------> | 538 |------------------> 539 | IPv6 ND RA | 540 |<--------------| 541 | | 542 | NS(EARO) | 543 |-------------->| 544 | | 545 | NA(EARO) | 546 |<--------------| 547 | | 549 Figure 1: Initial Registration Flow 551 The lifetime in the registration should start with a small value 552 (X=RMin, TBD), and exponentially grow with each reregistration to a 553 mlarger value (X=Rmax, TBD). The IP Link is considered down when 554 (X=NbBeacons, TDB) expected messages are not received in a row. It 555 must be noted that the Link flapping does not affect the state of the 556 registration and when a Link comes back up, the active -lifetime not 557 elapsed- registrations are still usable. Packets should be held or 558 destroyed when the Link is down. 560 P2P Links may be federated in Hub-and-Spoke and then in Route-Over 561 MLSNs as described above. More details on the operation of WiND and 562 RPL over the MLSN can be found in section 3.1, 3.2, 4.1 and 4.2.2 of 563 [I-D.ietf-6tisch-architecture]. 565 6LoWPAN Node 6LR 6LBR 6BBR 566 (RPL leaf) (router) (root) 567 | | | | 568 | 6LoWPAN ND |6LoWPAN ND+RPL | 6LoWPAN ND | IPv6 ND 569 | LLN link |Route-Over mesh|Ethernet/serial| Backbone 570 | | | | 571 | IPv6 ND RS | | | 572 |-------------->| | | 573 |-----------> | | | 574 |------------------> | | 575 | IPv6 ND RA | | | 576 |<--------------| | | 577 | | | | 578 | NS(EARO) | | | 579 |-------------->| | | 580 | 6LoWPAN ND | Extended DAR | | 581 | |-------------->| | 582 | | | NS(EARO) | 583 | | |-------------->| 584 | | | | NS-DAD 585 | | | |------> 586 | | | | (EARO) 587 | | | | 588 | | | NA(EARO) | 589 | | |<--------------| 590 | | Extended DAC | | 591 | |<--------------| | 592 | NA(EARO) | | | 593 |<--------------| | | 594 | | | | 596 Figure 2: Initial Registration Flow over Multi-Link Subnet 598 An example Hub-and-Spoke is an OCB Road-Side Unit (RSU) that owns a 599 prefix, provides Internet connectivity using that prefix to On-Board 600 Units (OBUs) within its physical broadcast domain. An example of 601 Route-Over MLSN is a collection of cars in a parking lot operating 602 RPL to extend the connectivity provided by the RSU beyond its 603 physical broadcast domain. Cars may then operate NEMO [RFC3963] for 604 their own prefix using their address derived from the prefix of the 605 RSU as CareOf Address. 607 5. IANA Considerations 609 This specification does not require IANA action. 611 6. Security Considerations 613 This specification refers to the security sections of IPv6 ND and 614 WiND, respectively. 616 7. Acknowledgments 618 Many thanks to the participants of the 6lo WG where a lot of the work 619 discussed here happened. Also ROLL, 6TiSCH, and 6LoWPAN. 621 8. References 623 8.1. Normative References 625 [I-D.ietf-6lo-ap-nd] 626 Thubert, P., Sarikaya, B., Sethi, M., and R. Struik, 627 "Address Protected Neighbor Discovery for Low-power and 628 Lossy Networks", draft-ietf-6lo-ap-nd-12 (work in 629 progress), April 2019. 631 [I-D.ietf-6lo-backbone-router] 632 Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 633 Backbone Router", draft-ietf-6lo-backbone-router-11 (work 634 in progress), February 2019. 636 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 637 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 638 RFC 3963, DOI 10.17487/RFC3963, January 2005, 639 . 641 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 642 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 643 November 2005, . 645 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 646 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 647 DOI 10.17487/RFC4861, September 2007, 648 . 650 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 651 Address Autoconfiguration", RFC 4862, 652 DOI 10.17487/RFC4862, September 2007, 653 . 655 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 656 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 657 2011, . 659 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 660 (IPv6) Specification", STD 86, RFC 8200, 661 DOI 10.17487/RFC8200, July 2017, 662 . 664 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 665 Perkins, "Registration Extensions for IPv6 over Low-Power 666 Wireless Personal Area Network (6LoWPAN) Neighbor 667 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 668 . 670 8.2. Informative References 672 [I-D.ietf-6tisch-architecture] 673 Thubert, P., "An Architecture for IPv6 over the TSCH mode 674 of IEEE 802.15.4", draft-ietf-6tisch-architecture-20 (work 675 in progress), March 2019. 677 [I-D.ietf-rift-rift] 678 Team, T., "RIFT: Routing in Fat Trees", draft-ietf-rift- 679 rift-05 (work in progress), April 2019. 681 [I-D.thubert-6lo-unicast-lookup] 682 Thubert, P. and E. Levy-Abegnoli, "IPv6 Neighbor Discovery 683 Unicast Lookup", draft-thubert-6lo-unicast-lookup-00 (work 684 in progress), January 2019. 686 [I-D.thubert-roll-unaware-leaves] 687 Thubert, P., "Routing for RPL Leaves", draft-thubert-roll- 688 unaware-leaves-07 (work in progress), April 2019. 690 [IEEE80211] 691 "IEEE Standard 802.11 - IEEE Standard for Information 692 Technology - Telecommunications and information exchange 693 between systems Local and metropolitan area networks - 694 Specific requirements - Part 11: Wireless LAN Medium 695 Access Control (MAC) and Physical Layer (PHY) 696 Specifications.". 698 [IEEE802154] 699 IEEE standard for Information Technology, "IEEE Std. 700 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 701 and Physical Layer (PHY) Specifications for Low-Rate 702 Wireless Personal Area Networks". 704 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 705 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 706 2006, . 708 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 709 DOI 10.17487/RFC4903, June 2007, 710 . 712 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 713 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 714 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 715 Low-Power and Lossy Networks", RFC 6550, 716 DOI 10.17487/RFC6550, March 2012, 717 . 719 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 720 Bormann, "Neighbor Discovery Optimization for IPv6 over 721 Low-Power Wireless Personal Area Networks (6LoWPANs)", 722 RFC 6775, DOI 10.17487/RFC6775, November 2012, 723 . 725 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 726 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 727 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 728 . 730 Author's Address 732 Pascal Thubert (editor) 733 Cisco Systems, Inc 734 Building D 735 45 Allee des Ormes - BP1200 736 MOUGINS - Sophia Antipolis 06254 737 FRANCE 739 Phone: +33 497 23 26 34 740 Email: pthubert@cisco.com