idnits 2.17.1 draft-thubert-6man-ipv6-over-wireless-00.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 26, 2019) is 1820 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 8505' is mentioned on line 421, but not defined == Unused Reference: 'RFC8200' is defined on line 554, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 586, but no explicit reference was found in the text == Unused Reference: 'RFC4389' is defined on line 590, but no explicit reference was found in the text == Unused Reference: 'RFC4903' is defined on line 594, but no explicit reference was found in the text == Outdated reference: A later version (-23) exists of draft-ietf-6lo-ap-nd-12 == Outdated reference: A later version (-20) exists of draft-ietf-6lo-backbone-router-11 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-20 Summary: 0 errors (**), 0 flaws (~~), 9 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 26, 2019 5 Expires: October 28, 2019 7 IPv6 Neighbor Discovery on Wireless Networks 8 draft-thubert-6man-ipv6-over-wireless-00 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 October 28, 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 . . . . . . . . . . . . 4 55 2.4. Mapping the IPv6 Subnet Abstraction . . . . . . . . . . . 6 56 3. IPv6 Over Wireless . . . . . . . . . . . . . . . . . . . . . 7 57 3.1. Case of LPWANs . . . . . . . . . . . . . . . . . . . . . 7 58 3.2. Case of Infrastructure BSS and ESS . . . . . . . . . . . 7 59 3.3. Case of Mesh Under Technologies . . . . . . . . . . . . . 8 60 3.4. Case of DMC radios . . . . . . . . . . . . . . . . . . . 8 61 3.4.1. Using IPv6 ND only . . . . . . . . . . . . . . . . . 9 62 3.4.2. Using Wireless ND . . . . . . . . . . . . . . . . . . 9 63 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 65 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 68 7.2. Informative References . . . . . . . . . . . . . . . . . 13 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 71 1. Introduction 73 2. IP Models 75 2.1. Physical Broadcast Domain 77 At the physical (PHY) Layer, a broadcast domain is the set of all 78 peers that may receive a datagram that one sends over an interface. 79 This set can comprise a single peer on a serial cable used as point- 80 to-point (P2P) link. It may also comprise multiple peer nodes on a 81 broadcast radio or a shared physical resource such as the legacy 82 Ethernet shared wire. 84 On WLAN and WPAN radios, the physical broadcast domain is defined by 85 a particular transmitter, as the set of nodes that can receive what 86 this transmitter is sending. Litterally every datagram defines its 87 own broadcast domain since the chances of reception of a given 88 datagram are statistical. In average and in stable conditions, the 89 broadcast domain of a particular node can be still be seen as mostly 90 constant and can be used to define a closure of nodes on which an 91 upper-layer abstraction can be built. 93 A PHY-layer communication can be established between 2 nodes if their 94 physical broadcast domains overlap. 96 On WLAN and WPAN radios, this property is usually reflexive, meaning 97 that if B can receive a datagram from A, then A can receive a 98 datagram from B. But there can be asymmetries due to power levels, 99 interferers near one of the receivers, or differences in the quality 100 of the hardware (e.g., cristals, PAs and antennas) that may affect 101 the balance to the point that the connectivity becomes mostly uni- 102 directional, e.g., A to B but not practically not B to A. It takes a 103 particular effort to place a set of devices in a fashion that all 104 their physical broadcast domains fully overlap, and it can not be 105 assumed in the general case. In other words, the property of radio 106 connectivity is generally not transitive, meaning that A may talk to 107 B and B may talk to C does not necessarily imply that A can talk to 108 C. 110 We define MAC-Layer Direct Broadcast (DMC) a transmission mode where 111 the broadcast domain that is usable at the MAC layer is directly the 112 physical broadcast domain. IEEE 802.15.4 [IEEE802154] and IEEE 113 802.11 [IEEE80211] OCB (for Out of the Context of a BSS) are examples 114 of DMC radios. This constrasts with a number of MAC-layer Broadcast 115 Emulation schemes that are described in the next section. 117 2.2. MAC-Layer Broadcast Emulations 119 While a physical broadcast domain is constrained to a single shared 120 wire, Ethernet Briging emulates the broadcast properties of that wire 121 over a whole physical mesh of Ethernet links. For the upper layer, 122 the qualities of the shared wire are essentially conserved, with a 123 reliable and cheap broadcast operation over a closure of nodes 124 defined by their connectivity to the emulated wire. 126 In large switched fabrics, overlay techniques enable a limited 127 connectivity between nodes that are known to a mapping server. The 128 emulated broadcast domain is configured to the system, e.g., with a 129 VXLAN network identifier (VNID). Broadcast operations on the overlay 130 can be emulated but can become very expensive, and it makes sense to 131 proactively install the relevant state in the mapping server as 132 opposed to rely on reactive broadcast lookups. 134 An IEEE Std 802.11 Infrastructure Basic Service Set (BSS) also 135 provides a closure of nodes as defined by the broadcast domain of a 136 central Access Point (AP). The AP relays both unicast and broadcast 137 packets and ensures a reflexive and transitive emulation of the 138 shared wire between the associated nodes, with the capability to 139 signal link-up/link-down to the upper layer. Within an 140 Infrastructure BSS, the physical broadcast domain of the AP serves as 141 emulated broadcast domain for all the nodes that are associated to 142 the AP. Broadcast packets are relayed by the AP and are not 143 acknowledged. For that reason, special efforts are made to ensure 144 that all nodes in the BSS receive the broadcast transmission. To 145 achieve this, the transmission is sent at the highest power and 146 slowest PHY speed. This translates into maximum co-channel 147 interferences for others and longest occupancy of the medium, for a 148 duration that can be 100 times that of a unicast. For that reason, 149 upper layer protocols should tend to avoid the use of broadcast when 150 operating over Wi-Fi. 152 In an IEEE Std 802.11 Infrastructure Extended Service Set (ESS), the 153 process of the association also prepares a bridging state proactively 154 at the AP, so as to avoid the reactive broadcast lookup that takes 155 place in the process of transparent bridging over a spanning tree. 156 This model provides a more reliable operation than the reactive 157 transparent bridging and avoid the need of multicast, and it is only 158 logical that IPv6 ND evolved towards proposes similar methods at 159 Layer-3 for its operation. 161 in some cases of WLAN and WPAN radios, a mesh-under technology (e.g., 162 a IEEE 802.11s or IEEE 802.15.10) provides meshing services that are 163 similar to bridgeing, and the broadcast domain is well defined by the 164 membership of the mesh. Mesh-Under emulates a broadcast domain by 165 flooding the broadcast packets at Layer-2. When operating on a 166 single frequency, this operation is known to interfere with itself, 167 forcing deployment to introduce delays that dampen the collisions. 168 All in all, the mechanism is slow, inefficient and expensive. 170 Going down the list of cases above, the cost of a broadcast 171 transmissions becomes increasingly expensive, and there is a push to 172 rethink the upper-layer protocols so as to reduce the depency on 173 broadcast operations. 175 There again, a MAC-layer communication can be established between 2 176 nodes if their MAC-layer broadcast domains overlap. In the absence 177 of a MAC-layer emulation such as a mesh-under or an Infrastructure 178 BSS, the MAC-layer broadcast domain is congruent with that of the 179 PHY-layer and inherits its properties for reflexivity and 180 transitivity. IEEE 802.11p, which operates Out of the Context of a 181 BSS (DMC radios) is an example of a network that does not have a MAC- 182 Layer broadcast domain emulation, which means that it will exhibit 183 mostly reflexive and mostly non-transitive transmission properties. 185 2.3. Mapping the IPv6 Link Abstraction 187 IPv6 defines a concept of Link, Link Scope and Link-Local Addresses 188 (LLA), an LLA being unique and usable only within the Scope of a 189 Link. The IPv6 Neighbor Discovery (ND) [RFC4861][RFC4862] Duplicate 190 Adress Detection (DAD) process leverages a multicast transmission to 191 ensure that an IPv6 address is unique as long as the owner of the 192 address is connected to the broadcast domain. It must be noted that 193 in all the cases in this specification, the Layer-3 multicast 194 operation is always a MAC_Layer broadcast for the lack of a Layer-2 195 multicast operation that could handle a possibly very large number of 196 groups in order to make the unicast efficient. This means that for 197 every multicast packet regardless of the destination group, all nodes 198 will receive the packet and process it all the way to Layer-3. 200 On wired media, the Link is often confused with the physical 201 broadcast domain because both are determined by the serial cable or 202 the Ethernet shared wire. Ethernet Bridging reinforces that illusion 203 by provising a MAC-Layer broadcast domain that emulates a physical 204 broadcast domain over the mesh of wires. But the difference shows on 205 legacy Non-Broadcast Multi-Access (NBMA) such as ATM and Frame-Relay, 206 on shared links and on newer types of NBMA networks such as radio and 207 composite radio-wires networks. It also shows when private VLANs or 208 Layer-2 cryptography restrict the capability to read a frame to a 209 subset of the connected nodes. 211 In mesh-under and Infrastructure BSS, the IP Link extends beyond the 212 physical broadcast domain to the emulated MAC-Layer broadcast domain. 213 Relying on Multicast for the ND operation remains feasible but 214 becomes detrimental to unicast traffic, energy-inefficient and 215 unreliable, and its use is discouraged. 217 On DMC radios, IP Links between peers come and go as the individual 218 physical broadcast domains of the transmitters meet and overlap. The 219 DAD operation cannot provide once and for all guarantees on the 220 broadcast domain defined by one radio transmitter if that transmitter 221 keeps meeting new peers on the go. The nodes may need to form new 222 LLAs to talk to one another and the scope where LLA uniqueness can be 223 dynamically checked is that pair of nodes. As long as there's no 224 conflict a node may use the same LLA with multiple peers but it has 225 to revalidate DAD with every new peer node. In practice, each pair 226 of nodes defines a temporary P2P link, which can be modeled as a sub- 227 interface of the radio interface. 229 Wireless Neighbor Discovery (WiND) 230 [RFC6775][RFC8505][I-D.ietf-6lo-backbone-router][I-D.ietf-6lo-ap-nd] 231 defines a new ND operation that derives from the IEEE 802.11 232 Infrastructure mode. For LLAs, DAD is performed between 233 communicating pairs of nodes. It is carried out as part of a 234 registration process that is based on a NS/NA exchange that 235 transports an Extended Address Registration Option (EARO). During 236 that process, the DAD is validated and a Neighbor Cache Entry (NCE) 237 is populated with a single unicast exchange. 239 2.4. Mapping the IPv6 Subnet Abstraction 241 IPv6 also defines a concept of Subnet for Glocal and Unique Local 242 Addresses. Addresses in a same Subnet share a same prefix and by 243 extension, a node belongs to a Subnet if it has an interface with an 244 address on that Subnet. A Subnet prefix is Globally Unique so it is 245 sufficient to validate that an address that is formed from a Subnet 246 prefix is unique within that Subnet to guarantee that it is globally 247 unique. IPv6 aggregation relies on the property that a packet from 248 the outside of a Subnet can be routed to any router that belongs to 249 the Subnet, and that this router will be able to either resolve the 250 destination MAC address and deliver the packet, or route the packet 251 to the destination within the Subnet. If the Subnet is known as 252 onlink, then any node may also resolve the destination MAC address 253 and deliver the packet, but if the Subnet is not onlink, then a host 254 that does not have an NCE for the destination will need to pass the 255 packet to a router. 257 On IEEE Std. 802.3, a Subnet is often congruent with an IP Link 258 because both are determined by the physical attachment to an Ethernet 259 shared wire or an IEEE Std. 802.1 bridged broadcast domain. In that 260 case, the connectivity over the Link is transitive, the Subnet can 261 appear as onlink, and any node can resolve a destination MAC address 262 of any other node directly using IPv6 Neighbor Discovery. 264 But an IP Link and an IP Subnet are not always congruent. In a 265 shared Link situation, a Subnet may encompass only a subset of the 266 nodes connected to the Link. In Route-Over Multi-Link Subnets 267 (MLSN), routers federate the Links between nodes that belong to the 268 Subnet, the Subnet is not onlink and it extends beyond any of the 269 federated Links. 271 The DAD and lookup procedures in IPv6 ND expects that a node in a 272 Subnet is reachable within the broadcast domain of any other node in 273 the Subnet when that other node attempts to form an address that 274 would be a duplicate or attempts to resolve the MAC address of this 275 node. This is why ND is only applicable for P2P and transit links, 276 and requires extensions for other topologies. 278 WiND extends IPv6 ND for Hub-and-Spoke MLSN (e.g., a central and some 279 peripheral nodes in Bluetooth low energy (BTLE)[RFC7668]) and Route- 280 Over MLSN (e.g., [I-D.ietf-6tisch-architecture] leveraging [RFC6550]) 281 topologies. 283 In the Hub-and-Spoke case, each Hub-Spoke pair is a distinct IP Link, 284 and a Subnet can be mapped on a collection of Links that are 285 connected to the Hub. The Subnet prefix is associated to the Hub. 286 Acting as 6LR, the Hub advertises the prefix as not-onlink to the 287 spokes in RA messages Prefix Information Options (PIO). Acting as 288 6LNs, the Spokes autoconfigure addresses from that prefix and 289 register them to the Hub with a corresponding lifetime. Acting as a 290 6LBR, the Hub maintains a binding table of all the registered IP 291 addresses and rejects duplicate registrations, thus ensuring a DAD 292 protection for a registered address even if the registering node is 293 sleeping. Acting as 6LR, the Hub also maintains an NCE for the 294 registered addresses and can deliver a packet to any of them for 295 their respective lifetimes. It can be observed that this design 296 builds a form of Layer-3 Infrastructure BSS. 298 A Route-Over MLSN is considered as a collection of Hub-and-Spoke 299 where the Hubs form a connected dominating set of the member nodes of 300 the Subnet, and IPv6 routing takes place between the Hubs within the 301 Subnet. A single logical 6LBR is deployed to serve the whole mesh. 302 The registration in [RFC8505] is abstract to the routing protocol and 303 provides enough information to feed a routing protocol such as RPL 304 [draft unaware leaf]. In a degraded mode, all the Hubs are connected 305 to a same high speed backbone such as an Ethernet bridging domain 306 where IPv6 ND is operated. In that case, it is possible to federate 307 the Hub, Spoke and Backbone nodes as a single Subnet, operating IPv6 308 ND proxy operations [I-D.ietf-6lo-backbone-router] at the Hubs, 309 acting as 6BBRs. It can be observed that this latter design builds a 310 form of Layer-3 Infrastructure ESS. 312 3. IPv6 Over Wireless 314 3.1. Case of LPWANs 316 LPWANs are by nature so constrained that the addresses and Subnets 317 are fully pre-configured and operate as P2P or Hub-and-Spoke. This 318 saves the steps of neighbor Discovery and enables a very efficient 319 stateful compression of the IPv6 header. 321 3.2. Case of Infrastructure BSS and ESS 323 In contrast to IPv4, IPv6 enables a node to form multiple addresses, 324 some of them temporary to elusive, and with a particular attention 325 paid to privacy. Addresses may be formed and deprecated 326 asynchronously to the association. Even if the knowledge of IPv6 327 addresses used by a STA can be obtained by snooping protocols such as 328 IPv6 ND and DHCPv6, or by observing data traffic sourced at the STA, 329 such methods provide only an imperfect knowledge of the state of the 330 STA at the AP. This may result in a loss of connectivity for some 331 IPv6 addresses, in particular for addresses rarely used and in a 332 situation of mobility. This may also result in undesirable remanent 333 state in the AP when a STA ceases to use an IPv6 address. It results 334 that snooping protocols is not a recommended technique and that it 335 should only be used as last resort. 337 The recommended alternate is to use the IPv6 Registration method 338 speficied in p. By that method, the AP exposes its capability to 339 proxy ND to the STA in Router Advertisement messages. In turn, the 340 STA may request proxy ND services from the AP for one or more IPv6 341 addresses, using an Address Registration Option. The Registration 342 state has a lifetime that limits unwanted state remanence in the 343 network. The registration is optionally secured using 344 [I-D.ietf-6lo-ap-nd] to prevent address theft and impersonation. The 345 registration carries a sequence number, which enables a fast mobility 346 without a loss of connectivity. 348 The ESS mode requires a proxy ND operation at the AP. The proxy ND 349 operation must cover Duplicate Address Detection, Neighbor 350 Unreachability Detection, Address Resolution and Address Mobility to 351 transfer a role of ND proxy to the AP where a STA is associated 352 following the mobility of the STA. The proxy ND specification 353 associated to the address registration is 354 [I-D.ietf-6lo-backbone-router]. With that specification, the AP 355 participates to the protocol as a Backbone Router, typically 356 operating as a bridging proxy though the routing proxy operation is 357 also possible. As a bridging proxy, the proxy replies to NS lookups 358 with the MAC address of the STA, and then bridges packets to the STA 359 normally; as a routing proxy, it replies with its own MAC address and 360 then routes to the STA at the IP layer. The routing proxy reduces 361 the need to expose the MAC address of the STA on the wired side, for 362 a better stability and scalability of the bridged fabric. 364 3.3. Case of Mesh Under Technologies 366 The Mesh-Under provides a broadcast domain emulation with reflexive 367 and Transitive properties and defines a transit Link for IPv6 368 operations. It results that the model for IPv6 operation is similar 369 to that of a BSS, with the root of the mesh operating an Access Point 370 does in a BSS/ESS. While it is still possible to operate IPv6 ND, 371 the inefficiencies of the flooding operation make the IPv6 ND 372 operations even less desirable than in a BSS, and the use of WiND is 373 highly recommended. 375 3.4. Case of DMC radios 377 IPv6 over DMC radios uses P2P Links that can be formed and maintained 378 when a pair of DMC radios transmitters are in range from one another. 380 3.4.1. Using IPv6 ND only 382 By definition, DMC radios uses IEEE Std. 802.11 transmissions but 383 does not provide the BSS functions. 385 It is possible to form P2P IP Links between each individual pairs of 386 nodes and operate IPv6 ND over those Links with Link Local addresses. 387 DAD must be performed for all addresses on all P2P IP Links. 389 If special deployment care is taken so that the physical broadcast 390 domains of a collection of the nodes fully overlap, then it is also 391 possible to build an IP Subnet within that collection of nodes and 392 operate IPv6 ND. 394 The model can be stretched beyond the scope of IPv6 ND if an external 395 mechanism avoids duplicate addresses and if the deployment ensures 396 the connectivity between peers. This can be achieved for instance in 397 a Hub-and-Spoke deployment if the Hub is the only router in the 398 Subnet and the Prefix is advertised as not onlink. 400 3.4.2. Using Wireless ND 402 Though this can be achieved with IPv6 ND, WiND is the recommended 403 approach since it uses more unicast communications which are more 404 reliable and less impacting for other users of the medium. 406 Router and Hosts respectively send a compressed RA/NA with a SLLAO at 407 a regular period. The period can be indicated in a RA as in an RA- 408 Interval Option [RFC6275]. If available, the message can be 409 transported in a compressed form in a beacon, e.g., in OCB Basic 410 Safety Messages (BSM) that are nominally sent every 100ms. An active 411 beaconing mode is possible whereby the Host sends broadcast RS 412 messages to which a router can answer with a unicast RA. 414 A router that has Internet connectivity and is willing to serve as an 415 Internet Access may advertise itself as a default router [RFC4191] in 416 its RA. The NA/RA is sent over an Unspecified Link where it does not 417 conflict to anyone, so DAD is not necessary at that stage. 419 The receiver instantiates a Link where the sender's address is not a 420 duplicate. To achieve this, it forms an LLA that does not conflict 421 with that of the sender and registers to the sender using [RFC 8505]. 422 If the sender sent an RA(PIO) the receiver can also autoconfigure an 423 address from the advertised prefix and register it. 425 6LoWPAN Node 6LR 426 (RPL leaf) (router) 427 | | 428 | LLN link | 429 | | 430 | IPv6 ND RS | 431 |-------------->| 432 |-----------> | 433 |------------------> 434 | IPv6 ND RA | 435 |<--------------| 436 | | 437 | NS(EARO) | 438 |-------------->| 439 | | 440 | NA(EARO) | 441 |<--------------| 442 | | 444 Figure 1: Initial Registration Flow 446 The lifetime in the registration should start with a small value 447 (X=RMin, TBD), and exponentially grow with each reregistration to a 448 mlarger value (X=Rmax, TBD). The IP Link is considered down when 449 (X=NbBeacons, TDB) expected messages are not received in a row. It 450 must be noted that the Link flapping does not affect the state of the 451 registration and when a Link comes back up, the active -lifetime not 452 elapsed- registrations are still usable. Packets should be held or 453 destroyed when the Link is down. 455 P2P Links may be federated in Hub-and-Spoke and then in Route-Over 456 MLSNs as described above. More details on the operation of WiND and 457 RPL over the MLSN can be found in section 3.1, 3.2, 4.1 and 4.2.2 of 458 [I-D.ietf-6tisch-architecture]. 460 6LoWPAN Node 6LR 6LBR 6BBR 461 (RPL leaf) (router) (root) 462 | | | | 463 | 6LoWPAN ND |6LoWPAN ND+RPL | 6LoWPAN ND | IPv6 ND 464 | LLN link |Route-Over mesh|Ethernet/serial| Backbone 465 | | | | 466 | IPv6 ND RS | | | 467 |-------------->| | | 468 |-----------> | | | 469 |------------------> | | 470 | IPv6 ND RA | | | 471 |<--------------| | | 472 | | | | 473 | NS(EARO) | | | 474 |-------------->| | | 475 | 6LoWPAN ND | Extended DAR | | 476 | |-------------->| | 477 | | | NS(EARO) | 478 | | |-------------->| 479 | | | | NS-DAD 480 | | | |------> 481 | | | | (EARO) 482 | | | | 483 | | | NA(EARO) | 484 | | |<--------------| 485 | | Extended DAC | | 486 | |<--------------| | 487 | NA(EARO) | | | 488 |<--------------| | | 489 | | | | 491 Figure 2: Initial Registration Flow over Multi-Link Subnet 493 An example Hub-And-Spoke is an OCB Road-Side Unit (RSU) that owns a 494 prefix, provides Internet connectivity using that prefix to On-Board 495 Units (OBUs) within its physical broadcast domain. An example of 496 Route-Over MLSN is a collection of cars in a parking lot operating 497 RPL to extend the connectivity provided by the RSU beyond its 498 physical broadcast domain. Cars may then operate NEMO [RFC3963] for 499 their own prefix using their address derived from the prefix of the 500 RSU as CareOf Address. 502 4. IANA Considerations 504 This specification does not require IANA action. 506 5. Security Considerations 508 This specification refers to the security sections of IPv6 ND and 509 WiND, respectively. 511 6. Acknowledgments 513 Many thanks to the participants of the 6lo WG where a lot of the work 514 discussed here happened. Also ROLL, 6TiSCH, and 6LoWPAN. 516 7. References 518 7.1. Normative References 520 [I-D.ietf-6lo-ap-nd] 521 Thubert, P., Sarikaya, B., Sethi, M., and R. Struik, 522 "Address Protected Neighbor Discovery for Low-power and 523 Lossy Networks", draft-ietf-6lo-ap-nd-12 (work in 524 progress), April 2019. 526 [I-D.ietf-6lo-backbone-router] 527 Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 528 Backbone Router", draft-ietf-6lo-backbone-router-11 (work 529 in progress), February 2019. 531 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 532 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 533 RFC 3963, DOI 10.17487/RFC3963, January 2005, 534 . 536 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 537 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 538 November 2005, . 540 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 541 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 542 DOI 10.17487/RFC4861, September 2007, 543 . 545 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 546 Address Autoconfiguration", RFC 4862, 547 DOI 10.17487/RFC4862, September 2007, 548 . 550 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 551 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 552 2011, . 554 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 555 (IPv6) Specification", STD 86, RFC 8200, 556 DOI 10.17487/RFC8200, July 2017, 557 . 559 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 560 Perkins, "Registration Extensions for IPv6 over Low-Power 561 Wireless Personal Area Network (6LoWPAN) Neighbor 562 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 563 . 565 7.2. Informative References 567 [I-D.ietf-6tisch-architecture] 568 Thubert, P., "An Architecture for IPv6 over the TSCH mode 569 of IEEE 802.15.4", draft-ietf-6tisch-architecture-20 (work 570 in progress), March 2019. 572 [IEEE80211] 573 "IEEE Standard 802.11 - IEEE Standard for Information 574 Technology - Telecommunications and information exchange 575 between systems Local and metropolitan area networks - 576 Specific requirements - Part 11: Wireless LAN Medium 577 Access Control (MAC) and Physical Layer (PHY) 578 Specifications.". 580 [IEEE802154] 581 IEEE standard for Information Technology, "IEEE Std. 582 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 583 and Physical Layer (PHY) Specifications for Low-Rate 584 Wireless Personal Area Networks". 586 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 587 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 588 2006, . 590 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 591 Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 592 2006, . 594 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 595 DOI 10.17487/RFC4903, June 2007, 596 . 598 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 599 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 600 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 601 Low-Power and Lossy Networks", RFC 6550, 602 DOI 10.17487/RFC6550, March 2012, 603 . 605 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 606 Bormann, "Neighbor Discovery Optimization for IPv6 over 607 Low-Power Wireless Personal Area Networks (6LoWPANs)", 608 RFC 6775, DOI 10.17487/RFC6775, November 2012, 609 . 611 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 612 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 613 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 614 . 616 Author's Address 618 Pascal Thubert (editor) 619 Cisco Systems, Inc 620 Building D 621 45 Allee des Ormes - BP1200 622 MOUGINS - Sophia Antipolis 06254 623 FRANCE 625 Phone: +33 497 23 26 34 626 Email: pthubert@cisco.com