idnits 2.17.1 draft-thubert-bess-secure-evpn-mac-signaling-00.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 (8 July 2021) is 1023 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) == Outdated reference: A later version (-02) exists of draft-thubert-6lo-unicast-lookup-00 == Outdated reference: A later version (-21) exists of draft-ietf-rift-rift-12 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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: 9 January 2022 Juniper Networks, Inc 6 J. Tantsura 7 Microsoft 8 8 July 2021 10 Secure EVPN MAC Signaling 11 draft-thubert-bess-secure-evpn-mac-signaling-00 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 9 January 2022. 38 Copyright Notice 40 Copyright (c) 2021 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 Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified 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. RFC 6775 Address Registration . . . . . . . . . . . . . . 6 61 3.2. RFC 8505 Extended Address Registration . . . . . . . . . 7 62 3.2.1. R Flag . . . . . . . . . . . . . . . . . . . . . . . 8 63 3.2.2. TID, "I" Field and Opaque Fields . . . . . . . . . . 8 64 3.2.3. Status . . . . . . . . . . . . . . . . . . . . . . . 8 65 3.2.4. Route Ownership Verifier . . . . . . . . . . . . . . 9 66 3.3. RFC 8505 Extended DAR/DAC . . . . . . . . . . . . . . . . 9 67 3.4. RFC 7400 Capability Indication Option . . . . . . . . . . 10 68 4. Extending 6LoWPAN ND . . . . . . . . . . . . . . . . . . . . 11 69 4.1. Use of the R flag in NA . . . . . . . . . . . . . . . . . 11 70 4.2. Distributing the 6LBR . . . . . . . . . . . . . . . . . . 11 71 4.3. Unicast Address Lookup with the 6LBR . . . . . . . . . . 15 72 5. Requirements on the EVPN-Unaware Host . . . . . . . . . . . . 21 73 5.1. Support of 6LoWPAN ND . . . . . . . . . . . . . . . . . . 21 74 6. Enhancements to EVPN . . . . . . . . . . . . . . . . . . . . 22 75 6.1. ROVR MAC Mobility Extended Community . . . . . . . . . . 24 76 6.2. Extended ROVR MAC Procedures . . . . . . . . . . . . . . 25 77 7. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 26 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 36 79 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 80 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 81 11. Normative References . . . . . . . . . . . . . . . . . . . . 37 82 12. Informative References . . . . . . . . . . . . . . . . . . . 38 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 85 1. Introduction 87 "Registration Extensions for IPv6 over 6LoWPAN Neighbor Discovery" 88 [RFC8505] (ND) provides a zeroconf routing-agnostic Host-to-Router 89 Link-Local interface for Stateful Address Autoconfiguration. 90 "Address-Protected Neighbor Discovery for Low-Power and Lossy 91 Networks" [RFC8928] (AP-ND) adds a zeroconf anti-theft protection 92 that protects the ownership of the autoconfigured address with 93 autoconfigured proof of ownership called a Registration Ownership 94 Verifier (ROVR). 96 [RFC8505] enables the host to claim an IPv6 address and obtain 97 reachability services for that address. It is already used to inject 98 host routes in RPL [RFC9010] and RIFT "Routing in Fat Trees" [RIFT], 99 and to maintain a proxy-ND state in a backbone router [RFC8929]; this 100 specification extends its applicability to the case of Ethernet 101 Virtual Private Network (eVPN). 103 [RFC8505] specifies a unicast address registration mechanism that 104 enables the host called a 6LowPAN Node (6LN) to install a ND binding 105 state in the 6LowPAN Router (6LR) that can serve as Neighbor Cache 106 Entry (NCE), though it is not operated as a cache. The protocol 107 provides the means to reject the registration in case of address 108 duplication. It also enables to discriminate mobility from 109 multihoming. [RFC8928] adds the capability to verify the ownership 110 of the address and prevent an attacker from stealing and/or 111 impersonating an address. 113 [RFC8505] defines the 6LoWPAN Border Router (6LBR) as an abstract 114 address registrar that provides authoritative service for Address 115 Registration and duplicate detection. The 6LBR stores address 116 metadata that is obtained during the Address Registration, including 117 an owner ID and a sequence counter. As part of the process of a new 118 Address Registration, the 6LR queries the 6LBR for existing metadata 119 related to the address being registered. This enables in particular 120 to detect a duplication and reject the registration. This 121 specification extends the 6LBR abstract data model to store the Link 122 Layer Address (LLA) of the Registering Node. This enables the 6LBR 123 to perform locally, and using unicast communication, the IPv6 ND 124 services of address lookup and duplicate address detection. 126 The [RFC8505] address registrar can be centralized, but it can also 127 be distributed and maintained synchronized using a routing protocol. 128 This specification adds attributes to EVPN to carry the IPv6 address 129 metadata learned from [RFC8505] so as to maintain a synchronized copy 130 of the 6LBR abstract data at each EVPN router. 132 2. Terminology 134 2.1. Requirements Language 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 138 "OPTIONAL" in this document are to be interpreted as described in BCP 139 14 [RFC2119] [RFC8174] when, and only when, they appear in all 140 capitals, as shown here. 142 2.2. Glossary 144 This document uses the following acronyms: 146 6CIO Capability Indication Option [RFC7400] 147 6LN: 6LoWPAN Node (the Host) [RFC6775] 148 6LR: 6LoWPAN router (the router) [RFC6775] 149 6LBR: 6LoWPAN Border router [RFC6775] 150 AMC: Address Mapping Confirmation [UNICAST-LOOKUP] 151 AMR: Address Mapping Request [UNICAST-LOOKUP] 152 ARO Address Registration Option [RFC6775] 153 CIPO: Crypto-ID Parameters Option 154 DAD: Duplicate Address Detection [RFC4862] 155 ICMPv6: Internet Control Message Protocol for IPv6 156 DAC Duplicate Address Confirmation [RFC6775] 157 DAR Duplicate Address Request [RFC6775] 158 EDAC Extended Duplicate Address Confirmation [RFC8505] 159 EDAR Extended Duplicate Address Request [RFC8505] 160 EARO: Extended Address Registration Option [RFC8505] 161 EVPN: Ethernet VPN [RFC7432] 162 LLA: Link-Layer Address (the MAC address on Ethernet) 163 LLN Low-Power and Lossy Network [RFC6550] 164 NA: Neighbor Advertisement [RFC4861] 165 NCE: Neighbor Cache Entry [RFC4861] 166 ND: Neighbor Discovery [RFC4861] 167 NDPSO: Neighbor Discovery Protocol Signature Option 168 NS: Neighbor Solicitation [RFC4861] 169 RA: Router Advertisement [RFC4861] 170 ROVR: Registration Ownership Verifier [RFC8505] 171 TID: Transaction ID (a sequence counter in the EARO) [RFC8505] 172 SLAAC: Stateless Address Autoconfiguration [RFC4862] 173 SLLAO: Source Link-Layer Address Option [RFC4861] 174 TLLAO: Target Link-Layer Address Option [RFC4861] 175 ROVR MAC: MAC obtained from a host meeting requirements in Section 5 176 Validated ROVR MAC: ROVR MAC validated by procedures specified in 177 [RFC8928] 178 ROVR Node: EVPN node capable of advertising ROVR MACs 179 non-ROVR Node: EVPN node not supporting extensions defined in this 180 document. 181 VPN: Virtual Private Network 183 2.3. References 185 This document uses the terms Clos fabric and Fat Tree 186 interchangeably, to refer to a folded spine-and-leaf topology as 187 defined in the terminology section of "RIFT: Routing in Fat Trees" 188 [RIFT]. 190 The term "leaf" represents the access switch that connects the 191 servers to the Fat Tree. The leaf is typically a Top-of-Rack (ToR) 192 switch. 194 This specification uses the terms 6LN, 6LR and 6LBR to refer 195 specifically to nodes that implement the said roles in [RFC8505] and 196 does not expect other functionality such as 6LoWPAN Header 197 Compression: 199 * In the context of this document, the 6LN is a server that 200 advertises an address mapping using [RFC8505], and optionally 201 protects its ownership with [RFC8928]. 203 * The 6LR and 6LBR function are collapsed at the leaf and its state 204 is synchronized with that of the EVPN functional support using an 205 internal interface that is out of scope. That interface could be 206 "pull" meaning that the 6LBR fetches the EVPN information when it 207 needs it, or "push", meaning that any information that EVPN 208 distributes is immediately fed in all the 6LBRs in all the leaves. 209 Note that this is pure control plane and is not subject to 210 abbreviating optimization as the FIB may be. 212 In this document, readers will encounter terms and concepts that are 213 discussed in the following documents: 215 EVPN: "BGP MPLS-Based Ethernet VPN" [RFC7432] and "Network 216 Virtualization Overlay Solution" [RFC8365], 218 Classical IPv6 ND: "Neighbor Discovery for IP version 6" [RFC4861] 219 and "IPv6 Stateless Address Autoconfiguration" [RFC4862], 221 6LoWPAN ND: Neighbor Discovery Optimization for Low-Power and Lossy 222 Networks [RFC6775], "Registration Extensions for 6LoWPAN Neighbor 223 Discovery" [RFC8505], "Address Protected Neighbor Discovery for 224 Low-power and Lossy Networks" [RFC8928], and "IPv6 Backbone 225 Router" [RFC8929]. 227 3. 6LoWPAN Neighbor Discovery 229 6LoWPAN Neighbor Discovery defines a stateful address 230 autoconfiguration mechanism for IPv6. 6LoWPAN ND enables to divorce 231 the L3 abstractions for link and subnet from the characteristics of 232 the L2 link and broadcast domain. It is applicable beyond its 233 original field of IoT to any environment where the broadcast nature 234 of the underlaying network should not be exploited, e.g., in the case 235 of a wireless link where broadcast uses an excessive amount of 236 spectrum, and a distributed cloud, where it may span too widely. 238 In contrast to Stateless Address Autoconfiguration (SLAAC) [RFC4862] 239 which relies on broadcast for duplicate address detection (DAD) and 240 address lookup, 6LoWPAN ND installs and maintains a state in the 241 neighbors for the duration of their interaction. Though it is also 242 called a Neighbor Cache Entry (BCE) in [RFC6775], and in contrast 243 with the the BCE in SLAAC, that state is not a cache that can be 244 casually flushed and rebuilt. It must be installed proactively and 245 refreshed periodically to maintain the connectivity and enable 246 unicast-only operations. 248 The typical abstraction for an IP Link with 6LoWPAN ND is point-to- 249 point (P2P) between a node and a router. An IP interface bundles 250 multiple links between this node and peers in the same subnet, aka 251 point-to-multipoint (P2MP). The subnet is a not-on-link L3-connected 252 collection of such nodes and links, which means that the any-to-any 253 connectivity across the subnet is ensured through L3 routing as 254 opposed to transitive (any-to-any) reachability from L2. 256 This section goes through the 6LoWPAN ND mechanisms that this 257 specification leverages, as a non-normative reference to the reader. 258 The relevant normative text is to be found in [RFC6775], [RFC8505], 259 and [RFC8928]. 261 3.1. RFC 6775 Address Registration 263 The classical "IPv6 Neighbor Discovery (IPv6 ND) Protocol" [RFC4861] 264 [RFC4862] was defined for serial links and transit media such as 265 Ethernet. It is a reactive protocol that relies heavily on multicast 266 operations for Address Discovery (aka Lookup) and Duplicate Address 267 Detection (DAD). 269 "Neighbor Discovery Optimizations for 6LoWPAN networks" [RFC6775] 270 adapts IPv6 ND for operations over energy-constrained LLNs. The main 271 functions of [RFC6775] are to proactively establish the Neighbor 272 Cache Entry (NCE) in the 6LR and to prevent address duplication. To 273 that effect, [RFC6775] introduces a new unicast Address Registration 274 mechanism that contributes to reducing the use of multicast messages 275 compared to the classical IPv6 ND protocol. 277 [RFC6775] defines a new Address Registration Option (ARO) that is 278 carried in the unicast Neighbor Solicitation (NS) and Neighbor 279 Advertisement (NA) messages between the 6LoWPAN Node (6LN) and the 280 6LoWPAN router (6LR). It also defines the Duplicate Address Request 281 (DAR) and Duplicate Address Confirmation (DAC) messages between the 282 6LR and the 6LBR. In a Low-Power and Lossy Network (LLN), the 6LBR 283 is the central repository of all the Registered Addresses in its 284 domain and the authoritative source of truth for uniqueness and 285 ownership. 287 3.2. RFC 8505 Extended Address Registration 289 "Registration Extensions for 6LoWPAN Neighbor Discovery" [RFC8505] 290 updates RFC 6775 into a generic Address Registration mechanism that 291 can be used to access services such as routing and ND proxy. To that 292 effect, [RFC8505] defines the Extended Address Registration Option 293 (EARO), shown in Figure 1: 295 0 1 2 3 296 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 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Type | Length | Status | Opaque | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Rsvd | I |R|T| TID | Registration Lifetime | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | | 303 ... Registration Ownership Verifier ... 304 | | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 Figure 1: EARO Option Format 309 3.2.1. R Flag 311 [RFC8505] introduces the R Flag in the EARO. The Registering Node 312 sets the R Flag to indicate whether the 6LR should ensure 313 reachability for the Registered Address. If the R Flag is set to 0, 314 then the Registering Node handles the reachability of the Registered 315 Address by other means. In an EVPN network, this means that either 316 it is a RAN that injects the route by itself or that it uses another 317 EVPN router for reachability services. 319 This document specifies how the R Flag is used in the context of 320 EVPN. An EVPN Host that implements the 6LN functionality from 321 [RFC8505] requires reachability services for an IPv6 address if and 322 only if it sets the R Flag in the NS(EARO) used to register the 323 address to a 6LR acting as an EVPN border router. Upon receiving the 324 NS(EARO), the EVPN router generates a BGP advertisement for the 325 Registered Address if and only if the R flag is set to 1. 327 [RFC9010] specifies that the 'R' flags is set in the responded NA 328 messages if and only if the route was installed. This specification 329 echoes that behavior. 331 3.2.2. TID, "I" Field and Opaque Fields 333 When the T Flag is set to 1, the EARO includes a sequence counter 334 called Transaction ID (TID), that is needed to format the MAC 335 Mobility Extended Community. This is the reason why the support of 336 [RFC8505] by the Host, as opposed to only [RFC6775], is a 337 prerequisite for this specification); this requirement is fully 338 explained in Section 5.1. The EARO also transports an Opaque field 339 and an associated "I" field that describes what the Opaque field 340 transports and how to use it. 342 This document specifies the use of the "I" field and the Opaque field 343 by a Host. 345 3.2.3. Status 347 The values of the EARO status are maintained by IANA in the Address 348 Registration Option Status Values subregistry [IANA-EARO-STATUS] of 349 the Internet Control Message Protocol version 6 (ICMPv6) Parameters 350 registry. 352 [RFC6775] and [RFC8505] defined the original values whereas [RFC9010] 353 reduced range to 64 values and reformatted the octet field to enable 354 to transport an external error, e.g., coming form a routing protocol. 356 This specification uses the format expressed in [RFC9010]. The value 357 of 0 denotes an unqualified success, 1 indicates an address 358 duplication, 3 a TID value that is outdated, and 4 is used in an 359 asynchronous NA to indicate that 6LN should remove that address and 360 possibly form new ones. 362 3.2.4. Route Ownership Verifier 364 Section 5.3 of [RFC8505] introduces the Registration Ownership 365 Verifier (ROVR) field of variable length from 64 to 256 bits. The 366 ROVR is a replacement of the EUI-64 in the ARO [RFC6775] that was 367 used to identify uniquely an Address Registration with the Link-Layer 368 address of the owner but provided no protection against spoofing. 370 "Address Protected Neighbor Discovery for Low-power and Lossy 371 Networks" [RFC8928] leverages the ROVR field as a cryptographic proof 372 of ownership to prevent a rogue third party from registering an 373 address that is already owned. The use of ROVR field enables the 6LR 374 to block traffic that is not sourced at an owned address. 376 This specification does not address how the protection by [RFC8928] 377 could be extended for use in EVPN. On the other hand, it adds the 378 ROVR to the BGP advertisement to share the state with the other 379 routers via the Reflector (see Section 6.1), which means that the 380 routers that are aware of the Host route are also aware of the ROVR 381 associated to the Target Address, whether it is cryptographic and 382 should be verified. 384 3.3. RFC 8505 Extended DAR/DAC 386 [RFC8505] updates the DAR/DAC messages to EDAR/EDAC messages to carry 387 the ROVR field. The EDAR/EDAC exchange takes place between the 6LR 388 to which the node registers an address, and the abstract 6LBR that 389 stores the reference value for the ROVR and the TID associated to 390 that address. It is triggered by an NS(EARO) message from a 6LN to 391 the 6LR, to create, refresh, compare and delete the corresponding 392 state in the 6LBR. 394 In the status returned with the EDAC message, the 6LBR indicates if 395 the registration is accepted, should be challenged, or is duplicate. 396 The status of 0 (success) indicates that the address is either new or 397 that the current registration matches, and in particular that the 398 ROVR at the 6LBR and the one in the EDAR message are identical. 400 6LN 6LR 6LBR 401 | | | 402 | IP Link | subnetwork | 403 | | | 404 | NS(EARO) | | 405 |---------------->| | 406 | | | 407 | | EDAR | 408 | |------------------>| 409 | | | 410 | | EDAC(status) | 411 | |<------------------| 412 | | | 413 | NA(EARO) | | 414 |<----------------| | 415 | | | 417 Figure 2: EDAR/EDAC flow 419 The EDAR/EDAC exchange is protected by the retry mechanism specified 420 in Section 8.2.6 of [RFC6775], though in a data center, a duration 421 significantly shorter than the default value of the Retransmission 422 Timer [RFC4861] of 1 second may be sufficient to cover the round-trip 423 delay between the 6R and the 6LBR. 425 With this specification, the 6LBR is distributed across the leaves, 426 and all the leaves where an address is currently registered maintain 427 a full 6LBR state for the address, aka local state in the following 428 text. The specification leverages the EDAR/EDAC exchange to ensure 429 that a leaf (acting as a 6LR) that needs to create a 6LBR state for a 430 new registration has the same value for the ROVR as any 6LBR already 431 serving that address on another leaf. At the same time, the 432 specification avoids placing full ROVR information in BGP so 1) it is 433 not observable by a potential attacker and 2) the new attributes 434 remain reasonably small. 436 3.4. RFC 7400 Capability Indication Option 438 "6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power 439 Wireless Personal Area Networks (6LoWPANs)" [RFC7400] defines the 440 6LoWPAN Capability Indication Option (6CIO) that enables a node to 441 expose its capabilities in router Advertisement (RA) messages. 443 [RFC8505] defines a number of bits in the 6CIO, in particular: 445 L: Node is a 6LR. 446 E: Node is an IPv6 ND Registrar -- i.e., it supports registrations 447 based on EARO. 448 P: Node is a Routing Registrar, -- i.e., an IPv6 ND Registrar that 449 also provides reachability services for the Registered Address. 451 0 1 2 3 452 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 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Type | Length = 1 | Reserved |D|L|B|P|E|G| 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Reserved | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 Figure 3: 6CIO flags 461 A 6LR that provides reachability services for a Host in an EVPN 462 network as specified in this document includes a 6CIO in its RA 463 messages and set the L, P and E flags to 1 as prescribed by 464 [RFC8505]. 466 4. Extending 6LoWPAN ND 468 4.1. Use of the R flag in NA 470 This document extends [RFC8928] and [RFC8505] as follows 472 This document also updates the behavior of a 6LR acting as EVPN 473 router and of a 6LN acting as Host in the 6LoWPAN ND Address 474 Registration as follows: 476 * The use of the R Flag is extended to the NA(EARO) to confirm 477 whether the route was installed. 479 4.2. Distributing the 6LBR 481 This specification enables to distribute the 6LBR at the edge of the 482 EVPN network and collapse the 6LBR function with that of the EVPN 483 support. In that model, the EVPN to 6LBR interaction becomes an 484 internal interface, where each side informs the other in case of new 485 information concerning an IP to Link-Layer Address (LLA) mapping. 486 Since this is an internal interface, this specification makes no 487 assumption on whether the 6LBR stores its own representation of the 488 full EVPN state, which means that the EVPN support informs the 6LBR 489 in case of any change on the EVPN side (this is called the push 490 model, see Figure 10), or if the 6LBR queries the EVPN support when 491 it does not have a mapping to satisfy a request (pull model, see 492 Figure 9). 494 This specification leverages [RFC8929] that augments the abstract 495 data model of the 6LBR to store the LLA associated with the 496 registered address. Based on that additional state, the 6LBR in a 497 leaf can communicate the mapping to the collocated EVPN function and 498 respond to unicast address mapping lookups from the server side. 500 In an environment where the server ranges from a classical host to a 501 more complex platform that runs a collection of virtual hosts 502 interconnected by a virtual switch, but where the host-to-leaf 503 interface remains at layer 2, the 6LR and the 6LBR functions can be 504 collapsed in the leaf. The 6LR to 6LBR interaction also becomes an 505 internal interface, and there is no need for EDAR/EDAC messages. 507 In that case, the MAC address associated to the Registered Address is 508 indicated in the Target Link-Layer Address Option (TLLAO) in the NS 509 message used for the registration, as shown in Figure 4. In the case 510 of a pull model, if the 6LBR does not have a local state for the 511 mapping, it queries the EVPN support to obtain the EVPN state if any. 512 If a mapping is known then the 6LR/6LBR evaluates the registration 513 for address duplication and other possible issues per [RFC8505]. 514 Else (this is for a new mapping), if the registration is accepted, 515 then the 6LBR notifies the EVPN support to inject a route type 2 in 516 the fabric. 518 Server Leaf 519 +--------------+ +-------------------+ 520 | | | | 521 6LN 6LR/6LBR EVPN 522 | | | 523 | Ethernet | | 524 | | | 525 | NS(EARO) | | 526 |------------------->| | 527 | | | ^ 528 | | query | | 529 | |----------->| | if pull 530 | | response | | model 531 | |<-----------| | 532 | | v 533 | Evaluation (DAD) | 534 | | 535 | |new mapping | 536 | | indication | 537 | |----------->| 538 | | Inject/maintain 539 | store a mapping state | EVPN route type 2 540 | | ------------------> 541 | NA(EARO) | | [via BGP signaling] 542 |<-------------------| | 543 | | | 545 Figure 4: Direct Registration 547 In another type of deployment, the 6LR may be a virtual router in the 548 server whereas the 6LBR runs in the leaf node. To address that case, 549 the EDAR/EDAC may be used to communicate as shown in figure 5 of 550 [RFC8505]. This draft leverages the capability to insert IPv6 ND 551 options in the EDAR and EDAC messages introduced in [RFC8929] to 552 place a TLLAO that carries the MAC address associated to the 553 Registered address in the EDAR and EDAC messages as shown in 554 Figure 5: 556 Server Leaf 557 +----------------+ +----------------+ 558 | | | | 559 6LN 6LR 6LBR EVPN 560 | | | | 561 | | Ethernet | | 562 | | | | 563 | NS(EARO) | | | 564 |----------->| | | 565 | | EDAR(TLLAO) | | 566 | |------------->| | 567 | | | | ^ 568 | | | query | | 569 | | |----------->| | if pull 570 | | | response | | model 571 | | |<-----------| | 572 | | | v 573 | | Evaluation (DAD) | 574 | | | 575 | | |new mapping | 576 | | | indication | 577 | | |----------->| 578 | | | Inject/maintain 579 | | store a mapping state | EVPN route type 2 580 | | | ------------------> 581 | | EDAC(TLLAO) | | [via BGP signaling] 582 | |<-------------| | 583 | NA(EARO) | | | 584 |<-----------| | | 585 | | | | 587 Figure 5: leveraging EDAR 589 [RFC8505] updates the DAR/DAC messages into the Extended DAR/DAC to 590 carry the ROVR field. With this specification, the abstract 6LBR is 591 distributed in all the Leaf nodes and synchronized with EVPN. When a 592 server successfully registers an address to a leaf, the 6LR on that 593 leaf becomes 6LBR for that address. It stores the full state for 594 that address including the ROVR and the TID. When the address 595 registration moves to another leaf, an EDAR/EDAC flow between the 6LR 596 in the new leaf and the 6LBR in the old leaf confirms that the ROVR 597 in the NS(EARO) received at the new leaf is correct, in which case 598 the 6LR in the new leaf becomes 6LBR. 600 When the address is already registered to the local leaf, the EDAR/ 601 EDAC exchange is either local between a virtual router in the server 602 and the leaf, or internal to the leaf between a collapsed 6LR and 603 6LBR. Based on its local state, the 6LBR in the leaf checks whether 604 the proposed address/route is new and legit, and can reject it 605 otherwise. 607 It results that duplicate addresses and address impersonation attacks 608 can be filtered at the level of IPv6 ND by the 6LBR before the 609 information reaches EVPN. 611 4.3. Unicast Address Lookup with the 6LBR 613 A classical IPv6 ND stack in the server that treats the subnet prefix 614 as on-link (more in section 4.6.2. of [RFC4861]), will resolve an 615 unknown LLA mapping with a multicast NS(lookup) message addressed to 616 the solicited node multicast address (SNMA) associated with the 617 destination address being resolved. The RECOMMENDED operation in 618 that case is for the 6LBR that has a mapping state to forward the 619 packet as a unicast MAC to the LLA that is stored for the IPv6 620 address as expected by [RFC6085]. The actual owner of the address 621 can then answer unicast with a NA message, setting the override (O) 622 bit to 1, as shown in Figure 6. 624 Local Local Remote 625 Server Leaf Server 626 +----+ +--------+ +----+ 627 | | | | | | 628 6LN 6LR/6LBR 6LN 629 | | | 630 | Ethernet | | 631 | | [via EVPN ] | 632 | multicast | [Data Tunnels] | 633 | NS(lookup) | | 634 |---------------->| | 635 | | forward unicast | 636 | | NS(lookup) | 637 | |---------------------->| 638 | | | 639 | | NA(O) | 640 | |<----------------------| 641 | NA(O) | | 642 |<----------------| | 643 | | | 645 Figure 6: Forwarding legacy NS (Lookup) 647 Section 3.1. of [RFC8929] adds the capability to insert IPv6 ND 648 options in the EDAR and EDAC messages. This enables the 6LBR to 649 store the link-layer address associated with the Registered Address 650 and to serve as a mapping server. [UNICAST-LOOKUP] leverages that 651 state to define a new unicast address lookup operation, extending the 652 EDAR and EDAC messages as the Address Mapping Request (AMR) and 653 Confirmation (AMC) with a different Code Prefix [RFC8505]. 655 In that model, the router advertises the subnet prefix as not on-link 656 by setting the L flag to 0 in the Prefix Information Option (PIO), 657 more in section 4.6.2. of [RFC4861]. The expected behavior is that 658 the host that communicates with a peer in the same subnet refrains 659 from resolving the address mapping and passes the packets directly to 660 the router. 662 In the case where the router is a virtual 6LR running in the server, 663 and the source and destination are in the same subnet served by EVPN, 664 the router then resolves the address mapping on behalf of the host. 665 To that effect, the router sends a unicast AMR message to the 6LBR. 666 The message contains the SLLAO of the router to which the 6LBR will 667 reply. If the binding is found, the 6LBR replies with an AMC message 668 that contains the TLLOA with the requested MAC address, as shown in 669 Figure 7. 671 Local Local Remote 672 Server Leaf Server 673 +----------------+ +---------+ +----+ 674 | | | | | | 675 6LN 6LR 6LBR/EVPN 6LN 676 | | | | 677 | | | [via EVPN ] | 678 | | Ethernet | [Data Tunnels] | 679 | | | | 680 | | | | 681 | RA(PIO) | | | 682 | not onlink | | | 683 |<-----------| | | 684 | | | | 685 | Packet | | | 686 |----------->| | | 687 | | | | 688 | | AMR (SLLAO) | | 689 | |------------->| | 690 | | | | 691 | | AMC (TLLAO) | | 692 | |<-------------| | 693 | | | | 694 | NCE in STALE state | | 695 | | | 696 | | Packet | 697 | |------------------------------->| 698 | | | 699 | NCE in DELAY state | | 700 | | | | 702 Figure 7: Unicast Lookup from the virtual Host 704 If it is not found, [UNICAST-LOOKUP] provides the capability to 705 indicate immediately that the mapping is not known with a "not found" 706 status in the AMC, as opposed to waiting for an NS(lookup) and 707 retries to time out per [RFC4861]. 709 In a fully stateful subnet where all nodes register all their 710 addresses with [RFC8505], this means that the looked up address is 711 not present in the network; in that case the packet is dropped and an 712 ICMP error type 1 "Destination Unreachable" code 3 "Address 713 unreachable" [RFC4443] is returned as shown in Figure 8. 715 Local Local 716 Server Leaf 717 +----------------+ +---------+ 718 | | | | 719 6LN 6LR 6LBR/EVPN 720 | | | 721 | | | 722 | | Ethernet | 723 | | | 724 | | | 725 | RA(PIO | | 726 |not on-link)| | 727 |<-----------| | 728 | | | 729 | Packet | | 730 |----------->| | 731 | | | 732 | | AMR (SLLAO) | 733 | |------------->| 734 | | | 735 | | AMC(status= | 736 | | "Not Found") | 737 | |<-------------| 738 |ICMPv6 Error| | 739 | "Address | | 740 |Unreachable"| | 741 |<-----------| | 742 | Drop Packet | 743 | | | 745 Figure 8: Unicast Lookup failure 747 Note that the figures above make no assumption on the pull vs. push 748 model. In the case of pull model, the 6LBR queries the EVPN support 749 when it does not have the mapping information to satisfy a request. 750 Figure 9 illustrates a successful pull model lookup flow, when the 751 route type 2 for the mapping is already known on the EVPN side. 753 Server Leaf 754 +----------------+ +----------------+ 755 | | | | 756 6LN 6LR 6LBR EVPN 757 | | | | 758 | | Ethernet | | 759 | | | | 760 | | | | 761 | | | | Receive EVPN 762 | | | | route type 2 for 763 | | | | remote address A' 764 | | | | [via BGP signaling] 765 | | | |<----------------- 766 | | | store a mapping state 767 | | | | 768 |Packet for A' | | 769 |----------->| | | 770 | |AMR(lookup A')| | 771 | |------------->| | 772 | | |Query addr A' 773 | | |----------->| 774 | | | | 775 | | | return LLA | 776 | | |<-----------| 777 | | | | 778 | |AMC(A''s TLLA)| | 779 | |<-------------| | 780 | | | | 781 | | Packet for A' | 782 | | [via EVPN ] | 783 | | [Data Tunnels] | 784 | |-----------------------------------> 785 | | | | 787 Figure 9: Pull model 789 In the case of push model, the EVPN support synchronizes its state 790 upon a route type 2 with the 6LBR, and the 6LBR maintains an abstract 791 data structure for all information known to EVPN. This way, the 6LBR 792 already has the mapping information to satisfy any request for an 793 existing mapping and it can answer right away. Figure 10 illustrates 794 a successful push model lookup flow, when the 6LBR is already in 795 possession of the mapping. 797 Server Leaf 798 +----------------+ +----------------+ 799 | | | | 800 6LN 6LR 6LBR EVPN 801 | | | | 802 | | Ethernet | | 803 | | | | 804 | | | | 805 | | | | 806 | | | | Receive EVPN 807 | | | | route type 2 for 808 | | | | remote address A' 809 | | | | [via BGP signaling] 810 | | | |<----------------- 811 | | | store a mapping state 812 | | | | 813 | | |indicate LLA| 814 | | |<-----------| 815 | | store a mapping state | 816 | | | | 817 |Packet to A'| | | 818 |----------->| | | 819 | |AMR(lookup A')| | 820 | |------------->| | 821 | | | | 822 | |AMC(A's TLLA) | | 823 | |<-------------| | 824 | | | | 825 | | Packet to A' | 826 | | [via EVPN ] | 827 | | [Data Tunnels] | 828 | |-----------------------------------> 829 | | | | 831 Figure 10: Push model 833 In a mixed environment, a lookup failure (the mapping is not found 834 though the address is present in the network) may be caused by a 835 legacy node that was node discovered (aka a silent node). In that 836 case, it is an administrative decision for the 6LR to broadcast an 837 NS(lookup) or to return an error as shown in Figure 8. 839 5. Requirements on the EVPN-Unaware Host 841 This document describes how EVPN routing can be extended to reach a 842 Host. This section specifies the minimal EVPN-independent 843 functionality that the Host needs to implement to obtain routing 844 services for its addresses. 846 5.1. Support of 6LoWPAN ND 848 A host sees a prefix as not on-link (e.g., it learned that prefix in 849 a PIO in a RA with the L flag not set) should not attempt to resolve 850 an address within that prefix using a multicast NS(lookup). Instead, 851 it must pass its packets to a router, preferably one that advertises 852 that prefix in a PIO; it must register the address that it uses as 853 source to that router to enable source address validation using 854 [RFC8505]. It is recommended that the Host also implements [RFC8928] 855 to prove its ownership of its addresses. 857 The Host is expected to request routing services from a router only 858 if that router originates RA messages with a 6CIO that has the L, P, 859 and E flags all set to 1 as discussed in Section 3.4, unless 860 configured to do so. To obtain routing services for one of its 861 addresses, the host must register the address to a router that 862 advertises the prefix, setting the "R" and "T" flags in the EARO to 1 863 as discussed in Section 3.2.1 and Section 3.2.2, respectively. 865 This document echoes the behavior specified in [RFC9010] whereby, 866 when the R Flag set to 1 in a NS(EARO) is not echoed in the NA(EARO), 867 the host must understand that the route injection failed, and if the 868 R flag is reset later in an asynchronous NA(EARO), the host must 869 understand that routing service has failed. 871 The host may attach to multiple 6LRs and is expected to prefer those 872 that provide routing services. The abstract model for this is a P2MP 873 interface that wraps together as many P2P IP Links the host has 874 adjacencies to 6LRs over that interface. The IPv6 address and the 875 subnet are associated to that interface. The interface may be 876 virtual and it may bundle multiple physical Ethernet interfaces that 877 connect to the individual 6LRs over point to point wires, possibly 878 via a software switch. It can also be associated to one physical 879 interface to an external switch, either way the PI Links can be 880 associated to sub-interface of the interface. 882 The Host needs to register to all the 6LRs from which it desires 883 routing services. The multiple Address Registrations to several 6LRs 884 should be performed in a rapid sequence, using the same EARO for the 885 same Address. Gaps between the Address Registrations will invalidate 886 some of the routes till the Address Registration finally shows on 887 those routes. The routers recognize the same (ROVR, TID) as the 888 signal of a multihomed address and maintain all the routes. In the 889 case of EVPN, the Ethernet Segment must also be the same. The flow 890 for a successful multihomed registration is illustrated in Figure 13. 892 [RFC8505] introduces error Status values in the NA(EARO) which can be 893 received synchronously upon an NS(EARO) or asynchronously. The Host 894 needs to support both cases and refrain from using the address when 895 the Status value indicates a rejection. 897 6. Enhancements to EVPN 899 This section addresses the necessary changes to EVPN formats and 900 behavior to support address registration security per [RFC8928] and 901 mobility per [RFC8505] while retaining interoperability with 902 traditional nodes. With 6LR injecting not only MACs via packet 903 sources and TLLAO options but also ROVR into mobility extended 904 community their semantics will be somewhat extended. Specifically 905 following issues have to be addressed: 907 * The ROVR extends the semantics of the type-2 MAC advertisement via 908 changes in MAC Mobility Extended Community in the sense that the 909 MAC must be aligned with the ROVR and under normal circumstances 910 only the validity of ROVR guarantees that the type-2 MAC can be 911 allocated to the requester. A MAC validated by ROVR should take 912 precedence over MAC addresses allocated without using it given it 913 presents a much more trustworthy topological information (it will 914 be called ROVR MAC in further text). EVPN nodes not supporting 915 extensions introduced by this document will need to be led to 916 believe that a ROVR MAC is to be preferred over any advertisement 917 they see as long a ROVR MAC route is present. Nevertheless, 918 primary key of NRLI is still the IP/MAC/ESI combination as defined 919 in [RFC7432], Section 7.2 and 7.7. This implies that the same MAC 920 (and consequently ROVR MAC) can be assigned multiple IP addresses 921 and those represent independent NLRIs. 923 * The TID field in the EARO is smaller than the mobility sequence 924 number in [RFC7432]. To allow a ROVR MAC mobility to "win" over 925 legacy MACs in every circumstance, signaling must be introduced 926 that enables to distinguish a TID-generated sequence number from a 927 legacy sequence number. 929 * [RFC8505] supports IP multihoming, but does not differentiate 930 multihoming from anycast, e.g., using the MAC address, to enable 931 MAC address rotation. If an anycast IP address is registered with 932 a different ROVR it will be rejected as duplicate. If it is 933 registered with a different TID, the older sequence will be 934 withdrawn. So the basic expectation with [RFC8505] is that the 935 advertisement of an anycast address is coordinated, with the same 936 keypair known to all parties, and the same value of the TID used 937 by all nodes (and possibly never increasing), in other words, with 938 no concept of mobility. This specification adds a flag in EVPN 939 that signals that the IP address is anycast and requires the local 940 6LBR to ignore the duplication if the same IP address is 941 registered locally, and then to inject the NLRI with the A flag 942 set on mobility extended community as well. 944 * [RFC8928] needs the full ROVR to validate the address ownership, 945 but the full ROVR can be too large to advertise through BGP. When 946 an IP address is advertised through EVPN, it is REQUIRED that the 947 EVPN Next Hop represents the address of the 6LBR of the leaf where 948 the address was registered as well. This way, if the address is 949 registered later on a second leaf, the 6LR in second leaf can 950 leverage an out-of-band, i.e. via EVPN traffic carrying tunnels, 951 EDAR/EDAC exchange with that 6LBR to validate that the ROVR in the 952 registration is indeed the same. When that is the case, it can 953 continue with the registration procedure and if successful, become 954 a 6LBR for that IP address, either as a mobility event or as a 955 multihomed registration. 957 * [RFC8928] expects nodes to autoconfigure the keypair that is used 958 to form the ROVR, in which case the IPv6 address can be locally 959 autoconfigured with no central coordination; in that case, the 960 ROVR only protects the ownership and enforce first-come first- 961 serve and source address validation. But it is also possible to 962 pre-provision the ROVR in the 6LBR and then provision the keypair 963 in the node, e.g., in the case of a trusted server. To enable 964 that capability in EVPN, this specification adds a flag to signal 965 that the 6LBR that injects the address in EVPN does not provide 966 reachability to the address. When that flag is set, the value of 967 the TID is ignored in the mobility computation, the mapping to the 968 MAC address is ignored, and the route to the IP address is not 969 injected in the RIB on ROVR nodes. Non-ROVR nodes will consider 970 the node a "honey-pot". Once the address is registered by a 6LN 971 in the network and the according validation with the node 972 advertising the U-bit version of the route performed, the owner 973 will inject the route without the U-bit. A node advertising the 974 NLRI with U-bit in its mobility extended community MUST withdraw 975 the U-bit route once it sees a validated NLRI without the U-bit 976 and it MAY reinject the route with the U-bit once all routes 977 without the U-bit are withdrawn to protect the address again. 979 EVPN signaling is not used to carry ROVR since without challenge per 980 [RFC8928] they do not represent any difference over using the IP/MAC 981 combination. Instead, the full ROVR is verified upon a movement or a 982 multi-homed advertisement using an EDAR/EDAC exchange. Additionally, 983 backwards compatibility could not be preserved given comparing routes 984 based on ROVR would present a change in primary key of NLRIs which 985 non-ROVR routers do not implement. An indication from a ROVR node 986 that a MAC has been validated by proof of ownership is enough to 987 convey the necessary information. Only a small hash of the ROVR is 988 carried to speed up the identification of an address duplication. 990 6.1. ROVR MAC Mobility Extended Community 992 Extending MAC Mobility Extended Community allows to design a solution 993 that, while backwards compatible, allows to introduce ROVR MAC as 994 "more trusted" entities. Figure 11 presents the according extensions 995 that will however necessitate some further explanation. 997 To introduce a "precedence" of ROVR MACs over normal EVPN MACs ROVR 998 MACs are advertised to look like "sticky" MACs for non-ROVR nodes. 999 As defined in the glossary, for simplicity reasons such nodes will be 1000 called non-ROVR nodes vs. ROVR nodes. The "sticky" bit will force 1001 non-ROVR nodes to disregard the sequence number and accept any IP/MAC 1002 route provided. 1004 ROVR nodes MUST set the "R" flag in Mobility Extended Community to 1005 indicate that the advertisement is a ROVR MAC in case the host 1006 followed the according procedures. ROVR MACs use (instead of 1007 increasing the normal sequence number) the TID in the high bits of 1008 the sequence number field to "override" any normal MAC advertisement 1009 (further considerations will be provided in Section 6.2). 1011 ROVR nodes MUST set the "V" flag if the address assignment passed 1012 proof of ownership per [RFC8928]. Such "validated" ROVR MAC 1013 addresses will be preferred by ROVR nodes over non validated ROVR 1014 MACs. 1016 In case a ROVR node configures the address as "sticky" (since the 1017 sticky bit semantics have been changed to the point a ROVR cannot 1018 tell whether address is really sticky unless advertised as such by 1019 non-ROVR node) a new "X" flag called "super sticky" is introduced. 1021 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 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 | Type=0x06 | Sub-Type=0x00 |rsv|U|A|X|V|R|S| Reserved = 0 | 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 | TID | Reserved = 0 | ROVR Hash | 1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 Figure 11: Modified MAC Mobility Extended Community 1030 Flags: 1032 U: Unreachable, indicating that the IP address is not reachable via 1033 that EVPN next hop, but is advertised for the purpose of 1034 protecting the value of the ROVR until a first 6LBR that can reach 1035 the address becomes available. 1037 A: Anycast, indicating that the IP address duplication should be 1038 ignored. When this bit is set, TID should be ignored in 1039 comparison of EVPN advertisements, i.e. all ROVR MACs at same 1040 level of validation MUST be considered having same TID. 1042 S: Sticky as defined in [RFC7432]. 1044 R: ROVR Capable indicates that the advertisement is originated after 1045 processing signaling from host meeting the requirements in 1046 Section 5. This indicates a ROVR MAC. 1048 V: ROVR Validated indicates that the MAC passed proof of ownership 1049 per [RFC8928]. Presence of this bit implies the "R" bit being set 1050 irregardless of its value. 1052 X: Super Sticky indicates that the ROVR MAC is sticky and should 1053 follow procedures of sticky per [RFC7432]. 1055 Sequence Number Field: 1057 TID: contains the ROVR MAC TID per [RFC8505]. This MUST NOT be 1058 zero, i.e. a ROVR 1060 ROVR Hash: Hash of ROVR used to generate the according ROVR MAC. 1061 Hash is built by XOR'ing ROVR bytes in network order into the 1062 least significant byte and rotating the two bytes result after 1063 every byte by one bit to the left. 1065 6.2. Extended ROVR MAC Procedures 1067 In case a non-ROVR node advertises a sticky MAC by setting the "S" 1068 bit and a ROVR node sees an ROVR address registration for the same 1069 MAC it MUST follow procedures per [RFC7432]. 1071 In case a non-ROVR node advertises a sequence number larger than the 1072 one generated by TID on a ROVR node, the ROVR node SHOULD advertise a 1073 Sequence Number consisting of all bits being set to force a "roll- 1074 over" on all nodes and then fall back to advertising the TID 1075 generated sequence number again. In case a non-ROVR node persists in 1076 increasing the sequence number after that it is indication of 1077 violation of [RFC7432] on its part. 1079 A ROVR node advertising a ROVR MAC that has not been validated and 1080 receiving same type-2 route that has been validated MUST immediately 1081 withdraw its advertisement. 1083 A ROVR node advertising a ROVR MAC and receiving an equivalent ROVR 1084 MAC from other node with a higher TID MUST immediately withdraw its 1085 advertisement. This will allow the non-ROVR nodes to correctly 1086 interpret the sequence as MAC move despite ignoring the sequence 1087 number due to presence of "S" bit. 1089 A ROVR node that receives a ROVR MAC with "super sticky" indication 1090 and seeing the MAC locally MUST follow analogous procedures to 1091 [RFC7432]. 1093 Multi-homing a MAC on mix of ROVR and non-ROVR nodes will lead to 1094 operational notifications since per [RFC7432] the non-ROVR node will 1095 interpret the situation as a sticky MAC that has shown up on its 1096 local interface unless an implementation is somewhat clever and 1097 understands that the presence of the same ESI on all the routes 1098 indicates that this situation does not represent a sticky MAC being 1099 moved. 1101 7. Protocol Operations 1103 Following section illustrates several situations and resulting 1104 signaling in EVPN from the point of view of a ROVR node. 1106 Figure 12 illustrates the registration flow of a new address 1107 protected by [RFC8928]. The ROVR in the EARO is a Crypto-ID that 1108 derives from a public address through hashing with some other terms. 1109 The router challenges the host with a status of 5 (validation 1110 requested). 1112 The host performs the NS again, passing the parameters that enable to 1113 build the Crypto-ID in a Crypto-ID Parameters Option (CIPO), and 1114 signing that set of parameters together with a pair of Nonce values, 1115 one from each side, in a resulting Neighbor Discovery Protocol 1116 Signature Option (NDPDO). The 6LR first verifies that the Crypto-ID 1117 can be rebuilt based on the public key, then verifies that the 1118 signature in the NDPSO was effectively performed with the associated 1119 public key. When that is the case, the registration flow can 1120 continue, else the registration is rejected with a status of 10 1121 (Validation Failed) in the NA(EARO). 1123 With this specification, the 6LBR communicates internally with the 1124 collocated eVPN router to inject the route in eVPN. Since the 1125 [RFC8928] validation was performed, the V flag is set. Once this is 1126 done, the local 6LBR installs a local state associated to the NCE and 1127 becomes owner of the registration, whereas the remote leaves 1128 optionally install a remote state for the address with the indication 1129 of the 6LBR that owns the registration. The local 6LBR MUST be 1130 signalled as EVPN Next Hop for the route. 1132 Local Local Route Remote 1133 Server Leaf Reflector Leaf 1134 +-------+ +---------+ +-------+ +---------+ 1135 | | | | | | | | 1136 6LN 6LBR/EVPN BGP EVPN/6LBR 1137 | | | | 1138 | Ethernet | [via BGP signaling] | 1139 | | | | 1140 | | | | 1141 | NS(EARO( | | | 1142 | R set)) | | | 1143 |--------------->| | | 1144 | ROVR in EARO is cryptographic | | 1145 | | | | 1146 | NA(EARO( | | | 1147 | R not set, | | | 1148 | status = 5), | | | 1149 | Nonce1) | | | 1150 |<---------------| | | 1151 | | | | 1152 | NS(EARO( | | | 1153 | R set), | | | 1154 | CIPO, | | | 1155 | Nonce2, | | | 1156 | NDPSO) | | | 1157 |--------------->| | | 1158 | Proof verified | | 1159 | no state for that address | | 1160 | install local state | | 1161 | | | | 1162 | | ROVR MAC Route A' | 1163 | |---------------->| | 1164 | route injected | | 1165 | | | | 1166 | NA(EARO( | | | 1167 | R set, | | | 1168 | status = 0)) | | | 1169 |<---------------| | | 1170 | | | ROVR MAC Route A' 1171 | | |--------------->| 1172 | | | install remote state 1173 | | | | 1174 Figure 12: Host Registration 1176 Figure 13 presents the same flow but for a multihomed address; here 1177 and in the following flows, the proof of ownership section is not 1178 shown, but its use is RECOMMENDED. The interesting piece is that 1179 when the node registers to the second 6LBR, that second 6LBR find 1180 that there is a first 6LBR that already own the registration. Using 1181 and EDAR / EDAC flow, the second 6LBR validates that the ROVR and TID 1182 are identical, in which case it accepts the registration and becomes 1183 another 6LBR owner of the registration. The result is that the 2 1184 6LBRs are synchronized and any of the 2 can now be used, e.g., if the 1185 address is registered a third time. 1187 Local Local Local 1188 Server Leaf 1 Leaf 2 Reflector 1189 +-------+ +---------+ +---------+ +---------+ 1190 | | | | | | | | 1191 6LN 6LBR/EVPN 6LBR/EVPN | 1192 | | | | 1193 | Ethernet | | | 1194 | | | [via BGP signaling] 1195 | | | | 1196 | NS(EARO) | | | 1197 |--------------->| | | 1198 | install local state | | 1199 | | | 1200 | |------ROVR MAC Route A' ----->| 1201 | NA(EARO) | | | 1202 |<---------------| | | 1203 | | |<----------------| 1204 | | install remote state | 1205 | | | | 1206 | NS(same address, ES and EARO) | | 1207 |------------------------------>| | 1208 | | | | 1209 | | Same ES and ROVR Hash | 1210 | | EDAR | | 1211 | |<-------------| | 1212 | | | | 1213 | ROVR match, TID OK | | 1214 | | | | 1215 | |EDAC(status=0)| | 1216 | |------------->| | 1217 | | install local state | 1218 | | | | 1219 | | ROVR MAC Route A' | 1220 | | |---------------->| 1221 | |<-------------------------------| 1222 | install remote state | | 1223 | | | | 1224 | NA(EARO(status = 0)) | | 1225 |<------------------------------| | 1226 | | | | 1228 Figure 13: Multihoming 1230 The registration is associated with a lifetime, and it must be 1231 renewed with an incremented TID. The new TID is propagated in eVPN 1232 as illustrated in Figure 14. 1234 Local Local Route Remote 1235 Server Leaf Reflector Leaf 1236 +-------+ +---------+ +-------+ +---------+ 1237 | | | | | | | | 1238 6LN 6LBR/EVPN BGP EVPN/6LBR 1239 | | | | 1240 | Ethernet | [via BGP signaling] | 1241 | | | | 1242 | | | | 1243 | NS(EARO( | | | 1244 | TID+1)) | | | 1245 |--------------->| | | 1246 | renew lifetime locally | | 1247 | | | | 1248 | | ROVR MAC Route A'(TID+1) | 1249 | |---------------->| | 1250 | NA(EARO | |--------------->| 1251 | status = 0)) | | update remote state 1252 |<---------------| | | 1253 | | | | 1254 | | | | 1256 Figure 14: Host Registration Renewal 1258 Figure 15 illustrates the case where a second host registers the same 1259 address, creating a potential address duplication situation. in most 1260 cases, the ROVR hash will be different, and the local 6LBR can reject 1261 the registration is a status of 1 (duplicate) right away. 1263 Local Local Route Remote 1264 Server Leaf Reflector Leaf 1265 +-------+ +---------+ +-------+ +---------+ 1266 | | | | | | | | 1267 6LN 6LBR/EVPN BGP EVPN/6LBR 1268 | | | | 1269 | Ethernet | | | 1270 | | [via BGP signaling] | 1271 | | | | 1272 | | | Local state for A' 1273 | | | | 1274 | | ROVR MAC Route A' | 1275 | | ROVR Hash G | 1276 | | |<---------------| 1277 | |<----------------| | 1278 | Create remote state for A' | | 1279 | | | | 1280 | NS(EARO) | | | 1281 |--------------->| | | 1282 | compute ROVR Hash F | | 1283 | | | | 1284 | NA(EARO( | | | 1285 | status = 1)) | | | 1286 |<---------------| | | 1287 | | | | 1288 | | | | 1290 Figure 15: Duplicate Addresses 1292 Figure 16 illustrates the case of an address duplication situation 1293 where by chance, the ROVR hashes are the same. In that case, the 1294 local 6LR checks with the 6LBR that owns the registration using an 1295 EDAR/EDAC message exchange. As opposed to the ROVR hash, the full 1296 ROVRs do not collide and the registration is also rejected. 1298 Local Local Route Remote 1299 Server Leaf Reflector Leaf 1300 +-------+ +---------+ +-------+ +---------+ 1301 | | | | | | | | 1302 6LN 6LBR EVPN BGP EVPN/6LBR 1303 | | | | | | 1304 | Ethernet | | | | | 1305 | | | [via BGP signaling] | | 1306 | | | | | | 1307 | | | | Local state for A' 1308 | | | | | | 1309 | | | ROVR MAC Route A' | | 1310 | | | ROVR Hash G | | 1311 | | | |<--------------| | 1312 | | |<--------------| | | 1313 | Create remote state for A' | | | 1314 | | | | | 1315 | | | 1316 | | [[out of band signaling]] | 1317 | NS(EARO) | | 1318 |------------->| | 1319 | compute ROVR Hash G | 1320 | | | 1321 | | EDAR to EVPN Next Hop | 1322 | |-------------------------------------->| 1323 | | | 1324 | | EDAC (status = 1) | 1325 | |<--------------------------------------| 1326 | | | 1327 | NA(EARO( | | 1328 | status = 1))| | 1329 |<-------------| | 1330 | | | 1332 Figure 16: Duplicate Addresses, ROVR Hash Collision 1334 Figure 17 shows a rare case where the registration has already moved 1335 elsewhere with an incremented TID when the local registration is 1336 received after being delayed in the network. In that case, the 1337 registration is rejected with a status of 3 (moved). 1339 Local Local Route Remote 1340 Server Leaf Reflector Leaf 1341 +-------+ +---------+ +-------+ +---------+ 1342 | | | | | | | | 1343 6LN 6LBR/EVPN BGP EVPN/6LBR 1344 | | | | 1345 | Ethernet | | | 1346 | | [via BGP signaling] | 1347 | | | | 1348 | | ROVR MAC Route A' | 1349 | | ESI X', Hash F, TID Z | 1350 | | |<---------------| 1351 | |<----------------| | 1352 | create remote start A' | | 1353 | ESI X', ROVR Hash F, TID Z | | 1354 | | | | 1355 | NS(EARO( | | | 1356 | TID=Z-1)) | | | 1357 |--------------->| | | 1358 | computes as | | 1359 | ROVR Hash F | | 1360 | ESI X'', TID Z-1 | | 1361 | NA(EARO) | | | 1362 | status = 3)) | | | 1363 |<---------------| | | 1364 | | | | 1366 Figure 17: Address Already Moved 1368 Address move differs from multi-homing by the ESI being different as 1369 visualized by Figure 18. In case of different ESI BGP signalling 1370 happens immediately, in case of multi-homing we can reasonably expect 1371 for the signalling to catch up on the other leg with a new, higher 1372 TID. However, since ESI matches TID doesn't matter strictly speaking 1373 and the new remote state can be installed as is. However, if 6LN is 1374 not refreshing it registration we can expect elapsed lifetime to 1375 create scenario Figure 21 over time. 1377 Local Local Route Remote 1378 Server Leaf Reflector Leaf 1379 +-------+ +---------+ +-------+ +---------+ 1380 | | | | | | | | 1381 6LN 6LBR/EVPN BGP EVPN/6LBR 1382 | | | | 1383 | Ethernet | | | 1384 | | [via BGP signaling] | 1385 | NS(EARO) | | | 1386 |--------------->| | | 1387 | Create local state | | 1388 | | ROVR MAC Route A' | 1389 | | ESI X', ROVR Hash F, TID Z | 1390 | |---------------->| | 1391 | | |--------------->| 1392 | | | Create remote state 1394 Same ES (multihomed): 1395 | | | |<-- 1396 | | | New local state A' created 1397 | | | | 1398 | | ROVR MAC Route A' | 1399 | | ESI X', Hash F, TID Z+1 | 1400 | | |<---------------| 1401 | |<----------------| | 1402 | Create remote state | | 1403 | Keep local expect renew | | 1404 | | | | 1406 Different ES (movement): 1407 | | | |<-- 1408 | | | New local state A' created 1409 | | | | 1410 | | ROVR MAC Route A' | 1411 | | ESI X'', ROVR Hash F, TID Z+1 | 1412 | | |<---------------| 1413 | |<----------------| | 1414 | Create remote state | | 1415 | | | | 1416 | NA(EARO( | | | 1417 | status = 4)) | | | 1418 |<---------------| | | 1419 | | Withdraw ROVR MAC Route A' | 1420 | |---------------->| | 1421 | | |--------------->| 1422 | remove local state | | 1423 | | | | 1424 Figure 18: Address Move 1426 The host that registered the address may cancel the registration at 1427 any time, e.g., if the address is removed fmor its own interface. 1428 This is done by registering with a lifetime if 0 as shown in 1429 Figure 19. The Leaf may respond with a status of 0 to indicate 1430 success, but a status of 4 (removed) is preferred for this situation. 1432 Local Local Route Remote 1433 Server Leaf Reflector Leaf 1434 +-------+ +---------+ +-------+ +---------+ 1435 | | | | | | | | 1436 6LN 6LBR/EVPN BGP EVPN/6LBR 1437 | | | | 1438 | Ethernet | | | 1439 | | [via BGP signaling] | 1440 | | | | 1441 | NS(EARO, | | | 1442 | lifetime=0) | | | 1443 |--------------->| | | 1444 | | | | 1445 | | Withdraw ROVR MAC Route A' | 1446 | |---------------->| | 1447 | | |--------------->| 1448 | NA(EARO( | | | 1449 | status = 4)) | | | 1450 |<---------------| | | 1451 | | | | 1452 | remove local state | | 1453 | | | | 1455 Figure 19: Address Removal 1457 The host that registered the address may withdraw the route but 1458 maintain the NCE, e.g., in the case where it is multihomed but does 1459 not want to use one interface for the traffic back as this time. 1460 This is done by registering with the R flag set to 0 as shown in 1461 Figure 20. 1463 | NS(EARO, | | | 1464 | R reset) | | | 1465 |--------------->| | | 1466 | | | | 1467 | | Withdraw ROVR MAC Route A' | 1468 | |---------------->| | 1469 | | |--------------->| 1470 | NA(EARO( | | | 1471 | R reset, | | | 1472 | status = 0)) | | | 1473 |<---------------| | | 1474 | | | | 1475 | retain only NCE | | 1476 | | | | 1478 Figure 20: Route Type 2 Removal 1480 When the lifetime elapses, the 6LBR requires the collocated eVPN 1481 router to withdraw the route. 1483 Local Local Route Remote 1484 Server Leaf Reflector Leaf 1485 +-------+ +---------+ +-------+ +---------+ 1486 | | | | | | | | 1487 6LN 6LBR/EVPN BGP EVPN/6LBR 1488 | | | | 1489 | Ethernet | | | 1490 | | [via BGP signaling] | 1491 | | | | 1492 | lifetime Expired | | 1493 | | | | 1494 | | Withdraw ROVR MAC Route A' | 1495 | |---------------->| | 1496 | | |--------------->| 1497 | NA(EARO( | | | 1498 | status = 4)) | | | 1499 |<---------------| | | 1500 | | | | 1501 | remove local state | | 1502 | | | | 1504 Figure 21: Lifetime Elapse 1506 8. Security Considerations 1508 TBD 1510 9. IANA Considerations 1512 10. Acknowledgments 1514 The authors wish to thank you for reading that far. We acknowledge 1515 and express gratitude to Wen Lin, Stephane Litkowski, Eric Levy- 1516 Abegnoli, Lukas Krattiger, Jerome Tollet, and Ali Sajassi, for their 1517 help and support. 1519 11. Normative References 1521 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1522 Requirement Levels", BCP 14, RFC 2119, 1523 DOI 10.17487/RFC2119, March 1997, 1524 . 1526 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1527 Control Message Protocol (ICMPv6) for the Internet 1528 Protocol Version 6 (IPv6) Specification", STD 89, 1529 RFC 4443, DOI 10.17487/RFC4443, March 2006, 1530 . 1532 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1533 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1534 DOI 10.17487/RFC4861, September 2007, 1535 . 1537 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1538 Address Autoconfiguration", RFC 4862, 1539 DOI 10.17487/RFC4862, September 2007, 1540 . 1542 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 1543 Bormann, "Neighbor Discovery Optimization for IPv6 over 1544 Low-Power Wireless Personal Area Networks (6LoWPANs)", 1545 RFC 6775, DOI 10.17487/RFC6775, November 2012, 1546 . 1548 [RFC6085] Gundavelli, S., Townsley, M., Troan, O., and W. Dec, 1549 "Address Mapping of IPv6 Multicast Packets on Ethernet", 1550 RFC 6085, DOI 10.17487/RFC6085, January 2011, 1551 . 1553 [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for 1554 IPv6 over Low-Power Wireless Personal Area Networks 1555 (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November 1556 2014, . 1558 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 1559 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 1560 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 1561 2015, . 1563 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1564 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1565 May 2017, . 1567 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 1568 Perkins, "Registration Extensions for IPv6 over Low-Power 1569 Wireless Personal Area Network (6LoWPAN) Neighbor 1570 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 1571 . 1573 [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., 1574 Uttaro, J., and W. Henderickx, "A Network Virtualization 1575 Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, 1576 DOI 10.17487/RFC8365, March 2018, 1577 . 1579 [RFC8928] Thubert, P., Ed., Sarikaya, B., Sethi, M., and R. Struik, 1580 "Address-Protected Neighbor Discovery for Low-Power and 1581 Lossy Networks", RFC 8928, DOI 10.17487/RFC8928, November 1582 2020, . 1584 [UNICAST-LOOKUP] 1585 Thubert, P. and E. Levy-Abegnoli, "IPv6 Neighbor Discovery 1586 Unicast Lookup", Work in Progress, Internet-Draft, draft- 1587 thubert-6lo-unicast-lookup-00, 25 January 2019, 1588 . 1591 12. Informative References 1593 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1594 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1595 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1596 Low-Power and Lossy Networks", RFC 6550, 1597 DOI 10.17487/RFC6550, March 2012, 1598 . 1600 [RFC8929] Thubert, P., Ed., Perkins, C.E., and E. Levy-Abegnoli, 1601 "IPv6 Backbone Router", RFC 8929, DOI 10.17487/RFC8929, 1602 November 2020, . 1604 [RFC9010] Thubert, P., Ed. and M. Richardson, "Routing for RPL 1605 (Routing Protocol for Low-Power and Lossy Networks) 1606 Leaves", RFC 9010, DOI 10.17487/RFC9010, April 2021, 1607 . 1609 [RIFT] Przygienda, T., Sharma, A., Thubert, P., Rijsman, B., and 1610 D. Afanasiev, "RIFT: Routing in Fat Trees", Work in 1611 Progress, Internet-Draft, draft-ietf-rift-rift-12, 26 May 1612 2020, . 1615 [IANA-EARO-STATUS] 1616 IANA, "Address Registration Option Status Values", 1617 . 1620 Authors' Addresses 1622 Pascal Thubert (editor) 1623 Cisco Systems, Inc 1624 France 1626 Phone: +33 497 23 26 34 1627 Email: pthubert@cisco.com 1629 Tony Przygienda 1630 Juniper Networks, Inc 1631 Switzerland 1633 Email: prz@juniper.net 1635 Jeff Tantsura 1636 Microsoft 1638 Email: jefftant.ietf@gmail.com