idnits 2.17.1 draft-ietf-6lo-backbone-router-07.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 (September 3, 2018) is 2054 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'IEEEstd8021' is mentioned on line 994, but not defined == Missing Reference: 'IEEEstd80211' is mentioned on line 1001, but not defined == Missing Reference: 'IEEEstd802154' is mentioned on line 1018, but not defined == Missing Reference: 'IEEEstd802151' is mentioned on line 1009, but not defined == Unused Reference: 'RFC6550' is defined on line 805, but no explicit reference was found in the text == Unused Reference: 'I-D.delcarpio-6lo-wlanah' is defined on line 831, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6lo-nfc' is defined on line 842, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-bier-architecture' is defined on line 864, but no explicit reference was found in the text == Unused Reference: 'I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks' is defined on line 880, but no explicit reference was found in the text == Unused Reference: 'RFC3810' is defined on line 898, but no explicit reference was found in the text == Unused Reference: 'RFC6282' is defined on line 936, but no explicit reference was found in the text == Unused Reference: 'RFC7217' is defined on line 955, but no explicit reference was found in the text == Unused Reference: 'RFC7428' is defined on line 961, but no explicit reference was found in the text == Unused Reference: 'RFC8105' is defined on line 981, but no explicit reference was found in the text == Unused Reference: 'RFC8163' is defined on line 987, but no explicit reference was found in the text == Outdated reference: A later version (-23) exists of draft-ietf-6lo-ap-nd-07 == Outdated reference: A later version (-22) exists of draft-ietf-6lo-nfc-10 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-14 -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 0 errors (**), 0 flaws (~~), 19 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6lo P. Thubert, Ed. 3 Internet-Draft cisco 4 Intended status: Standards Track C. Perkins 5 Expires: March 7, 2019 Futurewei 6 September 3, 2018 8 IPv6 Backbone Router 9 draft-ietf-6lo-backbone-router-07 11 Abstract 13 Backbone Routers placed at the wireless edge of a backbone link 14 interconnect multiple wireless links at Layer-3 to form a large 15 MultiLink Subnet, so that the broadcast domain of the backbone does 16 not extend to the wireless links. Wireless nodes register or are 17 proxy-registered to a Backbone Router to establish IPv6 Neighbor 18 Discovery proxy services, and the Backbone Router takes care of the 19 ND operation on behalf of registered nodes and ensures and routes 20 towards the registered addresses over the wireless interface. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on March 7, 2019. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Applicability and Requirements Served . . . . . . . . . . . . 4 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 5. Backbone Router Routing Operations . . . . . . . . . . . . . 8 61 5.1. Over the Backbone Link . . . . . . . . . . . . . . . . . 9 62 5.2. Over the LLN Link . . . . . . . . . . . . . . . . . . . . 10 63 6. Backbone Router Proxy Operations . . . . . . . . . . . . . . 11 64 6.1. Registration and Binding State Creation . . . . . . . . . 14 65 6.2. Defending Addresses . . . . . . . . . . . . . . . . . . . 15 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 67 8. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 16 68 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 69 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 70 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 71 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 72 11.2. Informative References . . . . . . . . . . . . . . . . . 18 73 11.3. External Informative References . . . . . . . . . . . . 22 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 76 1. Introduction 78 One of the key services provided by IEEE STD. 802.1 [IEEEstd8021] 79 Ethernet Bridging is an efficient and reliable broadcast service, and 80 multiple applications and protocols have been built that heavily 81 depend on that feature for their core operation. Unfortunately, a 82 wide range of wireless networks do not provide economical broadcast 83 capabilities of Ethernet Bridging; protocols designed for bridged 84 networks that rely on broadcast often exhibit disappointing 85 behaviours when applied unmodified to a wireless medium. 87 Wi-Fi [IEEEstd80211] Access Points (APs) deployed in an Extended 88 Service Set (ESS) act as bridges. However, in order to ensure a 89 solid connectivity to the devices and protect the medium against 90 harmful broadcasts, they refrain from relying on broadcast-intensive 91 protocols such as Transparent Bridging on the wireless side. 92 Instead, an association process is used to register proactively the 93 MAC addresses of the wireless device (STA) to the AP. Then, the APs 94 proxy the bridging operation and cancel the broadcasts. 96 The IPv6 [RFC8200] Neighbor Discovery [RFC4861] [RFC4862] Protocol 97 (NDP) operations are reactive and rely heavily on multicast 98 transmissions to locate an on-link correspondent and ensure address 99 uniqueness. When the Duplicate Address Detection [RFC4862] (DAD) 100 mechanism was designed, it was a natural match with the efficient 101 broadcast operation of Ethernet Bridging. However, since broadcast 102 can be unreliable over wireless media, DAD often fails to discover 103 duplications [I-D.yourtchenko-6man-dad-issues]. DAD usually appears 104 to work on wireless media, not because address duplication is 105 detected and solved as designed, but because the use of 64-bit 106 Interface IDs makes duplication into a very rare event. 108 IPv6 multicast messages are usually broadcast over the wireless 109 medium. They are processed by most if not all wireless nodes over 110 the ESS fabric even when very few if any of the nodes are subscribed 111 to the multicast address. Consequently a simple Neighbor 112 Solicitation (NS) lookup message [RFC4861], that is supposedly 113 targeted to a very small group of nodes, can consume the whole 114 wireless bandwidth across the fabric 115 [I-D.vyncke-6man-mcast-not-efficient]. The reactive IPv6 ND 116 operation leads to undesirable power consumption in battery-operated 117 devices. 119 The inefficiencies of using radio broadcasts to support IPv6 NDP 120 suggest restricting broadcast transmissions over the wireless access 121 links. This can be done by splitting the subnet in multiple ones, 122 and in extreme cases providing a /64 per wireless device. Another 123 way is to take over (proxy) the Layer-3 protocols that rely on 124 broadcast operation at the boundary of the wired and wireless 125 domains, emulating the Layer-2 association at Layer-3. Indeed, the 126 IEEE STD. 802.11 [IEEEstd80211] specifications require ARP and ND 127 proxy [RFC4389] functions at the Access Points (APs) but the 128 specification for the ND proxy operations is still missing. 130 Current devices rely on snooping for detecting association state, 131 which is unsatisfactory in a lossy and mobile conditions. With 132 snooping, a state (e.g. a new IPv6 address) may not be discovered or 133 a change of state (e.g. a movement) may be missed, leading to 134 unreliable connectivity. 136 WPAN devices (i.e., those implementing IEEE STD. 802.15.4 137 [IEEEstd802154]) can make use of Neighbor Discovery Optimization for 138 IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) 139 [RFC6775] which treats the wireless medium as different from 140 Ethernet. RFC 6775 is updated as [I-D.ietf-6lo-rfc6775-update]; the 141 update includes changes that are required by this document. 143 This specification applies to other wireless links such as Low-Power 144 IEEE STD. 802.11 (Wi-Fi) and IEEE STD. 802.15.1 (Bluetooth) 145 [IEEEstd802151], and extends [RFC6775] to enable proxy operation by 146 the 6BBR. The proxy operation on the BBR eliminates the need for 147 low-power nodes or nodes that are deep in a mesh to respond 148 synchronously when a lookup is performed for their addresses. This 149 provides the function of a Sleep Proxy for ND 150 [I-D.nordmark-6man-dad-approaches]. 152 2. Applicability and Requirements Served 154 Efficiency aware IPv6 Neighbor Discovery Optimizations 155 [I-D.chakrabarti-nordmark-6man-efficient-nd] suggests that 6LoWPAN ND 156 [RFC6775] can be extended to other types of links beyond IEEE STD. 157 802.15.4 for which it was defined. The registration technique is 158 beneficial when the Link-Layer technique used to carry IPv6 multicast 159 packets has poor delivery ratio or requires high energy consumption 160 in the end devices, all the more in use cases that involve mobility. 162 This specification updates and generalizes 6LoWPAN ND to a broader 163 range of Low power and Lossy Networks (LLNs) with support for 164 Duplicate Address Detection (DAD) and address lookup that does not 165 require broadcasts over the LLNs. The term LLN is used loosely in 166 this specification to cover multiple types of WLANs and WPANs, 167 including Low-Power Wi-Fi, BLUETOOTH(R) Low Energy, IEEE STD. 168 802.11AH and IEEE STD. 802.15.4 wireless meshes, so as to address the 169 requirements listed in Appendix B.3 of [I-D.ietf-6lo-rfc6775-update] 170 "Requirements Related to the Variety of Low-Power Link types". 172 The scope of this draft is a Backbone that enable the federation of 173 multiple LLNs into a IPv6 MultiLink Subnet. Each LLN in the subnet 174 is anchored at an IPv6 Backbone Router (6BBR). The Backbone Routers 175 interconnect the LLNs and advertise the addresses of the LLN nodes 176 using proxy-ND operations. This specification extends IPv6 ND over 177 the backbone to distinguish address movement from duplication and 178 eliminate stale state in the backbone routers and backbone nodes once 179 a LLN node has roamed. In this way, mobile nodes may roam rapidly 180 from one 6BBR to the next and requirements in Appendix B.1 of 181 [I-D.ietf-6lo-rfc6775-update]"Requirements Related to Mobility" are 182 met. 184 This specification can be used by any wireless node to associate at 185 Layer-3 with a 6BBR and register its IPv6 addresses to obtain routing 186 services including proxy-ND operations over the backbone, providing a 187 solution to the requirements expressed in Appendix B.4 of 188 [I-D.ietf-6lo-rfc6775-update] "Requirements Related to Proxy 189 Operations". 191 The Link Layer Address (LLA) that is returned as Target LLA (TLLA) in 192 Neighbor Advertisements (NA) messages by the 6BBR on behalf of the 193 Registered Node over the backbone may be that of the Registering 194 Node. In that case, the 6BBR needs to bridge the unicast packets 195 (Bridging proxy), or that of the 6BBR on the backbone, in which case 196 the 6BBRs needs to route the unicast packets (Routing proxy). In the 197 latter case, the 6BBR maintains the list of correspondents to which 198 it has advertised its own MAC address on behalf of the LLN node. The 199 IPv6 ND operation is minimized as the number of nodes scale up in the 200 LLN. This meets the requirements in Appendix B.6 of 201 [I-D.ietf-6lo-rfc6775-update] "Requirements Related to Scalability", 202 as long has the 6BBRs are dimensioned for the number of registrations 203 that each needs to support. 205 For the TimeSlotted Channel Hopping (TSCH) mode of [IEEEstd802154], 206 the 6TiSCH architecture [I-D.ietf-6tisch-architecture] describes how 207 a 6LoWPAN ND host could connect to the Internet via a RPL mesh 208 Network, but doing so requires additions to the 6LOWPAN ND protocol 209 to support mobility and reachability in a secure and manageable 210 environment. This document details such additions for the 6TiSCH 211 architecture, and serves the requirements listed in Appendix B.2 of 212 [I-D.ietf-6lo-rfc6775-update] "Requirements Related to Routing 213 Protocols". 215 In the case of Low-Power IEEE STD. 802.11, a 6BBR may be collocated 216 with a standalone AP or a CAPWAP [RFC5415] wireless controller. Then 217 the wireless client (STA) makes use of this specification to register 218 its IPv6 address(es) to the 6BBR over the wireless medium. In the 219 case of a 6TiSCH LLN mesh, the RPL root is collocated with a 6LoWPAN 220 Border Router (6LBR), and either collocated with or connected to the 221 6BBR over an IPv6 Link. The 6LBR makes use of this specification to 222 register the LLN nodes on their behalf to the 6BBR. In the case of 223 BTLE, the 6BBR is collocated with the router that implements the BTLE 224 central role as discussed in section 2.2 of [RFC7668]. 226 3. Terminology 228 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 229 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 230 document are to be interpreted as described in [RFC2119]. 232 Readers are expected to be familiar with all the terms and concepts 233 that are discussed in "Neighbor Discovery for IP version 6" 234 [RFC4861], "IPv6 Stateless Address Autoconfiguration" [RFC4862], 235 "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): 236 Overview, Assumptions, Problem Statement, and Goals" [RFC4919], 237 Neighbor Discovery Optimization for Low-power and Lossy Networks 239 [RFC6775] and "Multi-link Subnet Support in IPv6" 240 [I-D.ietf-ipv6-multilink-subnets]. 242 Readers would benefit from reading "Multi-Link Subnet Issues" 243 [RFC4903], ,"Mobility Support in IPv6" [RFC6275], "Neighbor Discovery 244 Proxies (ND Proxy)" [RFC4389] and "Optimistic Duplicate Address 245 Detection" [RFC4429] prior to this specification for a clear 246 understanding of the art in ND-proxying and binding. 248 Additionally, this document uses terminology from [RFC7102], 249 [I-D.ietf-6lo-rfc6775-update] and [I-D.ietf-6tisch-terminology], and 250 introduces the following terminology: 252 Sleeping Proxy 254 A 6BBR acts as a Sleeping Proxy if it answers ND Neighbor 255 Solicitation over the backbone on behalf of the Registered 256 Node. 258 Unicasting Proxy 260 A Unicasting Proxy forwards NS messages to the Registering 261 Node, transforming Layer-2 multicast into unicast. 263 Routing proxy 265 A routing proxy advertises its own MAC address, as opposed to 266 that of the node that performs the registration, as the TLLA in 267 the proxied NAs over the backbone. 269 Bridging proxy 271 A Bridging proxy advertises the MAC address of the node that 272 performs the registration as the TLLA in the proxied NAs over 273 the backbone. In that case, the MAC address and the mobility 274 of the node is still visible across the bridged backbone 275 fabric. 277 Primary BBR 279 The BBR that will defend a Registered Address for the purpose 280 of DAD over the backbone. 282 Secondary BBR 284 A BBR other than the Primary BBR to which an address is 285 registered. A Secondary Router MAY advertise the address over 286 the backbone and proxy for it. 288 4. Overview 290 An LLN node can move freely from an LLN anchored at a Backbone Router 291 to an LLN anchored at another Backbone Router on the same backbone 292 and keep any or all of the IPv6 addresses that it has formed. 294 | 295 +-----+ 296 | | Gateway (default) Router 297 | | 298 +-----+ 299 | 300 | Backbone Link 301 +--------------------+------------------+ 302 | | | 303 +-----+ +-----+ +-----+ 304 | | Backbone | | Backbone | | Backbone 305 | | router | | router | | router 306 +-----+ +-----+ +-----+ 307 o o o o o o 308 o o o o o o o o o o o o o o 309 o o o o o o o o o o o o o o o 310 o o o o o o o o o o 311 o o o o o o o 313 LLN LLN LLN 315 Figure 1: Backbone Link and Backbone Routers 317 Each Backbone Router (6BBR) maintains a Binding Table of its 318 Registered Nodes. The Binding Table operates as a distributed 319 database of wireless Nodes whether they reside on the LLNs or on the 320 backbone, and use an extension to the Neighbor Discovery Protocol to 321 exchange that information across the Backbone as with IPv6 ND. 323 The Extended Address Registration Option (EARO) defined in 324 [I-D.ietf-6lo-rfc6775-update] is used to enable the registration for 325 routing and proxy options in the ND exchanges over the backbone 326 between the 6BBRs to disambiguate duplication from movement. 328 Address duplication is detected using the ROVR field in the EARO, 329 which is a generalization of the EUI-64 that allows different types 330 of unique IDs beyond the name space derived from the MAC addresses. 331 First-Come First-Serve rules apply, whether the duplication happens 332 between LLN nodes as represented by their respective 6BBRs, or 333 between an LLN node and a node that defends its address over the 334 backbone with IPv6 ND and does not include the EARO. 336 In case of conflicting registrations to multiple 6BBRs from a same 337 node, a sequence counter called Transaction ID (TID) in the EARO 338 enables 6BBRs to determine the latest registration for that node. 339 Registrations with a same TID are compatible and maintained, but, in 340 case of different TIDs, only the freshest registration is maintained 341 and the stale state is eliminated. The EARO also transports a 'R' 342 flag to be used by a 6LN when registering, to indicate that this 6LN 343 is not a router and that it will not handle its own reachability. 345 With this specification, Backbone Routers perform a ND proxy 346 operation over the Backbone Link on behalf of their Registered Nodes. 347 The registration to the proxy service is done with a NS/NA(EARO) 348 exchange. The EARO with a 'R' flag is used in this specification to 349 request the 6BBR to perform this proxy operation. The Backbone 350 Router operation is essentially similar to that of a Mobile IPv6 351 (MIPv6) [RFC6275] Home Agent. This enables mobility support for LLN 352 nodes that would move outside of the network delimited by the 353 Backbone link attach to a Home Agent from that point on. This also 354 enables collocation of Home Agent functionality within Backbone 355 Router functionality on the same backbone interface of a router. 356 Further specification may extend this be allowing the 6BBR to 357 redistribute host routes in routing protocols that would operate over 358 the backbone, or in MIPv6 or the Locator/ID Separation Protocol 359 (LISP) [RFC6830] to support mobility on behalf of the nodes, etc... 361 The Optimistic Duplicate Address Detection [RFC4429] (ODAD) 362 specification details how an address can be used before a Duplicate 363 Address Detection (DAD) is complete, and insists that an address that 364 is TENTATIVE should not be associated to a Source Link-Layer Address 365 Option in a Neighbor Solicitation message. This specification makes 366 use of ODAD to create a temporary proxy state in the 6BBR till DAD is 367 completed over the backbone. This way, the specification enables to 368 distribute proxy states across multiple 6BBR and co-exist with IPv6 369 ND over the backbone. 371 5. Backbone Router Routing Operations 372 | 373 +-----+ 374 | | Gateway (default) Router 375 | | 376 +-----+ 377 | /64 378 | Backbone Link 379 +-------------------+-------------------+ 380 | /64 | /64 | /64 381 +-----+ +-----+ +-----+ 382 | | Backbone | | Backbone | | Backbone 383 | | router | | router | | router 384 +-----+ +-----+ +-----+ 385 o N * /128 o M * /128 o P * /128 386 o o o o o o o o o o o o o o 387 o o o o o o o o o o o o o o o 388 o o o o o o o o o o 389 o o o o o o o 391 Figure 2: Example Routing Configuration for 3 LLNs in the ML Subnet 393 5.1. Over the Backbone Link 395 A 6BBR is a specific kind of Border Router that performs proxy 396 Neighbor Discovery on its backbone interface on behalf of the nodes 397 that it has discovered on its LLN interfaces. 399 Some restrictions of the attached LLNs will apply to the backbone. 400 In particular, the MTU MUST be set to the same value on the backbone 401 and all attached LLNs. The scalability of the whole subnet requires 402 that broadcast operations are avoided as much as possible on the 403 backbone as well. Unless configured otherwise, in the RAs that it 404 sends towards the LLN links, the Backbone Router MUST use the same 405 MTU that it learns from RAs over the backbone. 407 On the backbone side, the 6BBR behaves like any other IPv6 router. 408 It advertises on the backbone the prefixes of the LLNs for which it 409 serves as a proxy. 411 The 6BBR uses an EARO in the NS-DAD and the multicast NA messages 412 that it generates over the Backbone Link on behalf of a Registered 413 Node, and it places an EARO in its unicast NA messages, if and only 414 if the NS/NA that stimulates it had an EARO in it and the 'R' bit 415 set. 417 The 6BBR SHOULD use unicast or solicited-node multicast address 418 (SNMA) [RFC4291] to defend its Registered Addresses over the 419 backbone. In particular, the 6BBR MUST join the SNMA group that 420 corresponds to a Registered Address as soon as it creates an entry 421 for that address, and as long as it maintains that entry. 423 Optimistic DAD (ODAD) [RFC4429] SHOULD be supported by the 6BBRs in 424 their proxy activity over the backbone. A node supporting ODAD MUST 425 join the SNMA of a Tentative address. 427 A 6BBR in Routing Proxy mode advertises the Registered IPv6 Address 428 with the 6BBR Link Layer Address, and updates Neighbor Cache Entries 429 (NCE) in correspondent nodes over the backbone, using gratuitous 430 NA(Override). This method may fail if the multicast message is not 431 properly received, and correspondent nodes may maintain an incorrect 432 neighbor state, which they will eventually discover through Neighbor 433 Unreachability Detection (NUD). For slow movements, the NUD 434 procedure defined in [RFC4861] may time out too quickly, and the 435 support of [RFC7048] is recommended in all nodes in the network. 437 Since the MultiLink Subnet may grow to contain many nodes, multicast 438 should be avoided as much as possible even on the backbone. Though 439 hosts can participate using legacy IPv6 ND, all nodes connected to 440 the backbone SHOULD support [I-D.ietf-6man-rs-refresh], which also 441 requires the support of [RFC7559]. 443 5.2. Over the LLN Link 445 BBRs and LLN hosts on the LLN follow [RFC6775] and do not depend on 446 multicast RAs to discover routers. LLN nodes SHOULD accept multicast 447 RAs [RFC7772], but those are rare on the LLN link. Nodes SHOULD 448 follow the Simple Procedures for Detecting Network Attachment in IPv6 449 [RFC6059] (DNA procedures) to assert movements, and to support the 450 Packet-Loss Resiliency for Router Solicitations [RFC7559] to make the 451 unicast RS more reliable. 453 LLN node signals that it requires IPv6 ND proxy services from a 6BBR 454 by registering the corresponding IPv6 Address with an NS(EARO) 455 message with the 'R' flag set. The LLN node that performs the 456 registration (the Registering Node) may be the owner of the IPv6 457 Address (the Registered Node) or a 6LBR that performs the 458 registration on its behalf. 460 When operating as a Routing Proxy, the BBR installs host routes 461 (/128) to the Registered Addresses over the LLN links, via the 462 Registering Node as identified by the Source Address and the SLLA 463 option in the NS(EARO) messages. In that case, the MAC address of 464 the node is not visible at Layer-2 over the backbone and the bridging 465 fabric is not aware of the addresses of the LLN devices and their 466 mobility. The 6BBR installs a connected host route towards the 467 registered node over the interface to the node, and acts as a Layer-3 468 router for unicast packets to the node. 470 In that mode, the 6BBR handles the ND protocol over the backbone on 471 behalf of the Registered Nodes, using its own MAC address in the TLLA 472 and SLLA options in proxied NS and NA messages. For each Registered 473 Address, multiple peer Nodes on the backbone may have resolved the 474 address with the 6BBR MAC address and store that mapping in their 475 Neighbor cache. 477 For each Registered Address, the 6BBR SHOULD maintain a list of the 478 peers on the backbone which have associated its MAC address with the 479 Registered Address. If that Registered Address moves to a different 480 6BBR, the first 6BBR SHOULD unicast a gratuitous NA(Override) to each 481 such peer, to supply the MAC address of the new 6BBR in the TLLA 482 option for the Address. 484 A Bridging Proxy can be implemented in a Layer-3 switch, or in a 485 wireless Access Point that acts as an IPv6 Host. In the latter case, 486 the SLLA option in the proxied NA messages is that of the Registering 487 Node, and the 6BBR acts as a Layer-2 bridge for unicast packets to 488 the Registered Address. The MAC address in the S/TLLA is that of the 489 Registering Node, which is not necessarily the Registered Node. When 490 a device moves within a LLN mesh, it may attach to a different 6LBR 491 acting as Registering Node, and the MAC address advertised over the 492 backbone will change. 494 If a registration moves from one 6BBR to the next, but the 495 Registering Node does not change, as indicated by the S/TLLA option 496 in the ND exchanges, there is no need to update the Neighbor Caches 497 in the peers Nodes on the backbone. On the other hand, if the LLA 498 changes, the 6BBR SHOULD inform all the relevant peers as described 499 above, to update the impacted Neighbor Caches. In the same fashion, 500 if the Registering Node changes with a new registration, the 6BBR 501 SHOULD also update the impacted Neighbor Caches over the backbone. 503 6. Backbone Router Proxy Operations 505 This specification enables a Backbone Router to proxy Neighbor 506 Discovery operations over the backbone on behalf of the nodes that 507 are registered to it, allowing any node on the backbone to reach a 508 Registered Node as if it was on-link. The backbone and the LLNs are 509 considered different Links in a MultiLink subnet but the prefix that 510 is used may still be advertised as on-link on the backbone to support 511 legacy nodes; multicast ND messages are link-scoped and not forwarded 512 across the backbone routers. 514 By default, a 6BBR operates as a Sleeping Proxy, as follows: 516 o Create a new entry in a Binding Table for a new Registered Address 517 and ensure that the address is not a duplicate over the backbone 519 o Defend a Registered Address over the backbone using NA messages 520 with the Override bit set on behalf of the sleeping node 522 o Advertise a Registered Address over the backbone using NA 523 messages, asynchronously or as a response to a Neighbor 524 Solicitation messages. 526 o To deliver packets arriving from the LLN, use Neighbor 527 Solicitation messages to look up the destination over the 528 backbone. 530 o Forward packets between the LLN and the backbone. 532 o Verify liveliness when needed for a stale registration. 534 A 6BBR may act as a Sleeping Proxy only for a Registered Address that 535 is REACHABLE, or TENTATIVE in which case the answer is delayed. In 536 any other state, the Sleeping Proxy operates as a Unicasting Proxy. 538 The 6BBR does not act on ND Messages over the backbone unless they 539 are relevant to a Registered Node on the LLN side, saving wireless 540 interference. On the LLN side, the prefixes associated to the 541 MultiLink Subnet are presented as not on-link, so address resolution 542 for other hosts do not occur. 544 As a Unicasting Proxy, the 6BBR forwards NS lookup messages to the 545 Registering Node, transforming Layer-2 multicast into unicast. This 546 is not possible in UNREACHABLE state, so the NS messages are 547 multicasted, and rate-limited with an exponential back-off to protect 548 the medium. In other states, the messages are forwarded to the 549 Registering Node as unicast Layer-2 messages. In TENTATIVE state, 550 the NS message is either held till DAD completes, or dropped. 552 The draft introduces the optional concept of primary and secondary 553 BBRs. The primary is the backbone router that has the highest EUI-64 554 address of all the 6BBRs that share a registration for a same 555 Registered Address, with the same ROVR and same Transaction ID, the 556 EUI-64 address being considered as an unsigned 64bit integer. A 557 given 6BBR can be primary for a given address and secondary for 558 another address, regardless on whether or not the addresses belong to 559 the same node. The primary Backbone Router is in charge of 560 protecting the address for DAD over the Backbone. Any of the Primary 561 and Secondary 6BBR may claim the address over the backbone, since 562 they are all capable to route from the backbone to the LLN node; the 563 address appears on the backbone as an anycast address. 565 The Backbone Routers maintain a distributed binding table, using IPv6 566 ND over the backbone to detect duplication. This specification 567 requires that: 569 1. Addresses in a LLN that can be reachable from the backbone by way 570 of a 6BBR MUST be registered to that 6BBR. 572 2. A Registered Node MUST include the EARO in the NS message when 573 registering its addresses to a 6LR. The 6LR MUST forward the 574 EARO unchanged to the 6LBR in the DAR/DAC exchange. The 6LBR 575 MUST propagate the EARO unchanged to 6BBR. 577 3. The 6LR MUST respond with the same EARO in the NA, except for the 578 status field. 580 A false positive duplicate detection may arise over the backbone, for 581 instance if the Registered Address is registered to more than one 582 LBR, or if the node has moved. Both situations are handled by the 583 6BBR transparently to the node. In the former case, one LBR becomes 584 primary to defend the address over the backbone while the others 585 become secondary and may still forward packets. In the latter case 586 the LBR that receives the newest registration becomes primary. 588 Only one node may register a given Address at a particular 6BBR. 589 However, that Registered Address may be registered to Multiple 6BBRs 590 for higher availability. 592 Over the LLN, Binding Table management is as follows: 594 De-registrations (newer TID, same ROVR, null Lifetime) are 595 accepted and acknowledged with a status of 4; the entry is 596 deleted; 598 Newer registrations (newer TID, same ROVR, non-null Lifetime) are 599 acknowledged with a status of 0 (success); the binding is updated 600 with the new TID, the Registration Lifetime and the Registering 601 Node; in TENTATIVE state the acknowledgement is held and may be 602 overwritten; in other states the Registration-Lifetime timer is 603 restarted and the entry is placed in REACHABLE state. 605 Identical registrations (same TID, same ROVR) from a same 606 Registering Node are acknowledged with a status of 0 (success). 607 If they are not identical, an error SHOULD be logged. In 608 TENTATIVE state, the response is held and may be overwritten, but 609 it MUST be eventually produced and it carries the result of the 610 DAD process; 611 Older registrations (older TID, same ROVR) from a Registering Node 612 are ignored; 614 Identical and older registrations (not-newer TID, same ROVR) from 615 a different Registering Node are acknowledged with a status of 3 616 (moved); this may be rate limited to protect the medium; 618 Any registration for a different Registered Node (different ROVR) 619 are acknowledged with a status of 1 (duplicate). 621 6.1. Registration and Binding State Creation 623 Upon receiving a registration for a new address with an NS(EARO) with 624 the 'R' bit set, the 6BBR performs DAD over the backbone, placing the 625 new address as target in the NS-DAD message. The EARO from the 626 registration MUST be placed unchanged in the NS-DAD message, and an 627 Neighbor Cache entry created in TENTATIVE state for a duration of 628 TENTATIVE_DURATION. The NS-DAD message is sent multicast over the 629 backbone to the SNMA associated with the registered address, unless 630 that operation is known to be costly, and the 6BBR has an indication 631 from another source (such as a Neighbor Cache entry) that the 632 Registered Address was known on the backbone; in the latter case, an 633 NS-DAD message may be sent as a Layer-2 unicast to the MAC Address 634 that was associated with the Registered Address. 636 In TENTATIVE state after EARO with 'R' bit set: 638 1. The entry is removed if an NA is received over the backbone for 639 the Registered Address with no EARO, or with an EARO with a 640 status of 1 (duplicate) that indicates an existing registration 641 for another LLN node. The ROVR and TID fields in the EARO 642 received over the backbone are ignored. A status of 1 is 643 returned in the EARO of the NA back to the Registering Node; 645 2. The entry is also removed if an NA with an ARO option with a 646 status of 3 (moved), or a NS-DAD with an ARO option that 647 indicates a newer registration for the same Registered Node, is 648 received over the backbone for the Registered Address. A status 649 of 3 is returned in the NA(EARO) back to the Registering Node; 651 3. When a registration is updated but not deleted, e.g. from a newer 652 registration, the DAD process on the backbone continues and the 653 running timers are not restarted; 655 4. Other NS (including DAD with no EARO) and NA from the backbone 656 are not acknowledged in TENTATIVE state. To cover legacy nodes 657 that do not support ODAD, the list of their origins MAY be stored 658 and then, if the TENTATIVE_DURATION timer elapses, the 6BBR MAY 659 send each such legacy node a unicast NA. 661 5. When the TENTATIVE_DURATION timer elapses, a status 0 (success) 662 is returned in a NA(EARO) back to the Registering Node(s), and 663 the entry goes to REACHABLE state for the Registration Lifetime. 664 The 6BBR MUST send a multicast NA(EARO) to the SNMA associated to 665 the Registered Address over the backbone with the Override bit 666 set so as to take over the binding from other 6BBRs. 668 6.2. Defending Addresses 670 If a 6BBR has an entry in REACHABLE state for a Registered Address: 672 o If the 6BBR is primary, or does not support the function of 673 primary, it MUST defend that address over the backbone upon 674 receiving NS-DAD, either if the NS does not carry an EARO, or if 675 an EARO is present that indicates a different Registering Node 676 (different ROVR). The 6BBR sends a NA message with the Override 677 bit set and the NA carries an EARO if and only if the NS-DAD did 678 so. When present, the EARO in the NA(Override) that is sent in 679 response to the NS-DAD(EARO) carries a status of 1 (duplicate), 680 and the ROVR and TID fields in the EARO are obfuscated with null 681 or random values to avoid network scanning and impersonation 682 attacks. 684 o If the 6BBR receives an NS-DAD(EARO) for a newer registration, the 685 6BBR updates the entry and the routing state to forward packets to 686 the new 6BBR, but keeps the entry REACHABLE. Afterwards, the 6BBR 687 MAY use REDIRECT messages to reroute traffic for the Registered 688 Address to the new 6BBR. 690 o If the 6BBR receives an NA(EARO) for a newer registration, the 691 6BBR removes its entry and sends a NA(EARO) with a status of 3 692 (MOVED) to the Registering Node, if the Registering Node is 693 different from the Registered Node. The 6BBR cleans up existing 694 Neighbor Cache Entries in peer nodes as discussed in Section 5.1, 695 by unicasting to each such peer, or one broadcast NA(Override). 697 o If the 6BBR receives a NS(LOOKUP) for a Registered Address, it 698 answers immediately with an NA on behalf of the Registered Node, 699 without polling it. There is no need of an EARO in that exchange. 701 o When the Registration-Lifetime timer elapses, the entry goes to 702 STALE state for a duration of STABLE_STALE_DURATION in LLNs that 703 keep stable addresses such as LWPANs, and UNSTABLE_STALE_DURATION 704 in LLNs where addresses are renewed rapidly, e.g. for privacy 705 reasons. 707 The STALE state enables tracking of the backbone peers that have a 708 Neighbor Cache entry pointing to this 6BBR in case the Registered 709 Address shows up later. If the Registered Address is claimed by 710 another node on the backbone, with an NS-DAD or an NA, the 6BBR does 711 not defend the address. In STALE state: 713 o If STALE_DURATION elapses, the 6BBR removes the entry. 715 o Upon receiving an NA(Override) the 6BBR removes its entry and 716 sends a NA(EARO) with a status of 4 (removed) to the Registering 717 Node. 719 o If the 6BBR receives a NS(LOOKUP) for a Registered Address, the 720 6BBR MUST send an NS(NUD) following rules in [RFC7048] to the 721 Registering Node targeting the Registered Address prior to 722 answering. If the NUD succeeds, the operation in REACHABLE state 723 applies. If the NUD fails, the 6BBR refrains from answering the 724 lookup. The NUD SHOULD be used by the Registering Node to 725 indicate liveness of the Registered Node, if they are different 726 nodes. 728 7. Security Considerations 730 This specification applies to LLNS in which the link layer is 731 protected, either by means of physical or IP security for the 732 Backbone Link or MAC sublayer cryptography. In particular, the LLN 733 MAC is required to provide secure unicast to/from the Backbone Router 734 and secure Broadcast from the Backbone Router in a way that prevents 735 tempering with or replaying the RA messages. 737 The use of EUI-64 for forming the Interface ID in the link local 738 address prevents the usage of Secure ND ([RFC3971] and [RFC3972]) and 739 address privacy techniques. This specification RECOMMENDS the use of 740 additional protection against address theft such as provided by 741 [I-D.ietf-6lo-ap-nd], which guarantees the ownership of the ROVR. 743 When the ownership of the ROVR cannot be assessed, this specification 744 limits the cases where the ROVR and the TID are multicasted, and 745 obfuscates them in responses to attempts to take over an address. 747 8. Protocol Constants 749 This Specification uses the following constants: 751 TENTATIVE_DURATION: 800 milliseconds 753 STABLE_STALE_DURATION: 24 hours 754 UNSTABLE_STALE_DURATION: 5 minutes 756 DEFAULT_NS_POLLING: 3 times 758 9. IANA Considerations 760 This document has no request to IANA. 762 10. Acknowledgments 764 Kudos to Eric Levy-Abegnoli who designed the First Hop Security 765 infrastructure at Cisco. 767 11. References 769 11.1. Normative References 771 [I-D.ietf-6lo-rfc6775-update] 772 Thubert, P., Nordmark, E., Chakrabarti, S., and C. 773 Perkins, "Registration Extensions for 6LoWPAN Neighbor 774 Discovery", draft-ietf-6lo-rfc6775-update-21 (work in 775 progress), June 2018. 777 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 778 Requirement Levels", BCP 14, RFC 2119, 779 DOI 10.17487/RFC2119, March 1997, 780 . 782 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 783 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 784 2006, . 786 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 787 for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, 788 . 790 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 791 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 792 DOI 10.17487/RFC4861, September 2007, 793 . 795 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 796 Address Autoconfiguration", RFC 4862, 797 DOI 10.17487/RFC4862, September 2007, 798 . 800 [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for 801 Detecting Network Attachment in IPv6", RFC 6059, 802 DOI 10.17487/RFC6059, November 2010, 803 . 805 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 806 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 807 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 808 Low-Power and Lossy Networks", RFC 6550, 809 DOI 10.17487/RFC6550, March 2012, 810 . 812 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 813 Bormann, "Neighbor Discovery Optimization for IPv6 over 814 Low-Power Wireless Personal Area Networks (6LoWPANs)", 815 RFC 6775, DOI 10.17487/RFC6775, November 2012, 816 . 818 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 819 (IPv6) Specification", STD 86, RFC 8200, 820 DOI 10.17487/RFC8200, July 2017, 821 . 823 11.2. Informative References 825 [I-D.chakrabarti-nordmark-6man-efficient-nd] 826 Chakrabarti, S., Nordmark, E., Thubert, P., and M. 827 Wasserman, "IPv6 Neighbor Discovery Optimizations for 828 Wired and Wireless Networks", draft-chakrabarti-nordmark- 829 6man-efficient-nd-07 (work in progress), February 2015. 831 [I-D.delcarpio-6lo-wlanah] 832 Vega, L., Robles, I., and R. Morabito, "IPv6 over 833 802.11ah", draft-delcarpio-6lo-wlanah-01 (work in 834 progress), October 2015. 836 [I-D.ietf-6lo-ap-nd] 837 Thubert, P., Sarikaya, B., and M. Sethi, "Address 838 Protected Neighbor Discovery for Low-power and Lossy 839 Networks", draft-ietf-6lo-ap-nd-07 (work in progress), 840 September 2018. 842 [I-D.ietf-6lo-nfc] 843 Choi, Y., Hong, Y., Youn, J., Kim, D., and J. Choi, 844 "Transmission of IPv6 Packets over Near Field 845 Communication", draft-ietf-6lo-nfc-10 (work in progress), 846 July 2018. 848 [I-D.ietf-6man-rs-refresh] 849 Nordmark, E., Yourtchenko, A., and S. Krishnan, "IPv6 850 Neighbor Discovery Optional RS/RA Refresh", draft-ietf- 851 6man-rs-refresh-02 (work in progress), October 2016. 853 [I-D.ietf-6tisch-architecture] 854 Thubert, P., "An Architecture for IPv6 over the TSCH mode 855 of IEEE 802.15.4", draft-ietf-6tisch-architecture-14 (work 856 in progress), April 2018. 858 [I-D.ietf-6tisch-terminology] 859 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 860 "Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e", 861 draft-ietf-6tisch-terminology-10 (work in progress), March 862 2018. 864 [I-D.ietf-bier-architecture] 865 Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and 866 S. Aldrin, "Multicast using Bit Index Explicit 867 Replication", draft-ietf-bier-architecture-08 (work in 868 progress), September 2017. 870 [I-D.ietf-ipv6-multilink-subnets] 871 Thaler, D. and C. Huitema, "Multi-link Subnet Support in 872 IPv6", draft-ietf-ipv6-multilink-subnets-00 (work in 873 progress), July 2002. 875 [I-D.nordmark-6man-dad-approaches] 876 Nordmark, E., "Possible approaches to make DAD more robust 877 and/or efficient", draft-nordmark-6man-dad-approaches-02 878 (work in progress), October 2015. 880 [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks] 881 Popa, D. and J. Hui, "6LoPLC: Transmission of IPv6 Packets 882 over IEEE 1901.2 Narrowband Powerline Communication 883 Networks", draft-popa-6lo-6loplc-ipv6-over- 884 ieee19012-networks-00 (work in progress), March 2014. 886 [I-D.vyncke-6man-mcast-not-efficient] 887 Vyncke, E., Thubert, P., Levy-Abegnoli, E., and A. 888 Yourtchenko, "Why Network-Layer Multicast is Not Always 889 Efficient At Datalink Layer", draft-vyncke-6man-mcast-not- 890 efficient-01 (work in progress), February 2014. 892 [I-D.yourtchenko-6man-dad-issues] 893 Yourtchenko, A. and E. Nordmark, "A survey of issues 894 related to IPv6 Duplicate Address Detection", draft- 895 yourtchenko-6man-dad-issues-01 (work in progress), March 896 2015. 898 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 899 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 900 DOI 10.17487/RFC3810, June 2004, 901 . 903 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 904 "SEcure Neighbor Discovery (SEND)", RFC 3971, 905 DOI 10.17487/RFC3971, March 2005, 906 . 908 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 909 RFC 3972, DOI 10.17487/RFC3972, March 2005, 910 . 912 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 913 Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 914 2006, . 916 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 917 DOI 10.17487/RFC4903, June 2007, 918 . 920 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 921 over Low-Power Wireless Personal Area Networks (6LoWPANs): 922 Overview, Assumptions, Problem Statement, and Goals", 923 RFC 4919, DOI 10.17487/RFC4919, August 2007, 924 . 926 [RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, 927 Ed., "Control And Provisioning of Wireless Access Points 928 (CAPWAP) Protocol Specification", RFC 5415, 929 DOI 10.17487/RFC5415, March 2009, 930 . 932 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 933 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 934 2011, . 936 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 937 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 938 DOI 10.17487/RFC6282, September 2011, 939 . 941 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 942 Locator/ID Separation Protocol (LISP)", RFC 6830, 943 DOI 10.17487/RFC6830, January 2013, 944 . 946 [RFC7048] Nordmark, E. and I. Gashinsky, "Neighbor Unreachability 947 Detection Is Too Impatient", RFC 7048, 948 DOI 10.17487/RFC7048, January 2014, 949 . 951 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 952 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 953 2014, . 955 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 956 Interface Identifiers with IPv6 Stateless Address 957 Autoconfiguration (SLAAC)", RFC 7217, 958 DOI 10.17487/RFC7217, April 2014, 959 . 961 [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets 962 over ITU-T G.9959 Networks", RFC 7428, 963 DOI 10.17487/RFC7428, February 2015, 964 . 966 [RFC7559] Krishnan, S., Anipko, D., and D. Thaler, "Packet-Loss 967 Resiliency for Router Solicitations", RFC 7559, 968 DOI 10.17487/RFC7559, May 2015, 969 . 971 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 972 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 973 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 974 . 976 [RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy 977 Consumption of Router Advertisements", BCP 202, RFC 7772, 978 DOI 10.17487/RFC7772, February 2016, 979 . 981 [RFC8105] Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt, 982 M., and D. Barthel, "Transmission of IPv6 Packets over 983 Digital Enhanced Cordless Telecommunications (DECT) Ultra 984 Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May 985 2017, . 987 [RFC8163] Lynn, K., Ed., Martocci, J., Neilson, C., and S. 988 Donaldson, "Transmission of IPv6 over Master-Slave/Token- 989 Passing (MS/TP) Networks", RFC 8163, DOI 10.17487/RFC8163, 990 May 2017, . 992 11.3. External Informative References 994 [IEEEstd8021] 995 IEEE standard for Information Technology, "IEEE Standard 996 for Information technology -- Telecommunications and 997 information exchange between systems Local and 998 metropolitan area networks Part 1: Bridging and 999 Architecture". 1001 [IEEEstd80211] 1002 IEEE standard for Information Technology, "IEEE Standard 1003 for Information technology -- Telecommunications and 1004 information exchange between systems Local and 1005 metropolitan area networks-- Specific requirements Part 1006 11: Wireless LAN Medium Access Control (MAC) and Physical 1007 Layer (PHY) Specifications". 1009 [IEEEstd802151] 1010 IEEE standard for Information Technology, "IEEE Standard 1011 for Information Technology - Telecommunications and 1012 Information Exchange Between Systems - Local and 1013 Metropolitan Area Networks - Specific Requirements. - Part 1014 15.1: Wireless Medium Access Control (MAC) and Physical 1015 Layer (PHY) Specifications for Wireless Personal Area 1016 Networks (WPANs)". 1018 [IEEEstd802154] 1019 IEEE standard for Information Technology, "IEEE Standard 1020 for Local and metropolitan area networks -- Part 15.4: 1021 Low-Rate Wireless Personal Area Networks (LR-WPANs)". 1023 Authors' Addresses 1025 Pascal Thubert (editor) 1026 Cisco Systems, Inc 1027 Building D 1028 45 Allee des Ormes - BP1200 1029 MOUGINS - Sophia Antipolis 06254 1030 FRANCE 1032 Phone: +33 497 23 26 34 1033 Email: pthubert@cisco.com 1034 Charles E. Perkins 1035 Futurewei 1036 2330 Central Expressway 1037 Santa Clara 95050 1038 United States of America 1040 Email: charliep@computer.org