idnits 2.17.1 draft-ietf-6lo-backbone-router-08.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 22, 2018) is 2013 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 894, but not defined == Missing Reference: 'IEEEstd80211' is mentioned on line 901, but not defined == Missing Reference: 'IEEEstd802154' is mentioned on line 918, but not defined == Missing Reference: 'IEEEstd802151' is mentioned on line 909, but not defined == 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-15 == Outdated reference: A later version (-15) exists of draft-ietf-mboned-ieee802-mcast-problems-02 -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6lo P. Thubert, Ed. 3 Internet-Draft cisco 4 Intended status: Standards Track C. Perkins 5 Expires: April 25, 2019 Futurewei 6 October 22, 2018 8 IPv6 Backbone Router 9 draft-ietf-6lo-backbone-router-08 11 Abstract 13 Backbone Routers running IPv6 Neighbor Discovery can manage multiple 14 wireless links to form a large MultiLink Subnet, but it is more 15 efficient if IPv6 Neighbor Discovery packets are not broadcast over 16 the wireless links. This specification specifies proxy operations 17 for IPv6 Neighbor Discovery on behalf of devices located on 18 broadcast-inefficient wireless networks. Backbone Routers placed 19 along the wireless edge of the backbone handle IPv6 Neighbor 20 Discovery, and route packets on behalf of registered nodes. Wireless 21 nodes register, or are registered by proxy, to a Backbone Router to 22 establish proxy services in a fashion similar to layer-2 association. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 25, 2019. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Applicability and Requirements Served . . . . . . . . . . . . 4 60 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 5. Backbone Router Routing Operations . . . . . . . . . . . . . 8 63 5.1. Over the Backbone Link . . . . . . . . . . . . . . . . . 8 64 5.2. Proxy Operations Over the LLN Interface . . . . . . . . . 9 65 5.2.1. Routing Proxy Operations . . . . . . . . . . . . . . 10 66 5.2.2. Bridging Proxy Operations . . . . . . . . . . . . . . 10 67 6. Backbone Router Proxy Operations . . . . . . . . . . . . . . 11 68 6.1. Primary and Secondary BBRs . . . . . . . . . . . . . . . 12 69 6.2. Binding Table . . . . . . . . . . . . . . . . . . . . . . 12 70 6.3. Registration and Binding Table Entry Creation . . . . . . 13 71 6.4. Defending Addresses . . . . . . . . . . . . . . . . . . . 14 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 73 8. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 16 74 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 75 10. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 16 76 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 77 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 12.1. Normative References . . . . . . . . . . . . . . . . . . 16 79 12.2. Informative References . . . . . . . . . . . . . . . . . 17 80 12.3. External Informative References . . . . . . . . . . . . 19 81 Appendix A. Changes from revision 07 to revision 08 . . . . . . 20 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 84 1. Introduction 86 IEEE STD. 802.1 [IEEEstd8021] Ethernet Bridging provides an efficient 87 and reliable broadcast service; applications and protocols have been 88 built that heavily depend on that feature for their core operation. 89 Unfortunately, many wireless networks do not economically provide the 90 broadcast capabilities of Ethernet Bridging; protocols designed for 91 bridged networks that rely on broadcast often exhibit disappointing 92 behaviours when applied unmodified to a wireless medium (see 93 [I-D.ietf-mboned-ieee802-mcast-problems]). 95 WiFi [IEEEstd80211] Access Points (APs) deployed in an Extended 96 Service Set (ESS) act as bridges. In order to ensure a solid 97 connectivity to the devices and protect the medium against harmful 98 broadcasts, they refrain from relying on broadcast-intensive 99 protocols such as Transparent Bridging on the wireless side. 100 Instead, an association process is used to register the MAC addresses 101 of the wireless device (STA) to the AP. The APs subsequently proxy 102 the bridging operation and eliminate the broadcasts. 104 The IPv6 [RFC8200] Neighbor Discovery [RFC4861] [RFC4862] Protocol 105 (IPv6 ND) operations are reactive and rely heavily on multicast 106 transmissions to locate an on-link correspondent and ensure address 107 uniqueness. Duplicate Address Detection [RFC4862] (DAD) mechanism 108 was designed as a natural match with the efficient broadcast 109 operation of Ethernet Bridging. However, since broadcast can be 110 unreliable over wireless media, DAD often fails to discover 111 duplications [I-D.yourtchenko-6man-dad-issues]. DAD usually appears 112 to work on wireless media, not because address duplication is 113 detected and solved as designed, but because the use of 64-bit 114 Interface IDs makes duplication into a very rare event. 116 IPv6 multicast messages are typically broadcast over the wireless 117 medium. They are processed by most if not all wireless nodes over 118 the ESS fabric even when very few if any of them are subscribed to 119 the multicast address. A simple Neighbor Solicitation (NS) 120 [RFC4861], that is supposedly targeted to a small group of nodes, can 121 congest the wireless bandwidth 122 [I-D.ietf-mboned-ieee802-mcast-problems]. The IPv6 ND operation 123 leads to undesirable power consumption in battery-operated devices. 125 These problems suggest restricting IPv6 ND broadcasts over wireless 126 access links, which can be done by dividing up the subnet. Another 127 way is to take over (proxy) the Layer-3 protocols that rely on 128 broadcast operation at the boundary of the wired and wireless 129 domains, emulating the Layer-2 association at layer-3. For instance, 130 IEEE 802.11 [IEEEstd80211] specifies ARP and ND proxy [RFC4389] 131 services at the Access Points (APs). 133 Current devices rely on snooping for detecting association state, 134 which is failure-prone in lossy and mobile conditions. With 135 snooping, a state (e.g. a new IPv6 address) may not be discovered, or 136 a change of state (e.g. a movement) may be missed, leading to 137 unreliable connectivity. 139 WPAN devices (i.e., those implementing IEEE STD. 802.15.4 140 [IEEEstd802154]) can make use of Neighbor Discovery Optimization for 141 IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) 142 [RFC6775] which treats the wireless medium as different from 143 Ethernet. RFC 6775 is updated as [I-D.ietf-6lo-rfc6775-update]; the 144 update includes changes that are required by this document. 146 2. Applicability and Requirements Served 148 This specification updates and generalizes 6LoWPAN ND to a broader 149 range of Low power and Lossy Networks (LLNs) with support for 150 Duplicate Address Detection (DAD) and address lookup that does not 151 require broadcasts over the LLNs. The term LLN is used loosely in 152 this specification to cover multiple types of WLANs and WPANs, 153 including Low-Power Wi-Fi, BLUETOOTH(R) Low Energy, IEEE STD. 154 802.11AH and IEEE STD. 802.15.4 wireless meshes, so as to address the 155 requirements listed in Appendix B.3 of [I-D.ietf-6lo-rfc6775-update] 156 "Requirements Related to the Variety of Low-Power Link types". 158 For the TimeSlotted Channel Hopping (TSCH) mode of [IEEEstd802154], 159 the 6TiSCH architecture [I-D.ietf-6tisch-architecture] describes how 160 a 6LoWPAN ND host could connect to the Internet via a RPL mesh 161 Network, but doing so requires extensions to the 6LOWPAN ND protocol 162 to support mobility and reachability in a secure and manageable 163 environment. The extensions detailed in this document also work for 164 the 6TiSCH architecture, serving the requirements listed in 165 Appendix B.2 of [I-D.ietf-6lo-rfc6775-update] "Requirements Related 166 to Routing Protocols". 168 This specification also applies to wireless links such as Low-Power 169 IEEE STD. 802.11 (Wi-Fi) and IEEE STD. 802.15.1 (Bluetooth) 170 [IEEEstd802151]. It makes use of extensions to [RFC6775] to enable 171 proxy operation by the 6BBR, as specified in 172 [I-D.ietf-6lo-rfc6775-update]. The BBR proxy operations eliminate 173 the need for wireless nodes to respond synchronously when a lookup is 174 performed for their addresses. This provides the function of a Sleep 175 Proxy for ND [I-D.nordmark-6man-dad-approaches]. 177 This draft establishes a Backbone that treats multiple LLNs as a 178 single IPv6 MultiLink Subnet. Each LLN in the subnet is anchored at 179 an IPv6 Backbone Router (6BBR). The Backbone Routers interconnect 180 the LLNs and advertise the addresses of the 6LNs using proxy-ND 181 operations. This specification extends IPv6 ND over the backbone to 182 distinguish address movement from duplication and eliminate stale 183 state in the backbone routers and backbone nodes once a 6LN has 184 roamed. In this way, mobile nodes may roam rapidly from one 6BBR to 185 the next and requirements in Appendix B.1 of 186 [I-D.ietf-6lo-rfc6775-update] "Requirements Related to Mobility" are 187 met. 189 This specification enables any 6LN to register its IPv6 addresses and 190 thereby obtain routing services including proxy-ND operations over 191 the backbone, providing a solution to the requirements expressed in 192 Appendix B.4 of [I-D.ietf-6lo-rfc6775-update] "Requirements Related 193 to Proxy Operations". 195 The Link Layer Address (LLA) that is returned as Target LLA (TLLA) in 196 Neighbor Advertisements (NA) messages by the 6BBR on behalf of the 197 Registered Node over the backbone may be that of the Registering 198 Node. In that case, the 6BBR needs to bridge the unicast packets 199 (Bridging proxy), or that of the 6BBR on the backbone, in which case 200 the 6BBRs needs to route the unicast packets (Routing proxy). The 201 IPv6 ND operation is minimized as the number of 6LNs grows in the 202 LLN. This meets the requirements in Appendix B.6 of 203 [I-D.ietf-6lo-rfc6775-update] "Requirements Related to Scalability", 204 as long has the 6BBRs are dimensioned for the number of registrations 205 that each needs to support. 207 In the case of Low-Power IEEE STD. 802.11, a 6BBR may be collocated 208 with a standalone AP or a CAPWAP [RFC5415] wireless controller. Then 209 the wireless client (STA) makes use of this specification to register 210 its IPv6 address(es) to the 6BBR over the wireless medium. In the 211 case RPL, the RPL root is collocated with a 6LoWPAN Border Router 212 (6LBR), and either collocated with or connected to the 6BBR over an 213 IPv6 Link. The 6LBR makes use of this specification to register the 214 6LNs on their behalf to the 6BBR. 216 3. Terminology 218 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 219 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 220 "OPTIONAL" in this document are to be interpreted as described in BCP 221 14 [RFC2119] . 223 In this document, readers will encounter terms and concepts that are 224 discussed in the following documents: 226 o "Neighbor Discovery for IP version 6" [RFC4861], 228 o "IPv6 Stateless Address Autoconfiguration" [RFC4862], 230 o "Multi-Link Subnet Issues" [RFC4903], 232 o "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): 233 Overview, Assumptions, Problem Statement, and Goals" [RFC4919], 235 o Neighbor Discovery Optimization for Low-power and Lossy Networks 236 [RFC6775], 238 o ,"Mobility Support in IPv6" [RFC6275], 240 o "Neighbor Discovery Proxies (ND Proxy)" [RFC4389] 242 o "Optimistic Duplicate Address Detection" [RFC4429], and 243 o "Registration Extensions for 6LoWPAN Neighbor Discovery" 244 [I-D.ietf-6lo-rfc6775-update] 246 This document also uses terminology from [RFC7102] and 247 [I-D.ietf-6lo-rfc6775-update], and introduces the following 248 terminology: 250 Sleeping Proxy 252 A 6BBR acts as a Sleeping Proxy if it answers ND Neighbor 253 Solicitation over the backbone on behalf of the Registered 254 Node. 256 Unicasting Proxy 258 A Unicasting Proxy forwards NS messages to the Registering 259 Node, transforming Layer-2 multicast into unicast. 261 Routing proxy 263 A routing proxy advertises its own MAC address as the TLLA in 264 the proxied NAs over the backbone, as opposed to that of the 265 node that performs the registration. 267 Bridging proxy 269 A Bridging proxy advertises the MAC address of the node that 270 performs the registration as the TLLA in the proxied NAs over 271 the backbone. In that case, the MAC address and the mobility 272 of 6LN is still visible across the bridged backbone fabric. 274 Primary BBR 276 The BBR that will defend a Registered Address for the purpose 277 of DAD over the backbone. 279 Secondary BBR 281 A BBR other than the Primary BBR to which an address is 282 registered. A Secondary Router MAY advertise the address over 283 the backbone and proxy for it. 285 4. Overview 287 The services specified in this document assist a 6LN to move freely 288 from an LLN anchored at one 6BBR to an LLN anchored at another 6BBR 289 on the same backbone and keep any or all of the IPv6 addresses that 290 the 6LN has formed. 292 | 293 +-----+ 294 | | Gateway (default) Router 295 | | 296 +-----+ 297 | 298 | Backbone Link 299 +-------------------------+----------------------+ 300 | | | 301 +------+ +------+ +------+ 302 | 6BBR | | 6BBR | | 6BBR | 303 | | | | | | 304 +------+ +------+ +------+ 305 o o o o o o 306 o o o o o o o o o o o o o o 307 o o o o o o o o o o o o o o o 308 o o o o o o o o o o 309 o o o o o o o 311 LLN LLN LLN 313 Figure 1: Backbone Link and Backbone Routers 315 Each Backbone Router (6BBR) maintains a Binding Table of its 316 Registered Nodes. The Binding Tables form a distributed database of 317 wireless 6LNs that reside on the LLNs or on the backbone, and use an 318 extension to IPv6 ND to exchange that information across the Backbone 319 as described below. 321 The Extended Address Registration Option (EARO) defined in 322 [I-D.ietf-6lo-rfc6775-update] is used in the ND exchanges over the 323 backbone between the 6BBRs to enable the registration for routing and 324 proxy services, as well as distinguish duplication from movement. 326 Address duplication is detected using the ROVR field in the EARO. In 327 case of conflicting registrations to multiple 6BBRs from the same 328 node, the Transaction ID (TID) in the EARO enables 6BBRs to determine 329 the latest registration for that 6LN. 331 6BBRs perform ND proxy operations over the backbone, on behalf of 332 their Registered Nodes. Registration to a proxy service is done via 333 a NS/NA(EARO) exchange. 6BBR operation resembles that of a Mobile 334 IPv6 (MIPv6) [RFC6275] Home Agent. This enables mobility support for 335 6LNs; if they move outside of the network delimited by the Backbone 336 link, then they make use of a Home Agent. Home Agent functionality 337 can easily be collocated with a 6BBR on the same backbone interface 338 of a router. 340 The Optimistic Duplicate Address Detection [RFC4429] (ODAD) 341 specification details how an address can be used before a Duplicate 342 Address Detection (DAD) is complete, and mandates that an address 343 that is TENTATIVE should not be associated to a Source Link-Layer 344 Address Option in a Neighbor Solicitation message. This 345 specification makes use of ODAD to create a temporary proxy state in 346 the 6BBR until DAD is completed over the backbone. This way, the 347 specification allows proxy state distribution across multiple 6BBR 348 and co-existence with IPv6 ND over the backbone. 350 5. Backbone Router Routing Operations 352 | 353 +-----+ 354 | | Gateway (default) Router 355 | | 356 +-----+ 357 | /64 358 | Backbone Link 359 +-------------------+-------------------+ 360 | /64 | /64 | /64 361 +------+ +------+ +------+ 362 | 6BBR | | 6BBR | | 6BBR | 363 | | | | | | 364 +------+ +------+ +------+ 365 o o o o o o 366 o o o o o o o o o o o o o o 367 o o o o o o o o o o o o o o o 368 o o o o o o o o o o 369 o o o o o o o 371 LLN: N*/128 LLN: M*/128 LLN: P*/128 373 Figure 2: Example Routing Configuration for 3 LLNs in the ML Subnet 375 5.1. Over the Backbone Link 377 A 6BBR is a specific kind of Border Router that performs proxy 378 Neighbor Discovery on its backbone interface on behalf of registered 379 6LNs on its LLN interfaces. 381 On the backbone side, the 6BBR advertises the prefixes of the LLNs 382 for which it serves as a proxy. Some restrictions of the attached 383 LLNs will apply to the backbone. In particular, the MTU SHOULD be 384 set to the same value on the backbone and all attached LLNs. The 385 scalability of the multilink subnet [RFC4903] requires that broadcast 386 operations are avoided as much as possible on the backbone as well. 388 The 6BBR uses an EARO in the NS-DAD and the multicast NA messages 389 that it generates over the Backbone Link on behalf of a Registered 390 Node. The 6BBR places an EARO in its unicast NA messages, if and 391 only if the NS/NA that stimulates it had an EARO in it and the 'R' 392 bit set. 394 The 6BBR SHOULD use unicast or the solicited-node multicast address 395 (SNMA) [RFC4291] to defend its Registered Addresses in its Binding 396 Table over the backbone. In particular, the 6BBR MUST join the SNMA 397 group that corresponds to a Registered Address as soon as it creates 398 an entry for that address, and maintain its SNMA membership as long 399 as it maintains that entry. 401 Optimistic DAD (ODAD) [RFC4429] SHOULD be supported by the 6BBRs in 402 their proxy activity over the backbone. A 6BBR supporting ODAD MUST 403 join the SNMA of a Tentative address. 405 A 6BBR in Routing Proxy mode MAY advertise the Registered IPv6 406 Address with the 6BBR Link Layer Address, and update Neighbor Cache 407 Entries (NCE) in correspondent nodes over the backbone, using 408 gratuitous NA(Override). This method may fail if the multicast 409 message is not received, and correspondent nodes may maintain an 410 incorrect neighbor state, which they will eventually discover through 411 Neighbor Unreachability Detection (NUD). For slow movements, the NUD 412 procedure defined in [RFC4861] may time out too quickly, and the 413 support of [RFC7048] is recommended in all 6LNs in the network. 415 Multicast should be avoided as much as possible even on the backbone 416 [I-D.ietf-mboned-ieee802-mcast-problems]. Although hosts can 417 participate using legacy IPv6 ND, all 6LNs connected to the backbone 418 SHOULD support [I-D.ietf-6man-rs-refresh], which also requires the 419 support of [RFC7559]. 421 5.2. Proxy Operations Over the LLN Interface 423 6LNs on the LLN follow [RFC6775] and do not depend on multicast RAs 424 to discover routers. 6LNs SHOULD accept multicast RAs [RFC7772], but 425 those are expected to be rare within in the LLN. Nodes SHOULD follow 426 the Simple Procedures for Detecting Network Attachment in IPv6 427 [RFC6059] (DNA procedures) to assert movements, and support Packet- 428 Loss Resiliency for Router Solicitations [RFC7559] to make the 429 unicast RS more reliable. 431 A 6LN signals that it requires IPv6 ND proxy services from a 6BBR by 432 registering the corresponding IPv6 Address with an NS(EARO) message 433 with the 'R' flag set. The 6LN that performs the registration (the 434 Registering Node) may be the owner of the IPv6 Address (the 435 Registered Node) or a 6LBR that performs the registration on its 436 behalf. 438 5.2.1. Routing Proxy Operations 440 When operating as a Routing Proxy, the BBR installs host routes 441 (/128) to the Registered Addresses within the LLN, via the 442 Registering Node as identified by the Source Address and the SLLA 443 option in the NS(EARO) messages. In that case, the MAC address of 444 the 6LN is not visible at Layer-2 over the backbone. The 6BBR 445 installs a host route towards the Registered Node over the interface 446 toward the 6LN, and routes unicast packets to the 6LN. 448 The Routing Proxy 6BBR handles the ND protocol over the backbone on 449 behalf of the Registered Nodes, using its own MAC address in the TLLA 450 and SLLA options in proxied NS and NA messages. For each Registered 451 Address, multiple peer Nodes on the backbone may have resolved the 452 address with the 6BBR MAC address, maintaining that mapping in their 453 Neighbor cache. 455 For each Registered Address, the 6BBR SHOULD maintain a list of the 456 peers on the backbone which have associated its MAC address with the 457 Registered Address. If that Registered Address moves to a different 458 6BBR, the first 6BBR SHOULD unicast a gratuitous NA(Override) to each 459 such peer, to supply the MAC address of the new 6BBR in the TLLA 460 option for the Address. 462 5.2.2. Bridging Proxy Operations 464 A Bridging Proxy can be implemented in a Layer-3 switch, or in a 465 wireless Access Point that acts as an IPv6 Host. In the latter case, 466 the SLLA option in the proxied NA messages is that of the Registering 467 Node, and the 6BBR acts as a Layer-2 bridge for unicast packets to 468 the Registered Address. The MAC address in the S/TLLA is that of the 469 Registering Node, which is not necessarily the Registered Node. When 470 a 6LN moves within a LLN mesh, it may attach to a different 6LBR 471 acting as Registering Node, and the MAC address advertised over the 472 backbone might change. 474 If a registration moves from one 6BBR to the next, but the 475 Registering Node does not change, as indicated by the S/TLLA option 476 in the ND exchanges, there is no need to update the Neighbor Caches 477 of the peer's Nodes on the backbone. On the other hand, if the LLA 478 changes, the 6BBR SHOULD inform all the relevant peers as described 479 above, to update the affected Neighbor Caches. In the same fashion, 480 if the Registering Node changes with a new registration, the 6BBR 481 SHOULD also update the affected Neighbor Caches over the backbone. 483 6. Backbone Router Proxy Operations 485 The LLNs attached to each 6BBR are considered different Links in a 486 multi-link subnet. The prefix that is used may still be advertised 487 as on-link on the backbone to support legacy 6LNs. Multicast ND 488 messages are link-scoped and not forwarded across the backbone 489 routers. 491 By default, a 6BBR operates as a Sleeping Proxy, as follows: 493 o Create a new entry in a Binding Table for a new Registered Address 494 and ensure that the address is not a duplicate over the backbone 496 o Defend a Registered Address over the backbone using NA messages 497 with the Override bit set on behalf of the sleeping 6LN 499 o Advertise a Registered Address over the backbone using NA 500 messages, asynchronously or as a response to a Neighbor 501 Solicitation messages. 503 o To deliver packets arriving from the LLN, use Neighbor 504 Solicitation messages to look up the destination over the 505 backbone. 507 o Forward packets between the LLN and the backbone. 509 o Verify liveliness when needed for a stale registration. 511 A 6BBR may act as a Sleeping Proxy only for a Registered Address that 512 is REACHABLE, or TENTATIVE in which case the answer is delayed. In 513 any other state, the Sleeping Proxy operates as a Unicasting Proxy. 515 The 6BBR does not act on ND Messages over the backbone unless they 516 are relevant to a Registered Node on the LLN side, saving wireless 517 interference. On the LLN side, the prefixes associated to the 518 MultiLink Subnet are presented as not on-link, so address resolution 519 for other hosts do not occur. 521 As a Unicasting Proxy, the 6BBR forwards NS lookup messages to the 522 Registering Node, transforming Layer-2 multicast into unicast. This 523 is not possible in UNREACHABLE state, so the NS messages are 524 multicasted, and rate-limited. Retries are possible, using an 525 exponential back-off to protect the medium. In other states, the 526 messages are forwarded to the Registering Node as unicast Layer-2 527 messages. In TENTATIVE state, the NS message is either held till DAD 528 completes, or dropped if DAD does not complete. 530 6.1. Primary and Secondary BBRs 532 A 6BBR MAY be primary or secondary. The primary is the backbone 533 router that has the highest EUI-64 address of all the 6BBRs that 534 share a registration for a same Registered Address, with the same 535 ROVR and same Transaction ID, the EUI-64 address being considered as 536 an unsigned 64bit integer. A given 6BBR can be primary for a given 537 address and secondary for another address, regardless of whether or 538 not the addresses belong to the same 6LN. The primary Backbone 539 Router is in charge of protecting the address for DAD over the 540 Backbone. Any of the Primary and Secondary 6BBR may claim the 541 address over the backbone, since they are all capable to route from 542 the backbone to the 6LN; the address appears on the backbone as an 543 anycast address. 545 6.2. Binding Table 547 Each 6BBR maintains a Binding Table, using IPv6 ND over the backbone 548 to detect duplication. Another document 549 [I-D.ietf-6lo-rfc6775-update] provides details about how the EARO is 550 used between 6LRs and 6LBRs by way of DAR/DAC messages within the 551 LLN. Addresses in a LLN that can be reachable from the backbone by 552 way of a 6BBR MUST be registered to that 6BBR. 554 A false positive duplicate detection may arise over the backbone, for 555 instance if a 6LN's Registered Address is registered to more than one 556 LBR, or if the 6LN has moved. Both situations are handled by the 557 6BBR transparently to the 6LN. In the former case, one LBR becomes 558 primary to defend the address over the backbone while the others 559 become secondary and may still forward packets. In the latter case 560 the LBR that receives the newest registration becomes primary because 561 of the TID. 563 Only one 6LN may register a given Address at a particular 6BBR. 564 However, that Registered Address may be registered to Multiple 6BBRs 565 for higher availability. 567 Over the LLN, Binding Table management is as follows: 569 De-registrations (newer TID, same ROVR, null Lifetime) are 570 accepted and acknowledged with a status of 4 (TBD); the entry is 571 deleted; 573 Newer registrations (newer TID, same ROVR, non-null Lifetime) are 574 acknowledged with a status of 0 (success); the binding is updated 575 with the new TID, the Registration Lifetime and the Registering 576 Node; in TENTATIVE state the acknowledgement is held and may be 577 overwritten; in other states the Registration-Lifetime timer is 578 restarted and the entry is placed in REACHABLE state. 580 Identical registrations (same TID, same ROVR) from a same 581 Registering Node are acknowledged with a status of 0 (success). 582 If they are not identical, an error SHOULD be logged. In 583 TENTATIVE state, the response is held and may be overwritten, but 584 it MUST be eventually produced and it carries the result of the 585 DAD process; 587 Older registrations (older TID, same ROVR) from a Registering Node 588 are ignored; 590 Identical and older registrations (not-newer TID, same ROVR) from 591 a different Registering Node are acknowledged with a status of 3 592 (moved); this may be rate limited to protect the medium; 594 Any registration for a different Registered Node (different ROVR) 595 are acknowledged with a status of 1 (duplicate). 597 6.3. Registration and Binding Table Entry Creation 599 Upon receiving a registration for a new address with an NS(EARO) with 600 the 'R' bit set, the 6BBR performs DAD over the backbone, placing the 601 new address as target in the NS-DAD message. The EARO from the 602 registration MUST be placed unchanged in the NS-DAD message, and an 603 Neighbor Cache entry created in TENTATIVE state for a duration of 604 TENTATIVE_DURATION. The NS-DAD message is sent multicast over the 605 backbone to the SNMA associated with the registered address, unless 606 that operation is known to be costly, and the 6BBR has an indication 607 from another source (such as a Neighbor Cache entry) that the 608 Registered Address was known on the backbone; in the latter case, an 609 NS-DAD message may be sent as a Layer-2 unicast to the MAC Address 610 that was associated with the Registered Address. 612 In TENTATIVE state after EARO with 'R' bit set: 614 1. The entry is removed if an NA is received over the backbone for 615 the Registered Address with no EARO, or containing an EARO with a 616 status of 1 (duplicate) that indicates an existing registration 617 for another 6LN. The ROVR and TID fields in the EARO received 618 over the backbone are ignored. A status of 1 is returned in the 619 EARO of the NA back to the Registering Node; 621 2. The entry is also removed if an NA with an ARO option with a 622 status of 3 (moved), or a NS with an ARO option that indicates a 623 newer registration for the same Registered Node, is received over 624 the backbone for the Registered Address. A status of 3 is 625 returned in the NA(EARO) back to the Registering Node; 627 3. When a registration is updated but not deleted, e.g. from a newer 628 registration, the DAD process on the backbone continues and the 629 running timers are not restarted; 631 4. Other NS (including DAD with no EARO) and NA from the backbone 632 are not acknowledged in TENTATIVE state. To cover legacy 6LNs 633 that do not support ODAD, the list of their origins MAY be stored 634 and then, if the TENTATIVE_DURATION timer elapses, the 6BBR MAY 635 send each such legacy 6LN a unicast NA. 637 5. When the TENTATIVE_DURATION timer elapses, a status 0 (success) 638 is returned in a NA(EARO) back to the Registering Node(s), and 639 the entry goes to REACHABLE state for the Registration Lifetime. 640 The 6BBR MUST send a multicast NA(EARO) to the SNMA associated to 641 the Registered Address over the backbone with the Override bit 642 set so as to take over the binding from other 6BBRs. 644 6.4. Defending Addresses 646 If a 6BBR has an entry in REACHABLE state for a Registered Address: 648 o If the 6BBR is primary, or does not support the function of 649 primary, it MUST defend that address over the backbone upon 650 receiving NS, either if the NS does not carry an EARO, or if an 651 EARO is present that indicates a different Registering Node 652 (different ROVR). The 6BBR sends a NA message with the Override 653 bit set and the NA carries an EARO if and only if the NS-DAD did 654 so. When present, the EARO in the NA(Override) that is sent in 655 response to the NS(EARO) carries a status of 1 (duplicate), and 656 the ROVR and TID fields in the EARO are obfuscated with null or 657 random values to avoid network scanning and impersonation attacks. 659 o If the 6BBR receives an NS(EARO) for a newer registration, the 660 6BBR updates the entry and the routing state to forward packets to 661 the new 6BBR, but keeps the entry REACHABLE. Afterwards, the 6BBR 662 MAY use REDIRECT messages to reroute traffic for the Registered 663 Address to the new 6BBR. 665 o If the 6BBR receives an NA(EARO) for a newer registration, the 666 6BBR removes its entry and sends a NA(EARO) with a status of 3 667 (MOVED) to the Registering Node, if the Registering Node is 668 different from the Registered Node. The 6BBR cleans up existing 669 Neighbor Cache entries in peer nodes as discussed in Section 5.1, 670 by unicasting to each such peer, or one broadcast NA(Override). 672 o If the 6BBR receives a NS(LOOKUP) for a Registered Address, it 673 answers immediately with an NA on behalf of the Registered Node, 674 without polling it. There is no need of an EARO in that exchange. 676 o When the Registration-Lifetime timer elapses, the entry goes to 677 STALE state for a duration of STABLE_STALE_DURATION in LLNs that 678 keep stable addresses such as LWPANs, and UNSTABLE_STALE_DURATION 679 in LLNs where addresses are renewed rapidly, e.g. for privacy 680 reasons. 682 The STALE state enables tracking of the backbone peers that have a 683 Neighbor Cache entry pointing to this 6BBR in case the Registered 684 Address shows up later. If the Registered Address is claimed by 685 another 6LN on the backbone, with an NS-DAD or an NA, the 6BBR does 686 not defend the address. In STALE state: 688 o If STALE_DURATION elapses, the 6BBR removes the entry. 690 o Upon receiving an NA(Override) the 6BBR removes its entry and 691 sends a NA(EARO) with a status of 4 (removed) to the Registering 692 Node. 694 o If the 6BBR receives a NS(LOOKUP) for a Registered Address, the 695 6BBR MUST send an NS(NUD) following rules in [RFC7048] to the 696 Registering Node targeting the Registered Address prior to 697 answering. If the NUD succeeds, the operation in REACHABLE state 698 applies. If the NUD fails, the 6BBR refrains from answering the 699 lookup. The NUD SHOULD be used by the Registering Node to 700 indicate liveness of the Registered Node, if they are different 701 nodes. 703 7. Security Considerations 705 This specification applies to LLNS in which the link layer is 706 protected, either by means of physical or IP security for the 707 Backbone Link or MAC sublayer cryptography. In particular, the LLN 708 MAC is required to provide secure unicast to/from the Backbone Router 709 and secure Broadcast from the Backbone Router in a way that prevents 710 tampering with or replaying the RA messages. 712 The use of EUI-64 for forming the Interface ID in the link local 713 address prevents the usage of Secure ND ([RFC3971] and [RFC3972]) and 714 address privacy techniques. Additional protection against address 715 theft is provided by [I-D.ietf-6lo-ap-nd], which guarantees the 716 ownership of the ROVR. 718 When the ownership of the ROVR cannot be assessed, this specification 719 limits the cases where the ROVR and the TID are multicasted, and 720 obfuscates them in responses to attempts to take over an address. 722 8. Protocol Constants 724 This Specification uses the following constants: 726 TENTATIVE_DURATION: 800 milliseconds 728 STABLE_STALE_DURATION: 24 hours 730 UNSTABLE_STALE_DURATION: 5 minutes 732 DEFAULT_NS_POLLING: 3 times 734 9. IANA Considerations 736 This document has no request to IANA. 738 10. Future Work 740 Future documents may extend this specification by allowing the 6BBR 741 to redistribute host routes in routing protocols that would operate 742 over the backbone, or in MIPv6, or FMIP, or the Locator/ID Separation 743 Protocol (LISP) [RFC6830] to support mobility on behalf of the 6LNs, 744 etc... 746 11. Acknowledgments 748 Kudos to Eric Levy-Abegnoli who designed the First Hop Security 749 infrastructure at Cisco. 751 12. References 753 12.1. Normative References 755 [I-D.ietf-6lo-rfc6775-update] 756 Thubert, P., Nordmark, E., Chakrabarti, S., and C. 757 Perkins, "Registration Extensions for 6LoWPAN Neighbor 758 Discovery", draft-ietf-6lo-rfc6775-update-21 (work in 759 progress), June 2018. 761 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 762 Requirement Levels", BCP 14, RFC 2119, 763 DOI 10.17487/RFC2119, March 1997, 764 . 766 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 767 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 768 2006, . 770 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 771 for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, 772 . 774 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 775 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 776 DOI 10.17487/RFC4861, September 2007, 777 . 779 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 780 Address Autoconfiguration", RFC 4862, 781 DOI 10.17487/RFC4862, September 2007, 782 . 784 [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for 785 Detecting Network Attachment in IPv6", RFC 6059, 786 DOI 10.17487/RFC6059, November 2010, 787 . 789 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 790 Bormann, "Neighbor Discovery Optimization for IPv6 over 791 Low-Power Wireless Personal Area Networks (6LoWPANs)", 792 RFC 6775, DOI 10.17487/RFC6775, November 2012, 793 . 795 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 796 (IPv6) Specification", STD 86, RFC 8200, 797 DOI 10.17487/RFC8200, July 2017, 798 . 800 12.2. Informative References 802 [I-D.ietf-6lo-ap-nd] 803 Thubert, P., Sarikaya, B., Sethi, M., and R. Struik, 804 "Address Protected Neighbor Discovery for Low-power and 805 Lossy Networks", draft-ietf-6lo-ap-nd-08 (work in 806 progress), October 2018. 808 [I-D.ietf-6man-rs-refresh] 809 Nordmark, E., Yourtchenko, A., and S. Krishnan, "IPv6 810 Neighbor Discovery Optional RS/RA Refresh", draft-ietf- 811 6man-rs-refresh-02 (work in progress), October 2016. 813 [I-D.ietf-6tisch-architecture] 814 Thubert, P., "An Architecture for IPv6 over the TSCH mode 815 of IEEE 802.15.4", draft-ietf-6tisch-architecture-15 (work 816 in progress), October 2018. 818 [I-D.ietf-mboned-ieee802-mcast-problems] 819 Perkins, C., McBride, M., Stanley, D., Kumari, W., and J. 820 Zuniga, "Multicast Considerations over IEEE 802 Wireless 821 Media", draft-ietf-mboned-ieee802-mcast-problems-02 (work 822 in progress), August 2018. 824 [I-D.nordmark-6man-dad-approaches] 825 Nordmark, E., "Possible approaches to make DAD more robust 826 and/or efficient", draft-nordmark-6man-dad-approaches-02 827 (work in progress), October 2015. 829 [I-D.yourtchenko-6man-dad-issues] 830 Yourtchenko, A. and E. Nordmark, "A survey of issues 831 related to IPv6 Duplicate Address Detection", draft- 832 yourtchenko-6man-dad-issues-01 (work in progress), March 833 2015. 835 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 836 "SEcure Neighbor Discovery (SEND)", RFC 3971, 837 DOI 10.17487/RFC3971, March 2005, 838 . 840 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 841 RFC 3972, DOI 10.17487/RFC3972, March 2005, 842 . 844 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 845 Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 846 2006, . 848 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 849 DOI 10.17487/RFC4903, June 2007, 850 . 852 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 853 over Low-Power Wireless Personal Area Networks (6LoWPANs): 854 Overview, Assumptions, Problem Statement, and Goals", 855 RFC 4919, DOI 10.17487/RFC4919, August 2007, 856 . 858 [RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, 859 Ed., "Control And Provisioning of Wireless Access Points 860 (CAPWAP) Protocol Specification", RFC 5415, 861 DOI 10.17487/RFC5415, March 2009, 862 . 864 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 865 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 866 2011, . 868 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 869 Locator/ID Separation Protocol (LISP)", RFC 6830, 870 DOI 10.17487/RFC6830, January 2013, 871 . 873 [RFC7048] Nordmark, E. and I. Gashinsky, "Neighbor Unreachability 874 Detection Is Too Impatient", RFC 7048, 875 DOI 10.17487/RFC7048, January 2014, 876 . 878 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 879 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 880 2014, . 882 [RFC7559] Krishnan, S., Anipko, D., and D. Thaler, "Packet-Loss 883 Resiliency for Router Solicitations", RFC 7559, 884 DOI 10.17487/RFC7559, May 2015, 885 . 887 [RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy 888 Consumption of Router Advertisements", BCP 202, RFC 7772, 889 DOI 10.17487/RFC7772, February 2016, 890 . 892 12.3. External Informative References 894 [IEEEstd8021] 895 IEEE standard for Information Technology, "IEEE Standard 896 for Information technology -- Telecommunications and 897 information exchange between systems Local and 898 metropolitan area networks Part 1: Bridging and 899 Architecture". 901 [IEEEstd80211] 902 IEEE standard for Information Technology, "IEEE Standard 903 for Information technology -- Telecommunications and 904 information exchange between systems Local and 905 metropolitan area networks-- Specific requirements Part 906 11: Wireless LAN Medium Access Control (MAC) and Physical 907 Layer (PHY) Specifications". 909 [IEEEstd802151] 910 IEEE standard for Information Technology, "IEEE Standard 911 for Information Technology - Telecommunications and 912 Information Exchange Between Systems - Local and 913 Metropolitan Area Networks - Specific Requirements. - Part 914 15.1: Wireless Medium Access Control (MAC) and Physical 915 Layer (PHY) Specifications for Wireless Personal Area 916 Networks (WPANs)". 918 [IEEEstd802154] 919 IEEE standard for Information Technology, "IEEE Standard 920 for Local and metropolitan area networks -- Part 15.4: 921 Low-Rate Wireless Personal Area Networks (LR-WPANs)". 923 Appendix A. Changes from revision 07 to revision 08 925 This section lists the changes between draft-ietf-6lo-backbone-router 926 revisions ...-07.txt and ...-08.txt. 928 o Reorganized the order of presentation of some sections so that 929 related material is closer together. 931 o Added "Future Work" section. 933 o Added this section detailing recent changes. 935 o Used '6LN' when LLN node is meant. 937 o Updated bibliographic citations. 939 Authors' Addresses 940 Pascal Thubert (editor) 941 Cisco Systems, Inc 942 Building D 943 45 Allee des Ormes - BP1200 944 MOUGINS - Sophia Antipolis 06254 945 FRANCE 947 Phone: +33 497 23 26 34 948 Email: pthubert@cisco.com 950 Charles E. Perkins 951 Futurewei 952 2330 Central Expressway 953 Santa Clara 95050 954 United States of America 956 Email: charliep@computer.org