idnits 2.17.1 draft-ietf-bess-evpn-na-flags-08.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 (October 12, 2020) is 1291 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 (-17) exists of draft-ietf-bess-evpn-irb-extended-mobility-03 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Workgroup J. Rabadan, Ed. 3 Internet-Draft S. Sathappan 4 Intended status: Standards Track K. Nagaraj 5 Expires: April 15, 2021 Nokia 6 W. Lin 7 Juniper 8 October 12, 2020 10 Propagation of ARP/ND Flags in EVPN 11 draft-ietf-bess-evpn-na-flags-08 13 Abstract 15 This document defines an Extended Community that is advertised along 16 with an EVPN MAC/IP Advertisement route and carries information 17 relevant to the ARP/ND resolution, so that an EVPN PE implementing a 18 proxy-ARP/ND or ARP/ND (on IRB interfaces) function can reply to ARP 19 Requests or Neighbor Solicitations with the correct information. 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 April 15, 2021. 38 Copyright Notice 40 Copyright (c) 2020 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 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Terminology and Conventions . . . . . . . . . . . . . . . 3 57 2. The EVPN ARP/ND Extended Community . . . . . . . . . . . . . 3 58 3. Use of the EVPN ARP/ND Extended Community . . . . . . . . . . 5 59 3.1. Transmission of the EVPN ARP/ND Extended Community . . . 5 60 3.2. Reception of the EVPN ARP/ND Extended Community . . . . . 6 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 63 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 66 7.2. Informative References . . . . . . . . . . . . . . . . . 10 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 69 1. Introduction 71 An Ethernet Virtual Private Network (EVPN) MAC/IP Advertisement route 72 can optionally carry IPv4 or IPv6 addresses associated with a MAC 73 address. Remote Provider Edge (PE) routers can use this information 74 to populate their Address Resolution Protocol (ARP) or Neighbor 75 Discovery (ND) tables on Integrated Routing and Bridging (IRB) 76 interfaces or their proxy-ARP/ND tables in Broadcast Domains (BD). 77 PEs can then reply locally (act as an ARP/ND proxy, as per [RFC7432]) 78 to IPv4 ARP requests and IPv6 Neighbor Solicitation messages and 79 reduce/suppress the flooding produced by the Address Resolution 80 procedure. However, the information conveyed in the EVPN MAC/IP 81 Advertisement route may not be enough for the remote PE to reply to 82 local ARP or ND requests. For example, if a PE learns an IPv6->MAC 83 ND entry via EVPN, the PE would not know if that particular IPv6->MAC 84 pair belongs to a router or a host, and if that address is an anycast 85 address, as this information is not carried in the EVPN MAC/IP 86 Advertisement routes. 88 This document defines an Extended Community that is advertised along 89 with an EVPN MAC/IP Advertisement route and carries information 90 relevant to the ARP/ND resolution, so that an EVPN PE implementing a 91 proxy-ARP/ND function can reply to ARP Requests or Neighbor 92 Solicitations with the correct information. In particular, the Flags 93 defined in [RFC4861] can now be conveyed along with a MAC/IP 94 Advertisement route, so that an egress EVPN PE can issue Neighbor 95 Advertisement messages with the correct Flag information. 97 The Flags are carried in the EVPN Address Resolution Protocol (ARP) 98 and Neighbor Discovery (ND) Extended Community, as described in the 99 following sections. 101 1.1. Terminology and Conventions 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in BCP 106 14 [RFC2119] [RFC8174] when, and only when, they appear in all 107 capitals, as shown here. 109 EVPN: Ethernet Virtual Private Networks, as in [RFC7432]. 111 BD: Broadcast Domain, also described in [RFC7432]. 113 ARP: Address Resolution Protocol. 115 ND: Neighbor Discovery protocol, specified in [RFC4861]. 117 PE: Provider Edge router. 119 CE: Customer Edge router. 121 IRB: Integrated Routing and Bridging interface. 123 Proxy-ARP/ND: function on the EVPN PEs by which received Address 124 Resolution Protocol (ARP) Requests or Neighbor Solicitation (NS) 125 messages are replied to locally by the PE, without the need to flood 126 the requests to remote PEs in the BD. In order to reply to ARP 127 Requests or NS messages, the PE does a lookup on an ARP/ND table, 128 that is a collection of IP->MAC entries learned by the PE. 130 IP->MAC: an IP address and MAC address combination that represents a 131 given host and is added to an Address Resolution Protocol table or 132 Neighbor Discovery table. This document uses IP->MAC generically for 133 IPv4 and IPv6 addresses. When something is specific to IPv4, the 134 document will use IPv4->MAC and likewise, IPv6->MAC will be used when 135 something is specific to IPv6 entries only. 137 Familiarity with the terminology in [RFC7432] and [RFC4861] is 138 expected. 140 2. The EVPN ARP/ND Extended Community 142 This document defines a transitive EVPN Extended Community (Type 143 field value of 0x06) with a Sub-Type of 0x08, as allocated by IANA. 145 It is advertised along with EVPN MAC/IP Advertisement routes that 146 carry an IPv4 or IPv6 address. 148 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 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | Type=0x06 | Sub-Type=0x08 |Flags (1 octet)| Reserved=0 | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Reserved=0 | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 Flags field: 157 0 1 2 3 4 5 6 7 158 +-+-+-+-+-+-+-+-+ 159 | |I| |O|R| 160 +-+-+-+-+-+-+-+-+ 162 The following Flags are defined in the Flags field, third octet of 163 the Extended Community: 165 R - Router Flag (corresponds to Bit 23 of the Extended Community) 167 Bit 7 of the Flags field is defined as the "Router Flag". When set, 168 the R Flag indicates that the IPv6->MAC pair advertised in the MAC/IP 169 Advertisement route along with the Extended Community belongs to an 170 IPv6 router. If the R Flag is zero, the IPv6->MAC pair belongs to a 171 host. The receiving PE implementing the ND function will use this 172 information in Neighbor Advertisement messages for the associated 173 IPv6 address. This Flag has no meaning for ARP IPv4->MAC entries and 174 MUST be ignored when the Extended Community is received with an EVPN 175 MAC/IP Advertisement route for an IPv4->MAC pair. 177 O - Override Flag (corresponds to Bit 22 of the Extended Community) 179 Bit 6 of the Flags field is defined as the "Override Flag". An 180 egress PE will normally advertise IPv6->MAC pairs with the O Flag 181 set, and only when IPv6 "anycast" is enabled in the BD or interface, 182 the PE will send an IPv6->MAC pair with the O Flag = 0. The ingress 183 PE will install the ND entry with the received O Flag and will always 184 use this O Flag value when replying to a Neighbor Solicitation for 185 the IPv6 address. Similarly to the Router Flag, the Override Flag 186 has no meaning for ARP IPv4->MAC entries and MUST be ignored when the 187 Extended Community is received with an EVPN MAC/IP Advertisement 188 route for an IPv4->MAC pair. 190 I - Immutable ARP/ND Binding Flag (corresponds to Bit 20 of the 191 Extended Community) 192 Bit 4 of the Flags field is defined as the "Immutable ARP/ND Binding 193 Flag". When set, the egress PE indicates that the IP->MAC pair sent 194 in an EVPN MAC/IP Advertisement route (along with the Extended 195 Community) is a configured ARP/ND entry. In this case, the IP 196 address in the EVPN MAC/IP Advertisement route can only be bound 197 together with the MAC address specified in the same route, and not 198 with any other MAC addresses received in a different route without 199 the I Flag set. 201 Bits 0-3 and 5 are not assigned by this document. They MUST be set 202 to zero, and ignored on receipt. 204 The reserved fields are set to 0 and ignored by the receiver. 206 3. Use of the EVPN ARP/ND Extended Community 208 This section describes the relevant procedures when advertising and 209 processing the EVPN ARP/ND Extended Community. In all the procedures 210 below a "PE" must be interpreted as a "PE which supports the ND/ARP 211 proxy function (introduced by [RFC7432]) and implements the 212 propagation of the ARP/ND Flags that this document specifies". 214 3.1. Transmission of the EVPN ARP/ND Extended Community 216 When an IP->MAC entry is not learned via EVPN, a PE may learn IP->MAC 217 pairs in the management plane (this will create static entries in the 218 ARP/ND or proxy-ARP/ND table) or by snooping ARP or Neighbor 219 Advertisement (NA) messages coming from the CE (this will create 220 dynamic entries). Those static and dynamic IP->MAC entries will be 221 advertised in EVPN MAC/IP Advertisement routes that use the EVPN ARP/ 222 ND Extended Community as follows: 224 o Advertised MAC/IP Advertisement routes for IPv6->MAC entries MUST 225 include one (and only one) ARP/ND Extended Community with the R 226 and O Flag values associated with the entry. Those Flag values 227 are either dynamically learned (from NA messages) or configured in 228 case of static entries. 230 o MAC/IP Advertisement routes for IPv4->MAC entries MAY include one 231 ARP/ND Extended Community. If the EVPN ARP/ND Extended Community 232 is advertised along with an EVPN IPv4/MAC Advertisement route, the 233 R and O Flags SHOULD be set to zero. 235 o If an IP->MAC pair is static (it has been configured) the 236 corresponding MAC/IP Advertisement route MUST be sent along with 237 an ARP/ND Extended Community with the I Flag set. 239 o This Extended Community does not change the procedures described 240 in [RFC7432]. Specifically the procedures for advertising the MAC 241 Mobility Extended Community along with the MAC/IP Advertisement 242 route are not changed. 244 3.2. Reception of the EVPN ARP/ND Extended Community 246 In addition to the procedures specified in [RFC7432] a PE receiving a 247 MAC/IP Advertisement route will process the EVPN ARP/ND Extended 248 Community as follows: 250 o Only one EVPN ARP/ND Extended Community is expected to be received 251 along with an EVPN MAC/IP Advertisement route. If more than one 252 ARP/ND Extended Community is received, the PE MUST consider only 253 the first one on the list for processing purposes and MUST NOT 254 propagate the rest of the ARP/ND Extended Communities. 256 o The R, O and I Flags MUST be ignored if they are advertised along 257 with an EVPN MAC/IP Advertisement route that does not contain an 258 IP (IPv4 or IPv6) address. Otherwise they are processed as 259 follows. 261 o R and O Flags processing: 263 * If the EVPN MAC/IP Advertisement route contains an IPv6 address 264 and the EVPN ARP/ND Extended Community, the PE MUST add the R 265 and O Flag values to the ND entry in the ND or proxy-ND table, 266 and propagate the value of the R and O flags from the ARP/ND 267 Extended Community to the Neighbor Advertisements when replying 268 to a Solicitation for the IPv6 address. 270 * If no EVPN ARP/ND Extended Community is received along with the 271 route, the PE will add the default R and O Flags to the entry. 272 The default R Flag SHOULD be an administrative choice. The 273 default O Flag SHOULD be 1. 275 * A PE MUST ignore the received R and O Flags for an EVPN MAC/IP 276 Advertisement route that contains an IPv4->MAC pair. 278 o I Flag processing: 280 * A PE receiving an EVPN MAC/IP Advertisement route containing an 281 IP->MAC and the I Flag set SHOULD install the IP->MAC entry in 282 the ARP/ND or proxy-ARP/ND table as an "Immutable binding". 283 This Immutable binding entry will override an existing non- 284 immutable binding for the same IP->MAC. The absence of the 285 EVPN ARP/ND Extended Community in a MAC/IP Advertisement route 286 indicates that the IP->MAC entry is not an "Immutable binding". 288 * Receiving multiple EVPN MAC/IP Advertisement routes with I=1 289 for the same IP but different MAC is considered a 290 misconfiguration. Note that if a configured IP1->MAC1 changes 291 to point to a new MAC address, i.e., IP1->MAC2, the EVPN MAC/IP 292 Advertisement route for IP1->MAC1 will be withdrawn before the 293 EVPN MAC/IP Advertisement route for IP1->MAC2 is advertised. 295 * A PE originating an EVPN MAC/IP Advertisement route for 296 IP1->MAC1 with I=1 MAY also originate the route with the Static 297 bit set (in the MAC Mobility Extended Community). In such a 298 case, the IP1->MAC1 binding is not only immutable but it cannot 299 move as well. Even so, if an update for the same IP1->MAC1 300 immutable and static, is received from a different PE, one of 301 the two routes will be selected. This case is analogous to the 302 [RFC7432] case when two MAC/IP routes with the Static bit set 303 are received, and the PE likewise MUST alert the operator of 304 such a situation. 306 In a situation where a host (with an IP->MAC that is configured as 307 Immutable binding in the attached PE) is allowed to move between PEs 308 (that is, the associated MAC is non-static), PEs can receive multiple 309 MAC/IP advertisement routes for the same IP->MAC. In such 310 situations, MAC mobility procedures as in [RFC7432] dictate the 311 reachability of the MAC. 313 As an example of the use of the I Flag, consider PE1, PE2 and PE3 are 314 attached to the same BD. PE1 originates an EVPN MAC/IP Advertisement 315 route for IP1->MAC1 with I=1; later on, PE2 also originates an EVPN 316 MAC/IP Advertisement route IP1->MAC1 with a higher sequence number 317 and I=1. Then all the EVPN PEs attached to the same BD SHOULD retain 318 their IP1->MAC1 ARP/ND binding but update MAC1's forwarding 319 destination to PE2. If for some reason, PE3 originates an EVPN MAC/ 320 IP Advertisement route for IP1->MAC2 with I=0 (even with a higher 321 sequence number), then the EVPN PEs in the BD will not update their 322 IP1->MAC1 ARP/ND bindings, since IP1 is bound to MAC1 (MAC2 SHOULD 323 still be programmed in the layer-2 BDs). This is considered a 324 misconfiguration in PE3. 326 The use of the Flag I=1 assumes that a given IP is always bound to 327 the same MAC address, and therefore the mobility procedures described 328 in [I-D.ietf-bess-evpn-irb-extended-mobility] for "Host IP move to a 329 new MAC" will not apply. 331 4. Security Considerations 333 The same security considerations described in [RFC7432] apply to this 334 document. In general, it is worth noting that the use of Proxy ARP/ 335 ND in EVPN BDs may add some security risks. Attackers can make use 336 of ARP/ND messages to create state in all the PEs attached to the 337 same BD as the attacker and exhaust resources in those PEs. 338 Therefore, additional security mechanisms may be needed. Some 339 examples of such additional security mechanisms are e.g., limit the 340 number of Proxy ARP/ND entries per-BD/per-port, or monitor closely 341 the rate at which hosts create dynamic Proxy-ARP/ND entries. 343 In addition, this document adds pieces of information that impact on 344 the way ARP/ND entries are installed in ARP/ND and/or proxy-ARP/ND 345 tables, and therefore the resolution protocols for IPv4 and IPv6 346 addresses. For instance, if a given IPv6->MAC binding is configured 347 with the wrong R or O Flags (intentionally or not) on a given PE, the 348 rest of the PEs attached to the same BD will install the wrong 349 information for the IPv6->MAC. This will cause all the PEs in the BD 350 to reply to Neighbor Solicitations for the IPv6 with Neighbor 351 Advertisement (NA) messages containing the wrong R and O Flags. For 352 example, as specified in [RFC4861], the receiver of a NA message with 353 O not set will not update its existing cache entry for the IP->MAC, 354 hence the communication between the owner of the IP address and the 355 receiver of the NA message with the wrong O flag will fail. 356 Similarly, the receiver of a NA message with the wrong R flag, may 357 update its Default Router List incorrectly adding or removing an 358 entry, which could for example lead to sending traffic to a node that 359 is not a router, causing the traffic to be dropped . 361 The I Flag, or Immutable ARP/ND Binding Flag, introduces a useful 362 security tool so that an operator makes sure a given IP address is 363 always bound to the same MAC and that information is distributed to 364 all the PEs attached to the same BD. ARP/ND spoofing attacks from 365 hosts injecting Gratuitous ARPs or unsolicited Neighbor Advertisement 366 messages for that IP address with a different MAC address will not 367 succeed to be programmed in ARP/ND and proxy-ARP/ND tables and 368 therefore will avoid attracting traffic to the spoofer. 370 5. IANA Considerations 372 This document request that the Name of the currently registered value 373 for Sub-Type 0x08 in the EVPN Extended Community Sub-Types registry 374 (https://www.iana.org/assignments/bgp-extended-communities/bgp- 375 extended-communities.xhtml#evpn) be changed to: 377 +----------+---------------------------+-----------------+ 378 | Sub-Type | Name | Reference | 379 +----------+---------------------------+-----------------+ 380 | 0x08 | ARP/ND Extended Community | [this document] | 381 +----------+---------------------------+-----------------+ 383 This document also requests the creation of a registry called "ARP/ND 384 Extended Community Flags" where the following initial allocations are 385 made: 387 +---------------+---------------------------------+-----------------+ 388 | Flag position | Name | Reference | 389 +---------------+---------------------------------+-----------------+ 390 | 0-3 | Unassigned | - | 391 | 4 | Immutable ARP/ND Binding Flag | [this document] | 392 | | (I) | | 393 | 5 | Unassigned | - | 394 | 6 | Override Flag (O) | [this document] | 395 | 7 | Router Flag (R) | [this document] | 396 +---------------+---------------------------------+-----------------+ 398 The registration procedure for this registry is Standards Action. 399 This registry should be located in the Border Gateway Protocol (BGP) 400 Extended Communities general registry 401 (https://www.iana.org/assignments/bgp-extended-communities/bgp- 402 extended-communities.xhtml). 404 Note that the Flag position 5 is left unassigned and not used in this 405 specification since it was previously requested by 406 [I-D.rbickhart-evpn-ip-mac-proxy-adv]. 408 6. Acknowledgments 410 The authors would like to thank Ali Sajassi for his feedback. 412 7. References 414 7.1. Normative References 416 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 417 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 418 DOI 10.17487/RFC4861, September 2007, 419 . 421 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 422 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 423 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 424 2015, . 426 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 427 Requirement Levels", BCP 14, RFC 2119, 428 DOI 10.17487/RFC2119, March 1997, 429 . 431 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 432 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 433 May 2017, . 435 7.2. Informative References 437 [I-D.ietf-bess-evpn-irb-extended-mobility] 438 Malhotra, N., Sajassi, A., Pattekar, A., Lingala, A., 439 Rabadan, J., and J. Drake, "Extended Mobility Procedures 440 for EVPN-IRB", draft-ietf-bess-evpn-irb-extended- 441 mobility-03 (work in progress), May 2020. 443 [I-D.rbickhart-evpn-ip-mac-proxy-adv] 444 Bickhart, R., "Proxy IP->MAC Advertisement in EVPNs", 445 January 2020. 447 Authors' Addresses 449 Jorge Rabadan (editor) 450 Nokia 451 777 Middlefield Road 452 Mountain View, CA 94043 453 USA 455 Email: jorge.rabadan@nokia.com 457 Senthil Sathappan 458 Nokia 459 701 E. Middlefield Road 460 Mountain View, CA 94043 USA 462 Email: senthil.sathappan@nokia.com 464 Kiran Nagaraj 465 Nokia 466 701 E. Middlefield Road 467 Mountain View, CA 94043 USA 469 Email: kiran.nagaraj@nokia.com 471 Wen Lin 472 Juniper Networks 474 Email: wlin@juniper.net