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