idnits 2.17.1 draft-ietf-6lo-backbone-router-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 17, 2017) is 2446 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 1049, but not defined == Missing Reference: 'IEEEstd80211' is mentioned on line 1056, but not defined == Missing Reference: 'IEEEstd802154' is mentioned on line 1073, but not defined == Missing Reference: 'IEEEstd802151' is mentioned on line 1064, but not defined == Outdated reference: A later version (-21) exists of draft-ietf-6lo-rfc6775-update-06 == Outdated reference: A later version (-23) exists of draft-ietf-6lo-ap-nd-02 == Outdated reference: A later version (-22) exists of draft-ietf-6lo-nfc-07 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-11 == Outdated reference: A later version (-10) exists of draft-ietf-6tisch-terminology-09 == Outdated reference: A later version (-08) exists of draft-ietf-bier-architecture-07 -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 0 errors (**), 0 flaws (~~), 11 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 July 17, 2017 5 Expires: January 18, 2018 7 IPv6 Backbone Router 8 draft-ietf-6lo-backbone-router-04 10 Abstract 12 This specification proposes an update to IPv6 Neighbor Discovery, to 13 enhance the operation of IPv6 over wireless links that exhibit lossy 14 multicast support, and enable a large degree of scalability by 15 splitting the broadcast domains. A broadcast-efficient backbone 16 running classical IPv6 Neighbor Discovery federates multiple wireless 17 links to form a large MultiLink Subnet, but the broadcast domain does 18 not need to extend to the wireless links for the purpose of ND 19 operation. Backbone Routers placed at the wireless edge of the 20 backbone proxy the ND operation and route packets from/to registered 21 nodes, and wireless nodes register or are proxy-registered to the 22 Backbone Router to setup proxy services in a fashion that is 23 essentially similar to a classical Layer-2 association. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 18, 2018. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Applicability and Requirements Served . . . . . . . . . . . . 4 61 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 5. Backbone Router Routing Operations . . . . . . . . . . . . . 9 64 5.1. Over the Backbone Link . . . . . . . . . . . . . . . . . 10 65 5.2. Over the LLN Link . . . . . . . . . . . . . . . . . . . . 11 66 6. BackBone Router Proxy Operations . . . . . . . . . . . . . . 13 67 6.1. Registration and Binding State Creation . . . . . . . . . 15 68 6.2. Defending Addresses . . . . . . . . . . . . . . . . . . . 16 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 70 8. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 18 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 72 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 74 11.1. Normative References . . . . . . . . . . . . . . . . . . 19 75 11.2. Informative References . . . . . . . . . . . . . . . . . 20 76 11.3. External Informative References . . . . . . . . . . . . 23 77 Appendix A. Requirements . . . . . . . . . . . . . . . . . . . . 24 78 A.1. Requirements Related to Mobility . . . . . . . . . . . . 24 79 A.2. Requirements Related to Routing Protocols . . . . . . . . 25 80 A.3. Requirements Related to the Variety of Low-Power Link 81 types . . . . . . . . . . . . . . . . . . . . . . . . . . 26 82 A.4. Requirements Related to Proxy Operations . . . . . . . . 26 83 A.5. Requirements Related to Security . . . . . . . . . . . . 27 84 A.6. Requirements Related to Scalability . . . . . . . . . . . 28 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29 87 1. Introduction 89 One of the key services provided by IEEE std. 802.1 [IEEEstd8021] 90 Ethernet Bridging is an efficient and reliable broadcast service, and 91 multiple applications and protocols have been built that heavily 92 depends on that feature for their core operation. But a wide range 93 of wireless networks do not provide the solid and cheap broadcast 94 capabilities of Ethernet Bridging, and protocols designed for bridged 95 networks that rely on broadcast often exhibit disappointing 96 behaviours when applied unmodified to a wireless medium. 98 IEEE std. 802.11 [IEEEstd80211] Access Points (APs) deployed in an 99 Extended Service Set (ESS) effectively act as bridges, but, in order 100 to ensure a solid connectivity to the devices and protect the medium 101 against harmful broadcasts, they refrain from relying on broadcast- 102 intensive protocols such as Transparent Bridging on the wireless 103 side. Instead, an association process is used to register 104 proactively the MAC addresses of the wireless device (STA) to the AP, 105 and then the APs proxy the bridging operation and cancel the 106 broadcasts. 108 Classical IPv6 [RFC8200] Neighbor Discovery [RFC4862] Protocol (NDP) 109 operations are reactive and rely heavily on multicast operations to 110 locate an on-link correspondent and ensure address uniqueness, which 111 is a pillar that sustains the whole IP architecture. When the 112 Duplicate Address Detection [RFC4862] (DAD) mechanism was designed, 113 it was a natural match with the efficient broadcast operation of 114 Ethernet Bridging, but with the unreliable broadcast that is typical 115 of wireless media, DAD is bound to fail to discover duplications 116 [I-D.yourtchenko-6man-dad-issues]. In other words, because the 117 broadcast service is unreliable, DAD appears to work on wireless 118 media not because address duplication is detected and solved as 119 designed, but because the duplication is a very rare event as a side 120 effect of the sheer amount of entropy in 64-bits Interface IDs. 122 In the real world, IPv6 multicast messages are effectively broadcast, 123 so they are processed by most if not all wireless nodes over the ESS 124 fabric even when very few if any of the nodes is effectively 125 listening to the multicast address. It results that a simple 126 Neighbor Solicitation (NS) lookup message [RFC4861], that is 127 supposedly targeted to a very small group of nodes, ends up polluting 128 the whole wireless bandwidth across the fabric 129 [I-D.vyncke-6man-mcast-not-efficient]. In other words, the reactive 130 IPv6 ND operation leads to undesirable power consumption in battery- 131 operated devices. 133 The inefficiencies of using radio broadcasts to support IPv6 NDP lead 134 the community to consider (again) splitting the broadcast domain 135 between the wired and the wireless access links. One classical way 136 to achieve this is to split the subnet in multiple ones, and at the 137 extreme provide a /64 per wireless device. Another is to proxy the 138 Layer-3 protocols that rely on broadcast operation at the boundary of 139 the wired and wireless domains, effectively emulating the Layer-2 140 association at layer-3. To that effect, the current IEEE std. 802.11 141 specifications require the capability to perform ARP and ND proxy 142 [RFC4389] functions at the Access Points (APs). 144 But for the lack a comprehensive specification for the ND proxy and 145 in particular the lack of an equivalent to an association process, 146 implementations have to rely on snooping for acquiring the related 147 state, which is unsatisfactory in a lossy and mobile conditions. 148 With snooping, a state (e.g. a new IPv6 address) may not be 149 discovered or a change of state (e.g. a movement) may be missed, 150 leading to unreliable connectivity. 152 In the context of IEEE std. 802.15.4 [IEEEstd802154], the step of 153 considering the radio as a medium that is different from Ethernet was 154 already taken with the publication of Neighbor Discovery Optimization 155 for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) 156 [RFC6775]. RFC 6775 is updated as [I-D.ietf-6lo-rfc6775-update]; the 157 update includes changes that are required by this document. 159 This specification applies that same thinking to other wireless links 160 such as Low-Power IEEE std. 802.11 (Wi-Fi) and IEEE std. 802.15.1 161 (Bluetooth) [IEEEstd802151], and extends [RFC6775] to enable proxy 162 operation by the 6BBR so as to decouple the broadcast domain in the 163 backbone from the wireless links. The proxy operation can be 164 maintained asynchronous so that low-power nodes or nodes that are 165 deep in a mesh do not need to be bothered synchronously when a lookup 166 is performed for their addresses, effectively implementing the ND 167 contribution to the concept of a Sleep Proxy 168 [I-D.nordmark-6man-dad-approaches]. 170 2. Applicability and Requirements Served 172 Efficiency aware IPv6 Neighbor Discovery Optimizations 173 [I-D.chakrabarti-nordmark-6man-efficient-nd] suggests that 6LoWPAN ND 174 [RFC6775] can be extended to other types of links beyond IEEE std. 175 802.15.4 for which it was defined. The registration technique is 176 beneficial when the Link-Layer technique used to carry IPv6 multicast 177 packets is not sufficiently efficient in terms of delivery ratio or 178 energy consumption in the end devices, in particular to enable 179 energy-constrained sleeping nodes. The value of such extension is 180 especially apparent in the case of mobile wireless nodes, to reduce 181 the multicast operations that are related to classical ND ([RFC4861], 182 [RFC4862]) and plague the wireless medium. 184 This specification updates and generalizes 6LoWPAN ND to a broader 185 range of Low power and Lossy Networks (LLNs) with a solid support for 186 Duplicate Address Detection (DAD) and address lookup that does not 187 require broadcasts over the LLNs. The term LLN is used loosely in 188 this specification to cover multiple types of WLANs and WPANs, 189 including Low-Power Wi-Fi, BLUETOOTH(R) Low Energy, IEEE std. 190 802.11AH and IEEE std. 802.15.4 wireless meshes, so as to address the 191 requirements listed in Appendix A.3 192 The scope of this draft is a Backbone Link that federates multiple 193 LLNs as a single IPv6 MultiLink Subnet. Each LLN in the subnet is 194 anchored at an IPv6 Backbone Router (6BBR). The Backbone Routers 195 interconnect the LLNs over the Backbone Link and emulate that the LLN 196 nodes are present on the Backbone using proxy-ND operations. This 197 specification extends IPv6 ND over the backbone to discriminate 198 address movement from duplication and eliminate stale state in the 199 backbone routers and backbone nodes once a LLN node has roamed. This 200 way, mobile nodes may roam rapidly from a 6BBR to the next and 201 requirements in Appendix A.1 are met. 203 This specification can be used by any wireless node to associate at 204 Layer-3 with a 6BBR and register its IPv6 addresses to obtain routing 205 services including proxy-ND operations over the backbone, effectively 206 providing a solution to the requirements expressed in Appendix A.4. 208 The Link Layer Address (LLA) that is returned as Target LLA (TLLA) in 209 Neighbor Advertisements (NA) messages by the 6BBR on behalf of the 210 Registered Node over the backbone may be that of the Registering 211 Node, in which case the 6BBR needs to bridge the unicast packets 212 (Bridging proxy), or that of the 6BBR on the backbone, in which case 213 the 6BBRs needs to route the unicast packets (Routing proxy). In the 214 latter case, the 6BBR may maintain the list of correspondents to 215 which it has advertised its own MAC address on behalf of the LLN node 216 and the IPv6 ND operation is minimized as the number of nodes scale 217 up in the LLN. This enables to meet the requirements in Appendix A.6 218 as long has the 6BBRs are dimensioned for the number of registration 219 that each needs to support. 221 In the context of the the TimeSlotted Channel Hopping (TSCH) mode of 222 [IEEEstd802154], the 6TiSCH architecture 223 [I-D.ietf-6tisch-architecture] introduces how a 6LoWPAN ND host could 224 connect to the Internet via a RPL mesh Network, but this requires 225 additions to the 6LOWPAN ND protocol to support mobility and 226 reachability in a secured and manageable environment. This 227 specification details the new operations that are required to 228 implement the 6TiSCH architecture and serves the requirements listed 229 in Appendix A.2. 231 In the case of Low-Power IEEE std. 802.11, a 6BBR may be collocated 232 with a standalone AP or a CAPWAP [RFC5415] wireless controller, and 233 the wireless client (STA) leverages this specification to register 234 its IPv6 address(es) to the 6BBR over the wireless medium. In the 235 case of a 6TiSCH LLN mesh, the RPL root is collocated with a 6LoWPAN 236 Border Router (6LBR), and either collocated with or connected to the 237 6BBR over an IPv6 Link. The 6LBR leverages this specification to 238 register the LLN nodes on their behalf to the 6BBR. In the case of 239 BTLE, the 6BBR is collocated with the router that implements the BTLE 240 central role as discussed in section 2.2 of [RFC7668]. 242 3. Terminology 244 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 245 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 246 document are to be interpreted as described in [RFC2119]. 248 Readers are expected to be familiar with all the terms and concepts 249 that are discussed in "Neighbor Discovery for IP version 6" 250 [RFC4861], "IPv6 Stateless Address Autoconfiguration" [RFC4862], 251 "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): 252 Overview, Assumptions, Problem Statement, and Goals" [RFC4919], 253 Neighbor Discovery Optimization for Low-power and Lossy Networks 254 [RFC6775] and "Multi-link Subnet Support in IPv6" 255 [I-D.ietf-ipv6-multilink-subnets]. 257 Readers would benefit from reading "Multi-Link Subnet Issues" 258 [RFC4903], ,"Mobility Support in IPv6" [RFC6275], "Neighbor Discovery 259 Proxies (ND Proxy)" [RFC4389] and "Optimistic Duplicate Address 260 Detection" [RFC4429] prior to this specification for a clear 261 understanding of the art in ND-proxying and binding. 263 Additionally, this document uses terminology from [RFC7102], 264 [I-D.ietf-6lo-rfc6775-update] and [I-D.ietf-6tisch-terminology], and 265 introduces the following terminology: 267 Sleeping Proxy A 6BBR acts as a Sleeping Proxy if it answers ND 268 Neighbor Solicitation over the backbone on behalf of the 269 Registered Node whenever possible. This is the default mode 270 for this specification but it may be overridden, for instance 271 by configuration, into Unicasting Proxy. 273 Unicasting Proxy As a Unicasting Proxy, the 6BBR forwards NS 274 messages to the Registering Node, transforming Layer-2 275 multicast into unicast whenever possible. 277 Routing proxy A 6BBR acts as a routing proxy if it advertises its 278 own MAC address, as opposed to that of the node that performs 279 the registration, as the TLLA in the proxied NAs over the 280 backbone. In that case, the MAC address of the node is not 281 visible at Layer-2 over the backbone and the bridging fabric is 282 not aware of the addresses of the LLN devices and their 283 mobility. The 6BBR installs a connected host route towards the 284 registered node over the interface to the node, and acts as a 285 Layer-3 router for unicast packets to the node. The 6BBR 286 updates the ND Neighbor Cache Entries (NCE) in correspondent 287 nodes if the wireless node moves and registers to another 6BBR, 288 either with a single broadcast, or with a series of unicast 289 NA(O) messages, indicating the TLLA of the new router. 291 Bridging proxy A 6BBR acts as a bridging proxy if it advertises the 292 MAC address of the node that performs the registration as the 293 TLLA in the proxied NAs over the backbone. In that case, the 294 MAC address and the mobility of the node is still visible 295 across the bridged backbone fabric, as is traditionally the 296 case with Layer-2 APs. The 6BBR acts as a Layer-2 bridge for 297 unicast packets to the registered node. The MAC address 298 exposed in the S/TLLA is that of the Registering Node, which is 299 not necessarily the Registered Device. When a device moves 300 within a LLN mesh, it may end up attached to a different 6LBR 301 acting as Registering Node, and the LLA that is exposed over 302 the backbone will change. 304 Primary BBR The BBR that will defend a Registered Address for the 305 purpose of DAD over the backbone. 307 Secondary BBR A BBR to which the address is registered. A Secondary 308 Router MAY advertise the address over the backbone and proxy 309 for it. 311 4. Overview 313 An LLN node can move freely from an LLN anchored at a Backbone Router 314 to an LLN anchored at another Backbone Router on the same backbone 315 and conserve any of the IPv6 addresses that it has formed, 316 transparently. 318 | 319 +-----+ 320 | | Other (default) Router 321 | | 322 +-----+ 323 | 324 | Backbone Link 325 +--------------------+------------------+ 326 | | | 327 +-----+ +-----+ +-----+ 328 | | Backbone | | Backbone | | Backbone 329 | | router | | router | | router 330 +-----+ +-----+ +-----+ 331 o o o o o o 332 o o o o o o o o o o o o o o 333 o o o o o o o o o o o o o o o 334 o o o o o o o o o o 335 o o o o o o o 337 LLN LLN LLN 339 Figure 1: Backbone Link and Backbone Routers 341 The Backbone Routers maintain an abstract Binding Table of their 342 Registered Nodes. The Binding Table operates as a distributed 343 database of all the wireless Nodes whether they reside on the LLNs or 344 on the backbone, and use an extension to the Neighbor Discovery 345 Protocol to exchange that information across the Backbone in the 346 classical ND reactive fashion. 348 The Extended Address Registration Option (ARO) defined in 349 [I-D.ietf-6lo-rfc6775-update] is used to enable the registration for 350 routing and proxy Neighbor Discovery operations by the 6BBR, and the 351 Extended ARO (EARO) option is included in the ND exchanges over the 352 backbone between the 6BBRs to sort out duplication from movement. 354 Address duplication is sorted out with the Owner Unique-ID field in 355 the EARO, which is a generalization of the EUI-64 that allows 356 different types of unique IDs beyond the name space derived from the 357 MAC addresses. First-Come First-Serve rules apply, whether the 358 duplication happens between LLN nodes as represented by their 359 respective 6BBRs, or between an LLN node and a classical node that 360 defends its address over the backbone with classical ND and does not 361 include the EARO option. 363 In case of conflicting registrations to multiple 6BBRs from a same 364 node, a sequence counter called Transaction ID (TID) is introduced 365 that enables 6BBRs to sort out the latest anchor for that node. 366 Registrations with a same TID are compatible and maintained, but, in 367 case of different TIDs, only the freshest registration is maintained 368 and the stale state is eliminated. 370 With this specification, Backbone Routers perform ND proxy over the 371 Backbone Link on behalf of their Registered Nodes. The Backbone 372 Router operation is essentially similar to that of a Mobile IPv6 373 (MIPv6) [RFC6275] Home Agent. This enables mobility support for LLN 374 nodes that would move outside of the network delimited by the 375 Backbone link attach to a Home Agent from that point on. This also 376 enables collocation of Home Agent functionality within Backbone 377 Router functionality on the same backbone interface of a router. 378 Further specification may extend this be allowing the 6BBR to 379 redistribute host routes in routing protocols that would operate over 380 the backbone, or in MIPv6 or the Locator/ID Separation Protocol 381 (LISP) [RFC6830] to support mobility on behalf of the nodes, etc... 383 The Optimistic Duplicate Address Detection [RFC4429] (ODAD) 384 specification details how an address can be used before a Duplicate 385 Address Detection (DAD) is complete, and insists that an address that 386 is TENTATIVE should not be associated to a Source Link-Layer Address 387 Option in a Neighbor Solicitation message. This specification 388 leverages ODAD to create a temporary proxy state in the 6BBR till DAD 389 is completed over the backbone. This way, the specification enables 390 to distribute proxy states across multiple 6BBR and co-exist with 391 classical ND over the backbone. 393 5. Backbone Router Routing Operations 394 | 395 +-----+ 396 | | Other (default) Router 397 | | 398 +-----+ 399 | /64 400 | Backbone Link 401 +-------------------+-------------------+ 402 | /64 | /64 | /64 403 +-----+ +-----+ +-----+ 404 | | Backbone | | Backbone | | Backbone 405 | | router | | router | | router 406 +-----+ +-----+ +-----+ 407 o N*/128 o o o M*/128 o o P*/128 408 o o o o o o o o o o o o o o 409 o o o o o o o o o o o o o o o 410 o o o o o o o o o o 411 o o o o o o o 413 LLN LLN LLN 415 Figure 2: Routing Configuration in the ML Subnet 417 5.1. Over the Backbone Link 419 The Backbone Router is a specific kind of Border Router that performs 420 proxy Neighbor Discovery on its backbone interface on behalf of the 421 nodes that it has discovered on its LLN interfaces. 423 The backbone is expected to be a high speed, reliable Backbone link, 424 with affordable and reliable multicast capabilities, such as a 425 bridged Ethernet Network, and to allow a full support of classical ND 426 as specified in [RFC4861] and subsequent RFCs. In other words, the 427 backbone is not a LLN. 429 Still, some restrictions of the attached LLNs will apply to the 430 backbone. In particular, it is expected that the MTU is set to the 431 same value on the backbone and all attached LLNs, and the scalability 432 of the whole subnet requires that broadcast operations are avoided as 433 much as possible on the backbone as well. Unless configured 434 otherwise, the Backbone Router MUST echo the MTU that it learns in 435 RAs over the backbone in the RAs that it sends towards the LLN links. 437 As a router, the Backbone Router behaves like any other IPv6 router 438 on the backbone side. It has a connected route installed towards the 439 backbone for the prefixes that are present on that backbone and that 440 it proxies for on the LLN interfaces. 442 As a proxy, the 6BBR uses an EARO option in the NS-DAD and the 443 multicast NA messages that it generates on behalf of a Registered 444 Node, and it places an EARO in its unicast NA messages if and only if 445 the NS/NA that stimulates it had an EARO in it. 447 When possible, the 6BBR SHOULD use unicast or solicited-node 448 multicast address (SNMA) [RFC4291] to defend its Registered Addresses 449 over the backbone. In particular, the 6BBR MUST join the SNMA group 450 that corresponds to a Registered Address as soon as it creates an 451 entry for that address and as long as it maintains that entry, 452 whatever the state of the entry. The expectation is that it is 453 possible to get a message delivered to all the nodes on the backbone 454 that listen to a particular address and support this specification - 455 which includes all the 6BBRs in the MultiLink Subnet - by sending a 456 multicast message to the associated SNMA over the backbone. 458 The support of Optimistic DAD (ODAD) [RFC4429] is recommended for all 459 nodes in the backbone and followed by the 6BBRs in their proxy 460 activity over the backbone. With ODAD, any optimistic node MUST join 461 the SNMA of a Tentative address, which interacts better with this 462 specification. 464 This specification allows the 6BBR in Routing Proxy mode to advertise 465 the Registered IPv6 Address with the 6BBR Link Layer Address, and 466 attempts to update Neighbor Cache Entries (NCE) in correspondent 467 nodes over the backbone, using gratuitous NA(Override). This method 468 may fail of the multicast message is not properly received, and 469 correspondent nodes may maintain an incorrect neighbor state, which 470 they will eventually discover through Neighbor Unreachability 471 Detection (NUD). Because mobility may be slow, the NUD procedure 472 defined in [RFC4861] may be too impatient, and the support of 473 [RFC7048] is recommended in all nodes in the network. 475 Since the MultiLink Subnet may grow very large in terms of individual 476 IPv6 addresses, multicasts should be avoided as much as possible even 477 on the backbone. Though it is possible for plain hosts to 478 participate with legacy IPv6 ND support, the support by all nodes 479 connected to the backbone of [I-D.ietf-6man-rs-refresh] is 480 recommended, and this implies the support of [RFC7559] as well. 482 5.2. Over the LLN Link 484 As a router, the Nodes and Backbone Router operation on the LLN 485 follows [RFC6775]. Per that specification, LLN Hosts generally do 486 not depend on multicast RAs to discover routers. It is still 487 generally required for LLN nodes to accept multicast RAs [RFC7772], 488 but those are rare on the LLN link. Nodes are expected to follow the 489 Simple Procedures for Detecting Network Attachment in IPv6 [RFC6059] 490 (DNA procedures) to assert movements, and to support the Packet-Loss 491 Resiliency for Router Solicitations [RFC7559] to make the unicast RS 492 more reliable. 494 The Backbone Router acquires its states about the addresses on the 495 LLN side through a registration process from either the nodes 496 themselves, or from a node such as a RPL root / 6LBR (the Registering 497 Node) that performs the registration on behalf of the address owner 498 (the Registered Node). 500 When operating as a Routing Proxy, the router installs hosts routes 501 (/128) to the Registered Addresses over the LLN links, via the 502 Registering Node as identified by the Source Address and the SLLAO 503 option in the NS(EARO) messages. 505 In that mode, the 6BBR handles the ND protocol over the backbone on 506 behalf of the Registered Nodes, using its own MAC address in the TLLA 507 and SLLA options in proxyed NS and NA messages. It results that for 508 each Registered Address, a number of peer Nodes on the backbone have 509 resolved the address with the 6BBR MAC address and keep that mapping 510 stored in their Neighbor cache. 512 The 6BBR SHOULD maintain, per Registered Address, the list of the 513 peers on the backbone to which it answered with it MAC address, and 514 when a binding moves to a different 6BBR, it SHOULD send a unicast 515 gratuitous NA(O) individually to each of them to inform them that the 516 address has moved and pass the MAC address of the new 6BBR in the 517 TLLAO option. If the 6BBR can not maintain that list, then it SHOULD 518 remember whether that list is empty or not and if not, send a 519 multicast NA(O) to all nodes to update the impacted Neighbor Caches 520 with the information from the new 6BBR. 522 The Bridging Proxy is a variation where the BBR function is 523 implemented in a Layer-3 switch or an wireless Access Point that acts 524 as a Host from the IPv6 standpoint, and, in particular, does not 525 operate the routing of IPv6 packets. In that case, the SLLAO in the 526 proxied NA messages is that of the Registering Node and classical 527 bridging operations take place on data frames. 529 If a registration moves from one 6BBR to the next, but the 530 Registering Node does not change, as indicated by the S/TLLAO option 531 in the ND exchanges, there is no need to update the Neighbor Caches 532 in the peers Nodes on the backbone. On the other hand, if the LLAO 533 changes, the 6BBR SHOULD inform all the relevant peers as described 534 above, to update the impacted Neighbor Caches. In the same fashion, 535 if the Registering Node changes with a new registration, the 6BBR 536 SHOULD also update the impacted Neighbor Caches over the backbone. 538 6. BackBone Router Proxy Operations 540 This specification enables a Backbone Router to proxy Neighbor 541 Discovery operations over the backbone on behalf of the nodes that 542 are registered to it, allowing any node on the backbone to reach a 543 Registered Node as if it was on-link. The backbone and the LLNs are 544 considered different Links in a MultiLink subnet but the prefix that 545 is used may still be advertised as on-link on the backbone to support 546 legacy nodes; multicast ND messages are link-scoped and not forwarded 547 across the backbone routers. 549 ND Messages on the backbone side that do not match to a registration 550 on the LLN side are not acted upon on the LLN side, which stands 551 protected. On the LLN side, the prefixes associated to the MultiLink 552 Subnet are presented as not on-link, so address resolution for other 553 hosts do not occur. 555 The default operation in this specification is Sleeping proxy which 556 means: 558 o creating a new entry in an abstract Binding Table for a new 559 Registered Address and validating that the address is not a 560 duplicate over the backbone 562 o defending a Registered Address over the backbone using NA messages 563 with the Override bit set on behalf of the sleeping node whenever 564 possible 566 o advertising a Registered Address over the backbone using NA 567 messages, asynchronously or as a response to a Neighbor 568 Solicitation messages. 570 o Looking up a destination over the backbone in order to deliver 571 packets arriving from the LLN using Neighbor Solicitation 572 messages. 574 o Forwarding packets from the LLN over the backbone, and the other 575 way around. 577 o Eventually triggering a liveliness verification of a stale 578 registration. 580 A 6BBR may act as a Sleeping Proxy only if the state of the binding 581 entry is REACHABLE, or TENTATIVE in which case the answer is delayed. 582 In any other state, the Sleeping Proxy operates as a Unicasting 583 Proxy. 585 As a Unicasting Proxy, the 6BBR forwards NS messages to the 586 Registering Node, transforming Layer-2 multicast into unicast 587 whenever possible. This is not possible in UNREACHABLE state, so the 588 NS messages are multicasted, and rate-limited to protect the medium 589 with an exponential back-off. In other states, The messages are 590 forwarded to the Registering Node as unicast Layer-2 messages. In 591 TENTATIVE state, the NS message is either held till DAD completes, or 592 dropped. 594 The draft introduces the optional concept of primary and secondary 595 BBRs. The primary is the backbone router that has the highest EUI-64 596 address of all the 6BBRs that share a registration for a same 597 Registered Address, with the same Owner Unique ID and same 598 Transaction ID, the EUI-64 address being considered as an unsigned 599 64bit integer. The concept is defined with the granularity of an 600 address, that is a given 6BBR can be primary for a given address and 601 secondary or another one, regardless on whether the addresses belong 602 to the same node or not. The primary Backbone Router is in charge of 603 protecting the address for DAD over the Backbone. Any of the Primary 604 and Secondary 6BBR may claim the address over the backbone, since 605 they are all capable to route from the backbone to the LLN node, and 606 the address appears on the backbone as an anycast address. 608 The Backbone Routers maintain a distributed binding table, using 609 classical ND over the backbone to detect duplication. This 610 specification requires that: 612 1. All addresses that can be reachable from the backbone, including 613 IPv6 addresses based on burn-in EUI64 addresses MUST be 614 registered to the 6BBR. 616 2. A Registered Node MUST include the EARO option in an NS message 617 that used to register an addresses to a 6LR; the 6LR MUST 618 propagate that option unchanged to the 6LBR in the DAR/DAC 619 exchange, and the 6LBR MUST propagate that option unchanged in 620 proxy registrations. 622 3. The 6LR MUST echo the same EARO option in the NA that it uses to 623 respond, but for the status filed which is not used in NS 624 messages, and significant in NA. 626 A false positive duplicate detection may arise over the backbone, for 627 instance if the Registered Address is registered to more than one 628 LBR, or if the node has moved. Both situations are handled 629 gracefully unbeknownst to the node. In the former case, one LBR 630 becomes primary to defend the address over the backbone while the 631 others become secondary and may still forward packets back and forth. 633 In the latter case the LBR that receives the newest registration wins 634 and becomes primary. 636 The expectation in this specification is that there is a single 637 Registering Node at a time per Backbone Router for a given Registered 638 Address, but that a Registered Address may be registered to Multiple 639 6BBRs for higher availability. 641 Over the LLN, and for any given Registered Address, it is REQUIRED 642 that: 644 de-registrations (newer TID, same OUID, null Lifetime) are 645 accepted and responded immediately with a status of 4; the entry 646 is deleted; 648 newer registrations (newer TID, same OUID, non-null Lifetime) are 649 accepted and responded with a status of 0 (success); the entry is 650 updated with the new TID, the new Registration Lifetime and the 651 new Registering Node, if any has changed; in TENTATIVE state the 652 response is held and may be overwritten; in other states the 653 Registration-Lifetime timer is restarted and the entry is placed 654 in REACHABLE state. 656 identical registrations (same TID, same OUID) from a same 657 Registering Node are not processed but responded with a status of 658 0 (success); they are expected to be identical and an error may be 659 logged if not; in TENTATIVE state, the response is held and may be 660 overwritten, but it MUST be eventually produced and it carries the 661 result of the DAD process; 663 older registrations (not(newer or equal) TID, same OUID) from a 664 same Registering Node are ignored; 666 identical and older registrations (not-newer TID, same OUID) from 667 a different Registering Node are responded immediately with a 668 status of 3 (moved); this may be rate limited to protect the 669 medium; 671 and any registration for a different Registered Node (different 672 OUID) are responded immediately with a status of 1 (duplicate). 674 6.1. Registration and Binding State Creation 676 Upon a registration for a new address with an NS(EARO), the 6BBR 677 performs a DAD operation over the backbone placing the new address as 678 target in the NS-DAD message. The EARO from the registration MUST be 679 placed unchanged in the NS-DAD message, and an entry is created in 680 TENTATIVE state for a duration of TENTATIVE_DURATION. The NS-DAD 681 message is sent multicast over the backbone to the SNMA address 682 associated with the registered address. If that operation is known 683 to be costly, and the 6BBR has an indication from another source 684 (such as a NCE) that the Registered Address was present on the 685 backbone, that information may be leveraged to send the NS-DAD 686 message as a Layer-2 unicast to the MAC that was associated with the 687 Registered Address. 689 In TENTATIVE state: 691 o the entry is removed if an NA is received over the backbone for 692 the Registered Address with no EARO option, or with an EARO option 693 with a status of 1 (duplicate) that indicates an existing 694 registration for another LLN node. The OUID and TID fields in the 695 EARO option received over the backbone are ignored. A status of 1 696 is returned in the EARO option of the NA back to the Registering 697 Node; 699 o the entry is also removed if an NA with an ARO option with a 700 status of 3 (moved), or a NS-DAD with an ARO option that indicates 701 a newer registration for the same Registered Node, is received 702 over the backbone for the Registered Address. A status of 3 is 703 returned in the NA(EARO) back to the Registering Node; 705 o when a registration is updated but not deleted, e.g. from a newer 706 registration, the DAD process on the backbone continues and the 707 running timers are not restarted; 709 o Other NS (including DAD with no EARO option) and NA from the 710 backbone are not responded in TENTATIVE state, but the list of 711 their origins may be kept in memory and if so, the 6BBR may send 712 them each a unicast NA with eventually an EARO option when the 713 TENTATIVE_DURATION timer elapses, so as to cover legacy nodes that 714 do not support ODAD. 716 o When the TENTATIVE_DURATION timer elapses, a status 0 (success) is 717 returned in a NA(EARO) back to the Registering Node(s), and the 718 entry goes to REACHABLE state for the Registration Lifetime; the 719 DAD process is successful and the 6BBR MUST send a multicast 720 NA(EARO) to the SNMA associated to the Registered Address over the 721 backbone with the Override bit set so as to take over the binding 722 from other 6BBRs. 724 6.2. Defending Addresses 726 If a 6BBR has an entry in REACHABLE state for a Registered Address: 728 o If the 6BBR is primary, or does not support the concept, it MUST 729 defend that address over the backbone upon an incoming NS-DAD, 730 either if the NS does not carry an EARO, or if an EARO is present 731 that indicates a different Registering Node (different OUID). The 732 6BBR sends a NA message with the Override bit set and the NA 733 carries an EARO option if and only if the NS-DAD did so. When 734 present, the EARO in the NA(O) that is sent in response to the NS- 735 DAD(EARO) carries a status of 1 (duplicate), and the OUID and TID 736 fields in the EARO option are obfuscated with null or random 737 values to avoid network scanning and impersonation attacks. 739 o If the 6BBR receives an NS-DAD(EARO) that reflect a newer 740 registration, the 6BBR updates the entry and the routing state to 741 forward packets to the new 6BBR, but keeps the entry REACHABLE. 742 In that phase, it MAY use REDIRECT messages to reroute traffic for 743 the Registered Address to the new 6BBR. 745 o If the 6BBR receives an NA(EARO) that reflect a newer 746 registration, the 6BBR removes its entry and sends a NA(AERO) with 747 a status of 3 (moved) to the Registering Node, if the Registering 748 Node is different from the Registered Node. If necessary, the 749 6BBR cleans up ND cache in peers nodes as discussed in 750 Section 5.1, by sending a series of unicast to the impacted nodes, 751 or one broadcast NA(O) to all-nodes. 753 o If the 6BBR received a NS(LOOKUP) for a Registered Address, it 754 answers immediately with an NA on behalf of the Registered Node, 755 without polling it. There is no need of an EARO in that exchange. 757 o When the Registration-Lifetime timer elapses, the entry goes to 758 STALE state for a duration of STABLE_STALE_DURATION in LLNs that 759 keep stable addresses such as LWPANs, and UNSTABLE_STALE_DURATION 760 in LLNs where addresses are renewed rapidly, e.g. for privacy 761 reasons. 763 The STALE state is a chance to keep track of the backbone peers that 764 may have an ND cache pointing on this 6BBR in case the Registered 765 Address shows back up on this or a different 6BBR at a later time. 766 In STALE state: 768 o If the Registered Address is claimed by another node on the 769 backbone, with an NS-DAD or an NA, the 6BBR does not defend the 770 address. Upon an NA(O), or the stale time elapses, the 6BBR 771 removes its entry and sends a NA(AERO) with a status of 4 772 (removed) to the Registering Node. 774 o If the 6BBR received a NS(LOOKUP) for a Registered Address, the 775 6BBR MUST send an NS(NUD) following rules in [RFC7048] to the 776 registering Node targeting the Registered Address prior to 777 answering. If the NUD succeeds, the operation in REACHABLE state 778 applies. If the NUD fails, the 6BBR refrains from answering the 779 lookup. The NUD expected to be mapped by the Registering Node 780 into a liveliness validation of the Registered Node if they are in 781 fact different nodes. 783 7. Security Considerations 785 This specification expects that the link layer is sufficiently 786 protected, either by means of physical or IP security for the 787 Backbone Link or MAC sublayer cryptography. In particular, it is 788 expected that the LLN MAC provides secure unicast to/from the 789 Backbone Router and secure Broadcast from the Backbone Router in a 790 way that prevents tempering with or replaying the RA messages. 792 The use of EUI-64 for forming the Interface ID in the link local 793 address prevents the usage of Secure ND ([RFC3971] and [RFC3972]) and 794 address privacy techniques. This specification RECOMMENDS the use of 795 additional protection against address theft such as provided by 796 [I-D.ietf-6lo-ap-nd], which guarantees the ownership of the OUID. 798 When the ownership of the OUID cannot be assessed, this specification 799 limits the cases where the OUID and the TID are multicasted, and 800 obfuscates them in responses to attempts to take over an address. 802 8. Protocol Constants 804 This Specification uses the following constants: 806 TENTATIVE_DURATION: 800 milliseconds 808 STABLE_STALE_DURATION: 24 hours 810 UNSTABLE_STALE_DURATION: 5 minutes 812 DEFAULT_NS_POLLING: 3 times 814 9. IANA Considerations 816 This document has no request to IANA. 818 10. Acknowledgments 820 Kudos to Eric Levy-Abegnoli who designed the First Hop Security 821 infrastructure at Cisco. 823 11. References 825 11.1. Normative References 827 [I-D.ietf-6lo-rfc6775-update] 828 Thubert, P., Nordmark, E., and S. Chakrabarti, "An Update 829 to 6LoWPAN ND", draft-ietf-6lo-rfc6775-update-06 (work in 830 progress), June 2017. 832 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 833 Requirement Levels", BCP 14, RFC 2119, 834 DOI 10.17487/RFC2119, March 1997, 835 . 837 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 838 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 839 2006, . 841 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 842 for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, 843 . 845 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 846 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 847 DOI 10.17487/RFC4861, September 2007, 848 . 850 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 851 Address Autoconfiguration", RFC 4862, 852 DOI 10.17487/RFC4862, September 2007, 853 . 855 [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for 856 Detecting Network Attachment in IPv6", RFC 6059, 857 DOI 10.17487/RFC6059, November 2010, 858 . 860 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 861 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 862 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 863 Low-Power and Lossy Networks", RFC 6550, 864 DOI 10.17487/RFC6550, March 2012, 865 . 867 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 868 Bormann, "Neighbor Discovery Optimization for IPv6 over 869 Low-Power Wireless Personal Area Networks (6LoWPANs)", 870 RFC 6775, DOI 10.17487/RFC6775, November 2012, 871 . 873 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 874 (IPv6) Specification", STD 86, RFC 8200, 875 DOI 10.17487/RFC8200, July 2017, 876 . 878 11.2. Informative References 880 [I-D.chakrabarti-nordmark-6man-efficient-nd] 881 Chakrabarti, S., Nordmark, E., Thubert, P., and M. 882 Wasserman, "IPv6 Neighbor Discovery Optimizations for 883 Wired and Wireless Networks", draft-chakrabarti-nordmark- 884 6man-efficient-nd-07 (work in progress), February 2015. 886 [I-D.delcarpio-6lo-wlanah] 887 Vega, L., Robles, I., and R. Morabito, "IPv6 over 888 802.11ah", draft-delcarpio-6lo-wlanah-01 (work in 889 progress), October 2015. 891 [I-D.ietf-6lo-ap-nd] 892 Sarikaya, B., Thubert, P., and M. Sethi, "Address 893 Protected Neighbor Discovery for Low-power and Lossy 894 Networks", draft-ietf-6lo-ap-nd-02 (work in progress), May 895 2017. 897 [I-D.ietf-6lo-nfc] 898 Choi, Y., Hong, Y., Youn, J., Kim, D., and J. Choi, 899 "Transmission of IPv6 Packets over Near Field 900 Communication", draft-ietf-6lo-nfc-07 (work in progress), 901 June 2017. 903 [I-D.ietf-6man-rs-refresh] 904 Nordmark, E., Yourtchenko, A., and S. Krishnan, "IPv6 905 Neighbor Discovery Optional RS/RA Refresh", draft-ietf- 906 6man-rs-refresh-02 (work in progress), October 2016. 908 [I-D.ietf-6tisch-architecture] 909 Thubert, P., "An Architecture for IPv6 over the TSCH mode 910 of IEEE 802.15.4", draft-ietf-6tisch-architecture-11 (work 911 in progress), January 2017. 913 [I-D.ietf-6tisch-terminology] 914 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 915 "Terminology in IPv6 over the TSCH mode of IEEE 916 802.15.4e", draft-ietf-6tisch-terminology-09 (work in 917 progress), June 2017. 919 [I-D.ietf-bier-architecture] 920 Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and 921 S. Aldrin, "Multicast using Bit Index Explicit 922 Replication", draft-ietf-bier-architecture-07 (work in 923 progress), June 2017. 925 [I-D.ietf-ipv6-multilink-subnets] 926 Thaler, D. and C. Huitema, "Multi-link Subnet Support in 927 IPv6", draft-ietf-ipv6-multilink-subnets-00 (work in 928 progress), July 2002. 930 [I-D.nordmark-6man-dad-approaches] 931 Nordmark, E., "Possible approaches to make DAD more robust 932 and/or efficient", draft-nordmark-6man-dad-approaches-02 933 (work in progress), October 2015. 935 [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks] 936 Popa, D. and J. Hui, "6LoPLC: Transmission of IPv6 Packets 937 over IEEE 1901.2 Narrowband Powerline Communication 938 Networks", draft-popa-6lo-6loplc-ipv6-over- 939 ieee19012-networks-00 (work in progress), March 2014. 941 [I-D.vyncke-6man-mcast-not-efficient] 942 Vyncke, E., Thubert, P., Levy-Abegnoli, E., and A. 943 Yourtchenko, "Why Network-Layer Multicast is Not Always 944 Efficient At Datalink Layer", draft-vyncke-6man-mcast-not- 945 efficient-01 (work in progress), February 2014. 947 [I-D.yourtchenko-6man-dad-issues] 948 Yourtchenko, A. and E. Nordmark, "A survey of issues 949 related to IPv6 Duplicate Address Detection", draft- 950 yourtchenko-6man-dad-issues-01 (work in progress), March 951 2015. 953 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 954 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 955 DOI 10.17487/RFC3810, June 2004, 956 . 958 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 959 "SEcure Neighbor Discovery (SEND)", RFC 3971, 960 DOI 10.17487/RFC3971, March 2005, 961 . 963 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 964 RFC 3972, DOI 10.17487/RFC3972, March 2005, 965 . 967 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 968 Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 969 2006, . 971 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 972 DOI 10.17487/RFC4903, June 2007, 973 . 975 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 976 over Low-Power Wireless Personal Area Networks (6LoWPANs): 977 Overview, Assumptions, Problem Statement, and Goals", 978 RFC 4919, DOI 10.17487/RFC4919, August 2007, 979 . 981 [RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, 982 Ed., "Control And Provisioning of Wireless Access Points 983 (CAPWAP) Protocol Specification", RFC 5415, 984 DOI 10.17487/RFC5415, March 2009, 985 . 987 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 988 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 989 2011, . 991 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 992 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 993 DOI 10.17487/RFC6282, September 2011, 994 . 996 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 997 Locator/ID Separation Protocol (LISP)", RFC 6830, 998 DOI 10.17487/RFC6830, January 2013, 999 . 1001 [RFC7048] Nordmark, E. and I. Gashinsky, "Neighbor Unreachability 1002 Detection Is Too Impatient", RFC 7048, 1003 DOI 10.17487/RFC7048, January 2014, 1004 . 1006 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 1007 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 1008 2014, . 1010 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 1011 Interface Identifiers with IPv6 Stateless Address 1012 Autoconfiguration (SLAAC)", RFC 7217, 1013 DOI 10.17487/RFC7217, April 2014, 1014 . 1016 [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets 1017 over ITU-T G.9959 Networks", RFC 7428, 1018 DOI 10.17487/RFC7428, February 2015, 1019 . 1021 [RFC7559] Krishnan, S., Anipko, D., and D. Thaler, "Packet-Loss 1022 Resiliency for Router Solicitations", RFC 7559, 1023 DOI 10.17487/RFC7559, May 2015, 1024 . 1026 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 1027 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 1028 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 1029 . 1031 [RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy 1032 Consumption of Router Advertisements", BCP 202, RFC 7772, 1033 DOI 10.17487/RFC7772, February 2016, 1034 . 1036 [RFC8105] Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt, 1037 M., and D. Barthel, "Transmission of IPv6 Packets over 1038 Digital Enhanced Cordless Telecommunications (DECT) Ultra 1039 Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May 1040 2017, . 1042 [RFC8163] Lynn, K., Ed., Martocci, J., Neilson, C., and S. 1043 Donaldson, "Transmission of IPv6 over Master-Slave/Token- 1044 Passing (MS/TP) Networks", RFC 8163, DOI 10.17487/RFC8163, 1045 May 2017, . 1047 11.3. External Informative References 1049 [IEEEstd8021] 1050 IEEE standard for Information Technology, "IEEE Standard 1051 for Information technology-- Telecommunications and 1052 information exchange between systems Local and 1053 metropolitan area networks Part 1: Bridging and 1054 Architecture". 1056 [IEEEstd80211] 1057 IEEE standard for Information Technology, "IEEE Standard 1058 for Information technology-- Telecommunications and 1059 information exchange between systems Local and 1060 metropolitan area networks-- Specific requirements Part 1061 11: Wireless LAN Medium Access Control (MAC) and Physical 1062 Layer (PHY) Specifications". 1064 [IEEEstd802151] 1065 IEEE standard for Information Technology, "IEEE Standard 1066 for Information Technology - Telecommunications and 1067 Information Exchange Between Systems - Local and 1068 Metropolitan Area Networks - Specific Requirements. - Part 1069 15.1: Wireless Medium Access Control (MAC) and Physical 1070 Layer (PHY) Specifications for Wireless Personal Area 1071 Networks (WPANs)". 1073 [IEEEstd802154] 1074 IEEE standard for Information Technology, "IEEE Standard 1075 for Local and metropolitan area networks-- Part 15.4: Low- 1076 Rate Wireless Personal Area Networks (LR-WPANs)". 1078 Appendix A. Requirements 1080 This section lists requirements that were discussed at 6lo for an 1081 update to 6LoWPAN ND. This specification meets most of them, but 1082 those listed in Appendix A.5 which are deferred to a different 1083 specification such as [I-D.ietf-6lo-ap-nd]. 1085 A.1. Requirements Related to Mobility 1087 Due to the unstable nature of LLN links, even in a LLN of immobile 1088 nodes a 6LoWPAN Node may change its point of attachment to a 6LR, say 1089 6LR-a, and may not be able to notify 6LR-a. Consequently, 6LR-a may 1090 still attract traffic that it cannot deliver any more. When links to 1091 a 6LR change state, there is thus a need to identify stale states in 1092 a 6LR and restore reachability in a timely fashion. 1094 Req1.1: Upon a change of point of attachment, connectivity via a new 1095 6LR MUST be restored timely without the need to de-register from the 1096 previous 6LR. 1098 Req1.2: For that purpose, the protocol MUST enable to differentiate 1099 between multiple registrations from one 6LoWPAN Node and 1100 registrations from different 6LoWPAN Nodes claiming the same address. 1102 Req1.3: Stale states MUST be cleaned up in 6LRs. 1104 Req1.4: A 6LoWPAN Node SHOULD also be capable to register its Address 1105 to multiple 6LRs, and this, concurrently. 1107 A.2. Requirements Related to Routing Protocols 1109 The point of attachment of a 6LoWPAN Node may be a 6LR in an LLN 1110 mesh. IPv6 routing in a LLN can be based on RPL, which is the 1111 routing protocol that was defined at the IETF for this particular 1112 purpose. Other routing protocols than RPL are also considered by 1113 Standard Defining Organizations (SDO) on the basis of the expected 1114 network characteristics. It is required that a 6LoWPAN Node attached 1115 via ND to a 6LR would need to participate in the selected routing 1116 protocol to obtain reachability via the 6LR. 1118 Next to the 6LBR unicast address registered by ND, other addresses 1119 including multicast addresses are needed as well. For example a 1120 routing protocol often uses a multicast address to register changes 1121 to established paths. ND needs to register such a multicast address 1122 to enable routing concurrently with discovery. 1124 Multicast is needed for groups. Groups MAY be formed by device type 1125 (e.g. routers, street lamps), location (Geography, RPL sub-tree), or 1126 both. 1128 The Bit Index Explicit Replication (BIER) Architecture 1129 [I-D.ietf-bier-architecture] proposes an optimized technique to 1130 enable multicast in a LLN with a very limited requirement for routing 1131 state in the nodes. 1133 Related requirements are: 1135 Req2.1: The ND registration method SHOULD be extended in such a 1136 fashion that the 6LR MAY advertise the Address of a 6LoWPAN Node over 1137 the selected routing protocol and obtain reachability to that Address 1138 using the selected routing protocol. 1140 Req2.2: Considering RPL, the Address Registration Option that is used 1141 in the ND registration SHOULD be extended to carry enough information 1142 to generate a DAO message as specified in [RFC6550] section 6.4, in 1143 particular the capability to compute a Path Sequence and, as an 1144 option, a RPLInstanceID. 1146 Req2.3: Multicast operations SHOULD be supported and optimized, for 1147 instance using BIER or MPL. Whether ND is appropriate for the 1148 registration to the 6BBR is to be defined, considering the additional 1149 burden of supporting the Multicast Listener Discovery Version 2 1150 [RFC3810] (MLDv2) for IPv6. 1152 A.3. Requirements Related to the Variety of Low-Power Link types 1154 6LoWPAN ND [RFC6775] was defined with a focus on IEEE std. 802.15.4 1155 and in particular the capability to derive a unique Identifier from a 1156 globally unique MAC-64 address. At this point, the 6lo Working Group 1157 is extending the 6LoWPAN Header Compression (HC) [RFC6282] technique 1158 to other link types ITU-T G.9959 [RFC7428], Master-Slave/Token- 1159 Passing [RFC8163], DECT Ultra Low Energy [RFC8105], Near Field 1160 Communication [I-D.ietf-6lo-nfc], IEEE std. 802.11ah 1161 [I-D.delcarpio-6lo-wlanah], as well as IEEE1901.2 Narrowband 1162 Powerline Communication Networks 1163 [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks] and BLUETOOTH(R) 1164 Low Energy [RFC7668]. 1166 Related requirements are: 1168 Req3.1: The support of the registration mechanism SHOULD be extended 1169 to more LLN links than IEEE 802.15.4, matching at least the LLN links 1170 for which an "IPv6 over foo" specification exists, as well as Low- 1171 Power Wi-Fi. 1173 Req3.2: As part of this extension, a mechanism to compute a unique 1174 Identifier should be provided, with the capability to form a Link- 1175 Local Address that SHOULD be unique at least within the LLN connected 1176 to a 6LBR discovered by ND in each node within the LLN. 1178 Req3.3: The Address Registration Option used in the ND registration 1179 SHOULD be extended to carry the relevant forms of unique Identifier. 1181 Req3.4: The Neighbour Discovery should specify the formation of a 1182 site-local address that follows the security recommendations from 1183 [RFC7217]. 1185 A.4. Requirements Related to Proxy Operations 1187 Duty-cycled devices may not be able to answer themselves to a lookup 1188 from a node that uses classical ND on a backbone and may need a 1189 proxy. Additionally, the duty-cycled device may need to rely on the 1190 6LBR to perform registration to the 6BBR. 1192 The ND registration method SHOULD defend the addresses of duty-cycled 1193 devices that are sleeping most of the time and not capable to defend 1194 their own Addresses. 1196 Related requirements are: 1198 Req4.1: The registration mechanism SHOULD enable a third party to 1199 proxy register an Address on behalf of a 6LoWPAN node that may be 1200 sleeping or located deeper in an LLN mesh. 1202 Req4.2: The registration mechanism SHOULD be applicable to a duty- 1203 cycled device regardless of the link type, and enable a 6BBR to 1204 operate as a proxy to defend the registered Addresses on its behalf. 1206 Req4.3: The registration mechanism SHOULD enable long sleep 1207 durations, in the order of multiple days to a month. 1209 A.5. Requirements Related to Security 1211 In order to guarantee the operations of the 6LoWPAN ND flows, the 1212 spoofing of the 6LR, 6LBR and 6BBRs roles should be avoided. Once a 1213 node successfully registers an address, 6LoWPAN ND should provide 1214 energy-efficient means for the 6LBR to protect that ownership even 1215 when the node that registered the address is sleeping. 1217 In particular, the 6LR and the 6LBR then should be able to verify 1218 whether a subsequent registration for a given Address comes from the 1219 original node. 1221 In a LLN it makes sense to base security on layer-2 security. During 1222 bootstrap of the LLN, nodes join the network after authorization by a 1223 Joining Assistant (JA) or a Commissioning Tool (CT). After joining 1224 nodes communicate with each other via secured links. The keys for 1225 the layer-2 security are distributed by the JA/CT. The JA/CT can be 1226 part of the LLN or be outside the LLN. In both cases it is needed 1227 that packets are routed between JA/CT and the joining node. 1229 Related requirements are: 1231 Req5.1: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for 1232 the 6LR, 6LBR and 6BBR to authenticate and authorize one another for 1233 their respective roles, as well as with the 6LoWPAN Node for the role 1234 of 6LR. 1236 Req5.2: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for 1237 the 6LR and the 6LBR to validate new registration of authorized 1238 nodes. Joining of unauthorized nodes MUST be impossible. 1240 Req5.3: 6LoWPAN ND security mechanisms SHOULD lead to small packet 1241 sizes. In particular, the NS, NA, DAR and DAC messages for a re- 1242 registration flow SHOULD NOT exceed 80 octets so as to fit in a 1243 secured IEEE std. 802.15.4 frame. 1245 Req5.4: Recurrent 6LoWPAN ND security operations MUST NOT be 1246 computationally intensive on the LoWPAN Node CPU. When a Key hash 1247 calculation is employed, a mechanism lighter than SHA-1 SHOULD be 1248 preferred. 1250 Req5.5: The number of Keys that the 6LoWPAN Node needs to manipulate 1251 SHOULD be minimized. 1253 Req5.6: The 6LoWPAN ND security mechanisms SHOULD enable CCM* for use 1254 at both Layer 2 and Layer 3, and SHOULD enable the reuse of security 1255 code that has to be present on the device for upper layer security 1256 such as TLS. 1258 Req5.7: Public key and signature sizes SHOULD be minimized while 1259 maintaining adequate confidentiality and data origin authentication 1260 for multiple types of applications with various degrees of 1261 criticality. 1263 Req5.8: Routing of packets should continue when links pass from the 1264 unsecured to the secured state. 1266 Req5.9: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for 1267 the 6LR and the 6LBR to validate whether a new registration for a 1268 given address corresponds to the same 6LoWPAN Node that registered it 1269 initially, and, if not, determine the rightful owner, and deny or 1270 clean-up the registration that is duplicate. 1272 A.6. Requirements Related to Scalability 1274 Use cases from Automatic Meter Reading (AMR, collection tree 1275 operations) and Advanced Metering Infrastructure (AMI, bi-directional 1276 communication to the meters) indicate the needs for a large number of 1277 LLN nodes pertaining to a single RPL DODAG (e.g. 5000) and connected 1278 to the 6LBR over a large number of LLN hops (e.g. 15). 1280 Related requirements are: 1282 Req6.1: The registration mechanism SHOULD enable a single 6LBR to 1283 register multiple thousands of devices. 1285 Req6.2: The timing of the registration operation should allow for a 1286 large latency such as found in LLNs with ten and more hops. 1288 Author's Address 1290 Pascal Thubert (editor) 1291 Cisco Systems, Inc 1292 Building D 1293 45 Allee des Ormes - BP1200 1294 MOUGINS - Sophia Antipolis 06254 1295 FRANCE 1297 Phone: +33 497 23 26 34 1298 Email: pthubert@cisco.com