idnits 2.17.1 draft-ietf-6lo-backbone-router-09.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4861, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC8505, but the abstract doesn't seem to directly say this. It does mention RFC8505 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4861, updated by this document, for RFC5378 checks: 2004-07-16) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 5, 2018) is 1970 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) == Missing Reference: 'IEEEstd8021' is mentioned on line 1124, but not defined == Missing Reference: 'IEEEstd80211' is mentioned on line 1131, but not defined == Missing Reference: 'IEEEstd802151' is mentioned on line 1139, but not defined == Missing Reference: 'IEEEstd802154' is mentioned on line 1202, but not defined == Outdated reference: A later version (-24) exists of draft-bi-savi-wlan-16 == Outdated reference: A later version (-23) exists of draft-ietf-6lo-ap-nd-08 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-17 == Outdated reference: A later version (-15) exists of draft-ietf-mboned-ieee802-mcast-problems-04 -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6lo P. Thubert, Ed. 3 Internet-Draft Cisco Systems 4 Updates: 4861, 8505 (if approved) C. Perkins 5 Intended status: Standards Track Futurewei 6 Expires: June 8, 2019 E. Levy-Abegnoli 7 Cisco Systems 8 December 5, 2018 10 IPv6 Backbone Router 11 draft-ietf-6lo-backbone-router-09 13 Abstract 15 Backbone Routers are RFC8505 Routing Registrars that provide proxy 16 services for IPv6 Neighbor Discovery. Backbone Routers federate 17 multiple wireless Links over a Backbone Link to form a MultiLink 18 Subnet. Backbone Routers placed along the wireless edge of the 19 Backbone handle IPv6 Neighbor Discovery, and route packets on behalf 20 of registered nodes. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on June 8, 2019. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.2. References . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.3. New Terms . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.4. Acronym Definitions . . . . . . . . . . . . . . . . . . . 6 62 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 3.1. Access Link . . . . . . . . . . . . . . . . . . . . . . . 9 64 3.2. Route-Over Mesh . . . . . . . . . . . . . . . . . . . . . 10 65 3.3. MultiLink Subnet Consistency . . . . . . . . . . . . . . 11 66 3.4. Registering Node . . . . . . . . . . . . . . . . . . . . 11 67 3.5. Using IPv6 ND Over the Backbone Link . . . . . . . . . . 12 68 3.6. Routing Proxy Operations . . . . . . . . . . . . . . . . 13 69 3.7. Bridging Proxy Operations . . . . . . . . . . . . . . . . 14 70 3.8. Leveraging Optimistic DAD . . . . . . . . . . . . . . . . 14 71 4. Updating RFC 4861 . . . . . . . . . . . . . . . . . . . . . . 15 72 5. Updating RFC 8505 . . . . . . . . . . . . . . . . . . . . . . 15 73 6. 6BBR detailed Operations . . . . . . . . . . . . . . . . . . 15 74 6.1. Primary and Secondary 6BBRs . . . . . . . . . . . . . . 16 75 6.2. Binding Table . . . . . . . . . . . . . . . . . . . . . . 16 76 6.3. Registration and Binding Table Entry Creation . . . . . . 17 77 6.4. Defending Addresses . . . . . . . . . . . . . . . . . . . 18 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 79 8. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 20 80 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 81 10. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 20 82 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 83 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 84 12.1. Normative References . . . . . . . . . . . . . . . . . . 21 85 12.2. Informative References . . . . . . . . . . . . . . . . . 22 86 12.3. External Informative References . . . . . . . . . . . . 24 87 Appendix A. Applicability and Requirements Served . . . . . . . 25 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 90 1. Introduction 92 IEEE STD. 802.1 [IEEEstd8021] Ethernet Bridging provides an efficient 93 and reliable broadcast service; applications and protocols have been 94 built that heavily depend on that feature for their core operation. 95 Unfortunately, Low-Power Lossy Networks (LLNs) and local wireless 96 networks generally do not provide the broadcast capabilities of 97 Ethernet Bridging in an economical fashion; protocols designed for 98 bridged networks that rely on multicast and broadcast often exhibit 99 disappointing behaviours when employed unmodified on a local wireless 100 medium (see [I-D.ietf-mboned-ieee802-mcast-problems]). 102 Wi-Fi [IEEEstd80211] Access Points (APs) deployed in an Extended 103 Service Set (ESS) act as Ethernet Bridges [IEEEstd8021], with the 104 interesting caveat that the bridging state is populated proactively 105 at the association time. This ensures a solid connectivity to the 106 node (STA) and protects the wireless medium against the broadcast- 107 intensive Transparent Bridging reactive lookups. In other words, the 108 association process is used to register the MAC Address of the STA to 109 the AP. The APs subsequently proxies the bridging operation and does 110 not need to forward the broadcast lookups over the radio. 112 Like Transparent Bridging, the operations of the IPv6 [RFC8200] 113 Neighbor Discovery [RFC4861] [RFC4862] Protocol (IPv6 ND) are 114 reactive and rely heavily on multicast transmissions to locate an on- 115 link correspondent and ensure the uniqueness of an Address. The 116 mechanism for Duplicate Address Detection (DAD) [RFC4862] was also 117 designed as a natural match with the efficient broadcast operation of 118 Ethernet Bridging. However, since broadcast can be unreliable over 119 wireless media, DAD often fails to discover duplications 120 [I-D.yourtchenko-6man-dad-issues]. A conflict of IPv6 Address is 121 still a very rare event, not because Address duplications are 122 detected and solved as designed, but because of the sheer entropy of 123 the 64-bit Interface IDs. 125 IPv6 multicast messages are typically broadcast over the wireless 126 medium; they are processed by most if not all the wireless nodes over 127 the subnet - e.g., the ESS fabric - even when very few if any of the 128 nodes is subscribed to the multicast flow. The IPv6 ND Neighbor 129 Solicitation (NS) [RFC4861] is such a message; NS messages are used 130 for DAD and Address lookup, and are frequently observed in a 131 situation of mobility and when a node wakes up and reconnects to the 132 wireless network. The NS message is targeted to a Sollicitated-Node 133 Multicast Address (SNMA) [RFC4291] and should in theory only reach a 134 very small group of nodes; but since Layer-3 multicast messages are 135 effectively broadcasted at Layer-2, the volume of Address lookups and 136 DADs over a large fabric can effectively consume bandwidth to the 137 point that it becomes detrimental to unicast traffic (see 138 [I-D.ietf-mboned-ieee802-mcast-problems]). 140 Additionally, wireless nodes that do not belong to the SNMA group 141 still have to keep their radio awake and listen to broadcasted NS 142 messages, which is a total waste of energy for them. In order to 143 control their power consumption, battery-operated nodes such as IOT 144 sensors and smartphones may then elect to blindly ignore a portion of 145 the broadcasts, which tends to make the Layer-3 protocol operations 146 even less reliable. 148 These problems can be alleviated by a reduction of IPv6 ND broadcasts 149 over wireless access links. One classical way to achieve this to 150 split the broadcast domains and route between subnets, possibly by 151 assigning a /64 prefix to each wireless node (see [RFC8273]). 153 Another way is to proxy the Layer-3 protocols that rely on broadcast 154 operations at the boundary of the wired and wireless domains, in a 155 fashion similar to the Layer-2 association but at layer-3. To that 156 effect, IEEE 802.11 [IEEEstd80211] requires ARP and proxy-ND 157 [RFC4389] services at the Access Points (APs), and this specification 158 is a possible response to that requirement. 160 IPv6 proxy-ND services can be obtained automatically by snooping the 161 IPV6 ND protocol (see [I-D.bi-savi-wlan]). Proprietary techniques 162 for IPv6 ND and DHCP snooping are effectively deployed, and though 163 snooping is really useful to cancel undesirable broadcast 164 transmissions, it has also proven to be unreliable; An IPv6 Address 165 may not be discovered immediately due to a packet loss, or a silent 166 node that does not use the Address for a while; a change of state 167 (e.g. due a movement) may be missed or misordered, leading to 168 unreliable connectivity and a partial knowledge of the state of the 169 network. 171 With this specification, a wireless node proactively registers its 172 IPv6 Addresses using a NS(EARO) as specified in [RFC8505] to an IPv6 173 Backbone Router (6BBR). The 6BBR is a Routing Registrar per 174 [RFC8505]. It is also a Border Router that performs the IPv6 proxy 175 Neighbor Discovery operations on its Backbone interface on behalf of 176 the 6LNs that are registered on its LLN interfaces. This effectively 177 recreates at Layer-3 the equivalent of an association such as found 178 in IEEE STD. 802.11 for the purpose of providing reachability to the 179 registered Addresses without the need of a broadcast lookup over the 180 wireless medium. Additional benefits are discussed in Appendix A. 182 2. Terminology 184 2.1. BCP 14 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 188 "OPTIONAL" in this document are to be interpreted as described in BCP 189 14 [RFC2119][RFC8174] when, and only when, they appear in all 190 capitals, as shown here. 192 2.2. References 194 In this document, readers will encounter terms and concepts that are 195 discussed in the following documents: 197 o "Neighbor Discovery Proxies (proxy-ND)" [RFC4389] 199 o "Optimistic Duplicate Address Detection" [RFC4429], and 201 o "Neighbor Discovery for IP version 6" [RFC4861], 203 o "IPv6 Stateless Address Autoconfiguration" [RFC4862], 205 o "MultiLink Subnet Issues" [RFC4903], 207 o "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): 208 Overview, Assumptions, Problem Statement, and Goals" [RFC4919], 210 o Neighbor Discovery Optimization for Low-Power and Lossy Networks 211 [RFC6775], 213 o ,"Mobility Support in IPv6" [RFC6275], 215 o "Problem Statement and Requirements for IPv6 over Low-Power 216 Wireless Personal Area Network (6LoWPAN) Routing" [RFC6606], and 217 mostly 219 o "Registration Extensions for 6LoWPAN Neighbor Discovery" 220 [RFC8505]. 222 2.3. New Terms 224 This document also introduces the following terminology: 226 Federated 228 A subnet that is partitionned over a Backbone and one or more 229 (wireless) access links, is said to be federated into one 230 MultiLink Subnet by the proxy-ND operation of 6BBRs located at 231 the edge of the Backbone and the access links and providing a 232 semblance of a non-partitionned subnet for IPv6 ND over the 233 Backbone. 235 Sleeping Proxy 237 A 6BBR acts as a Sleeping Proxy if it answers ND Neighbor 238 Solicitation over the Backbone on behalf of the Registered 239 Node. 241 Unicasting Proxy 243 A Unicasting Proxy forwards NS messages to the Registering 244 Node, transforming Layer-2 multicast into unicast. 246 Routing Proxy 248 A Routing Proxy advertises its own MAC Address as the TLLA in 249 the proxied NAs over the Backbone, as opposed to that of the 250 node that performs the registration. 252 Bridging Proxy 254 A Bridging Proxy advertises the MAC Address of the node that 255 performs the registration as the TLLA in the proxied NAs over 256 the Backbone. In that case, the MAC Address and the mobility 257 of 6LN is still visible across the bridged Backbone fabric. 259 Primary 6BBR 261 The 6BBR that will defend a Registered Address for the purpose 262 of DAD over the Backbone. 264 Secondary 6BBR 266 A 6BBR other than the Primary 6BBR to which an Address is 267 registered. A Secondary Router MAY advertise the Address over 268 the Backbone and proxy for it. 270 2.4. Acronym Definitions 272 This document uses the following acronyms: 274 6BBR: 6LoWPAN Backbone Router 276 6LBR: 6LoWPAN Border Router 278 6LN: 6LoWPAN Node 280 6LR: 6LoWPAN Router 282 6CIO: Capability Indication Option 284 EARO: (Extended) Address Registration Option -- (E)ARO 286 EDAR: (Extended) Duplicate Address Request -- (E)DAR 288 EDAC: (Extended) Duplicate Address Confirmation -- (E)DAC 289 DAD: Duplicate Address Detection 291 DODAG: Destination-Oriented Directed Acyclic Graph 293 LLN: Low-Power and Lossy Network 295 NA: Neighbor Advertisement 297 NCE: Neighbor Cache Entry 299 ND: Neighbor Discovery 301 NDP: Neighbor Discovery Protocol 303 NS: Neighbor Solicitation 305 ROVR: Registration Ownership Verifier (pronounced rover) 307 RPL: IPv6 Routing Protocol for LLNs (pronounced ripple) [RFC6550] 309 RA: Router Advertisement 311 RS: Router Solicitation 313 TID: Transaction ID (a sequence counter in the EARO) 315 3. Overview 317 A 6BBR provides proxy-ND services to 6LNs attached to an LLN that is 318 anchored at the 6BBR; this way, a subnet that is located on a 319 Backbone can be extended in the LLN as a MultiLink Subnet. The LLN 320 may be a hub-and-spoke network, a mesh-under or a route-over network. 322 The proxy-ND operation can co-exist with IPv6 ND over the Backbone. 323 The proxy state can be distributed across multiple 6BBR attached to a 324 same Backbone. A 6LN may move freely from an LLN anchored at one 325 6BBR to an LLN anchored at another 6BBR on the same Backbone and 326 retain any or all of the IPv6 Addresses that the 6LN has formed. 328 The registration to a proxy service is done via a NS/NA(EARO) 329 exchange. The 6BBR operation resembles that of a Mobile IPv6 (MIPv6) 330 [RFC6275] Home Agent. The combination if a 6BBR and a MIPv6 HA 331 enables a full mobility support for 6LNs, inside and outside the 332 links that form the subnet. 334 | 335 +-----+ 336 | | Gateway (default) Router 337 | | 338 +-----+ 339 | 340 | Backbone Link 341 +-------------------------+----------------------+ 342 | | | 343 +------+ +------+ +------+ 344 | 6BBR | | 6BBR | | 6BBR | 345 | | | | | | 346 +------+ +------+ +------+ 347 o o o o o o 348 o o o o o o o o o o o o o o 349 o o o o o o o o o o o o o o o 350 o o o o o o o o o o 351 o o o o o o o 353 LLN LLN LLN 355 Figure 1: Backbone Link and Backbone Routers 357 Each Backbone Router (6BBR) maintains an abstract Binding Table of 358 its Registered Nodes. The Binding Tables form a distributed database 359 of 6LNs that reside on the LLNs or on the IPv6 Backbone, and use an 360 extension to IPv6 ND to exchange that information across the 361 Backbone. In that process: 363 The Extended Address Registration Option (EARO) defined in 364 [RFC8505] is used in the ND exchanges over the Backbone between 365 the 6BBRs to help distinguish duplication from movement. 366 Optionally, Extended Duplicate Address Messages (EDAR and EDAC) 367 can also be used between the 6BBR and a 6LBR if one is present on 368 the Backbone. Address duplication is detected using the ROVR 369 field, and conflicting registrations to different 6BBRs by a same 370 owner 6LR are resolved using the TID field. 372 The Link Layer Address (LLA) that the 6BBR advertises for the 373 Registered Address on behalf of the Registered Node over the 374 Backbone may be that of the Registering Node; in that case, the 375 6BBR needs to bridge the unicast packets (Bridging Proxy). 376 Alternatively, the LLA can be that of the 6BBR on the Backbone 377 interface, in which case the 6BBRs receives at Layer-2 and and 378 needs to route at Layer-3 the unicast packets (Routing Proxy). 379 This is discussed in more details in Section 3.6 and Section 3.7, 380 respectively. 382 3.1. Access Link 384 This specification also applies to (hub-and-spoke) Access Links such 385 as (Low-Power) IEEE STD. 802.11 (Wi-Fi) [IEEEstd80211] and IEEE STD. 386 802.15.1 (Bluetooth) [IEEEstd802151]. Figure 2 illustrates an ODAD- 387 complient (see Section 3.8) example of a 6LN that forms an IPv6 388 Address and registers it to a 6BBR acting as a 6LR [RFC8505]. 390 6LoWPAN Node 6BBR 6LBR default 391 (STA) (AP) Router 392 |(Wireless) LLN | IPv6 ND Backbone | 393 | | (Ethernet) | 394 | RS | | | 395 |-------------->| | | 396 | (multicast) | | | 397 | | | | 398 | RA(PIO) | | | 399 |<--------------| | | 400 | (L2 unicast) | | | 401 | | | | 402 | NS(EARO) | | | 403 |-------------->| | | 404 | (optimistic) | | | 405 | | Extended DAR | | 406 | |------------->| | 407 | | Extended DAC | | 408 | |<-------------| | 409 | | NS-DAD(EARO) | 410 | |------------------------------>| 411 | |-------> (multicast) | 412 | |---------------------> | 413 | | RS(no SLLAO, for ODAD) | 414 | |------------------------------>| 415 | | (if no BCE) NS-LOOKUP | 416 | |<------------------------------| 417 | | NA(SLLAO, not(O), EARO) | 418 | |------------------------------>| 419 | | RA(unicast) | 420 | |<------------------------------| 421 | | | | 422 | IPv6 Packets in optimistic mode | 423 |<--------------------------------------------->| 424 | | | | 425 | NA(EARO) |DAD | | 426 |<--------------| | | 427 | | | | 429 Figure 2: Initial Registration Flow to a 6BBR acting as Routing Proxy 431 3.2. Route-Over Mesh 433 In the case of a Route-Over Mesh, e.g., using RPL [RFC6550], the 434 6TiSCH architecture [I-D.ietf-6tisch-architecture] suggests to 435 collocate the RPL root with a 6LoWPAN Border Router (6LBR), which is 436 either collocated with or connected to the 6BBR over an IPv6 Link. 438 Figure 3 illustrates the initial IPv6 signaling that enables a 6LN to 439 form a Global or a Unique-Local Address and register it to the 6LBR 440 using [RFC8505]. The 6LBR also leverages [RFC8505] to register the 441 6LNs on their behalf to the 6BBR and obtain proxy-ND services. 443 6LoWPAN Node 6LR 6LBR 6BBR 444 (mesh leaf) (mesh router) (mesh root) 445 | | | | 446 | 6LoWPAN ND |6LoWPAN ND+RPL | 6LoWPAN ND | IPv6 ND 447 | LLN link |Route-Over mesh|Ethernet/serial| Backbone 448 | | |/Internal call | 449 | IPv6 ND RS | | | 450 |-------------->| | | 451 |-----------> | | | 452 |------------------> | | 453 | IPv6 ND RA | | | 454 |<--------------| | | 455 | | | | 456 | NS(EARO) | | | 457 |-------------->| | | 458 | 6LoWPAN ND | Extended DAR | | 459 | |-------------->| | 460 | | | NS(EARO) | 461 | | |-------------->| 462 | | | (proxied) | NS-DAD 463 | | | |------> 464 | | | | (EARO) 465 | | | | 466 | | | NA(EARO) | 467 | | |<--------------| 468 | | Extended DAC | | 469 | |<--------------| | 470 | NA(EARO) | | | 471 |<--------------| | | 472 | | | | 474 Figure 3: Initial Registration Flow over Route-Over Mesh 476 3.3. MultiLink Subnet Consistency 478 The Backbone and the federated LLN Links are considered as different 479 Links in the MultiLink Subnet, even if multiple LLNs are attached to 480 a same 6BBR. Multicast ND messages are link-scoped and MUST NOT be 481 forwarded across the Backbone Routers. 483 A prefix that is used across a MultiLink Subnet may still be 484 advertised as on-link over the Backbone, by setting the "L" bit in 485 the Prefix Information Option (PIO) in RA messages ([RFC4861]), in 486 order to support classical IPv6 hosts; but the MultiLink Subnet 487 prefix MUST be advertised as not-onlink in RAs sent towards the LLN. 489 Nodes located inside the subnet will not perform the IPv6 Path MTU 490 Discovery [RFC8201] between one another. For that reason, the MTU 491 must have a same value on the Backbone and all attached LLNs. To 492 achieve this, the 6BBR MUST use the same MTU value that is used in 493 RAs over the Backbone in the RAs that it transmits towards the LLN 494 links. 496 3.4. Registering Node 498 A Registering Node MUST implement [RFC6775] as updated by [RFC8505] 499 in order to interact with a 6BBR. As such, it does not depend on 500 multicast RAs to discover the 6LR(s). 502 The Registering Node MUST accept multicast RAs, but those are 503 expected to be rare within in the LLN is the best practices 504 ([RFC7772]) are followed. 506 The Registering Node SHOULD comply with the Simple Procedures for 507 Detecting Network Attachment in IPv6 [RFC6059] (DNA procedures) to 508 assert movements, and support Packet-Loss Resiliency for Router 509 Solicitations [RFC7559] in order to make the unicast RS messages more 510 reliable. 512 The Registering Node signals that it requires IPv6 proxy-ND services 513 from a 6BBR by registering the corresponding IPv6 Address with an 514 NS(EARO) message with the 'R' flag set ([RFC8505]). It may be the 515 actual owner of the IPv6 Address or a 6LBR that performs the 516 registration on its behalf in a Route-Over mesh. 518 The Registering Node SHOULD register all of its Global Unicast and 519 Unique-Local IPv6 Addresses to the 6BBRs. Failure to register a 520 subset of Addresses may result in those Addresses being unreachable 521 by other parties if the 6BBR cancels the NS(LOOKUP) over the LLN or 522 to selected LLN nodes that are known to register their addresses. 524 3.5. Using IPv6 ND Over the Backbone Link 526 On the Backbone side, the 6BBR MUST join the SNMA group that 527 corresponds to a Registered Address as soon as it creates an entry 528 for that Address, and conserve its SNMA membership as long as it 529 maintains the associated entry. The 6BBR uses either the SNMA or 530 plain unicast to defend the Registered Addresses in its Binding 531 Table over the Backbone. 533 The 6BBR advertises and defends the Registered Addresses over the 534 Backbone using the IPv6 ND protocol [RFC4861]. It MUST uses an EARO 535 in the NS(DAD) and NA messages that it generates over the Backbone 536 Link for the Registered Address. A NA message generated in response 537 to a NS(LOOKUP) MUST NOT have the override (O) bit set. A proxied NS 538 MUST NOT contain an SLLAO to avoid the confusion with a registration. 540 A 6BBR may asynchronously update the NCEs in correspondent nodes over 541 the Backbone, e.g., in case of a movement. This is achieved using a 542 gratuitous NA with the override (O) bit set, that may be sent unicast 543 to each individual correspondent, or multicast to all nodes (more in 544 Section 3.7 and Section 3.6). 546 A 6LBR may optionally be deployed over the Backbone. When that is 547 the case, the 6BBR uses an EDAR/EDAC echange to check for duplication 548 or movement as prescribed in [RFC8505]. If this registration is 549 duplicate or not the freshest, then the 6LBR replies with a status 550 code of 1 ("Duplicate Address") or 3 ("Moved"), respectively. If 551 this registration is the freshest, then the 6LBR replies with a 552 status code of 0; in that case, if there was an existing registration 553 on an old 6BBR, then the 6LBR also sends an asynchronous EDAC with a 554 status of 4 ("Removed") to the old 6BBR. Note that an alternate 555 protocol such as LISP [RFC6830] may be used to provide an equivalent 556 service. 558 Nodes implementing this specification is expected to co-exist on a 559 same Backbone Link with nodes implementing classical IPv6 ND 560 [RFC4861] and snooping [I-D.bi-savi-wlan]. It results that the fact 561 that there is a 6LBR or an alternate protocol that is deployed on the 562 Backbone does not mean that all IPv6 addresses are known there; the 563 fact that a unicast DAD succeeds with the 6LBR does not mean that the 564 address is not duplicate, and, unless administratively overridden, 565 6BBRs must still perform classical IPv6 ND DAD after an EDAC with a 566 status code of 0. 568 For slow movements, the Neighbor Unreachability Detection (NUD) 569 procedure defined in [RFC4861] may time out too quickly, and the 570 support of [RFC7048] is recommended for all nodes in the subnet. 572 3.6. Routing Proxy Operations 574 When operating as a Routing Proxy, the 6BBR MUST use the Layer-2 575 Address on its Backbone Interface in the TLLA and SLLA options, when 576 present, of the RS, NS and NA messages that it generates to advertise 577 the Registered Addresses. In that case, the MAC Addresses of the 578 6LNs do not need to be visible at Layer-2 over the Backbone to 579 maintain end-to-end IP connectivity, but the NCEs of the 580 correspondents must be updated when the owner registers to a 581 different 6BBR. 583 This technique is useful when the churn on the Backbone fabric 584 associated to wireless mobility becomes expensive, e.g., when the 585 Layer-2 topology is virtualized over a wide area IP underlay. In 586 order to maintain IP connectivity, the 6BBR installs a connected host 587 route to the Registered Address on the LLN interface, via the 588 Registering Node as identified by the Source Address and the SLLA 589 option in the NS(EARO) messages. 591 This technique is also useful when the LLN uses a MAC address format 592 that is different from that on the Backbone (e.g., EUI-64 vs. EUI- 593 48). 595 For each Registered Address, multiple peer Nodes on the Backbone may 596 have resolved the Address with the 6BBR MAC Address, maintaining that 597 mapping in their Neighbor cache. The 6BBR SHOULD maintain a list of 598 the peers on the Backbone which have associated its MAC Address with 599 the Registered Address. If that Registered Address moves from an old 600 to a new 6BBR, the old 6BBR SHOULD unicast a gratuitous NA with the 601 Override (O) bit set to each such peer, to supply the LLA of the new 602 6BBR in the TLLA option for the Address. 604 If the 6BBR fails to maintain this list, then it MAY send the 605 gratuitous NA with the Override (O) bit set as a multicast message 606 that will possibly hit all the nodes on the Backbone, whether they 607 maintain an NCE or not for the Registered Address. 609 If a correspondent fails to receive the gratuitous NA, it will keep 610 sending traffic to a 6BBR to which the node was previously 611 registered. That old 6BBR having removed its host route to the 612 Registered Address, it will look it up over the backbone, resolve the 613 with the LLA of the new 6BBR, and forward the packet to the correct 614 6BBR. The old 6BBR SHOULD also issue a redirect message [RFC4861] is 615 order to update the cache of the correspondent. 617 3.7. Bridging Proxy Operations 619 A Bridging Proxy can be implemented in a Layer-3 switch, or in a 620 wireless Access Point or wireless Controller that acts as a Layer-2 621 Bridge for unicast packets from/to the Registered Address. The 622 Bridging Proxy appears as an IPv6 Host on the Backbone whereas the 623 Routing Proxy described in Section 3.6 is an IPv6 router operating as 624 a border router between Links of a MultiLink Subnet. 626 When operating as a Bridging Proxy, the 6BBR MUST use the Registering 627 Node's Layer-2 Address in the TLLA and SLLA options, when present, 628 of, respectively, the RS, NS and NA messages that it generates to 629 advertise the Registered Addresses. The Registering Node's Layer-2 630 address is found in the SLLA of the registration NS(EARO), and 631 maintained in the abstract Binding Table. 633 If the Registering Node is the owner of the Registered Address, then 634 its mobility does not impact existing NCEs over the Backbone. If it 635 is not, then when the 6LN selects another Registering Node, the new 636 Registering Node SHOULD send a multicast NA with the Override (O) bit 637 set to fix the existing NCEs across the Backbone. This method may 638 fail if the multicast message is not received, in which case one or 639 more correspondent nodes on the Backbone may maintain an obsolete NCE 640 and traffic to the Registered Address may be lost for a while. When 641 this condition happens, it is eventually be discovered and solved 642 through the Neighbor Unreachability Detection (NUD) procedure defined 643 in [RFC4861]. 645 3.8. Leveraging Optimistic DAD 647 The Optimistic Duplicate Address Detection [RFC4429] (ODAD) 648 specification details how an IPv6 Address can be used before a 649 Duplicate Address Detection (DAD) is complete. 651 ODAD provides a set of rules that guarantee that this behavior may 652 not harm an existing state should the new Address effectively be a 653 duplicate. This specification leverages ODAD to avoid delays in 654 installing the Neighbor Cache Entry (NCE) in the 6BBRs and the 655 default router in order to obtain immediate connectivity to the 656 registered node. 658 This specification RECOMMENDS to support ODAD to create an optimistic 659 proxy state in the 6BBR until DAD is completed over the Backbone. As 660 shown in Figure 2, if the 6BBR is aware of the Link-Layer Address 661 (LLA) of a router, then the 6BBR sends a Router Sollicitation (RS), 662 sourced with the Registered Address, to the known router(s). The RS 663 MUST be sent without a Source LLA Option (SLLAO), to ensure that a 664 preexisting NCE in the router is not affected. 666 Following the ODAD flows, the router may then send a unicast RA to 667 the Registered Address, and in the process of doing so, it may 668 resolve it using an NS(LOOKUP) message. In response, the 6BBR sends 669 a NA with the override (O) bit that is not set (per [RFC4429]), and 670 an EARO option. If the router supports this specification, then it 671 can determine the freshest EARO option in case of a conflicting 672 NA(EARO) messages, using section 5.2.1 of [RFC8505]. If the NA(EARO) 673 is the freshest or only answer then the default router creates a BCE 674 with the SLLAO of the 6BBR (in Routing Proxy mode) or that of the 675 Registering Node (in Bridging Proxy mode) and traffic from/to the 676 Registered Address can flow immediately. 678 4. Updating RFC 4861 680 This specification adds the EARO as a possible option in RS, NS(DAD) 681 and NA messages over the backbone. Note that [RFC8505] requires that 682 the registration NS(EARO) contains an SLLAO. Note that an NS(DAD) 683 does not contain an SLLAO and thus cannot be confused with a 684 registration. 686 5. Updating RFC 8505 688 This specification adds the capability to insert IPv6 ND options in 689 the EDAR and EDAC messages. In particular, a 6BBR acting as a 6LR 690 for the Registered Address can insert an SLLAO in the EDAR to the 691 6LBR in order to avoid a lookup back. 693 6. 6BBR detailed Operations 695 By default, a 6BBR operates as a Sleeping Proxy, as follows: 697 o Create a new entry in a Binding Table for a new Registered Address 698 and ensure that the Address is not a duplicate over the Backbone 700 o Defend a Registered Address over the Backbone using NA messages 701 with the Override bit set on behalf of the sleeping 6LN 703 o Advertise a Registered Address over the Backbone using NA 704 messages, asynchronously or as a response to a Neighbor 705 Solicitation messages. 707 o To deliver packets arriving from the LLN, use Neighbor 708 Solicitation messages to look up the destination over the 709 Backbone. 711 o Forward packets between the LLN and the Backbone. 713 o Verify liveliness when needed for a stale registration. 715 A 6BBR may act as a Sleeping Proxy only for a Registered Address that 716 is REACHABLE, or TENTATIVE in which case the answer is delayed. In 717 any other state, the Sleeping Proxy operates as a Unicasting Proxy. 719 The 6BBR does not act on ND Messages over the Backbone unless they 720 are relevant to a Registered Node on the LLN side, saving wireless 721 interference. On the LLN side, the prefixes associated to the 722 MultiLink Subnet are presented as not on-link, so Address resolution 723 for other hosts do not occur. 725 As a Unicasting Proxy, the 6BBR forwards NS lookup messages to the 726 Registering Node, transforming Layer-2 multicast into unicast. This 727 is not possible in UNREACHABLE state, so the NS messages are 728 multicasted, and rate-limited. Retries are possible, using an 729 exponential back-off to protect the medium. In other states, the 730 messages are forwarded to the Registering Node as unicast Layer-2 731 messages. In TENTATIVE state, the NS message is either held till DAD 732 completes, or dropped if DAD does not complete. 734 6.1. Primary and Secondary 6BBRs 736 A 6BBR MAY be primary or secondary. The primary is the Backbone 737 router that has the highest EUI-64 Address of all the 6BBRs that 738 share a registration for a same Registered Address, with the same 739 ROVR and same Transaction ID, the EUI-64 Address being considered as 740 an unsigned 64bit integer. A given 6BBR can be primary for a given 741 Address and secondary for another Address, regardless of whether or 742 not the Addresses belong to the same 6LN. The primary Backbone 743 Router is in charge of protecting the Address for DAD over the 744 Backbone. Any of the Primary and Secondary 6BBR may claim the 745 Address over the Backbone, since they are all capable to route from 746 the Backbone to the 6LN; the Address appears on the Backbone as an 747 anycast Address. 749 6.2. Binding Table 751 Each 6BBR maintains a Binding Table, using IPv6 ND over the Backbone 752 to detect duplication. Another document [RFC8505] provides details 753 about how the EARO is used between 6LRs and 6LBRs by way of DAR/DAC 754 messages within the LLN. Addresses in a LLN that can be reachable 755 from the Backbone by way of a 6BBR MUST be registered to that 6BBR. 757 A false positive duplicate detection may arise over the Backbone, for 758 instance if a 6LN's Registered Address is registered to more than one 759 LBR, or if the 6LN has moved. Both situations are handled by the 760 6BBR transparently to the 6LN. In the former case, one LBR becomes 761 primary to defend the Address over the Backbone while the others 762 become secondary and may still forward packets. In the latter case 763 the LBR that receives the newest registration becomes primary because 764 of the TID. 766 Only one 6LN may register a given Address at a particular 6BBR. 767 However, that Registered Address may be registered to Multiple 6BBRs 768 for higher availability. 770 Over the LLN, Binding Table management is as follows: 772 De-registrations (newer TID, same ROVR, null Lifetime) are 773 accepted and acknowledged with a status of 4 (TBD); the entry is 774 deleted; 776 Newer registrations (newer TID, same ROVR, non-null Lifetime) are 777 acknowledged with a status of 0 (success); the binding is updated 778 with the new TID, the Registration Lifetime and the Registering 779 Node; in TENTATIVE state the acknowledgement is held and may be 780 overwritten; in other states the Registration-Lifetime timer is 781 restarted and the entry is placed in REACHABLE state. 783 Identical registrations (same TID, same ROVR) from a same 784 Registering Node are acknowledged with a status of 0 (success). 785 If they are not identical, an error SHOULD be logged. In 786 TENTATIVE state, the response is held and may be overwritten, but 787 it MUST be eventually produced and it carries the result of the 788 DAD process; 790 Older registrations (older TID, same ROVR) from a Registering Node 791 are ignored; 793 Identical and older registrations (not-newer TID, same ROVR) from 794 a different Registering Node are acknowledged with a status of 3 795 (moved); this may be rate limited to protect the medium; 797 Any registration for a different Registered Node (different ROVR) 798 are acknowledged with a status of 1 (duplicate). 800 6.3. Registration and Binding Table Entry Creation 802 Upon receiving a registration for a new Address with an NS(EARO) with 803 the 'R' bit set, the 6BBR performs DAD over the Backbone, placing the 804 new Address as target in the NS(DAD) message. The EARO from the 805 registration MUST be placed unchanged in the NS(DAD) message, and an 806 Neighbor Cache entry created in TENTATIVE state for a duration of 807 TENTATIVE_DURATION. The NS(DAD) message is sent multicast over the 808 Backbone to the SNMA associated with the registered Address, unless 809 that operation is known to be costly, and the 6BBR has an indication 810 from another source (such as a Neighbor Cache entry) that the 811 Registered Address was known on the Backbone; in the latter case, an 812 NS(DAD) message may be sent as a Layer-2 unicast to the MAC Address 813 that was associated with the Registered Address. 815 In TENTATIVE state after EARO with 'R' bit set: 817 1. The entry is removed if an NA is received over the Backbone for 818 the Registered Address with no EARO, or containing an EARO with a 819 status of 1 (duplicate) that indicates an existing registration 820 for another 6LN. The ROVR and TID fields in the EARO received 821 over the Backbone are ignored. A status of 1 is returned in the 822 EARO of the NA back to the Registering Node; 824 2. The entry is also removed if an NA with an ARO option with a 825 status of 3 (moved), or a NS with an ARO option that indicates a 826 newer registration for the same Registered Node, is received over 827 the Backbone for the Registered Address. A status of 3 is 828 returned in the NA(EARO) back to the Registering Node; 830 3. When a registration is updated but not deleted, e.g. from a newer 831 registration, the DAD process on the Backbone continues and the 832 running timers are not restarted; 834 4. Other NS (including DAD with no EARO) and NA from the Backbone 835 are not acknowledged in TENTATIVE state. To cover legacy 6LNs 836 that do not support ODAD, the list of their origins MAY be stored 837 and then, if the TENTATIVE_DURATION timer elapses, the 6BBR MAY 838 send each such legacy 6LN a unicast NA. 840 5. When the TENTATIVE_DURATION timer elapses, a status 0 (success) 841 is returned in a NA(EARO) back to the Registering Node(s), and 842 the entry goes to REACHABLE state for the Registration Lifetime. 843 The 6BBR MUST send a multicast NA(EARO) to the SNMA associated to 844 the Registered Address over the Backbone with the Override bit 845 set so as to take over the binding from other 6BBRs. 847 6.4. Defending Addresses 849 If a 6BBR has an entry in REACHABLE state for a Registered Address: 851 o If the 6BBR is primary, or does not support the function of 852 primary, it MUST defend that Address over the Backbone upon 853 receiving NS, either if the NS does not carry an EARO, or if an 854 EARO is present that indicates a different Registering Node 855 (different ROVR). The 6BBR sends a NA message with the Override 856 bit set and the NA carries an EARO if and only if the NS(DAD) did 857 so. When present, the EARO in the NA(Override) that is sent in 858 response to the NS(EARO) carries a status of 1 (duplicate), and 859 the ROVR and TID fields in the EARO are obfuscated with null or 860 random values to avoid network scanning and impersonation attacks. 862 o If the 6BBR receives an NS(EARO) for a newer registration, the 863 6BBR updates the entry and the routing state to forward packets to 864 the new 6BBR, but keeps the entry REACHABLE. Afterwards, the 6BBR 865 MAY use REDIRECT messages to reroute traffic for the Registered 866 Address to the new 6BBR. 868 o If the 6BBR receives an NA(EARO) for a newer registration, the 869 6BBR removes its entry and sends a NA(EARO) with a status of 3 870 (MOVED) to the Registering Node, if the Registering Node is 871 different from the Registered Node. The 6BBR cleans up existing 872 Neighbor Cache entries in peer nodes as discussed in Section 3.5, 873 by unicasting to each such peer, or one broadcast NA(Override). 875 o If the 6BBR receives a NS(LOOKUP) for a Registered Address, it 876 answers immediately with an NA on behalf of the Registered Node, 877 without polling it. There is no need of an EARO in that exchange. 879 o When the Registration-Lifetime timer elapses, the entry goes to 880 STALE state for a duration of STABLE_STALE_DURATION in LLNs that 881 keep stable Addresses such as LWPANs, and UNSTABLE_STALE_DURATION 882 in LLNs where Addresses are renewed rapidly, e.g. for privacy 883 reasons. 885 The STALE state enables tracking of the Backbone peers that have a 886 Neighbor Cache entry pointing to this 6BBR in case the Registered 887 Address shows up later. If the Registered Address is claimed by 888 another 6LN on the Backbone, with an NS(DAD) or an NA, the 6BBR does 889 not defend the Address. In STALE state: 891 o If STALE_DURATION elapses, the 6BBR removes the entry. 893 o Upon receiving an NA(Override) the 6BBR removes its entry and 894 sends a NA(EARO) with a status of 4 (removed) to the Registering 895 Node. 897 o If the 6BBR receives a NS(LOOKUP) for a Registered Address, the 898 6BBR MUST send an NS(NUD) following rules in [RFC7048] to the 899 Registering Node targeting the Registered Address prior to 900 answering. If the NUD succeeds, the operation in REACHABLE state 901 applies. If the NUD fails, the 6BBR refrains from answering the 902 lookup. The NUD SHOULD be used by the Registering Node to 903 indicate liveness of the Registered Node, if they are different 904 nodes. 906 7. Security Considerations 908 This specification applies to LLNS in which the link layer is 909 protected, either by means of physical or IP security for the 910 Backbone Link or MAC sublayer cryptography. In particular, the LLN 911 MAC is required to provide secure unicast to/from the Backbone Router 912 and secure Broadcast from the Backbone Router in a way that prevents 913 tampering with or replaying the RA messages. 915 The use of EUI-64 for forming the Interface ID in the link local 916 Address prevents the usage of Secure ND ([RFC3971] and [RFC3972]) and 917 Address privacy techniques. Additional protection against Address 918 theft is provided by [I-D.ietf-6lo-ap-nd], which guarantees the 919 ownership of the ROVR. 921 When the ownership of the ROVR cannot be assessed, this specification 922 limits the cases where the ROVR and the TID are multicasted, and 923 obfuscates them in responses to attempts to take over an Address. 925 8. Protocol Constants 927 This Specification uses the following constants: 929 TENTATIVE_DURATION: 800 milliseconds 931 STABLE_STALE_DURATION: 24 hours 933 UNSTABLE_STALE_DURATION: 5 minutes 935 DEFAULT_NS_POLLING: 3 times 937 9. IANA Considerations 939 This document has no request to IANA. 941 10. Future Work 943 Future documents may extend this specification by allowing the 6BBR 944 to redistribute host routes in routing protocols that would operate 945 over the Backbone, or in MIPv6, or FMIP, or the Locator/ID Separation 946 Protocol (LISP) [RFC6830] to support mobility on behalf of the 6LNs, 947 etc... 949 11. Acknowledgments 951 Many thanks to Dorothy Stanley, Thomas Watteyne and Jerome Henry for 952 their various contributions. 954 12. References 956 12.1. Normative References 958 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 959 Requirement Levels", BCP 14, RFC 2119, 960 DOI 10.17487/RFC2119, March 1997, 961 . 963 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 964 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 965 2006, . 967 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 968 for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, 969 . 971 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 972 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 973 DOI 10.17487/RFC4861, September 2007, 974 . 976 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 977 Address Autoconfiguration", RFC 4862, 978 DOI 10.17487/RFC4862, September 2007, 979 . 981 [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for 982 Detecting Network Attachment in IPv6", RFC 6059, 983 DOI 10.17487/RFC6059, November 2010, 984 . 986 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 987 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 988 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 989 Low-Power and Lossy Networks", RFC 6550, 990 DOI 10.17487/RFC6550, March 2012, 991 . 993 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 994 Bormann, "Neighbor Discovery Optimization for IPv6 over 995 Low-Power Wireless Personal Area Networks (6LoWPANs)", 996 RFC 6775, DOI 10.17487/RFC6775, November 2012, 997 . 999 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1000 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1001 May 2017, . 1003 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1004 (IPv6) Specification", STD 86, RFC 8200, 1005 DOI 10.17487/RFC8200, July 2017, 1006 . 1008 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 1009 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 1010 DOI 10.17487/RFC8201, July 2017, 1011 . 1013 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 1014 Perkins, "Registration Extensions for IPv6 over Low-Power 1015 Wireless Personal Area Network (6LoWPAN) Neighbor 1016 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 1017 . 1019 12.2. Informative References 1021 [I-D.bi-savi-wlan] 1022 Bi, J., Wu, J., Wang, Y., and T. Lin, "A SAVI Solution for 1023 WLAN", draft-bi-savi-wlan-16 (work in progress), November 1024 2018. 1026 [I-D.ietf-6lo-ap-nd] 1027 Thubert, P., Sarikaya, B., Sethi, M., and R. Struik, 1028 "Address Protected Neighbor Discovery for Low-power and 1029 Lossy Networks", draft-ietf-6lo-ap-nd-08 (work in 1030 progress), October 2018. 1032 [I-D.ietf-6man-rs-refresh] 1033 Nordmark, E., Yourtchenko, A., and S. Krishnan, "IPv6 1034 Neighbor Discovery Optional RS/RA Refresh", draft-ietf- 1035 6man-rs-refresh-02 (work in progress), October 2016. 1037 [I-D.ietf-6tisch-architecture] 1038 Thubert, P., "An Architecture for IPv6 over the TSCH mode 1039 of IEEE 802.15.4", draft-ietf-6tisch-architecture-17 (work 1040 in progress), November 2018. 1042 [I-D.ietf-mboned-ieee802-mcast-problems] 1043 Perkins, C., McBride, M., Stanley, D., Kumari, W., and J. 1044 Zuniga, "Multicast Considerations over IEEE 802 Wireless 1045 Media", draft-ietf-mboned-ieee802-mcast-problems-04 (work 1046 in progress), November 2018. 1048 [I-D.nordmark-6man-dad-approaches] 1049 Nordmark, E., "Possible approaches to make DAD more robust 1050 and/or efficient", draft-nordmark-6man-dad-approaches-02 1051 (work in progress), October 2015. 1053 [I-D.yourtchenko-6man-dad-issues] 1054 Yourtchenko, A. and E. Nordmark, "A survey of issues 1055 related to IPv6 Duplicate Address Detection", draft- 1056 yourtchenko-6man-dad-issues-01 (work in progress), March 1057 2015. 1059 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 1060 "SEcure Neighbor Discovery (SEND)", RFC 3971, 1061 DOI 10.17487/RFC3971, March 2005, 1062 . 1064 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1065 RFC 3972, DOI 10.17487/RFC3972, March 2005, 1066 . 1068 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 1069 Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 1070 2006, . 1072 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 1073 DOI 10.17487/RFC4903, June 2007, 1074 . 1076 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 1077 over Low-Power Wireless Personal Area Networks (6LoWPANs): 1078 Overview, Assumptions, Problem Statement, and Goals", 1079 RFC 4919, DOI 10.17487/RFC4919, August 2007, 1080 . 1082 [RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, 1083 Ed., "Control And Provisioning of Wireless Access Points 1084 (CAPWAP) Protocol Specification", RFC 5415, 1085 DOI 10.17487/RFC5415, March 2009, 1086 . 1088 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 1089 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 1090 2011, . 1092 [RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem 1093 Statement and Requirements for IPv6 over Low-Power 1094 Wireless Personal Area Network (6LoWPAN) Routing", 1095 RFC 6606, DOI 10.17487/RFC6606, May 2012, 1096 . 1098 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 1099 Locator/ID Separation Protocol (LISP)", RFC 6830, 1100 DOI 10.17487/RFC6830, January 2013, 1101 . 1103 [RFC7048] Nordmark, E. and I. Gashinsky, "Neighbor Unreachability 1104 Detection Is Too Impatient", RFC 7048, 1105 DOI 10.17487/RFC7048, January 2014, 1106 . 1108 [RFC7559] Krishnan, S., Anipko, D., and D. Thaler, "Packet-Loss 1109 Resiliency for Router Solicitations", RFC 7559, 1110 DOI 10.17487/RFC7559, May 2015, 1111 . 1113 [RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy 1114 Consumption of Router Advertisements", BCP 202, RFC 7772, 1115 DOI 10.17487/RFC7772, February 2016, 1116 . 1118 [RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix 1119 per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017, 1120 . 1122 12.3. External Informative References 1124 [IEEEstd8021] 1125 IEEE standard for Information Technology, "IEEE Standard 1126 for Information technology -- Telecommunications and 1127 information exchange between systems Local and 1128 metropolitan area networks Part 1: Bridging and 1129 Architecture". 1131 [IEEEstd80211] 1132 IEEE standard for Information Technology, "IEEE Standard 1133 for Information technology -- Telecommunications and 1134 information exchange between systems Local and 1135 metropolitan area networks-- Specific requirements Part 1136 11: Wireless LAN Medium Access Control (MAC) and Physical 1137 Layer (PHY) Specifications". 1139 [IEEEstd802151] 1140 IEEE standard for Information Technology, "IEEE Standard 1141 for Information Technology - Telecommunications and 1142 Information Exchange Between Systems - Local and 1143 Metropolitan Area Networks - Specific Requirements. - Part 1144 15.1: Wireless Medium Access Control (MAC) and Physical 1145 Layer (PHY) Specifications for Wireless Personal Area 1146 Networks (WPANs)". 1148 [IEEEstd802154] 1149 IEEE standard for Information Technology, "IEEE Standard 1150 for Local and metropolitan area networks -- Part 15.4: 1151 Low-Rate Wireless Personal Area Networks (LR-WPANs)". 1153 Appendix A. Applicability and Requirements Served 1155 This document specifies proxy-ND functions that can be used to 1156 federate an IPv6 Backbone Link and multiple IPv6 LLNs into a single 1157 MultiLink Subnet. The proxy-ND functions enable IPv6 ND services for 1158 Duplicate Address Detection (DAD) and Address lookup that do not 1159 require broadcasts over the LLNs. 1161 The term LLN is used loosely to cover multiple types of WLANs and 1162 WPANs, including (Low-Power) Wi-Fi, BLUETOOTH(R) Low Energy, IEEE 1163 STD. 802.11ah and IEEE STD. 802.15.4 wireless meshes, so as to 1164 address the requirements listed in Appendix B.3 of [RFC8505] 1165 "Requirements Related to Various Low-Power Link Types". 1167 Each LLN in the subnet is anchored at an IPv6 Backbone Router (6BBR). 1168 The Backbone Routers interconnect the LLNs and advertise the 1169 Addresses of the 6LNs over the Backbone Link using proxy-ND 1170 operations. 1172 This specification updates IPv6 ND over the Backbone to distinguish 1173 Address movement from duplication and eliminate stale state in the 1174 Backbone routers and Backbone nodes once a 6LN has roamed. In this 1175 way, mobile nodes may roam rapidly from one 6BBR to the next and 1176 requirements in Appendix B.1 of [RFC8505] "Requirements Related to 1177 Mobility" are met. 1179 Any 6LN may register its IPv6 Addresses and thereby obtain proxy-ND 1180 services over the Backbone, providing a solution to the requirements 1181 expressed in Appendix B.4 of [RFC8505] "Requirements Related to Proxy 1182 Operations". 1184 The IPv6 ND operation is minimized as the number of 6LNs grows in the 1185 LLN. This meets the requirements in Appendix B.6 of [RFC8505] 1186 "Requirements Related to Scalability", as long has the 6BBRs are 1187 dimensioned for the number of registrations that each needs to 1188 support. 1190 In the case of a (Low-Power) Wi-Fi access link, a 6BBR may be 1191 collocated with the Access Point (AP), or with a Fabric Edge (FE) or 1192 a CAPWAP [RFC5415] Wireless LAN Controller (WLC). In that case, the 1193 wireless client (STA) is the 6LN [RFC8505] that makes use of this 1194 specification to register its IPv6 Address(es) to the 6BBR acting as 1195 Routing Registrar. The 6LBR can be centralized and either connected 1196 to the Backbone Link or reachable over IP. The 6BBR proxy-ND 1197 operations eliminate the need for wireless nodes to respond 1198 synchronously when a lookup is performed for their IPv6 Addresses. 1199 This provides the function of a Sleep Proxy for ND 1200 [I-D.nordmark-6man-dad-approaches]. 1202 For the TimeSlotted Channel Hopping (TSCH) mode of [IEEEstd802154], 1203 the 6TiSCH architecture [I-D.ietf-6tisch-architecture] describes how 1204 a 6LoWPAN ND host could connect to the Internet via a RPL mesh 1205 Network, but doing so requires extensions to the 6LOWPAN ND protocol 1206 to support mobility and reachability in a secure and manageable 1207 environment. The extensions detailed in this document also work for 1208 the 6TiSCH architecture, serving the requirements listed in 1209 Appendix B.2 of [RFC8505] "Requirements Related to Routing 1210 Protocols". 1212 The registration mechanism may be seen as a more reliable alternate 1213 to snooping [I-D.bi-savi-wlan]. It can be noted that registration 1214 and snooping are not mutually exclusive. Snooping may be used in 1215 conjunction with the registration for nodes that do not register 1216 their IPv6 Addresses. The 6BBR assumes that if a node registers at 1217 least one IPv6 Address to it, then the node registers all of its 1218 Addresses to the 6BBR. With this assumption, the 6BBR can possibly 1219 cancel all undesirable multicast NS messages that would otherwise 1220 have been delivered to that node. 1222 The scalability of the MultiLink Subnet [RFC4903] requires that 1223 multicast/broadcast operations are avoided as much as possible even 1224 on the Backbone [I-D.ietf-mboned-ieee802-mcast-problems]. Although 1225 hosts can connect to the Backbone using classical IPv6 ND operations, 1226 multicast RAs can be saved by using [I-D.ietf-6man-rs-refresh], which 1227 also requires the support of [RFC7559]. 1229 Authors' Addresses 1230 Pascal Thubert (editor) 1231 Cisco Systems, Inc 1232 Building D 1233 45 Allee des Ormes - BP1200 1234 MOUGINS - Sophia Antipolis 06254 1235 FRANCE 1237 Phone: +33 497 23 26 34 1238 Email: pthubert@cisco.com 1240 Charles E. Perkins 1241 Futurewei 1242 2330 Central Expressway 1243 Santa Clara 95050 1244 United States of America 1246 Email: charliep@computer.org 1248 Eric Levy-Abegnoli 1249 Cisco Systems, Inc 1250 Building D 1251 45 Allee des Ormes - BP1200 1252 MOUGINS - Sophia Antipolis 06254 1253 FRANCE 1255 Phone: +33 497 23 26 20 1256 Email: elevyabe@cisco.com