idnits 2.17.1 draft-ietf-6lo-backbone-router-06.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 (February 23, 2018) is 2251 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 1058, but not defined == Missing Reference: 'IEEEstd80211' is mentioned on line 1065, but not defined == Missing Reference: 'IEEEstd802154' is mentioned on line 1082, but not defined == Missing Reference: 'IEEEstd802151' is mentioned on line 1073, but not defined == Outdated reference: A later version (-21) exists of draft-ietf-6lo-rfc6775-update-13 == Outdated reference: A later version (-23) exists of draft-ietf-6lo-ap-nd-06 == Outdated reference: A later version (-22) exists of draft-ietf-6lo-nfc-09 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-13 == Outdated reference: A later version (-10) exists of draft-ietf-6tisch-terminology-09 -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 0 errors (**), 0 flaws (~~), 10 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 February 23, 2018 5 Expires: August 27, 2018 7 IPv6 Backbone Router 8 draft-ietf-6lo-backbone-router-06 10 Abstract 12 This specification proposes proxy operations for IPv6 Neighbor 13 Discovery on behalf of devices located on broadcast-inefficient 14 wireless networks. A broadcast-efficient backbone running classical 15 IPv6 Neighbor Discovery federates multiple wireless links to form a 16 large MultiLink Subnet, but the broadcast domain does not need to 17 extend to the wireless links for the purpose of ND operation. 18 Backbone Routers placed at the wireless edge of the backbone proxy 19 the ND operation and route packets from/to registered nodes, and 20 wireless nodes register or are proxy-registered to the Backbone 21 Router to setup proxy services in a fashion that is essentially 22 similar to a classical 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 August 27, 2018. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 5. Backbone Router Routing Operations . . . . . . . . . . . . . 9 63 5.1. Over the Backbone Link . . . . . . . . . . . . . . . . . 10 64 5.2. Over the LLN Link . . . . . . . . . . . . . . . . . . . . 11 65 6. BackBone Router Proxy Operations . . . . . . . . . . . . . . 13 66 6.1. Registration and Binding State Creation . . . . . . . . . 15 67 6.2. Defending Addresses . . . . . . . . . . . . . . . . . . . 17 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 69 8. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 18 70 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 71 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 73 11.1. Normative References . . . . . . . . . . . . . . . . . . 19 74 11.2. Informative References . . . . . . . . . . . . . . . . . 20 75 11.3. External Informative References . . . . . . . . . . . . 23 76 Appendix A. Requirements . . . . . . . . . . . . . . . . . . . . 24 77 A.1. Requirements Related to Mobility . . . . . . . . . . . . 24 78 A.2. Requirements Related to Routing Protocols . . . . . . . . 25 79 A.3. Requirements Related to the Variety of Low-Power Link 80 types . . . . . . . . . . . . . . . . . . . . . . . . . . 26 81 A.4. Requirements Related to Proxy Operations . . . . . . . . 26 82 A.5. Requirements Related to Security . . . . . . . . . . . . 27 83 A.6. Requirements Related to Scalability . . . . . . . . . . . 28 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29 86 1. Introduction 88 One of the key services provided by IEEE std. 802.1 [IEEEstd8021] 89 Ethernet Bridging is an efficient and reliable broadcast service, and 90 multiple applications and protocols have been built that heavily 91 depend on that feature for their core operation. But a wide range of 92 wireless networks do not provide the solid and cheap broadcast 93 capabilities of Ethernet Bridging, and protocols designed for bridged 94 networks that rely on broadcast often exhibit disappointing 95 behaviours when applied unmodified to a wireless medium. 97 IEEE std. 802.11 [IEEEstd80211] Access Points (APs) deployed in an 98 Extended Service Set (ESS) effectively act as bridges, but, in order 99 to ensure a solid connectivity to the devices and protect the medium 100 against harmful broadcasts, they refrain from relying on broadcast- 101 intensive protocols such as Transparent Bridging on the wireless 102 side. Instead, an association process is used to register 103 proactively the MAC addresses of the wireless device (STA) to the AP, 104 and then the APs proxy the bridging operation and cancel the 105 broadcasts. 107 Classical IPv6 [RFC8200] Neighbor Discovery [RFC4861] [RFC4862] 108 Protocol (NDP) operations are reactive and rely heavily on multicast 109 operations to locate an on-link correspondent and ensure address 110 uniqueness, which is a pillar that sustains the whole IP 111 architecture. When the Duplicate Address Detection [RFC4862] (DAD) 112 mechanism was designed, it was a natural match with the efficient 113 broadcast operation of Ethernet Bridging, but with the unreliable 114 broadcast that is typical of wireless media, DAD is bound to fail to 115 discover duplications [I-D.yourtchenko-6man-dad-issues]. In other 116 words, because the broadcast service is unreliable, DAD appears to 117 work on wireless media not because address duplication is detected 118 and solved as designed, but because the duplication is a very rare 119 event as a side effect of the sheer amount of entropy in 64-bits 120 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 (EARO) defined in 349 [I-D.ietf-6lo-rfc6775-update] is used to enable the registration for 350 routing and proxy option is included in the ND exchanges over the 351 backbone between the 6BBRs to sort out duplication from movement. 353 Address duplication is sorted out with the Owner Unique-ID field in 354 the EARO, which is a generalization of the EUI-64 that allows 355 different types of unique IDs beyond the name space derived from the 356 MAC addresses. First-Come First-Serve rules apply, whether the 357 duplication happens between LLN nodes as represented by their 358 respective 6BBRs, or between an LLN node and a classical node that 359 defends its address over the backbone with classical ND and does not 360 include the EARO option. 362 In case of conflicting registrations to multiple 6BBRs from a same 363 node, a sequence counter called Transaction ID (TID) in the EARO 364 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. The EARO also transports a 'R' 369 flag to be used by a 6LN when registering, to indicate that this 6LN 370 is not a router and that it will not handle its own reachability. 372 With this specification, Backbone Routers perform a ND proxy 373 operation over the Backbone Link on behalf of their Registered Nodes. 374 The registration to the proxy service is done with a NS/NA(EARO) 375 exchange. The EARO option with a 'R' flag is used in this 376 specification to indicate to the 6BBR that it is expected to perform 377 this proxy operation. The Backbone Router operation is essentially 378 similar to that of a Mobile IPv6 (MIPv6) [RFC6275] Home Agent. This 379 enables mobility support for LLN nodes that would move outside of the 380 network delimited by the Backbone link attach to a Home Agent from 381 that point on. This also enables collocation of Home Agent 382 functionality within Backbone Router functionality on the same 383 backbone interface of a router. Further specification may extend 384 this be allowing the 6BBR to redistribute host routes in routing 385 protocols that would operate over the backbone, or in MIPv6 or the 386 Locator/ID Separation Protocol (LISP) [RFC6830] to support mobility 387 on behalf of the nodes, etc... 389 The Optimistic Duplicate Address Detection [RFC4429] (ODAD) 390 specification details how an address can be used before a Duplicate 391 Address Detection (DAD) is complete, and insists that an address that 392 is TENTATIVE should not be associated to a Source Link-Layer Address 393 Option in a Neighbor Solicitation message. This specification 394 leverages ODAD to create a temporary proxy state in the 6BBR till DAD 395 is completed over the backbone. This way, the specification enables 396 to distribute proxy states across multiple 6BBR and co-exist with 397 classical ND over the backbone. 399 5. Backbone Router Routing Operations 400 | 401 +-----+ 402 | | Other (default) Router 403 | | 404 +-----+ 405 | /64 406 | Backbone Link 407 +-------------------+-------------------+ 408 | /64 | /64 | /64 409 +-----+ +-----+ +-----+ 410 | | Backbone | | Backbone | | Backbone 411 | | router | | router | | router 412 +-----+ +-----+ +-----+ 413 o N*/128 o o o M*/128 o o P*/128 414 o o o o o o o o o o o o o o 415 o o o o o o o o o o o o o o o 416 o o o o o o o o o o 417 o o o o o o o 419 LLN LLN LLN 421 Figure 2: Routing Configuration in the ML Subnet 423 5.1. Over the Backbone Link 425 The Backbone Router is a specific kind of Border Router that performs 426 proxy Neighbor Discovery on its backbone interface on behalf of the 427 nodes that it has discovered on its LLN interfaces. 429 The backbone is expected to be a high speed, reliable Backbone link, 430 with affordable and reliable multicast capabilities, such as a 431 bridged Ethernet Network, and to allow a full support of classical ND 432 as specified in [RFC4861] and subsequent RFCs. In other words, the 433 backbone is not a LLN. 435 Still, some restrictions of the attached LLNs will apply to the 436 backbone. In particular, it is expected that the MTU is set to the 437 same value on the backbone and all attached LLNs, and the scalability 438 of the whole subnet requires that broadcast operations are avoided as 439 much as possible on the backbone as well. Unless configured 440 otherwise, the Backbone Router MUST echo the MTU that it learns in 441 RAs over the backbone in the RAs that it sends towards the LLN links. 443 As a router, the Backbone Router behaves like any other IPv6 router 444 on the backbone side. It has a connected route installed towards the 445 backbone for the prefixes that are present on that backbone and that 446 it proxies for on the LLN interfaces. 448 As a proxy, the 6BBR uses an EARO option in the NS-DAD and the 449 multicast NA messages that it generates over the Backbone Link on 450 behalf of a Registered Node, and it places an EARO in its unicast NA 451 messages, if and only if the NS/NA that stimulates it had an EARO in 452 it and the 'R' bit set. 454 When possible, the 6BBR SHOULD use unicast or solicited-node 455 multicast address (SNMA) [RFC4291] to defend its Registered Addresses 456 over the backbone. In particular, the 6BBR MUST join the SNMA group 457 that corresponds to a Registered Address as soon as it creates an 458 entry for that address and as long as it maintains that entry, 459 whatever the state of the entry. The expectation is that it is 460 possible to get a message delivered to all the nodes on the backbone 461 that listen to a particular address and support this specification - 462 which includes all the 6BBRs in the MultiLink Subnet - by sending a 463 multicast message to the associated SNMA over the backbone. 465 The support of Optimistic DAD (ODAD) [RFC4429] is recommended for all 466 nodes in the backbone and followed by the 6BBRs in their proxy 467 activity over the backbone. With ODAD, any optimistic node MUST join 468 the SNMA of a Tentative address, which interacts better with this 469 specification. 471 This specification allows the 6BBR in Routing Proxy mode to advertise 472 the Registered IPv6 Address with the 6BBR Link Layer Address, and 473 attempts to update Neighbor Cache Entries (NCE) in correspondent 474 nodes over the backbone, using gratuitous NA(Override). This method 475 may fail of the multicast message is not properly received, and 476 correspondent nodes may maintain an incorrect neighbor state, which 477 they will eventually discover through Neighbor Unreachability 478 Detection (NUD). Because mobility may be slow, the NUD procedure 479 defined in [RFC4861] may be too impatient, and the support of 480 [RFC7048] is recommended in all nodes in the network. 482 Since the MultiLink Subnet may grow very large in terms of individual 483 IPv6 addresses, multicasts should be avoided as much as possible even 484 on the backbone. Though it is possible for plain hosts to 485 participate with legacy IPv6 ND support, the support by all nodes 486 connected to the backbone of [I-D.ietf-6man-rs-refresh] is 487 recommended, and this implies the support of [RFC7559] as well. 489 5.2. Over the LLN Link 491 As a router, the Nodes and Backbone Router operation on the LLN 492 follows [RFC6775]. Per that specification, LLN Hosts generally do 493 not depend on multicast RAs to discover routers. It is still 494 generally required for LLN nodes to accept multicast RAs [RFC7772], 495 but those are rare on the LLN link. Nodes are expected to follow the 496 Simple Procedures for Detecting Network Attachment in IPv6 [RFC6059] 497 (DNA procedures) to assert movements, and to support the Packet-Loss 498 Resiliency for Router Solicitations [RFC7559] to make the unicast RS 499 more reliable. 501 An LLN node signals that it requires IPv6 ND proxy services from a 502 6BBR by registering the corresponding IPv6 Address with an NS(EARO) 503 message with the 'R' flag set. The LLN node that performs the 504 registration (the Registering Node) may be the owner of the IPv6 505 Address (the Registered Node) or a 6LBR that performs the 506 registration on its behalf. 508 When operating as a Routing Proxy, the router installs hosts routes 509 (/128) to the Registered Addresses over the LLN links, via the 510 Registering Node as identified by the Source Address and the SLLAO 511 option in the NS(EARO) messages. 513 In that mode, the 6BBR handles the ND protocol over the backbone on 514 behalf of the Registered Nodes, using its own MAC address in the TLLA 515 and SLLA options in proxyed NS and NA messages. It results that for 516 each Registered Address, a number of peer Nodes on the backbone have 517 resolved the address with the 6BBR MAC address and keep that mapping 518 stored in their Neighbor cache. 520 The 6BBR SHOULD maintain, per Registered Address, the list of the 521 peers on the backbone to which it answered with it MAC address, and 522 when a binding moves to a different 6BBR, it SHOULD send a unicast 523 gratuitous NA(O) individually to each of them to inform them that the 524 address has moved and pass the MAC address of the new 6BBR in the 525 TLLAO option. If the 6BBR can not maintain that list, then it SHOULD 526 remember whether that list is empty or not and if not, send a 527 multicast NA(O) to all nodes to update the impacted Neighbor Caches 528 with the information from the new 6BBR. 530 The Bridging Proxy is a variation where the BBR function is 531 implemented in a Layer-3 switch or an wireless Access Point that acts 532 as a Host from the IPv6 standpoint, and, in particular, does not 533 operate the routing of IPv6 packets. In that case, the SLLAO in the 534 proxied NA messages is that of the Registering Node and classical 535 bridging operations take place on data frames. 537 If a registration moves from one 6BBR to the next, but the 538 Registering Node does not change, as indicated by the S/TLLAO option 539 in the ND exchanges, there is no need to update the Neighbor Caches 540 in the peers Nodes on the backbone. On the other hand, if the LLAO 541 changes, the 6BBR SHOULD inform all the relevant peers as described 542 above, to update the impacted Neighbor Caches. In the same fashion, 543 if the Registering Node changes with a new registration, the 6BBR 544 SHOULD also update the impacted Neighbor Caches over the backbone. 546 6. BackBone Router Proxy Operations 548 This specification enables a Backbone Router to proxy Neighbor 549 Discovery operations over the backbone on behalf of the nodes that 550 are registered to it, allowing any node on the backbone to reach a 551 Registered Node as if it was on-link. The backbone and the LLNs are 552 considered different Links in a MultiLink subnet but the prefix that 553 is used may still be advertised as on-link on the backbone to support 554 legacy nodes; multicast ND messages are link-scoped and not forwarded 555 across the backbone routers. 557 ND Messages on the backbone side that do not match to a registration 558 on the LLN side are not acted upon on the LLN side, which stands 559 protected. On the LLN side, the prefixes associated to the MultiLink 560 Subnet are presented as not on-link, so address resolution for other 561 hosts do not occur. 563 The default operation in this specification is Sleeping proxy which 564 means: 566 o creating a new entry in an abstract Binding Table for a new 567 Registered Address and validating that the address is not a 568 duplicate over the backbone 570 o defending a Registered Address over the backbone using NA messages 571 with the Override bit set on behalf of the sleeping node whenever 572 possible 574 o advertising a Registered Address over the backbone using NA 575 messages, asynchronously or as a response to a Neighbor 576 Solicitation messages. 578 o Looking up a destination over the backbone in order to deliver 579 packets arriving from the LLN using Neighbor Solicitation 580 messages. 582 o Forwarding packets from the LLN over the backbone, and the other 583 way around. 585 o Eventually triggering a liveliness verification of a stale 586 registration. 588 A 6BBR may act as a Sleeping Proxy only if the state of the binding 589 entry is REACHABLE, or TENTATIVE in which case the answer is delayed. 591 In any other state, the Sleeping Proxy operates as a Unicasting 592 Proxy. 594 As a Unicasting Proxy, the 6BBR forwards NS lookup messages to the 595 Registering Node, transforming Layer-2 multicast into unicast 596 whenever possible. This is not possible in UNREACHABLE state, so the 597 NS messages are multicasted, and rate-limited to protect the medium 598 with an exponential back-off. In other states, The messages are 599 forwarded to the Registering Node as unicast Layer-2 messages. In 600 TENTATIVE state, the NS message is either held till DAD completes, or 601 dropped. 603 The draft introduces the optional concept of primary and secondary 604 BBRs. The primary is the backbone router that has the highest EUI-64 605 address of all the 6BBRs that share a registration for a same 606 Registered Address, with the same Owner Unique ID and same 607 Transaction ID, the EUI-64 address being considered as an unsigned 608 64bit integer. The concept is defined with the granularity of an 609 address, that is a given 6BBR can be primary for a given address and 610 secondary or another one, regardless on whether the addresses belong 611 to the same node or not. The primary Backbone Router is in charge of 612 protecting the address for DAD over the Backbone. Any of the Primary 613 and Secondary 6BBR may claim the address over the backbone, since 614 they are all capable to route from the backbone to the LLN node, and 615 the address appears on the backbone as an anycast address. 617 The Backbone Routers maintain a distributed binding table, using 618 classical ND over the backbone to detect duplication. This 619 specification requires that: 621 1. All addresses that can be reachable from the backbone, including 622 IPv6 addresses based on burn-in EUI64 addresses MUST be 623 registered to the 6BBR. 625 2. A Registered Node MUST include the EARO option in an NS message 626 that used to register an addresses to a 6LR; the 6LR MUST 627 propagate that option unchanged to the 6LBR in the DAR/DAC 628 exchange, and the 6LBR MUST propagate that option unchanged in 629 proxy registrations. 631 3. The 6LR MUST echo the same EARO option in the NA that it uses to 632 respond, but for the status filed which is not used in NS 633 messages, and significant in NA. 635 A false positive duplicate detection may arise over the backbone, for 636 instance if the Registered Address is registered to more than one 637 LBR, or if the node has moved. Both situations are handled 638 gracefully unbeknownst to the node. In the former case, one LBR 639 becomes primary to defend the address over the backbone while the 640 others become secondary and may still forward packets back and forth. 641 In the latter case the LBR that receives the newest registration wins 642 and becomes primary. 644 The expectation in this specification is that there is a single 645 Registering Node at a time per Backbone Router for a given Registered 646 Address, but that a Registered Address may be registered to Multiple 647 6BBRs for higher availability. 649 Over the LLN, and for any given Registered Address, it is REQUIRED 650 that: 652 de-registrations (newer TID, same OUID, null Lifetime) are 653 accepted and responded immediately with a status of 4; the entry 654 is deleted; 656 newer registrations (newer TID, same OUID, non-null Lifetime) are 657 accepted and responded with a status of 0 (success); the entry is 658 updated with the new TID, the new Registration Lifetime and the 659 new Registering Node, if any has changed; in TENTATIVE state the 660 response is held and may be overwritten; in other states the 661 Registration-Lifetime timer is restarted and the entry is placed 662 in REACHABLE state. 664 identical registrations (same TID, same OUID) from a same 665 Registering Node are not processed but responded with a status of 666 0 (success); they are expected to be identical and an error may be 667 logged if not; in TENTATIVE state, the response is held and may be 668 overwritten, but it MUST be eventually produced and it carries the 669 result of the DAD process; 671 older registrations (not(newer or equal) TID, same OUID) from a 672 same Registering Node are ignored; 674 identical and older registrations (not-newer TID, same OUID) from 675 a different Registering Node are responded immediately with a 676 status of 3 (moved); this may be rate limited to protect the 677 medium; 679 and any registration for a different Registered Node (different 680 OUID) are responded immediately with a status of 1 (duplicate). 682 6.1. Registration and Binding State Creation 684 Upon a registration for a new address with an NS(EARO) with the 'R' 685 bit set, the 6BBR performs a DAD operation over the backbone placing 686 the new address as target in the NS-DAD message. The EARO from the 687 registration MUST be placed unchanged in the NS-DAD message, and an 688 entry is created in TENTATIVE state for a duration of 689 TENTATIVE_DURATION. The NS-DAD message is sent multicast over the 690 backbone to the SNMA address associated with the registered address. 691 If that operation is known to be costly, and the 6BBR has an 692 indication from another source (such as a NCE) that the Registered 693 Address was present on the backbone, that information may be 694 leveraged to send the NS-DAD message as a Layer-2 unicast to the MAC 695 that was associated with the Registered Address. 697 In TENTATIVE state: 699 o the entry is removed if an NA is received over the backbone for 700 the Registered Address with no EARO option, or with an EARO option 701 with a status of 1 (duplicate) that indicates an existing 702 registration for another LLN node. The OUID and TID fields in the 703 EARO option received over the backbone are ignored. A status of 1 704 is returned in the EARO option of the NA back to the Registering 705 Node; 707 o the entry is also removed if an NA with an ARO option with a 708 status of 3 (moved), or a NS-DAD with an ARO option that indicates 709 a newer registration for the same Registered Node, is received 710 over the backbone for the Registered Address. A status of 3 is 711 returned in the NA(EARO) back to the Registering Node; 713 o when a registration is updated but not deleted, e.g. from a newer 714 registration, the DAD process on the backbone continues and the 715 running timers are not restarted; 717 o Other NS (including DAD with no EARO option) and NA from the 718 backbone are not responded in TENTATIVE state, but the list of 719 their origins may be kept in memory and if so, the 6BBR may send 720 them each a unicast NA with eventually an EARO option when the 721 TENTATIVE_DURATION timer elapses, so as to cover legacy nodes that 722 do not support ODAD. 724 o When the TENTATIVE_DURATION timer elapses, a status 0 (success) is 725 returned in a NA(EARO) back to the Registering Node(s), and the 726 entry goes to REACHABLE state for the Registration Lifetime; the 727 DAD process is successful and the 6BBR MUST send a multicast 728 NA(EARO) to the SNMA associated to the Registered Address over the 729 backbone with the Override bit set so as to take over the binding 730 from other 6BBRs. 732 6.2. Defending Addresses 734 If a 6BBR has an entry in REACHABLE state for a Registered Address: 736 o If the 6BBR is primary, or does not support the function of 737 primary, it MUST defend that address over the backbone upon an 738 incoming NS-DAD, either if the NS does not carry an EARO, or if an 739 EARO is present that indicates a different Registering Node 740 (different OUID). The 6BBR sends a NA message with the Override 741 bit set and the NA carries an EARO option if and only if the NS- 742 DAD did so. When present, the EARO in the NA(O) that is sent in 743 response to the NS-DAD(EARO) carries a status of 1 (duplicate), 744 and the OUID and TID fields in the EARO option are obfuscated with 745 null or random values to avoid network scanning and impersonation 746 attacks. 748 o If the 6BBR receives an NS-DAD(EARO) that reflect a newer 749 registration, the 6BBR updates the entry and the routing state to 750 forward packets to the new 6BBR, but keeps the entry REACHABLE. 751 In that phase, it MAY use REDIRECT messages to reroute traffic for 752 the Registered Address to the new 6BBR. 754 o If the 6BBR receives an NA(EARO) that reflect a newer 755 registration, the 6BBR removes its entry and sends a NA(AERO) with 756 a status of 3 (moved) to the Registering Node, if the Registering 757 Node is different from the Registered Node. If necessary, the 758 6BBR cleans up ND cache in peers nodes as discussed in 759 Section 5.1, by sending a series of unicast to the impacted nodes, 760 or one broadcast NA(O) to all-nodes. 762 o If the 6BBR received a NS(LOOKUP) for a Registered Address, it 763 answers immediately with an NA on behalf of the Registered Node, 764 without polling it. There is no need of an EARO in that exchange. 766 o When the Registration-Lifetime timer elapses, the entry goes to 767 STALE state for a duration of STABLE_STALE_DURATION in LLNs that 768 keep stable addresses such as LWPANs, and UNSTABLE_STALE_DURATION 769 in LLNs where addresses are renewed rapidly, e.g. for privacy 770 reasons. 772 The STALE state is a chance to keep track of the backbone peers that 773 may have an ND cache pointing on this 6BBR in case the Registered 774 Address shows back up on this or a different 6BBR at a later time. 775 In STALE state: 777 o If the Registered Address is claimed by another node on the 778 backbone, with an NS-DAD or an NA, the 6BBR does not defend the 779 address. Upon an NA(O), or the stale time elapses, the 6BBR 780 removes its entry and sends a NA(AERO) with a status of 4 781 (removed) to the Registering Node. 783 o If the 6BBR received a NS(LOOKUP) for a Registered Address, the 784 6BBR MUST send an NS(NUD) following rules in [RFC7048] to the 785 Registering Node targeting the Registered Address prior to 786 answering. If the NUD succeeds, the operation in REACHABLE state 787 applies. If the NUD fails, the 6BBR refrains from answering the 788 lookup. The NUD expected to be mapped by the Registering Node 789 into a liveliness validation of the Registered Node if they are in 790 fact different nodes. 792 7. Security Considerations 794 This specification expects that the link layer is sufficiently 795 protected, either by means of physical or IP security for the 796 Backbone Link or MAC sublayer cryptography. In particular, it is 797 expected that the LLN MAC provides secure unicast to/from the 798 Backbone Router and secure Broadcast from the Backbone Router in a 799 way that prevents tempering with or replaying the RA messages. 801 The use of EUI-64 for forming the Interface ID in the link local 802 address prevents the usage of Secure ND ([RFC3971] and [RFC3972]) and 803 address privacy techniques. This specification RECOMMENDS the use of 804 additional protection against address theft such as provided by 805 [I-D.ietf-6lo-ap-nd], which guarantees the ownership of the OUID. 807 When the ownership of the OUID cannot be assessed, this specification 808 limits the cases where the OUID and the TID are multicasted, and 809 obfuscates them in responses to attempts to take over an address. 811 8. Protocol Constants 813 This Specification uses the following constants: 815 TENTATIVE_DURATION: 800 milliseconds 817 STABLE_STALE_DURATION: 24 hours 819 UNSTABLE_STALE_DURATION: 5 minutes 821 DEFAULT_NS_POLLING: 3 times 823 9. IANA Considerations 825 This document has no request to IANA. 827 10. Acknowledgments 829 Kudos to Eric Levy-Abegnoli who designed the First Hop Security 830 infrastructure at Cisco. 832 11. References 834 11.1. Normative References 836 [I-D.ietf-6lo-rfc6775-update] 837 Thubert, P., Nordmark, E., Chakrabarti, S., and C. 838 Perkins, "An Update to 6LoWPAN ND", draft-ietf-6lo- 839 rfc6775-update-13 (work in progress), February 2018. 841 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 842 Requirement Levels", BCP 14, RFC 2119, 843 DOI 10.17487/RFC2119, March 1997, 844 . 846 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 847 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 848 2006, . 850 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 851 for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, 852 . 854 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 855 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 856 DOI 10.17487/RFC4861, September 2007, 857 . 859 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 860 Address Autoconfiguration", RFC 4862, 861 DOI 10.17487/RFC4862, September 2007, 862 . 864 [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for 865 Detecting Network Attachment in IPv6", RFC 6059, 866 DOI 10.17487/RFC6059, November 2010, 867 . 869 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 870 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 871 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 872 Low-Power and Lossy Networks", RFC 6550, 873 DOI 10.17487/RFC6550, March 2012, 874 . 876 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 877 Bormann, "Neighbor Discovery Optimization for IPv6 over 878 Low-Power Wireless Personal Area Networks (6LoWPANs)", 879 RFC 6775, DOI 10.17487/RFC6775, November 2012, 880 . 882 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 883 (IPv6) Specification", STD 86, RFC 8200, 884 DOI 10.17487/RFC8200, July 2017, 885 . 887 11.2. Informative References 889 [I-D.chakrabarti-nordmark-6man-efficient-nd] 890 Chakrabarti, S., Nordmark, E., Thubert, P., and M. 891 Wasserman, "IPv6 Neighbor Discovery Optimizations for 892 Wired and Wireless Networks", draft-chakrabarti-nordmark- 893 6man-efficient-nd-07 (work in progress), February 2015. 895 [I-D.delcarpio-6lo-wlanah] 896 Vega, L., Robles, I., and R. Morabito, "IPv6 over 897 802.11ah", draft-delcarpio-6lo-wlanah-01 (work in 898 progress), October 2015. 900 [I-D.ietf-6lo-ap-nd] 901 Thubert, P., Sarikaya, B., and M. Sethi, "Address 902 Protected Neighbor Discovery for Low-power and Lossy 903 Networks", draft-ietf-6lo-ap-nd-06 (work in progress), 904 February 2018. 906 [I-D.ietf-6lo-nfc] 907 Choi, Y., Hong, Y., Youn, J., Kim, D., and J. Choi, 908 "Transmission of IPv6 Packets over Near Field 909 Communication", draft-ietf-6lo-nfc-09 (work in progress), 910 January 2018. 912 [I-D.ietf-6man-rs-refresh] 913 Nordmark, E., Yourtchenko, A., and S. Krishnan, "IPv6 914 Neighbor Discovery Optional RS/RA Refresh", draft-ietf- 915 6man-rs-refresh-02 (work in progress), October 2016. 917 [I-D.ietf-6tisch-architecture] 918 Thubert, P., "An Architecture for IPv6 over the TSCH mode 919 of IEEE 802.15.4", draft-ietf-6tisch-architecture-13 (work 920 in progress), November 2017. 922 [I-D.ietf-6tisch-terminology] 923 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 924 "Terminology in IPv6 over the TSCH mode of IEEE 925 802.15.4e", draft-ietf-6tisch-terminology-09 (work in 926 progress), June 2017. 928 [I-D.ietf-bier-architecture] 929 Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and 930 S. Aldrin, "Multicast using Bit Index Explicit 931 Replication", draft-ietf-bier-architecture-08 (work in 932 progress), September 2017. 934 [I-D.ietf-ipv6-multilink-subnets] 935 Thaler, D. and C. Huitema, "Multi-link Subnet Support in 936 IPv6", draft-ietf-ipv6-multilink-subnets-00 (work in 937 progress), July 2002. 939 [I-D.nordmark-6man-dad-approaches] 940 Nordmark, E., "Possible approaches to make DAD more robust 941 and/or efficient", draft-nordmark-6man-dad-approaches-02 942 (work in progress), October 2015. 944 [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks] 945 Popa, D. and J. Hui, "6LoPLC: Transmission of IPv6 Packets 946 over IEEE 1901.2 Narrowband Powerline Communication 947 Networks", draft-popa-6lo-6loplc-ipv6-over- 948 ieee19012-networks-00 (work in progress), March 2014. 950 [I-D.vyncke-6man-mcast-not-efficient] 951 Vyncke, E., Thubert, P., Levy-Abegnoli, E., and A. 952 Yourtchenko, "Why Network-Layer Multicast is Not Always 953 Efficient At Datalink Layer", draft-vyncke-6man-mcast-not- 954 efficient-01 (work in progress), February 2014. 956 [I-D.yourtchenko-6man-dad-issues] 957 Yourtchenko, A. and E. Nordmark, "A survey of issues 958 related to IPv6 Duplicate Address Detection", draft- 959 yourtchenko-6man-dad-issues-01 (work in progress), March 960 2015. 962 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 963 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 964 DOI 10.17487/RFC3810, June 2004, 965 . 967 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 968 "SEcure Neighbor Discovery (SEND)", RFC 3971, 969 DOI 10.17487/RFC3971, March 2005, 970 . 972 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 973 RFC 3972, DOI 10.17487/RFC3972, March 2005, 974 . 976 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 977 Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 978 2006, . 980 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 981 DOI 10.17487/RFC4903, June 2007, 982 . 984 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 985 over Low-Power Wireless Personal Area Networks (6LoWPANs): 986 Overview, Assumptions, Problem Statement, and Goals", 987 RFC 4919, DOI 10.17487/RFC4919, August 2007, 988 . 990 [RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, 991 Ed., "Control And Provisioning of Wireless Access Points 992 (CAPWAP) Protocol Specification", RFC 5415, 993 DOI 10.17487/RFC5415, March 2009, 994 . 996 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 997 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 998 2011, . 1000 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 1001 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1002 DOI 10.17487/RFC6282, September 2011, 1003 . 1005 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 1006 Locator/ID Separation Protocol (LISP)", RFC 6830, 1007 DOI 10.17487/RFC6830, January 2013, 1008 . 1010 [RFC7048] Nordmark, E. and I. Gashinsky, "Neighbor Unreachability 1011 Detection Is Too Impatient", RFC 7048, 1012 DOI 10.17487/RFC7048, January 2014, 1013 . 1015 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 1016 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 1017 2014, . 1019 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 1020 Interface Identifiers with IPv6 Stateless Address 1021 Autoconfiguration (SLAAC)", RFC 7217, 1022 DOI 10.17487/RFC7217, April 2014, 1023 . 1025 [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets 1026 over ITU-T G.9959 Networks", RFC 7428, 1027 DOI 10.17487/RFC7428, February 2015, 1028 . 1030 [RFC7559] Krishnan, S., Anipko, D., and D. Thaler, "Packet-Loss 1031 Resiliency for Router Solicitations", RFC 7559, 1032 DOI 10.17487/RFC7559, May 2015, 1033 . 1035 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 1036 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 1037 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 1038 . 1040 [RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy 1041 Consumption of Router Advertisements", BCP 202, RFC 7772, 1042 DOI 10.17487/RFC7772, February 2016, 1043 . 1045 [RFC8105] Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt, 1046 M., and D. Barthel, "Transmission of IPv6 Packets over 1047 Digital Enhanced Cordless Telecommunications (DECT) Ultra 1048 Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May 1049 2017, . 1051 [RFC8163] Lynn, K., Ed., Martocci, J., Neilson, C., and S. 1052 Donaldson, "Transmission of IPv6 over Master-Slave/Token- 1053 Passing (MS/TP) Networks", RFC 8163, DOI 10.17487/RFC8163, 1054 May 2017, . 1056 11.3. External Informative References 1058 [IEEEstd8021] 1059 IEEE standard for Information Technology, "IEEE Standard 1060 for Information technology-- Telecommunications and 1061 information exchange between systems Local and 1062 metropolitan area networks Part 1: Bridging and 1063 Architecture". 1065 [IEEEstd80211] 1066 IEEE standard for Information Technology, "IEEE Standard 1067 for Information technology-- Telecommunications and 1068 information exchange between systems Local and 1069 metropolitan area networks-- Specific requirements Part 1070 11: Wireless LAN Medium Access Control (MAC) and Physical 1071 Layer (PHY) Specifications". 1073 [IEEEstd802151] 1074 IEEE standard for Information Technology, "IEEE Standard 1075 for Information Technology - Telecommunications and 1076 Information Exchange Between Systems - Local and 1077 Metropolitan Area Networks - Specific Requirements. - Part 1078 15.1: Wireless Medium Access Control (MAC) and Physical 1079 Layer (PHY) Specifications for Wireless Personal Area 1080 Networks (WPANs)". 1082 [IEEEstd802154] 1083 IEEE standard for Information Technology, "IEEE Standard 1084 for Local and metropolitan area networks-- Part 15.4: Low- 1085 Rate Wireless Personal Area Networks (LR-WPANs)". 1087 Appendix A. Requirements 1089 This section lists requirements that were discussed at 6lo for an 1090 update to 6LoWPAN ND. This specification meets most of them, but 1091 those listed in Appendix A.5 which are deferred to a different 1092 specification such as [I-D.ietf-6lo-ap-nd]. 1094 A.1. Requirements Related to Mobility 1096 Due to the unstable nature of LLN links, even in a LLN of immobile 1097 nodes a 6LoWPAN Node may change its point of attachment to a 6LR, say 1098 6LR-a, and may not be able to notify 6LR-a. Consequently, 6LR-a may 1099 still attract traffic that it cannot deliver any more. When links to 1100 a 6LR change state, there is thus a need to identify stale states in 1101 a 6LR and restore reachability in a timely fashion. 1103 Req1.1: Upon a change of point of attachment, connectivity via a new 1104 6LR MUST be restored timely without the need to de-register from the 1105 previous 6LR. 1107 Req1.2: For that purpose, the protocol MUST enable to differentiate 1108 between multiple registrations from one 6LoWPAN Node and 1109 registrations from different 6LoWPAN Nodes claiming the same address. 1111 Req1.3: Stale states MUST be cleaned up in 6LRs. 1113 Req1.4: A 6LoWPAN Node SHOULD also be capable to register its Address 1114 to multiple 6LRs, and this, concurrently. 1116 A.2. Requirements Related to Routing Protocols 1118 The point of attachment of a 6LoWPAN Node may be a 6LR in an LLN 1119 mesh. IPv6 routing in a LLN can be based on RPL, which is the 1120 routing protocol that was defined at the IETF for this particular 1121 purpose. Other routing protocols than RPL are also considered by 1122 Standard Defining Organizations (SDO) on the basis of the expected 1123 network characteristics. It is required that a 6LoWPAN Node attached 1124 via ND to a 6LR would need to participate in the selected routing 1125 protocol to obtain reachability via the 6LR. 1127 Next to the 6LBR unicast address registered by ND, other addresses 1128 including multicast addresses are needed as well. For example a 1129 routing protocol often uses a multicast address to register changes 1130 to established paths. ND needs to register such a multicast address 1131 to enable routing concurrently with discovery. 1133 Multicast is needed for groups. Groups MAY be formed by device type 1134 (e.g. routers, street lamps), location (Geography, RPL sub-tree), or 1135 both. 1137 The Bit Index Explicit Replication (BIER) Architecture 1138 [I-D.ietf-bier-architecture] proposes an optimized technique to 1139 enable multicast in a LLN with a very limited requirement for routing 1140 state in the nodes. 1142 Related requirements are: 1144 Req2.1: The ND registration method SHOULD be extended in such a 1145 fashion that the 6LR MAY advertise the Address of a 6LoWPAN Node over 1146 the selected routing protocol and obtain reachability to that Address 1147 using the selected routing protocol. 1149 Req2.2: Considering RPL, the Address Registration Option that is used 1150 in the ND registration SHOULD be extended to carry enough information 1151 to generate a DAO message as specified in [RFC6550] section 6.4, in 1152 particular the capability to compute a Path Sequence and, as an 1153 option, a RPLInstanceID. 1155 Req2.3: Multicast operations SHOULD be supported and optimized, for 1156 instance using BIER or MPL. Whether ND is appropriate for the 1157 registration to the 6BBR is to be defined, considering the additional 1158 burden of supporting the Multicast Listener Discovery Version 2 1159 [RFC3810] (MLDv2) for IPv6. 1161 A.3. Requirements Related to the Variety of Low-Power Link types 1163 6LoWPAN ND [RFC6775] was defined with a focus on IEEE std. 802.15.4 1164 and in particular the capability to derive a unique Identifier from a 1165 globally unique MAC-64 address. At this point, the 6lo Working Group 1166 is extending the 6LoWPAN Header Compression (HC) [RFC6282] technique 1167 to other link types ITU-T G.9959 [RFC7428], Master-Slave/Token- 1168 Passing [RFC8163], DECT Ultra Low Energy [RFC8105], Near Field 1169 Communication [I-D.ietf-6lo-nfc], IEEE std. 802.11ah 1170 [I-D.delcarpio-6lo-wlanah], as well as IEEE1901.2 Narrowband 1171 Powerline Communication Networks 1172 [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks] and BLUETOOTH(R) 1173 Low Energy [RFC7668]. 1175 Related requirements are: 1177 Req3.1: The support of the registration mechanism SHOULD be extended 1178 to more LLN links than IEEE 802.15.4, matching at least the LLN links 1179 for which an "IPv6 over foo" specification exists, as well as Low- 1180 Power Wi-Fi. 1182 Req3.2: As part of this extension, a mechanism to compute a unique 1183 Identifier should be provided, with the capability to form a Link- 1184 Local Address that SHOULD be unique at least within the LLN connected 1185 to a 6LBR discovered by ND in each node within the LLN. 1187 Req3.3: The Address Registration Option used in the ND registration 1188 SHOULD be extended to carry the relevant forms of unique Identifier. 1190 Req3.4: The Neighbour Discovery should specify the formation of a 1191 site-local address that follows the security recommendations from 1192 [RFC7217]. 1194 A.4. Requirements Related to Proxy Operations 1196 Duty-cycled devices may not be able to answer themselves to a lookup 1197 from a node that uses classical ND on a backbone and may need a 1198 proxy. Additionally, the duty-cycled device may need to rely on the 1199 6LBR to perform registration to the 6BBR. 1201 The ND registration method SHOULD defend the addresses of duty-cycled 1202 devices that are sleeping most of the time and not capable to defend 1203 their own Addresses. 1205 Related requirements are: 1207 Req4.1: The registration mechanism SHOULD enable a third party to 1208 proxy register an Address on behalf of a 6LoWPAN node that may be 1209 sleeping or located deeper in an LLN mesh. 1211 Req4.2: The registration mechanism SHOULD be applicable to a duty- 1212 cycled device regardless of the link type, and enable a 6BBR to 1213 operate as a proxy to defend the registered Addresses on its behalf. 1215 Req4.3: The registration mechanism SHOULD enable long sleep 1216 durations, in the order of multiple days to a month. 1218 A.5. Requirements Related to Security 1220 In order to guarantee the operations of the 6LoWPAN ND flows, the 1221 spoofing of the 6LR, 6LBR and 6BBRs roles should be avoided. Once a 1222 node successfully registers an address, 6LoWPAN ND should provide 1223 energy-efficient means for the 6LBR to protect that ownership even 1224 when the node that registered the address is sleeping. 1226 In particular, the 6LR and the 6LBR then should be able to verify 1227 whether a subsequent registration for a given Address comes from the 1228 original node. 1230 In a LLN it makes sense to base security on layer-2 security. During 1231 bootstrap of the LLN, nodes join the network after authorization by a 1232 Joining Assistant (JA) or a Commissioning Tool (CT). After joining 1233 nodes communicate with each other via secured links. The keys for 1234 the layer-2 security are distributed by the JA/CT. The JA/CT can be 1235 part of the LLN or be outside the LLN. In both cases it is needed 1236 that packets are routed between JA/CT and the joining node. 1238 Related requirements are: 1240 Req5.1: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for 1241 the 6LR, 6LBR and 6BBR to authenticate and authorize one another for 1242 their respective roles, as well as with the 6LoWPAN Node for the role 1243 of 6LR. 1245 Req5.2: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for 1246 the 6LR and the 6LBR to validate new registration of authorized 1247 nodes. Joining of unauthorized nodes MUST be impossible. 1249 Req5.3: 6LoWPAN ND security mechanisms SHOULD lead to small packet 1250 sizes. In particular, the NS, NA, DAR and DAC messages for a re- 1251 registration flow SHOULD NOT exceed 80 octets so as to fit in a 1252 secured IEEE std. 802.15.4 frame. 1254 Req5.4: Recurrent 6LoWPAN ND security operations MUST NOT be 1255 computationally intensive on the LoWPAN Node CPU. When a Key hash 1256 calculation is employed, a mechanism lighter than SHA-1 SHOULD be 1257 preferred. 1259 Req5.5: The number of Keys that the 6LoWPAN Node needs to manipulate 1260 SHOULD be minimized. 1262 Req5.6: The 6LoWPAN ND security mechanisms SHOULD enable CCM* for use 1263 at both Layer 2 and Layer 3, and SHOULD enable the reuse of security 1264 code that has to be present on the device for upper layer security 1265 such as TLS. 1267 Req5.7: Public key and signature sizes SHOULD be minimized while 1268 maintaining adequate confidentiality and data origin authentication 1269 for multiple types of applications with various degrees of 1270 criticality. 1272 Req5.8: Routing of packets should continue when links pass from the 1273 unsecured to the secured state. 1275 Req5.9: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for 1276 the 6LR and the 6LBR to validate whether a new registration for a 1277 given address corresponds to the same 6LoWPAN Node that registered it 1278 initially, and, if not, determine the rightful owner, and deny or 1279 clean-up the registration that is duplicate. 1281 A.6. Requirements Related to Scalability 1283 Use cases from Automatic Meter Reading (AMR, collection tree 1284 operations) and Advanced Metering Infrastructure (AMI, bi-directional 1285 communication to the meters) indicate the needs for a large number of 1286 LLN nodes pertaining to a single RPL DODAG (e.g. 5000) and connected 1287 to the 6LBR over a large number of LLN hops (e.g. 15). 1289 Related requirements are: 1291 Req6.1: The registration mechanism SHOULD enable a single 6LBR to 1292 register multiple thousands of devices. 1294 Req6.2: The timing of the registration operation should allow for a 1295 large latency such as found in LLNs with ten and more hops. 1297 Author's Address 1299 Pascal Thubert (editor) 1300 Cisco Systems, Inc 1301 Building D 1302 45 Allee des Ormes - BP1200 1303 MOUGINS - Sophia Antipolis 06254 1304 FRANCE 1306 Phone: +33 497 23 26 34 1307 Email: pthubert@cisco.com