idnits 2.17.1 draft-thubert-bess-secure-evpn-mac-signaling-02.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 (18 January 2022) is 829 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) -- Possible downref: Normative reference to a draft: ref. 'I-D.thubert-6lo-multicast-registration' == Outdated reference: A later version (-21) exists of draft-ietf-rift-rift-15 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS P. Thubert, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track A. Przygienda 5 Expires: 22 July 2022 Juniper Networks, Inc 6 J. Tantsura 7 Microsoft 8 18 January 2022 10 Secure EVPN MAC Signaling 11 draft-thubert-bess-secure-evpn-mac-signaling-02 13 Abstract 15 This specification adds attributes to EVPN to carry IPv6 address 16 metadata learned from RFC 8505 and RFC 8928 so as to maintain a 17 synchronized copy of the 6LoWPAN ND registrar at each EVPN router and 18 perform locally a unicast IPv6 ND service for address lookup and 19 duplicate address detection. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 22 July 2022. 38 Copyright Notice 40 Copyright (c) 2022 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Revised BSD License text as 49 described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Revised BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 57 2.2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.3. References . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. 6LoWPAN Neighbor Discovery . . . . . . . . . . . . . . . . . 6 60 3.1. IPv6 Interface, Link, and Subnet . . . . . . . . . . . . 6 61 3.2. RFC 6775 Address Registration . . . . . . . . . . . . . . 10 62 3.3. RFC 8505 Extended Address Registration . . . . . . . . . 10 63 3.3.1. R Flag . . . . . . . . . . . . . . . . . . . . . . . 11 64 3.3.2. TID, "I" Field and Opaque Fields . . . . . . . . . . 11 65 3.3.3. Status . . . . . . . . . . . . . . . . . . . . . . . 12 66 3.3.4. Route Ownership Verifier . . . . . . . . . . . . . . 12 67 3.3.5. Anycast and Multicast Addresses . . . . . . . . . . . 13 68 3.4. RFC 8505 Extended DAR/DAC . . . . . . . . . . . . . . . . 13 69 3.5. RFC 7400 Capability Indication Option . . . . . . . . . . 14 70 4. Extending 6LoWPAN ND . . . . . . . . . . . . . . . . . . . . 15 71 4.1. Use of the R flag in NA . . . . . . . . . . . . . . . . . 15 72 4.2. Distributing the 6LBR . . . . . . . . . . . . . . . . . . 15 73 4.3. Unicast Address Lookup with the 6LBR . . . . . . . . . . 19 74 5. Requirements on the EVPN-Unaware Host . . . . . . . . . . . . 25 75 5.1. Support of 6LoWPAN ND . . . . . . . . . . . . . . . . . . 25 76 6. Enhancements to EVPN . . . . . . . . . . . . . . . . . . . . 26 77 6.1. ARP/ND Extended Community . . . . . . . . . . . . . . . . 28 78 6.2. ROVR MAC Mobility Extended Community . . . . . . . . . . 30 79 6.3. Extended ROVR MAC Procedures . . . . . . . . . . . . . . 31 80 7. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 31 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 42 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 83 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42 84 11. Normative References . . . . . . . . . . . . . . . . . . . . 42 85 12. Informative References . . . . . . . . . . . . . . . . . . . 44 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 88 1. Introduction 90 "Registration Extensions for IPv6 over 6LoWPAN Neighbor Discovery" 91 [RFC8505] (ND) provides a zeroconf routing-agnostic Host-to-Router 92 Link-Local interface for Stateful Address Autoconfiguration. 93 "Address-Protected Neighbor Discovery for Low-Power and Lossy 94 Networks" [RFC8928] (AP-ND) adds a zeroconf anti-theft protection 95 that protects the ownership of the autoconfigured address with 96 autoconfigured proof of ownership called a Registration Ownership 97 Verifier (ROVR). 99 [RFC8505] enables the host to claim an IPv6 address and obtain 100 reachability services for that address. It is already used to inject 101 host routes in RPL [RFC9010] and RIFT "Routing in Fat Trees" [RIFT], 102 and to maintain a proxy-ND state in a backbone router [RFC8929]; this 103 specification extends its applicability to the case of Ethernet 104 Virtual Private Network (EVPN). 106 [RFC8505] specifies a unicast address registration mechanism that 107 enables the host called a 6LowPAN Node (6LN) to install a ND binding 108 state in the 6LowPAN Router (6LR) that can serve as Neighbor Cache 109 Entry (NCE), though it is not operated as a cache. The protocol 110 provides the means to reject the registration in case of address 111 duplication. It also enables to discriminate mobility from 112 multihoming. [RFC8928] adds the capability to verify the ownership 113 of the address and prevent an attacker from stealing and/or 114 impersonating an address. 116 [RFC8505] defines the 6LoWPAN Border Router (6LBR) as an abstract 117 address registrar that provides authoritative service for Address 118 Registration and duplicate detection. The 6LBR stores address 119 metadata that is obtained during the Address Registration, including 120 an owner ID and a sequence counter. As part of the process of a new 121 Address Registration, the 6LR queries the 6LBR for existing metadata 122 related to the address being registered. This enables in particular 123 to detect a duplication and reject the registration. This 124 specification extends the 6LBR abstract data model to store the Link 125 Layer Address (LLA) of the Registering Node. This enables the 6LBR 126 to perform locally, and using unicast communication, the IPv6 ND 127 services of address lookup and duplicate address detection. 129 The [RFC8505] address registrar can be centralized, but it can also 130 be distributed and maintained synchronized using a routing protocol. 131 This specification adds attributes to EVPN to carry the IPv6 address 132 metadata learned from [RFC8505] so as to maintain a synchronized copy 133 of the 6LBR abstract data at each EVPN router. 135 2. Terminology 137 2.1. Requirements Language 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 141 "OPTIONAL" in this document are to be interpreted as described in BCP 142 14 [RFC2119] [RFC8174] when, and only when, they appear in all 143 capitals, as shown here. 145 2.2. Glossary 147 This document uses the following acronyms: 149 6CIO Capability Indication Option [RFC7400] 150 6LN: 6LoWPAN Node (the Host) [RFC6775] 151 6LR: 6LoWPAN router (the router) [RFC6775] 152 6LBR: 6LoWPAN Border router [RFC6775] 153 AMC: Address Mapping Confirmation [UNICAST-LOOKUP] 154 AMR: Address Mapping Request [UNICAST-LOOKUP] 155 ARO Address Registration Option [RFC6775] 156 CIPO: Crypto-ID Parameters Option 157 DAD: Duplicate Address Detection [RFC4862] 158 ICMPv6: Internet Control Message Protocol for IPv6 159 DAC Duplicate Address Confirmation [RFC6775] 160 DAR Duplicate Address Request [RFC6775] 161 EDAC Extended Duplicate Address Confirmation [RFC8505] 162 EDAR Extended Duplicate Address Request [RFC8505] 163 EARO: Extended Address Registration Option [RFC8505] 164 EVPN: Ethernet VPN [RFC7432] 165 LLA: Link-Layer Address (the MAC address on Ethernet) 166 LLN Low-Power and Lossy Network [RFC6550] 167 NA: Neighbor Advertisement [RFC4861] 168 NCE: Neighbor Cache Entry [RFC4861] 169 ND: Neighbor Discovery [RFC4861] 170 NDPSO: Neighbor Discovery Protocol Signature Option 171 NS: Neighbor Solicitation [RFC4861] 172 RA: Router Advertisement [RFC4861] 173 ROVR: Registration Ownership Verifier [RFC8505] 174 TID: Transaction ID (a sequence counter in the EARO) [RFC8505] 175 SLAAC: Stateless Address Autoconfiguration [RFC4862] 176 SLLAO: Source Link-Layer Address Option [RFC4861] 177 TLLAO: Target Link-Layer Address Option [RFC4861] 178 ROVR MAC: MAC obtained from a host meeting requirements in Section 5 179 Validated ROVR MAC: ROVR MAC validated by procedures specified in 180 [RFC8928] 181 ROVR Node: EVPN node capable of advertising ROVR MACs 182 non-ROVR Node: EVPN node not supporting extensions defined in this 183 document. 184 VPN: Virtual Private Network 186 2.3. References 188 This document uses the terms Clos fabric and Fat Tree 189 interchangeably, to refer to a folded spine-and-leaf topology as 190 defined in the terminology section of "RIFT: Routing in Fat Trees" 191 [RIFT]. 193 The term "leaf" represents the access switch that connects the 194 servers to the Fat Tree. The leaf is typically a Top-of-Rack (ToR) 195 switch. 197 This specification uses the terms 6LN, 6LR and 6LBR to refer 198 specifically to nodes that implement the said roles in [RFC8505] and 199 does not expect other functionality such as 6LoWPAN Header 200 Compression: 202 * In the context of this document, the 6LN is a server that 203 advertises an address mapping using [RFC8505], and optionally 204 protects its ownership with [RFC8928]. 206 * The 6LR and 6LBR function are collapsed at the leaf and its state 207 is synchronized with that of the EVPN functional support using an 208 internal interface that is out of scope. That interface could be 209 "pull" meaning that the 6LBR fetches the EVPN information when it 210 needs it, or "push", meaning that any information that EVPN 211 distributes is immediately fed in all the 6LBRs in all the leaves. 212 Note that this is pure control plane and is not subject to 213 abbreviating optimization as the FIB may be. 215 In this document, readers will encounter terms and concepts that are 216 discussed in the following documents: 218 EVPN: "BGP MPLS-Based Ethernet VPN" [RFC7432] and "Network 219 Virtualization Overlay Solution" [RFC8365], 221 Classical IPv6 ND: "Neighbor Discovery for IP version 6" [RFC4861] 222 and "IPv6 Stateless Address Autoconfiguration" [RFC4862], 224 6LoWPAN ND: Neighbor Discovery Optimization for Low-Power and Lossy 225 Networks [RFC6775], "Registration Extensions for 6LoWPAN Neighbor 226 Discovery" [RFC8505], "Address Protected Neighbor Discovery for 227 Low-power and Lossy Networks" [RFC8928], and "IPv6 Backbone 228 Router" [RFC8929]. 230 3. 6LoWPAN Neighbor Discovery 232 6LoWPAN Neighbor Discovery defines a stateful address 233 autoconfiguration mechanism for IPv6. 6LoWPAN ND enables to divorce 234 the L3 abstractions for link and subnet from the characteristics of 235 the L2 link and broadcast domain. It is applicable beyond its 236 original field of IoT to any environment where the broadcast nature 237 of the underlaying network should not be exploited, e.g., in the case 238 of a wireless link where broadcast uses an excessive amount of 239 spectrum, and a distributed cloud, where it may span too widely. 241 In contrast to Stateless Address Autoconfiguration (SLAAC) [RFC4862] 242 which relies on broadcast for duplicate address detection (DAD) and 243 address lookup, 6LoWPAN ND installs and maintains a state in the 244 neighbors for the duration of their interaction. Though it is also 245 called a Neighbor Cache Entry (BCE) in [RFC6775], and in contrast 246 with the the BCE in SLAAC, that state is not a cache that can be 247 casually flushed and rebuilt. It must be installed proactively and 248 refreshed periodically to maintain the connectivity and enable 249 unicast-only operations. 251 This section goes through the 6LoWPAN ND network abstractions and 252 mechanisms that this specification leverages, as a non-normative 253 reference to the reader. The relevant normative text is to be found 254 in [RFC6775], [RFC8505], and [RFC8928]. 256 3.1. IPv6 Interface, Link, and Subnet 258 The typical abstraction for an IP Link with 6LoWPAN ND is a logical 259 point-to-point (P2P) link between a node (a host or a router) and a 260 router, regardless of the physical medium between the node and the 261 router, which may or may not be shared with other nodes. 263 A Subnet is deployed over a mesh of nodes connected with those 264 logical P2P Links, where routers form a connected dominating set as 265 represented in Figure 1; the resulting aggregate is called a 266 multilink subnet (MLSN). An MLSN may be only partially meshed, and 267 the underlaying network is not expected to provide a multicast or a 268 broadcast service across the subnet. 270 +------+ +------+ 271 | Host |----------+ +-----| Host | 272 +------+ | | +------+ 273 | +--------+ 274 | +-------| Router | 275 | | +--------+ 276 +--------+ | | +------+ 277 | Router | | +------ | Host | 278 +--------+ | +------+ 279 | | +--------+ 280 | +---| Router | 281 | +--------+ 282 +------+ | | +------+ 283 | Host |-----+ +-----| Host | 284 +------+ +------+ 286 Figure 1: PPP Links in an NBMA Mesh 288 Consequently, the subnet model is not-on-link, meaning that the any- 289 to-any connectivity across the subnet is ensured through L3 290 operations (routing or proxy) as opposed to transitive (any-to-any) 291 reachability from L2. It also means that hosts do not lookup other 292 nodes using IPv6 Neighbor Discovery but forward all their traffic via 293 their connected routers. Which in turn means that only routers need 294 to be discovered, which is done by sending Router Advertisement (RA) 295 messages to all directly reachable nodes in the subnet, e.g., using a 296 radio broadcast. 298 As illustrated in Figure 2, an IP interface bundles multiple sub- 299 interfaces to connect the IP links between this node and peers in the 300 same subnet, which is known as a point-to-multipoint (P2MP) 301 interface. 303 +--------------------- 304 | P2MP Interface 305 | -------------- 306 | MAC Address 307 | IPv6 Link-Local address(es) 308 | IPv6 global addresses 309 | 310 | +------------------------ 311 | | P2P sub-interface 312 | | ----------------- 313 | | Peer MAC Address 314 | | Peer IP addresses 315 | +------------------------ 316 | 317 | +------------------------ 318 | | P2P sub-interface 319 | | ----------------- 320 | | Peer MAC Address 321 | | Peer IP addresses 322 | +------------------------ 323 | 324 | +------------------------ 325 | | P2P sub-interface 326 | | ----------------- 327 | | Peer MAC Address 328 | | Peer IP addresses 329 | +------------------------ 330 | 331 | .... 332 | 333 +--------------- 335 Figure 2: P2MP Interface 337 In the case of a 6LoWPAN radio, the IP Interface may be physical, and 338 the P2P IP links are virtual based on discovered neighbor routers; 339 the same model can apply when the node is connected via a switch to 340 one or more routers. 342 In the case of a multihomed NIC card in a datacenter, the NIC is 343 connected to several Top-of-Rack (ToR) switches acting as leaves in 344 the fabric, over as many Ethernet physical interfaces. If the NIC 345 provides a L2 virtual switch, then the stack can apply the same model 346 as above, modeling the virtual port to the virtual switch as a P2MP 347 interface. 349 On the other hand, if the NIC provides a virtual router, then 350 Ethernet ports are L3 ports and the physical link to the leaf is 351 modeled as P2P. To form the P2MP interface, the router bundles 352 (aggregates) the physical interfaces as the sub-interfaces of a 353 single logical P2MP Link, as shown in Figure 3. 355 +--------------------- 356 | NIC Aggregate interface 357 | ----------------------- 358 | virtual MAC Address 359 | IPv6 global addresses 360 | 361 | +------------------------ 362 | | Ethernet Port 1 363 | | ----------------- 364 | | Physical MAC Address 365 | | IPv6 Link-Local address(es) 366 | | Leaf MAC Address 367 | | Leaf IP addresses 368 | +------------------------ 369 | 370 | +------------------------ 371 | | Ethernet Port 2 372 | | ----------------- 373 | | Physical MAC Address 374 | | IPv6 Link-Local address(es) 375 | | Leaf MAC Address 376 | | Leaf IP addresses 377 | +------------------------ 378 | 379 | .... 380 | 381 +--------------- 383 Figure 3: Logical P2MP Interface 385 To conserve the same model, it makes sense to configure the same 386 (virtual) MAC address on all the physical interfaces, and use it for 387 the purpose of IPv6 ND. In that case, the same MAC address is 388 exposed as Link-layer Address (LLA) to both leaves for the NIC IP 389 addresses, and the IPv6 address still appears as unicast. Note that 390 the Link-Local addresses used to register the global IPv6 addresses 391 to the leaf may be different but that does not affect the exposed 392 mapping. 394 When that is not possible, then the same IP address is advertised 395 with the physical MAC address of each port as the LLA over that port. 396 In that case, the global IPv6 address appears as anycast, and SHOULD 397 be advertised as such, more in Section 3.3.5. 399 3.2. RFC 6775 Address Registration 401 The classical "IPv6 Neighbor Discovery (IPv6 ND) Protocol" [RFC4861] 402 [RFC4862] was defined for serial links and transit media such as 403 Ethernet. It is a reactive protocol that relies heavily on multicast 404 operations for Address Discovery (aka Lookup) and Duplicate Address 405 Detection (DAD). 407 "Neighbor Discovery Optimizations for 6LoWPAN networks" [RFC6775] 408 adapts IPv6 ND for operations over energy-constrained LLNs. The main 409 functions of [RFC6775] are to proactively establish the Neighbor 410 Cache Entry (NCE) in the 6LR and to prevent address duplication. To 411 that effect, [RFC6775] introduces a new unicast Address Registration 412 mechanism that contributes to reducing the use of multicast messages 413 compared to the classical IPv6 ND protocol. 415 [RFC6775] defines a new Address Registration Option (ARO) that is 416 carried in the unicast Neighbor Solicitation (NS) and Neighbor 417 Advertisement (NA) messages between the 6LoWPAN Node (6LN) and the 418 6LoWPAN router (6LR). It also defines the Duplicate Address Request 419 (DAR) and Duplicate Address Confirmation (DAC) messages between the 420 6LR and the 6LBR. In a Low-Power and Lossy Network (LLN), the 6LBR 421 is the central repository of all the Registered Addresses in its 422 domain and the authoritative source of truth for uniqueness and 423 ownership. 425 3.3. RFC 8505 Extended Address Registration 427 "Registration Extensions for 6LoWPAN Neighbor Discovery" [RFC8505] 428 updates RFC 6775 into a generic Address Registration mechanism that 429 can be used to access services such as routing and ND proxy. To that 430 effect, [RFC8505] defines the Extended Address Registration Option 431 (EARO), shown in Figure 4: 433 0 1 2 3 434 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | Type | Length | Status | Opaque | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Rsvd | I |R|T| TID | Registration Lifetime | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | | 441 ... Registration Ownership Verifier ... 442 | | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 Figure 4: EARO Option Format 447 3.3.1. R Flag 449 [RFC8505] introduces the R Flag in the EARO. The Registering Node 450 sets the R Flag to indicate whether the 6LR should ensure 451 reachability for the Registered Address. If the R Flag is set to 0, 452 then the Registering Node handles the reachability of the Registered 453 Address by other means. In an EVPN network, this means that either 454 it is a RAN that injects the route by itself or that it uses another 455 EVPN router for reachability services. 457 This document specifies how the R Flag is used in the context of 458 EVPN. An EVPN Host that implements the 6LN functionality from 459 [RFC8505] requires reachability services for an IPv6 address if and 460 only if it sets the R Flag in the NS(EARO) used to register the 461 address to a 6LR acting as an EVPN border router. Upon receiving the 462 NS(EARO), the EVPN router generates a BGP advertisement for the 463 Registered Address if and only if the R flag is set to 1. 465 [RFC9010] specifies that the 'R' flags is set in the responded NA 466 messages if and only if the route was installed. This specification 467 echoes that behavior. 469 3.3.2. TID, "I" Field and Opaque Fields 471 When the T Flag is set to 1, the EARO includes a sequence counter 472 called Transaction ID (TID), that is needed to format the MAC 473 Mobility Extended Community. This is the reason why the support of 474 [RFC8505] by the Host, as opposed to only [RFC6775], is a 475 prerequisite for this specification); this requirement is fully 476 explained in Section 5.1. The EARO also transports an Opaque field 477 and an associated "I" field that describes what the Opaque field 478 transports and how to use it. 480 This document specifies the use of the "I" field and the Opaque field 481 by a Host. 483 3.3.3. Status 485 The values of the EARO status are maintained by IANA in the Address 486 Registration Option Status Values subregistry [IANA-EARO-STATUS] of 487 the Internet Control Message Protocol version 6 (ICMPv6) Parameters 488 registry. 490 [RFC6775] and [RFC8505] defined the original values whereas [RFC9010] 491 reduced range to 64 values and reformatted the octet field to enable 492 to transport an external error, e.g., coming form a routing protocol. 494 This specification uses the format expressed in [RFC9010]. The value 495 of 0 denotes an unqualified success, 1 indicates an address 496 duplication, 3 a TID value that is outdated, and 4 is used in an 497 asynchronous NA to indicate that 6LN should remove that address and 498 possibly form new ones. 500 3.3.4. Route Ownership Verifier 502 Section 5.3 of [RFC8505] introduces the Registration Ownership 503 Verifier (ROVR) field of variable length from 64 to 256 bits. The 504 ROVR is a replacement of the EUI-64 in the ARO [RFC6775] that was 505 used to identify uniquely an Address Registration with the Link-Layer 506 address of the owner but provided no protection against spoofing. 508 "Address Protected Neighbor Discovery for Low-power and Lossy 509 Networks" [RFC8928] leverages the ROVR field as a cryptographic proof 510 of ownership to prevent a rogue third party from registering an 511 address that is already owned. The use of ROVR field enables the 6LR 512 to block traffic that is not sourced at an owned address. 514 This specification does not address how the protection by [RFC8928] 515 could be extended for use in EVPN. On the other hand, it adds the 516 ROVR to the BGP advertisement to share the state with the other 517 routers via the Reflector (see Section 6.2), which means that the 518 routers that are aware of the Host route are also aware of the ROVR 519 associated to the Target Address, whether it is cryptographic and 520 should be verified. 522 3.3.5. Anycast and Multicast Addresses 524 "IPv6 Neighbor Discovery Multicast Address Registration" 525 [I-D.thubert-6lo-multicast-registration] updates [RFC8505] to enable 526 the address registration of IPv6 anycast and multicast addresses. 527 From the host perspective, the registration is very similar to that 528 of unicast addresses, but for a flag in the EARO that signals that 529 the address is multicast or anycast. 531 This procedure can be used as a replacement to "Multicast Listener 532 Discovery Version 2 (MLDv2) for IPv6" [RFC3810] for source- 533 independant multicast operation. As for unicast, the method saves 534 the need for the host to listen to pollings from the router, and 535 allows the host to sleep for periods of time. 537 3.4. RFC 8505 Extended DAR/DAC 539 [RFC8505] updates the DAR/DAC messages to EDAR/EDAC messages to carry 540 the ROVR field. The EDAR/EDAC exchange takes place between the 6LR 541 to which the node registers an address, and the abstract 6LBR that 542 stores the reference value for the ROVR and the TID associated to 543 that address. It is triggered by an NS(EARO) message from a 6LN to 544 the 6LR, to create, refresh, compare and delete the corresponding 545 state in the 6LBR. 547 In the status returned with the EDAC message, the 6LBR indicates if 548 the registration is accepted, should be challenged, or is duplicate. 549 The status of 0 (success) indicates that the address is either new or 550 that the current registration matches, and in particular that the 551 ROVR at the 6LBR and the one in the EDAR message are identical. 553 6LN 6LR 6LBR 554 | | | 555 | IP Link | subnetwork | 556 | | | 557 | NS(EARO) | | 558 |---------------->| | 559 | | | 560 | | EDAR | 561 | |------------------>| 562 | | | 563 | | EDAC(status) | 564 | |<------------------| 565 | | | 566 | NA(EARO) | | 567 |<----------------| | 568 | | | 570 Figure 5: EDAR/EDAC flow 572 The EDAR/EDAC exchange is protected by the retry mechanism specified 573 in Section 8.2.6 of [RFC6775], though in a data center, a duration 574 significantly shorter than the default value of the Retransmission 575 Timer [RFC4861] of 1 second may be sufficient to cover the round-trip 576 delay between the 6R and the 6LBR. 578 With this specification, the 6LBR is distributed across the leaves, 579 and all the leaves where an address is currently registered maintain 580 a full 6LBR state for the address, aka local state in the following 581 text. The specification leverages the EDAR/EDAC exchange to ensure 582 that a leaf (acting as a 6LR) that needs to create a 6LBR state for a 583 new registration has the same value for the ROVR as any 6LBR already 584 serving that address on another leaf. At the same time, the 585 specification avoids placing full ROVR information in BGP so 1) it is 586 not observable by a potential attacker and 2) the new attributes 587 remain reasonably small. 589 3.5. RFC 7400 Capability Indication Option 591 "6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power 592 Wireless Personal Area Networks (6LoWPANs)" [RFC7400] defines the 593 6LoWPAN Capability Indication Option (6CIO) that enables a node to 594 expose its capabilities in router Advertisement (RA) messages. 596 [RFC8505] defines a number of bits in the 6CIO, in particular: 598 L: Node is a 6LR. 599 E: Node is an IPv6 ND Registrar -- i.e., it supports registrations 600 based on EARO. 601 P: Node is a Routing Registrar, -- i.e., an IPv6 ND Registrar that 602 also provides reachability services for the Registered Address. 604 0 1 2 3 605 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | Type | Length = 1 | Reserved |D|L|B|P|E|G| 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | Reserved | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 Figure 6: 6CIO flags 614 A 6LR that provides reachability services for a Host in an EVPN 615 network as specified in this document includes a 6CIO in its RA 616 messages and set the L, P and E flags to 1 as prescribed by 617 [RFC8505]. 619 4. Extending 6LoWPAN ND 621 4.1. Use of the R flag in NA 623 This document extends [RFC8928] and [RFC8505] as follows 625 This document also updates the behavior of a 6LR acting as EVPN 626 router and of a 6LN acting as Host in the 6LoWPAN ND Address 627 Registration as follows: 629 * The use of the R Flag is extended to the NA(EARO) to confirm 630 whether the route was installed. 632 4.2. Distributing the 6LBR 634 This specification enables to distribute the 6LBR at the edge of the 635 EVPN network and collapse the 6LBR function with that of the EVPN 636 support. In that model, the EVPN to 6LBR interaction becomes an 637 internal interface, where each side informs the other in case of new 638 information concerning an IP to Link-Layer Address (LLA) mapping. 639 Since this is an internal interface, this specification makes no 640 assumption on whether the 6LBR stores its own representation of the 641 full EVPN state, which means that the EVPN support informs the 6LBR 642 in case of any change on the EVPN side (this is called the push 643 model, see Figure 13), or if the 6LBR queries the EVPN support when 644 it does not have a mapping to satisfy a request (pull model, see 645 Figure 12). 647 This specification leverages [RFC8929] that augments the abstract 648 data model of the 6LBR to store the LLA associated with the 649 registered address. Based on that additional state, the 6LBR in a 650 leaf can communicate the mapping to the collocated EVPN function and 651 respond to unicast address mapping lookups from the server side. 653 In an environment where the server ranges from a classical host to a 654 more complex platform that runs a collection of virtual hosts 655 interconnected by a virtual switch, but where the host-to-leaf 656 interface remains at layer 2, the 6LR and the 6LBR functions can be 657 collapsed in the leaf. The 6LR to 6LBR interaction also becomes an 658 internal interface, and there is no need for EDAR/EDAC messages. 660 In that case, the MAC address associated to the Registered Address is 661 indicated in the Target Link-Layer Address Option (TLLAO) in the NS 662 message used for the registration, as shown in Figure 7. In the case 663 of a pull model, if the 6LBR does not have a local state for the 664 mapping, it queries the EVPN support to obtain the EVPN state if any. 665 If a mapping is known then the 6LR/6LBR evaluates the registration 666 for address duplication and other possible issues per [RFC8505]. 667 Else (this is for a new mapping), if the registration is accepted, 668 then the 6LBR notifies the EVPN support to inject a route type 2 in 669 the fabric. 671 Server Leaf 672 +--------------+ +-------------------+ 673 | | | | 674 6LN 6LR/6LBR EVPN 675 | | | 676 | Ethernet | | 677 | | | 678 | NS(EARO) | | 679 |------------------->| | 680 | | | ^ 681 | | query | | 682 | |----------->| | if pull 683 | | response | | model 684 | |<-----------| | 685 | | v 686 | Evaluation (DAD) | 687 | | 688 | |new mapping | 689 | | indication | 690 | |----------->| 691 | | Inject/maintain 692 | store a mapping state | EVPN route type 2 693 | | ------------------> 694 | NA(EARO) | | [via BGP signaling] 695 |<-------------------| | 696 | | | 698 Figure 7: Direct Registration 700 In another type of deployment, the 6LR may be a virtual router in the 701 server whereas the 6LBR runs in the leaf node. To address that case, 702 the EDAR/EDAC may be used to communicate as shown in figure 5 of 703 [RFC8505]. This draft leverages the capability to insert IPv6 ND 704 options in the EDAR and EDAC messages introduced in [RFC8929] to 705 place a TLLAO that carries the MAC address associated to the 706 Registered address in the EDAR and EDAC messages as shown in 707 Figure 8: 709 Server Leaf 710 +----------------+ +----------------+ 711 | | | | 712 6LN 6LR 6LBR EVPN 713 | | | | 714 | | Ethernet | | 715 | | | | 716 | NS(EARO) | | | 717 |----------->| | | 718 | | EDAR(TLLAO) | | 719 | |------------->| | 720 | | | | ^ 721 | | | query | | 722 | | |----------->| | if pull 723 | | | response | | model 724 | | |<-----------| | 725 | | | v 726 | | Evaluation (DAD) | 727 | | | 728 | | |new mapping | 729 | | | indication | 730 | | |----------->| 731 | | | Inject/maintain 732 | | store a mapping state | EVPN route type 2 733 | | | ------------------> 734 | | EDAC(TLLAO) | | [via BGP signaling] 735 | |<-------------| | 736 | NA(EARO) | | | 737 |<-----------| | | 738 | | | | 740 Figure 8: leveraging EDAR 742 [RFC8505] updates the DAR/DAC messages into the Extended DAR/DAC to 743 carry the ROVR field. With this specification, the abstract 6LBR is 744 distributed in all the Leaf nodes and synchronized with EVPN. When a 745 server successfully registers an address to a leaf, the 6LR on that 746 leaf becomes 6LBR for that address. It stores the full state for 747 that address including the ROVR and the TID. When the address 748 registration moves to another leaf, an EDAR/EDAC flow between the 6LR 749 in the new leaf and the 6LBR in the old leaf confirms that the ROVR 750 in the NS(EARO) received at the new leaf is correct, in which case 751 the 6LR in the new leaf becomes 6LBR. 753 When the address is already registered to the local leaf, the EDAR/ 754 EDAC exchange is either local between a virtual router in the server 755 and the leaf, or internal to the leaf between a collapsed 6LR and 756 6LBR. Based on its local state, the 6LBR in the leaf checks whether 757 the proposed address/route is new and legit, and can reject it 758 otherwise. 760 It results that duplicate addresses and address impersonation attacks 761 can be filtered at the level of IPv6 ND by the 6LBR before the 762 information reaches EVPN. 764 4.3. Unicast Address Lookup with the 6LBR 766 A classical IPv6 ND stack in the server that treats the subnet prefix 767 as on-link (more in section 4.6.2. of [RFC4861]), will resolve an 768 unknown LLA mapping with a multicast NS(lookup) message addressed to 769 the solicited node multicast address (SNMA) associated with the 770 destination address being resolved. The RECOMMENDED operation in 771 that case is for the 6LBR that has a mapping state to forward the 772 packet as a unicast MAC to the LLA that is stored for the IPv6 773 address as expected by [RFC6085]. The actual owner of the address 774 can then answer unicast with a NA message, setting the override (O) 775 bit to 1, as shown in Figure 9. 777 Local Local Remote 778 Server Leaf Server 779 +----+ +--------+ +----+ 780 | | | | | | 781 6LN 6LR/6LBR 6LN 782 | | | 783 | Ethernet | | 784 | | [via EVPN ] | 785 | multicast | [Data Tunnels] | 786 | NS(lookup) | | 787 |---------------->| | 788 | | forward unicast | 789 | | NS(lookup) | 790 | |---------------------->| 791 | | | 792 | | NA(O) | 793 | |<----------------------| 794 | NA(O) | | 795 |<----------------| | 796 | | | 798 Figure 9: Forwarding legacy NS (Lookup) 800 Section 3.1. of [RFC8929] adds the capability to insert IPv6 ND 801 options in the EDAR and EDAC messages. This enables the 6LBR to 802 store the link-layer address associated with the Registered Address 803 and to serve as a mapping server. [UNICAST-LOOKUP] leverages that 804 state to define a new unicast address lookup operation, extending the 805 EDAR and EDAC messages as the Address Mapping Request (AMR) and 806 Confirmation (AMC) with a different Code Prefix [RFC8505]. 808 In that model, the router advertises the subnet prefix as not on-link 809 by setting the L flag to 0 in the Prefix Information Option (PIO), 810 more in section 4.6.2. of [RFC4861]. The expected behavior is that 811 the host that communicates with a peer in the same subnet refrains 812 from resolving the address mapping and passes the packets directly to 813 the router. 815 In the case where the router is a virtual 6LR running in the server, 816 and the source and destination are in the same subnet served by EVPN, 817 the router then resolves the address mapping on behalf of the host. 818 To that effect, the router sends a unicast AMR message to the 6LBR. 819 The message contains the SLLAO of the router to which the 6LBR will 820 reply. If the binding is found, the 6LBR replies with an AMC message 821 that contains the TLLOA with the requested MAC address, as shown in 822 Figure 10. 824 Local Local Remote 825 Server Leaf Server 826 +----------------+ +---------+ +----+ 827 | | | | | | 828 6LN 6LR 6LBR/EVPN 6LN 829 | | | | 830 | | | [via EVPN ] | 831 | | Ethernet | [Data Tunnels] | 832 | | | | 833 | | | | 834 | RA(PIO) | | | 835 | not onlink | | | 836 |<-----------| | | 837 | | | | 838 | Packet | | | 839 |----------->| | | 840 | | | | 841 | | AMR (SLLAO) | | 842 | |------------->| | 843 | | | | 844 | | AMC (TLLAO) | | 845 | |<-------------| | 846 | | | | 847 | NCE in STALE state | | 848 | | | 849 | | Packet | 850 | |------------------------------->| 851 | | | 852 | NCE in DELAY state | | 853 | | | | 855 Figure 10: Unicast Lookup from the virtual Host 857 If it is not found, [UNICAST-LOOKUP] provides the capability to 858 indicate immediately that the mapping is not known with a "not found" 859 status in the AMC, as opposed to waiting for an NS(lookup) and 860 retries to time out per [RFC4861]. 862 In a fully stateful subnet where all nodes register all their 863 addresses with [RFC8505], this means that the looked up address is 864 not present in the network; in that case the packet is dropped and an 865 ICMP error type 1 "Destination Unreachable" code 3 "Address 866 unreachable" [RFC4443] is returned as shown in Figure 11. 868 Local Local 869 Server Leaf 870 +----------------+ +---------+ 871 | | | | 872 6LN 6LR 6LBR/EVPN 873 | | | 874 | | | 875 | | Ethernet | 876 | | | 877 | | | 878 | RA(PIO | | 879 |not on-link)| | 880 |<-----------| | 881 | | | 882 | Packet | | 883 |----------->| | 884 | | | 885 | | AMR (SLLAO) | 886 | |------------->| 887 | | | 888 | | AMC(status= | 889 | | "Not Found") | 890 | |<-------------| 891 |ICMPv6 Error| | 892 | "Address | | 893 |Unreachable"| | 894 |<-----------| | 895 | Drop Packet | 896 | | | 898 Figure 11: Unicast Lookup failure 900 Note that the figures above make no assumption on the pull vs. push 901 model. In the case of pull model, the 6LBR queries the EVPN support 902 when it does not have the mapping information to satisfy a request. 903 Figure 12 illustrates a successful pull model lookup flow, when the 904 route type 2 for the mapping is already known on the EVPN side. 906 Server Leaf 907 +----------------+ +----------------+ 908 | | | | 909 6LN 6LR 6LBR EVPN 910 | | | | 911 | | Ethernet | | 912 | | | | 913 | | | | 914 | | | | Receive EVPN 915 | | | | route type 2 for 916 | | | | remote address A' 917 | | | | [via BGP signaling] 918 | | | |<----------------- 919 | | | store a mapping state 920 | | | | 921 |Packet for A' | | 922 |----------->| | | 923 | |AMR(lookup A')| | 924 | |------------->| | 925 | | |Query addr A' 926 | | |----------->| 927 | | | | 928 | | | return LLA | 929 | | |<-----------| 930 | | | | 931 | |AMC(A''s TLLA)| | 932 | |<-------------| | 933 | | | | 934 | | Packet for A' | 935 | | [via EVPN ] | 936 | | [Data Tunnels] | 937 | |-----------------------------------> 938 | | | | 940 Figure 12: Pull model 942 In the case of push model, the EVPN support synchronizes its state 943 upon a route type 2 with the 6LBR, and the 6LBR maintains an abstract 944 data structure for all information known to EVPN. This way, the 6LBR 945 already has the mapping information to satisfy any request for an 946 existing mapping and it can answer right away. Figure 13 illustrates 947 a successful push model lookup flow, when the 6LBR is already in 948 possession of the mapping. 950 Server Leaf 951 +----------------+ +----------------+ 952 | | | | 953 6LN 6LR 6LBR EVPN 954 | | | | 955 | | Ethernet | | 956 | | | | 957 | | | | 958 | | | | 959 | | | | Receive EVPN 960 | | | | route type 2 for 961 | | | | remote address A' 962 | | | | [via BGP signaling] 963 | | | |<----------------- 964 | | | store a mapping state 965 | | | | 966 | | |indicate LLA| 967 | | |<-----------| 968 | | store a mapping state | 969 | | | | 970 |Packet to A'| | | 971 |----------->| | | 972 | |AMR(lookup A')| | 973 | |------------->| | 974 | | | | 975 | |AMC(A's TLLA) | | 976 | |<-------------| | 977 | | | | 978 | | Packet to A' | 979 | | [via EVPN ] | 980 | | [Data Tunnels] | 981 | |-----------------------------------> 982 | | | | 984 Figure 13: Push model 986 In a mixed environment, a lookup failure (the mapping is not found 987 though the address is present in the network) may be caused by a 988 legacy node that was node discovered (aka a silent node). In that 989 case, it is an administrative decision for the 6LR to broadcast an 990 NS(lookup) or to return an error as shown in Figure 11. 992 5. Requirements on the EVPN-Unaware Host 994 This document describes how EVPN routing can be extended to reach a 995 Host. This section specifies the minimal EVPN-independent 996 functionality that the Host needs to implement to obtain routing 997 services for its addresses. 999 5.1. Support of 6LoWPAN ND 1001 A host sees a prefix as not on-link (e.g., it learned that prefix in 1002 a PIO in a RA with the L flag not set) should not attempt to resolve 1003 an address within that prefix using a multicast NS(lookup). Instead, 1004 it must pass its packets to a router, preferably one that advertises 1005 that prefix in a PIO; it must register the address that it uses as 1006 source to that router to enable source address validation using 1007 [RFC8505]. It is recommended that the Host also implements [RFC8928] 1008 to prove its ownership of its addresses. 1010 The Host is expected to request routing services from a router only 1011 if that router originates RA messages with a 6CIO that has the L, P, 1012 and E flags all set to 1 as discussed in Section 3.5, unless 1013 configured to do so. To obtain routing services for one of its 1014 addresses, the host must register the address to a router that 1015 advertises the prefix, setting the "R" and "T" flags in the EARO to 1 1016 as discussed in Section 3.3.1 and Section 3.3.2, respectively. 1018 This document echoes the behavior specified in [RFC9010] whereby, 1019 when the R Flag set to 1 in a NS(EARO) is not echoed in the NA(EARO), 1020 the host must understand that the route injection failed, and if the 1021 R flag is reset later in an asynchronous NA(EARO), the host must 1022 understand that routing service has failed. 1024 The host may attach to multiple 6LRs and is expected to prefer those 1025 that provide routing services. The abstract model for this is a P2MP 1026 interface that wraps together as many P2P IP Links the host has 1027 adjacencies to 6LRs over that interface. The IPv6 address and the 1028 subnet are associated to that interface. The interface may be 1029 virtual and it may bundle multiple physical Ethernet interfaces that 1030 connect to the individual 6LRs over point to point wires, possibly 1031 via a software switch. It can also be associated to one physical 1032 interface to an external switch, either way the PI Links can be 1033 associated to sub-interface of the interface. 1035 The Host needs to register to all the 6LRs from which it desires 1036 routing services. The multiple Address Registrations to several 6LRs 1037 should be performed in a rapid sequence, using the same EARO for the 1038 same Address. Gaps between the Address Registrations will invalidate 1039 some of the routes till the Address Registration finally shows on 1040 those routes. The routers recognize the same (ROVR, TID) as the 1041 signal of a multihomed address and maintain all the routes. In the 1042 case of EVPN, the Ethernet Segment must also be the same. The flow 1043 for a successful multihomed registration is illustrated in Figure 17. 1045 [RFC8505] introduces error Status values in the NA(EARO) which can be 1046 received synchronously upon an NS(EARO) or asynchronously. The Host 1047 needs to support both cases and refrain from using the address when 1048 the Status value indicates a rejection. 1050 This specification can be used to register Anycast and Multicast IPv6 1051 addresses as discussed in Section 3.3.5 and replace MLDv2. To 1052 benefit from that capability, both the host and the 6LR MUST support 1053 the "A" and "M" flags that indicate Anycast and Multicast Addresses 1054 respectively. Those flags are defined in 1055 [I-D.thubert-6lo-multicast-registration] for use in the EARO and in 1056 the EDAR and EDAC messages. 1058 6. Enhancements to EVPN 1060 This section addresses the necessary changes to EVPN formats and 1061 behavior to support address registration security per [RFC8928] and 1062 mobility per [RFC8505] while retaining interoperability with 1063 traditional nodes. Basically the MAC Mobility Extended Community 1064 [RFC7432] and the ARP/ND Extended Community [RFC9047] are extended to 1065 advertise the sequencing and ownership validation information 1066 received in the EARO. With 6LR injecting not only MACs via packet 1067 sources and TLLAO options but also ROVR into MAC Mobility and ARP/ND 1068 Extended Community, their semantics will be somewhat extended. 1069 Specifically following issues have to be addressed: 1071 * The ROVR extends the semantics of the type-2 MAC advertisement via 1072 changes in ARP/ND and MAC Mobility Extended Community in the sense 1073 that the MAC must be aligned with the ROVR and under normal 1074 circumstances only the validity of ROVR guarantees that the type-2 1075 MAC can be allocated to the requester. A MAC validated by ROVR 1076 should take precedence over MAC addresses allocated without using 1077 it given it presents a much more trustworthy topological 1078 information (it will be called ROVR MAC in further text). EVPN 1079 nodes not supporting extensions introduced by this document will 1080 need to be led to believe that a ROVR MAC is to be preferred over 1081 any advertisement they see as long a ROVR MAC route is present. 1082 Nevertheless, primary key of NRLI is still the (IP, MAC, Ethernet 1083 Tag ID) tuple as defined in [RFC7432], Section 7.2 and 7.7. This 1084 implies that the same MAC (and consequently ROVR MAC) can be 1085 assigned multiple IP addresses and those represent independent 1086 NLRIs. 1088 * The TID field in the EARO is smaller than the mobility sequence 1089 number in [RFC7432]. To allow a ROVR MAC mobility to "win" over 1090 legacy MACs in every circumstance, signaling must be introduced 1091 that enables to distinguish a TID-generated sequence number from a 1092 legacy sequence number. 1094 * [RFC8505] supports IP multihoming, but does not differentiate 1095 multihoming from anycast, e.g., using the MAC address, to enable 1096 MAC address rotation. If an anycast IP address is registered with 1097 a different ROVR it will be rejected as duplicate. If it is 1098 registered with a different TID, the older sequence will be 1099 withdrawn. So the basic expectation with [RFC8505] is that the 1100 advertisement of an anycast address is coordinated, with the same 1101 keypair known to all parties, and the same value of the TID used 1102 by all nodes (and possibly never increasing), in other words, with 1103 no concept of mobility. 1105 * [I-D.thubert-6lo-multicast-registration] adds new flags in the 1106 EARO to signal that an address is anycast or multicast, 1107 respectively. This specification injects that information in the 1108 ARP/ND extended community using matching flags as follows: 1110 - This specification uses the "O" flag in the ARP/ND extended 1111 community to signal that the IP address is anycast, and 1112 requires the local 6LBR to ignore the duplication if the same 1113 IP address is registered locally, and then to inject the NLRI 1114 with the "O" flag set on the ARP/ND Extended Community as well. 1116 - This specification adds the new "M" flag in the ARP/ND extended 1117 community to signal that the IP address is multicast, and 1118 requires the local 6LBR to ignore the duplication if the same 1119 IP address is registered locally, and then to inject the NLRI 1120 with the "M" flag set on the ARP/ND Extended Community as well. 1122 * [RFC8928] needs the full ROVR to validate the address ownership, 1123 but the full ROVR can be too large to advertise through BGP. When 1124 an IP address is advertised through EVPN, it is REQUIRED that the 1125 EVPN Next Hop represents the address of the 6LBR of the leaf where 1126 the address was registered as well. This way, if the address is 1127 registered later on a second leaf, the 6LR in second leaf can 1128 leverage an out-of-band, i.e. via EVPN traffic carrying tunnels, 1129 EDAR/EDAC exchange with that 6LBR to validate that the ROVR in the 1130 registration is indeed the same. When that is the case, it can 1131 continue with the registration procedure and if successful, become 1132 a 6LBR for that IP address, either as a mobility event or as a 1133 multihomed registration. 1135 * [RFC8928] expects nodes to autoconfigure the keypair that is used 1136 to form the ROVR, in which case the IPv6 address can be locally 1137 autoconfigured with no central coordination; in that case, the 1138 ROVR only protects the ownership and enforce first-come first- 1139 serve and source address validation. But it is also possible to 1140 pre-provision the ROVR in the 6LBR and then provision the keypair 1141 in the node, e.g., in the case of a trusted server. To enable 1142 that capability in EVPN, this specification adds a flag to signal 1143 that the 6LBR that injects the address in EVPN does not provide 1144 reachability to the address. When that flag is set, the value of 1145 the TID is ignored in the mobility computation, the mapping to the 1146 MAC address is ignored, and the route to the IP address is not 1147 injected in the RIB on ROVR nodes. Non-ROVR nodes will consider 1148 the node a "honey-pot". Once the address is registered by a 6LN 1149 in the network and the according validation with the node 1150 advertising the U-bit version of the route performed, the owner 1151 will inject the route without the U-bit. A node advertising the 1152 NLRI with U-bit in its ARP/ND Extended Community MUST withdraw the 1153 U-bit route once it sees a validated NLRI without the U-bit and it 1154 MAY reinject the route with the U-bit once all routes without the 1155 U-bit are withdrawn to protect the address again. 1157 EVPN signaling is not used to carry ROVR since without challenge per 1158 [RFC8928] they do not represent any difference over using the IP/MAC 1159 combination. Instead, the full ROVR is verified upon a movement or a 1160 multi-homed advertisement using an EDAR/EDAC exchange. Additionally, 1161 backwards compatibility could not be preserved given comparing routes 1162 based on ROVR would present a change in primary key of NLRIs which 1163 non-ROVR routers do not implement. An indication from a ROVR node 1164 that a MAC has been validated by proof of ownership is enough to 1165 convey the necessary information. Only a small hash of the ROVR is 1166 carried to speed up the identification of an address duplication. 1168 6.1. ARP/ND Extended Community 1170 The ARP/ND Extended Community defined in [RFC9047] is a transitive 1171 EVPN Extended Community (Type field value of 0x06) with a Sub-Type of 1172 0x08. It is advertised along with EVPN MAC/IP Advertisement routes 1173 that carry an IPv4 or IPv6 address. Extending the ARP/ND Extended 1174 Community to transport fields from the EARO is natural since the EARO 1175 is an extension to IPv6 ND. 1177 ROVR nodes MUST set the "H" flag in Mobility Extended Community to 1178 indicate that the advertisement is a ROVR MAC in case the host 1179 followed the according procedures. ROVR MACs use (instead of 1180 increasing the normal sequence number) the TID in the high bits of 1181 the sequence number field to "override" any normal MAC advertisement 1182 (further considerations will be provided in Section 6.3). 1184 ROVR nodes MUST set the "V" flag if the address assignment passed 1185 proof of ownership per [RFC8928]. Such "validated" ROVR MAC 1186 addresses will be preferred by ROVR nodes over non validated ROVR 1187 MACs. 1189 In case a ROVR node configures the address as "sticky" (since the 1190 sticky bit semantics have been changed to the point a ROVR cannot 1191 tell whether address is really sticky unless advertised as such by 1192 non-ROVR node) a new "X" flag called "super sticky" is introduced. 1194 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1196 | Type=0x06 | Sub-Type=0x08 | Flags (2 octet) | 1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1198 | Reserved = 0 | ROVR Hash | 1199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1201 Flags field: 1202 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1204 | |I| |O|R| |M|U|M|X|V|H| 1205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1207 Figure 14: Updated ARP/ND Extended Community 1209 Flags: 1211 U: Unreachable, indicating that the IP address is not reachable via 1212 that EVPN next hop, but is advertised for the purpose of 1213 protecting the value of the ROVR until a first 6LBR that can reach 1214 the address becomes available. 1216 M: Multicast, indicating that the IP address duplication should be 1217 ignored. When this bit is set, TID should be ignored in 1218 comparison of EVPN advertisements, i.e. all ROVR MACs at same 1219 level of validation MUST be considered having same TID. 1221 V: ROVR Validated indicates that the MAC passed proof of ownership 1222 per [RFC8928]. Presence of this bit implies the "R" bit being set 1223 irregardless of its value. 1225 X: Super Sticky indicates that the ROVR MAC is sticky and should 1226 follow procedures of sticky per [RFC7432]. 1228 H: ROVR Capable indicates that the advertisement is originated after 1229 processing signaling from host meeting the requirements in 1230 Section 5. This indicates a ROVR MAC. 1232 ROVR Hash: Hash of ROVR used to generate the according ROVR MAC. 1233 Hash is built by XOR'ing ROVR bytes in network order into the 1234 least significant byte and rotating the two bytes result after 1235 every byte by one bit to the left. 1237 6.2. ROVR MAC Mobility Extended Community 1239 Extending MAC Mobility Extended Community to transport the TID allows 1240 to design a solution that, while backwards compatible, allows to 1241 introduce ROVR MAC as "more trusted" entities. Figure 15 presents 1242 the according extensions that will however necessitate some further 1243 explanation. 1245 To introduce a "precedence" of ROVR MACs over normal EVPN MACs ROVR 1246 MACs are advertised to look like "sticky" MACs for non-ROVR nodes. 1247 As defined in the glossary, for simplicity reasons such nodes will be 1248 called non-ROVR nodes vs. ROVR nodes. The "sticky" bit will force 1249 non-ROVR nodes to disregard the sequence number and accept any IP/MAC 1250 route provided. 1252 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1254 | Type=0x06 | Sub-Type=0x00 | Flags = 0 |S| Reserved = 0 | 1255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1256 |T| Flags = 0 | TID | Reserved = 0 | 1257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1259 Figure 15: Modified MAC Mobility Extended Community 1261 This specification updates the Sequence Number field defined in 1262 [RFC7432]. The field is split in 3 parts, one 8-bit flags field, the 1263 TID, and a reserver 2-byte field. The unspecified flags and the 1264 reserved fields MUST be set to 0 by the sender and ignored by the 1265 receiver. 1267 The "S" flag is defined in [RFC7432]. The following new fields are 1268 defined: 1270 T: 1-bit flag. MUST be set to 1 when this specification is used. 1271 This ensures that the TID always wins vs. the sequence counter 1272 defined in [RFC7432] 1274 TID: contains the ROVR MAC TID per [RFC8505]. This MUST NOT be 1275 zero, i.e. a ROVR 1277 6.3. Extended ROVR MAC Procedures 1279 In case a non-ROVR node advertises a sticky MAC by setting the "S" 1280 bit and a ROVR node sees an ROVR address registration for the same 1281 MAC it MUST follow procedures per [RFC7432]. 1283 In case a non-ROVR node advertises a sequence number larger than the 1284 one generated by TID on a ROVR node, the ROVR node SHOULD advertise a 1285 Sequence Number consisting of all bits being set to force a "roll- 1286 over" on all nodes and then fall back to advertising the TID 1287 generated sequence number again. In case a non-ROVR node persists in 1288 increasing the sequence number after that it is indication of 1289 violation of [RFC7432] on its part. 1291 A ROVR node advertising a ROVR MAC that has not been validated and 1292 receiving same type-2 route that has been validated MUST immediately 1293 withdraw its advertisement. 1295 A ROVR node advertising a ROVR MAC and receiving an equivalent ROVR 1296 MAC from other node with a higher TID MUST immediately withdraw its 1297 advertisement. This will allow the non-ROVR nodes to correctly 1298 interpret the sequence as MAC move despite ignoring the sequence 1299 number due to presence of "S" bit. 1301 A ROVR node that receives a ROVR MAC with "super sticky" indication 1302 and seeing the MAC locally MUST follow analogous procedures to 1303 [RFC7432]. 1305 Multi-homing a MAC on mix of ROVR and non-ROVR nodes will lead to 1306 operational notifications since per [RFC7432] the non-ROVR node will 1307 interpret the situation as a sticky MAC that has shown up on its 1308 local interface unless an implementation is somewhat clever and 1309 understands that the presence of the same ESI on all the routes 1310 indicates that this situation does not represent a sticky MAC being 1311 moved. 1313 7. Protocol Operations 1315 Following section illustrates several situations and resulting 1316 signaling in EVPN from the point of view of a ROVR node. 1318 Figure 16 illustrates the registration flow of a new address 1319 protected by [RFC8928]. The ROVR in the EARO is a Crypto-ID that 1320 derives from a public address through hashing with some other terms. 1321 The router challenges the host with a status of 5 (validation 1322 requested). 1324 The host performs the NS again, passing the parameters that enable to 1325 build the Crypto-ID in a Crypto-ID Parameters Option (CIPO), and 1326 signing that set of parameters together with a pair of Nonce values, 1327 one from each side, in a resulting Neighbor Discovery Protocol 1328 Signature Option (NDPDO). The 6LR first verifies that the Crypto-ID 1329 can be rebuilt based on the public key, then verifies that the 1330 signature in the NDPSO was effectively performed with the associated 1331 public key. When that is the case, the registration flow can 1332 continue, else the registration is rejected with a status of 10 1333 (Validation Failed) in the NA(EARO). 1335 With this specification, the 6LBR communicates internally with the 1336 collocated EVPN router to inject the route in EVPN. Since the 1337 [RFC8928] validation was performed, the V flag is set. Once this is 1338 done, the local 6LBR installs a local state associated to the NCE and 1339 becomes owner of the registration, whereas the remote leaves 1340 optionally install a remote state for the address with the indication 1341 of the 6LBR that owns the registration. The local 6LBR MUST be 1342 signalled as EVPN Next Hop for the route. 1344 Local Local Route Remote 1345 Server Leaf Reflector Leaf 1346 +-------+ +---------+ +-------+ +---------+ 1347 | | | | | | | | 1348 6LN 6LBR/EVPN BGP EVPN/6LBR 1349 | | | | 1350 | Ethernet | [via BGP signaling] | 1351 | | | | 1352 | | | | 1353 | NS(EARO( | | | 1354 | R set)) | | | 1355 |--------------->| | | 1356 | ROVR in EARO is cryptographic | | 1357 | | | | 1358 | NA(EARO( | | | 1359 | R not set, | | | 1360 | status = 5), | | | 1361 | Nonce1) | | | 1362 |<---------------| | | 1363 | | | | 1364 | NS(EARO( | | | 1365 | R set), | | | 1366 | CIPO, | | | 1367 | Nonce2, | | | 1368 | NDPSO) | | | 1369 |--------------->| | | 1370 | Proof verified | | 1371 | no state for that address | | 1372 | install local state | | 1373 | | | | 1374 | | ROVR MAC Route A' | 1375 | |---------------->| | 1376 | route injected | | 1377 | | | | 1378 | NA(EARO( | | | 1379 | R set, | | | 1380 | status = 0)) | | | 1381 |<---------------| | | 1382 | | | ROVR MAC Route A' 1383 | | |--------------->| 1384 | | | install remote state 1385 | | | | 1387 Figure 16: Host Registration 1389 Figure 17 presents the same flow but for a multihomed address; here 1390 and in the following flows, the proof of ownership section is not 1391 shown, but its use is RECOMMENDED. The interesting piece is that 1392 when the node registers to the second 6LBR, that second 6LBR find 1393 that there is a first 6LBR that already own the registration. Using 1394 and EDAR / EDAC flow, the second 6LBR validates that the ROVR and TID 1395 are identical, in which case it accepts the registration and becomes 1396 another 6LBR owner of the registration. The result is that the 2 1397 6LBRs are synchronized and any of the 2 can now be used, e.g., if the 1398 address is registered a third time. 1400 Local Local Local 1401 Server Leaf 1 Leaf 2 Reflector 1402 +-------+ +---------+ +---------+ +---------+ 1403 | | | | | | | | 1404 6LN 6LBR/EVPN 6LBR/EVPN | 1405 | | | | 1406 | Ethernet | | | 1407 | | | [via BGP signaling] 1408 | | | | 1409 | NS(EARO) | | | 1410 |--------------->| | | 1411 | install local state | | 1412 | | | 1413 | |------ROVR MAC Route A' ----->| 1414 | NA(EARO) | | | 1415 |<---------------| | | 1416 | | |<----------------| 1417 | | install remote state | 1418 | | | | 1419 | NS(same address, ES and EARO) | | 1420 |------------------------------>| | 1421 | | | | 1422 | | Same ES and ROVR Hash | 1423 | | EDAR | | 1424 | |<-------------| | 1425 | | | | 1426 | ROVR match, TID OK | | 1427 | | | | 1428 | |EDAC(status=0)| | 1429 | |------------->| | 1430 | | install local state | 1431 | | | | 1432 | | ROVR MAC Route A' | 1433 | | |---------------->| 1434 | |<-------------------------------| 1435 | install remote state | | 1436 | | | | 1437 | NA(EARO(status = 0)) | | 1438 |<------------------------------| | 1439 | | | | 1440 Figure 17: Multihoming 1442 The registration is associated with a lifetime, and it must be 1443 renewed with an incremented TID. The new TID is propagated in EVPN 1444 as illustrated in Figure 18. 1446 Local Local Route Remote 1447 Server Leaf Reflector Leaf 1448 +-------+ +---------+ +-------+ +---------+ 1449 | | | | | | | | 1450 6LN 6LBR/EVPN BGP EVPN/6LBR 1451 | | | | 1452 | Ethernet | [via BGP signaling] | 1453 | | | | 1454 | | | | 1455 | NS(EARO( | | | 1456 | TID+1)) | | | 1457 |--------------->| | | 1458 | renew lifetime locally | | 1459 | | | | 1460 | | ROVR MAC Route A'(TID+1) | 1461 | |---------------->| | 1462 | NA(EARO | |--------------->| 1463 | status = 0)) | | update remote state 1464 |<---------------| | | 1465 | | | | 1466 | | | | 1468 Figure 18: Host Registration Renewal 1470 Figure 19 illustrates the case where a second host registers the same 1471 address, creating a potential address duplication situation. in most 1472 cases, the ROVR hash will be different, and the local 6LBR can reject 1473 the registration is a status of 1 (duplicate) right away. 1475 Local Local Route Remote 1476 Server Leaf Reflector Leaf 1477 +-------+ +---------+ +-------+ +---------+ 1478 | | | | | | | | 1479 6LN 6LBR/EVPN BGP EVPN/6LBR 1480 | | | | 1481 | Ethernet | | | 1482 | | [via BGP signaling] | 1483 | | | | 1484 | | | Local state for A' 1485 | | | | 1486 | | ROVR MAC Route A' | 1487 | | ROVR Hash G | 1488 | | |<---------------| 1489 | |<----------------| | 1490 | Create remote state for A' | | 1491 | | | | 1492 | NS(EARO) | | | 1493 |--------------->| | | 1494 | compute ROVR Hash F | | 1495 | | | | 1496 | NA(EARO( | | | 1497 | status = 1)) | | | 1498 |<---------------| | | 1499 | | | | 1500 | | | | 1502 Figure 19: Duplicate Addresses 1504 Figure 20 illustrates the case of an address duplication situation 1505 where by chance, the ROVR hashes are the same. In that case, the 1506 local 6LR checks with the 6LBR that owns the registration using an 1507 EDAR/EDAC message exchange. As opposed to the ROVR hash, the full 1508 ROVRs do not collide and the registration is also rejected. 1510 Local Local Route Remote 1511 Server Leaf Reflector Leaf 1512 +-------+ +---------+ +-------+ +---------+ 1513 | | | | | | | | 1514 6LN 6LBR EVPN BGP EVPN/6LBR 1515 | | | | | | 1516 | Ethernet | | | | | 1517 | | | [via BGP signaling] | | 1518 | | | | | | 1519 | | | | Local state for A' 1520 | | | | | | 1521 | | | ROVR MAC Route A' | | 1522 | | | ROVR Hash G | | 1523 | | | |<--------------| | 1524 | | |<--------------| | | 1525 | Create remote state for A' | | | 1526 | | | | | 1527 | | | 1528 | | [[out of band signaling]] | 1529 | NS(EARO) | | 1530 |------------->| | 1531 | compute ROVR Hash G | 1532 | | | 1533 | | EDAR to EVPN Next Hop | 1534 | |-------------------------------------->| 1535 | | | 1536 | | EDAC (status = 1) | 1537 | |<--------------------------------------| 1538 | | | 1539 | NA(EARO( | | 1540 | status = 1))| | 1541 |<-------------| | 1542 | | | 1544 Figure 20: Duplicate Addresses, ROVR Hash Collision 1546 Figure 21 shows a rare case where the registration has already moved 1547 elsewhere with an incremented TID when the local registration is 1548 received after being delayed in the network. In that case, the 1549 registration is rejected with a status of 3 (moved). 1551 Local Local Route Remote 1552 Server Leaf Reflector Leaf 1553 +-------+ +---------+ +-------+ +---------+ 1554 | | | | | | | | 1555 6LN 6LBR/EVPN BGP EVPN/6LBR 1556 | | | | 1557 | Ethernet | | | 1558 | | [via BGP signaling] | 1559 | | | | 1560 | | ROVR MAC Route A' | 1561 | | ESI X', Hash F, TID Z | 1562 | | |<---------------| 1563 | |<----------------| | 1564 | create remote start A' | | 1565 | ESI X', ROVR Hash F, TID Z | | 1566 | | | | 1567 | NS(EARO( | | | 1568 | TID=Z-1)) | | | 1569 |--------------->| | | 1570 | computes as | | 1571 | ROVR Hash F | | 1572 | ESI X'', TID Z-1 | | 1573 | NA(EARO) | | | 1574 | status = 3)) | | | 1575 |<---------------| | | 1576 | | | | 1578 Figure 21: Address Already Moved 1580 Address move differs from multi-homing by the ESI being different as 1581 visualized by Figure 22. In case of different ESI BGP signalling 1582 happens immediately, in case of multi-homing we can reasonably expect 1583 for the signalling to catch up on the other leg with a new, higher 1584 TID. However, since ESI matches TID doesn't matter strictly speaking 1585 and the new remote state can be installed as is. However, if 6LN is 1586 not refreshing it registration we can expect elapsed lifetime to 1587 create scenario Figure 25 over time. 1589 Local Local Route Remote 1590 Server Leaf Reflector Leaf 1591 +-------+ +---------+ +-------+ +---------+ 1592 | | | | | | | | 1593 6LN 6LBR/EVPN BGP EVPN/6LBR 1594 | | | | 1595 | Ethernet | | | 1596 | | [via BGP signaling] | 1597 | NS(EARO) | | | 1598 |--------------->| | | 1599 | Create local state | | 1600 | | ROVR MAC Route A' | 1601 | | ESI X', ROVR Hash F, TID Z | 1602 | |---------------->| | 1603 | | |--------------->| 1604 | | | Create remote state 1606 Same ES (multihomed): 1607 | | | |<-- 1608 | | | New local state A' created 1609 | | | | 1610 | | ROVR MAC Route A' | 1611 | | ESI X', Hash F, TID Z+1 | 1612 | | |<---------------| 1613 | |<----------------| | 1614 | Create remote state | | 1615 | Keep local expect renew | | 1616 | | | | 1618 Different ES (movement): 1619 | | | |<-- 1620 | | | New local state A' created 1621 | | | | 1622 | | ROVR MAC Route A' | 1623 | | ESI X'', ROVR Hash F, TID Z+1 | 1624 | | |<---------------| 1625 | |<----------------| | 1626 | Create remote state | | 1627 | | | | 1628 | NA(EARO( | | | 1629 | status = 4)) | | | 1630 |<---------------| | | 1631 | | Withdraw ROVR MAC Route A' | 1632 | |---------------->| | 1633 | | |--------------->| 1634 | remove local state | | 1635 | | | | 1636 Figure 22: Address Move 1638 The host that registered the address may cancel the registration at 1639 any time, e.g., if the address is removed fmor its own interface. 1640 This is done by registering with a lifetime if 0 as shown in 1641 Figure 23. The Leaf may respond with a status of 0 to indicate 1642 success, but a status of 4 (removed) is preferred for this situation. 1644 Local Local Route Remote 1645 Server Leaf Reflector Leaf 1646 +-------+ +---------+ +-------+ +---------+ 1647 | | | | | | | | 1648 6LN 6LBR/EVPN BGP EVPN/6LBR 1649 | | | | 1650 | Ethernet | | | 1651 | | [via BGP signaling] | 1652 | | | | 1653 | NS(EARO, | | | 1654 | lifetime=0) | | | 1655 |--------------->| | | 1656 | | | | 1657 | | Withdraw ROVR MAC Route A' | 1658 | |---------------->| | 1659 | | |--------------->| 1660 | NA(EARO( | | | 1661 | status = 4)) | | | 1662 |<---------------| | | 1663 | | | | 1664 | remove local state | | 1665 | | | | 1667 Figure 23: Address Removal 1669 The host that registered the address may withdraw the route but 1670 maintain the NCE, e.g., in the case where it is multihomed but does 1671 not want to use one interface for the traffic back as this time. 1672 This is done by registering with the R flag set to 0 as shown in 1673 Figure 24. 1675 Local Local Route Remote 1676 Server Leaf Reflector Leaf 1677 +-------+ +---------+ +-------+ +---------+ 1678 | | | | | | | | 1679 6LN 6LBR/EVPN BGP EVPN/6LBR 1680 | | | | 1681 | Ethernet | | | 1682 | | [via BGP signaling] | 1683 | | | | 1684 | NS(EARO, | | | 1685 | R reset) | | | 1686 |--------------->| | | 1687 | | | | 1688 | | Withdraw ROVR MAC Route A' | 1689 | |---------------->| | 1690 | | |--------------->| 1691 | NA(EARO( | | | 1692 | R reset, | | | 1693 | status = 0)) | | | 1694 |<---------------| | | 1695 | | | | 1696 | retain only NCE | | 1697 | | | | 1699 Figure 24: Route Type 2 Removal 1701 When the lifetime elapses, the 6LBR requires the collocated EVPN 1702 router to withdraw the route. 1704 Local Local Route Remote 1705 Server Leaf Reflector Leaf 1706 +-------+ +---------+ +-------+ +---------+ 1707 | | | | | | | | 1708 6LN 6LBR/EVPN BGP EVPN/6LBR 1709 | | | | 1710 | Ethernet | | | 1711 | | [via BGP signaling] | 1712 | | | | 1713 | lifetime Expired | | 1714 | | | | 1715 | | Withdraw ROVR MAC Route A' | 1716 | |---------------->| | 1717 | | |--------------->| 1718 | NA(EARO( | | | 1719 | status = 4)) | | | 1720 |<---------------| | | 1721 | | | | 1722 | remove local state | | 1723 | | | | 1725 Figure 25: Lifetime Elapse 1727 8. Security Considerations 1729 TBD 1731 9. IANA Considerations 1733 10. Acknowledgments 1735 The authors wish to thank you for reading that far. We acknowledge 1736 and express gratitude to Wen Lin, Stephane Litkowski, Eric Levy- 1737 Abegnoli, Lukas Krattiger, Jerome Tollet, and Ali Sajassi, for their 1738 help and support. 1740 11. Normative References 1742 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1743 Requirement Levels", BCP 14, RFC 2119, 1744 DOI 10.17487/RFC2119, March 1997, 1745 . 1747 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 1748 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 1749 DOI 10.17487/RFC3810, June 2004, 1750 . 1752 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1753 Control Message Protocol (ICMPv6) for the Internet 1754 Protocol Version 6 (IPv6) Specification", STD 89, 1755 RFC 4443, DOI 10.17487/RFC4443, March 2006, 1756 . 1758 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1759 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1760 DOI 10.17487/RFC4861, September 2007, 1761 . 1763 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1764 Address Autoconfiguration", RFC 4862, 1765 DOI 10.17487/RFC4862, September 2007, 1766 . 1768 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 1769 Bormann, "Neighbor Discovery Optimization for IPv6 over 1770 Low-Power Wireless Personal Area Networks (6LoWPANs)", 1771 RFC 6775, DOI 10.17487/RFC6775, November 2012, 1772 . 1774 [RFC6085] Gundavelli, S., Townsley, M., Troan, O., and W. Dec, 1775 "Address Mapping of IPv6 Multicast Packets on Ethernet", 1776 RFC 6085, DOI 10.17487/RFC6085, January 2011, 1777 . 1779 [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for 1780 IPv6 over Low-Power Wireless Personal Area Networks 1781 (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November 1782 2014, . 1784 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 1785 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 1786 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 1787 2015, . 1789 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1790 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1791 May 2017, . 1793 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 1794 Perkins, "Registration Extensions for IPv6 over Low-Power 1795 Wireless Personal Area Network (6LoWPAN) Neighbor 1796 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 1797 . 1799 [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., 1800 Uttaro, J., and W. Henderickx, "A Network Virtualization 1801 Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, 1802 DOI 10.17487/RFC8365, March 2018, 1803 . 1805 [RFC8928] Thubert, P., Ed., Sarikaya, B., Sethi, M., and R. Struik, 1806 "Address-Protected Neighbor Discovery for Low-Power and 1807 Lossy Networks", RFC 8928, DOI 10.17487/RFC8928, November 1808 2020, . 1810 [RFC9047] Rabadan, J., Ed., Sathappan, S., Nagaraj, K., and W. Lin, 1811 "Propagation of ARP/ND Flags in an Ethernet Virtual 1812 Private Network (EVPN)", RFC 9047, DOI 10.17487/RFC9047, 1813 June 2021, . 1815 [UNICAST-LOOKUP] 1816 Thubert, P. and E. Levy-Abegnoli, "IPv6 Neighbor Discovery 1817 Unicast Lookup", Work in Progress, Internet-Draft, draft- 1818 thubert-6lo-unicast-lookup-02, 8 November 2021, 1819 . 1822 [I-D.thubert-6lo-multicast-registration] 1823 Thubert, P., "IPv6 Neighbor Discovery Multicast Address 1824 Registration", Work in Progress, Internet-Draft, draft- 1825 thubert-6lo-multicast-registration-02, 8 October 2021, 1826 . 1829 12. Informative References 1831 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1832 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1833 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1834 Low-Power and Lossy Networks", RFC 6550, 1835 DOI 10.17487/RFC6550, March 2012, 1836 . 1838 [RFC8929] Thubert, P., Ed., Perkins, C.E., and E. Levy-Abegnoli, 1839 "IPv6 Backbone Router", RFC 8929, DOI 10.17487/RFC8929, 1840 November 2020, . 1842 [RFC9010] Thubert, P., Ed. and M. Richardson, "Routing for RPL 1843 (Routing Protocol for Low-Power and Lossy Networks) 1844 Leaves", RFC 9010, DOI 10.17487/RFC9010, April 2021, 1845 . 1847 [RIFT] Sharma, A., Thubert, P., Rijsman, B., Afanasiev, D., and 1848 A. Przygienda, "RIFT: Routing in Fat Trees", Work in 1849 Progress, Internet-Draft, draft-ietf-rift-rift-15, 3 1850 January 2022, . 1853 [IANA-EARO-STATUS] 1854 IANA, "Address Registration Option Status Values", 1855 . 1858 Authors' Addresses 1860 Pascal Thubert (editor) 1861 Cisco Systems, Inc 1862 France 1864 Phone: +33 497 23 26 34 1865 Email: pthubert@cisco.com 1867 Tony Przygienda 1868 Juniper Networks, Inc 1869 Switzerland 1871 Email: prz@juniper.net 1873 Jeff Tantsura 1874 Microsoft 1876 Email: jefftant.ietf@gmail.com