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