idnits 2.17.1 draft-ietf-bess-evpn-proxy-arp-nd-14.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC7432, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 8, 2021) is 1051 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) No issues found here. 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 Workgroup J. Rabadan, Ed. 3 Internet-Draft S. Sathappan 4 Updates: 7432 (if approved) K. Nagaraj 5 Intended status: Standards Track G. Hankins 6 Expires: December 10, 2021 Nokia 7 T. King 8 DE-CIX 9 June 8, 2021 11 Operational Aspects of Proxy-ARP/ND in Ethernet Virtual Private Networks 12 draft-ietf-bess-evpn-proxy-arp-nd-14 14 Abstract 16 This document describes the Ethernet Virtual Private Networks (EVPN) 17 Proxy-ARP/ND function, augmented by the capability of the ARP/ND 18 Extended Community. From that perspective this document updates the 19 EVPN specification to provide more comprehensive documentation of the 20 operation of the Proxy-ARP/ND function. The EVPN Proxy-ARP/ND 21 function and the ARP/ND Extended Community help operators of Internet 22 Exchange Points, Data Centers, and other networks deal with IPv4 and 23 IPv6 address resolution issues associated with large Broadcast 24 Domains by reducing and even suppressing the flooding produced by 25 address resolution in the EVPN network. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on December 10, 2021. 44 Copyright Notice 46 Copyright (c) 2021 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.1. The Data Center Use-Case . . . . . . . . . . . . . . . . 5 64 2.2. The Internet Exchange Point Use-Case . . . . . . . . . . 5 65 3. Solution Description . . . . . . . . . . . . . . . . . . . . 6 66 3.1. Proxy-ARP/ND Sub-Functions . . . . . . . . . . . . . . . 8 67 3.2. Learning Sub-Function . . . . . . . . . . . . . . . . . . 9 68 3.2.1. Proxy-ND and the NA Flags . . . . . . . . . . . . . . 11 69 3.3. Reply Sub-Function . . . . . . . . . . . . . . . . . . . 12 70 3.4. Unicast-forward Sub-Function . . . . . . . . . . . . . . 13 71 3.5. Maintenance Sub-Function . . . . . . . . . . . . . . . . 14 72 3.6. Flood (to Remote PEs) Handling . . . . . . . . . . . . . 15 73 3.7. Duplicate IP Detection . . . . . . . . . . . . . . . . . 16 74 4. Solution Benefits . . . . . . . . . . . . . . . . . . . . . . 18 75 5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 19 76 5.1. All Dynamic Learning . . . . . . . . . . . . . . . . . . 19 77 5.2. Dynamic Learning with Proxy-ARP/ND . . . . . . . . . . . 20 78 5.3. Hybrid Dynamic Learning and Static Provisioning with 79 Proxy-ARP/ND . . . . . . . . . . . . . . . . . . . . . . 20 80 5.4. All Static Provisioning with Proxy-ARP/ND . . . . . . . . 20 81 5.5. Example of Deployment in Internet Exchange Points . . . . 21 82 5.6. Example of Deployment in Data Centers . . . . . . . . . . 22 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 85 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 86 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 88 10.1. Normative References . . . . . . . . . . . . . . . . . . 24 89 10.2. Informative References . . . . . . . . . . . . . . . . . 25 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 92 1. Terminology 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 96 "OPTIONAL" in this document are to be interpreted as described in 97 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all 98 capitals, as shown here. 100 ARP: Address Resolution Protocol. 102 AS-MAC: Anti-spoofing MAC. It is a especial MAC configured on all 103 the PEs attached to the same BD and used for the Duplicate IP 104 Detection procedures. 106 BD: Broadcast Domain. 108 BUM: Broadcast, Unknown unicast and Multicast layer-2 traffic. 110 CE: Customer Edge router. 112 DAD: Duplicate Address Detection, as per [RFC4861]. 114 DC: Data Center. 116 EVI: EVPN Instance. 118 EVPN: Ethernet Virtual Private Networks, as per [RFC7432]. 120 GARP: Gratuitous ARP message. 122 IP->MAC: an IP address associated to a MAC address. IP->MAC entries 123 are programmed in Proxy-ARP/ND tables and may be of three different 124 types: dynamic, static or EVPN-learned. 126 IXP: Internet eXchange Point. 128 IXP-LAN: the IXP's large Broadcast Domain to where Internet routers 129 are connected. 131 LAG: Link Aggregation Group. 133 MAC or IP DA: MAC or IP Destination Address. 135 MAC or IP SA: MAC or IP Source Address. 137 ND: Neighbor Discovery Protocol. 139 NS: Neighbor Solicitation message. 141 NA: Neighbor Advertisement. 143 NUD: Neighbor Unreachability Detection, as per [RFC4861]. 145 O Flag: Override Flag in NA messages, as per [RFC4861]. 147 PE: Provider Edge router. 149 R Flag: Router Flag in NA messages, as per [RFC4861]. 151 RT2: EVPN Route type 2 or EVPN MAC/IP Advertisement route, as per 152 [RFC7432]. 154 S Flag: Solicited Flag in NA messages, as per [RFC4861]. 156 SN-multicast address: Solicited-Node IPv6 multicast address used by 157 NS messages. 159 TLLA: Target Link Layer Address, as per [RFC4861]. 161 VPLS: Virtual Private LAN Service. 163 This document assumes familiarity with the terminology used in 164 [RFC7432]. 166 2. Introduction 168 As specified in [RFC7432] the IP Address field in the Ethernet 169 Virtual Private Networks (EVPN) MAC/IP Advertisement route may 170 optionally carry one of the IP addresses associated with the MAC 171 address. A PE may learn local IP->MAC pairs and advertise them in 172 EVPN MAC/IP Advertisement routes. Remote PEs importing those routes 173 in the same Broadcast Domain (BD) may add those IP->MAC pairs to 174 their Proxy-ARP/ND tables and reply to local ARP requests or Neighbor 175 Solicitations (or 'unicast-forward' those packets to the owner MAC), 176 reducing and even suppressing in some cases the flooding in the EVPN 177 network. 179 EVPN and its associated Proxy-ARP/ND function are extremely useful in 180 DCs or Internet Exchange Points (IXPs) with large broadcast domains, 181 where the amount of ARP/ND flooded traffic causes issues on connected 182 routers and CEs. [RFC6820] describes the address resolution problems 183 in large DC networks. 185 This document describes the Proxy-ARP/ND function in [RFC7432] 186 networks, augmented by the capability of the ARP/ND Extended 187 Community [I-D.ietf-bess-evpn-na-flags]. From that perspective this 188 document updates [RFC7432]. 190 Proxy-ARP/ND may be implemented to help IXPs, DCs and other operators 191 deal with the issues derived from address resolution in large 192 broadcast domains. 194 2.1. The Data Center Use-Case 196 As described in [RFC6820] the IPv4 and IPv6 address resolution can 197 create a lot of issues in large DCs. In particular, the issues 198 created by the IPv4 Address Resolution Protocol procedures may be 199 significant. 201 On one hand, ARP Requests use broadcast MAC addresses, therefore any 202 Tenant System in a large Broadcast Domain will see a large amount of 203 ARP traffic, which is not addressed to most of the receivers. 205 On the other hand, the flooding issue becomes even worse if some 206 Tenant Systems disappear from the broadcast domain, since some 207 implementations will persistently retry sending ARP Requests. As 208 [RFC6820] states, there are no clear requirements for retransmitting 209 ARP Requests in the absence of replies, hence an implementation may 210 choose to keep retrying endlessly even if there are no replies. 212 The amount of flooding that address resolution creates can be 213 mitigated by the use of EVPN and its Proxy-ARP/ND function. 215 2.2. The Internet Exchange Point Use-Case 217 The implementation described in this document is especially useful in 218 IXP networks. 220 A typical IXP provides access to a large layer-2 Broadcast Domain for 221 peering purposes (referred to as 'the peering network'), where 222 (hundreds of) Internet routers are connected. We refer to these 223 Internet routers as Customer Edge (CE) devices in this section. 224 Because of the requirement to connect all routers to a single layer-2 225 network the peering networks use IPv4 addresses in length ranges from 226 /21 to /24 (and even bigger for IPv6), which can create very large 227 broadcast domains. This peering network is transparent to the CEs, 228 and therefore, floods any ARP request or NS messages to all the CEs 229 in the network. Gratuitous ARP and NA messages are flooded to all 230 the CEs too. 232 In these IXP networks, most of the CEs are typically peering routers 233 and roughly all the BUM traffic is originated by the ARP and ND 234 address resolution procedures. This ARP/ND BUM traffic causes 235 significant data volumes that reach every single router in the 236 peering network. Since the ARP/ND messages are processed in "slow 237 path" software processors and they take high priority in the routers, 238 heavy loads of ARP/ND traffic can cause some routers to run out of 239 resources. CEs disappearing from the network may cause address 240 resolution explosions that can make a router with limited processing 241 power fail to keep BGP sessions running. 243 The issue might be better in IPv6 routers if MLD-snooping was 244 enabled, since ND uses SN-multicast address in NS messages; however, 245 ARP uses broadcast and has to be processed by all the routers in the 246 network. Some routers may also be configured to broadcast periodic 247 GARPs [RFC5227]. The amount of ARP/ND flooded traffic grows 248 exponentially with the number of IXP participants, therefore the 249 issue can only grow worse as new CEs are added. 251 In order to deal with this issue, IXPs have developed certain 252 solutions over the past years. While these solutions may mitigate 253 the issues of address resolution in large broadcasts domains, EVPN 254 provides new more efficient possibilities to IXPs. EVPN and its 255 Proxy-ARP/ND function may help solve the issue in a distributed and 256 scalable way, fully integrated with the PE network. 258 3. Solution Description 260 Figure 1 illustrates an example EVPN network where the Proxy-ARP/ND 261 function is enabled. 263 BD1 264 Proxy-ARP/ND 265 +------------+ 266 IP1/M1 +----------------------------+ |IP1->M1 EVPN| 267 GARP --->Proxy-ARP/ND | |IP2->M2 EVPN| 268 +---+ +--------+ RT2(IP1/M1) | |IP3->M3 sta | 269 |CE1+------| BD1 | ------> +------+---|IP4->M4 dyn | 270 +---+ +--------+ | +------------+ 271 PE1 | +--------+ Who has IP1? 272 | EVPN | | BD1 | <----- +---+ 273 | EVI1 | | | -----> |CE3| 274 IP2/M2 | | | | IP1->M1 +---+ 275 GARP --->Proxy-ARP/ND | +--------+ | IP3/M3 276 +---+ +--------+ RT2(IP2/M2) | | 277 |CE2+----| BD1 | ------> +--------------+ 278 +---+ +--------+ PE3| +---+ 279 PE2 | +----+CE4| 280 +----------------------------+ +---+ 281 <---IP4/M4 GARP 283 Figure 1: Proxy-ARP/ND network example 285 When the Proxy-ARP/ND function is enabled in a BD (Broadcast Domain) 286 of the EVPN PEs, each PE creates a Proxy table specific to that BD 287 that can contain three types of Proxy-ARP/ND entries: 289 a. Dynamic entries: learned by snooping CE's ARP and ND messages. 290 For instance, IP4->M4 in Figure 1. 292 b. Static entries: provisioned on the PE by the management system. 293 For instance, IP3->M3 in Figure 1. 295 c. EVPN-learned entries: learned from the IP/MAC information encoded 296 in the received RT2's coming from remote PEs. For instance, 297 IP1->M1 and IP2->M2 in Figure 1. 299 As a high level example, the operation of the EVPN Proxy-ARP/ND 300 function in the network of Figure 1 is described below. In this 301 example we assume IP1, IP2 and IP3 are IPv4 addresses: 303 1. Proxy-ARP/ND is enabled in BD1 of PE1, PE2 and PE3. 305 2. The PEs start adding dynamic, static and EVPN-learned entries to 306 their Proxy tables: 308 A. PE3 adds IP1->M1 and IP2->M2 based on the EVPN routes 309 received from PE1 and PE2. Those entries were previously 310 learned as dynamic entries in PE1 and PE2 respectively, and 311 advertised in BGP EVPN. 312 B. PE3 adds IP4->M4 as dynamic. This entry is learned by 313 snooping the corresponding ARP messages sent by CE4. 314 C. An operator also provisions the static entry IP3->M3. 316 3. When CE3 sends an ARP Request asking for the MAC address of IP1, 317 PE3 will: 319 A. Intercept the ARP Request and perform a Proxy-ARP lookup for 320 IP1. 321 B. If the lookup is successful (as in Figure 1), PE3 will send 322 an ARP Reply with IP1->M1. The ARP Request will not be 323 flooded to the EVPN network or any other local CEs. 324 C. If the lookup is not successful, PE3 will flood the ARP 325 Request in the EVPN network and the other local CEs. 327 In the same example, if we assume IP1, IP2, IP3 and IP4 are now IPv6 328 addresses and Proxy-ARP/ND is enabled in BD1: 330 1. PEs will start adding entries in a similar way as for IPv4, 331 however there are some differences: 333 A. IP1->M1 and IP2->M2 are learned as dynamic entries in PE1 and 334 PE2 respectively, by snooping NA messages and not by snooping 335 NS messages. In the IPv4 case, any ARP frame can be snooped 336 to learn the dynamic Proxy-ARP entry. When learning the 337 dynamic entries, the R and O Flags contained in the snooped 338 NA messages will be added to the Proxy-ND entries too. 340 B. PE1 and PE2 will advertise those entries in EVPN MAC/IP 341 Advertisement routes, including the corresponding learned R 342 and O Flags in the ARP/ND Extended Community. 344 C. PE3 also adds IP4->M4 as dynamic, after snooping an NA 345 message sent by CE4. 347 2. When CE3 sends an NS message asking for the MAC address of IP1, 348 PE3 behaves as in the IPv4 example, by intercepting the NS, doing 349 a lookup on the IP and replying with an NA if the lookup is 350 successful. If it is successful the NS is not flooded to the 351 EVPN PEs or any other local CEs. 353 3. If the lookup is not successful, PE3 will flood the NS to remote 354 EVPN PEs attached to the same BD and the other local CEs as in 355 the IPv4 case. 357 As PE3 learns more and more host entries in the Proxy-ARP/ND table, 358 the flooding of ARP Request messages among PEs is reduced and in some 359 cases it can even be suppressed. In a network where most of the 360 participant CEs are not moving between PEs and they advertise their 361 presence with GARPs or unsolicited-NA messages, the ARP/ND flooding 362 among PEs, as well as the unknown unicast flooding, can practically 363 be suppressed. In an EVPN-based IXP network, where all the entries 364 are Static, the ARP/ND flooding among PEs is in fact totally 365 suppressed. 367 In a network where CEs move between PEs, the Proxy-ARP/ND function 368 relies on the CE signaling its new location via GARP or unsolicited- 369 NA messages so that tables are immediately updated. If a CE moves 370 "silently", that is, without issuing any GARP or NA message upon 371 getting attached to the destination PE, the mechanisms described in 372 Section 3.5 make sure that the Proxy-ARP/ND tables are eventually 373 updated. 375 3.1. Proxy-ARP/ND Sub-Functions 377 The Proxy-ARP/ND function can be structured in six sub-functions or 378 procedures: 380 1. Learning sub-function 382 2. Reply sub-function 384 3. Unicast-forward sub-function 386 4. Maintenance sub-function 387 5. Flood handling sub-function 389 6. Duplicate IP detection sub-function 391 A Proxy-ARP/ND implementation MUST at least support the Learning, 392 Reply, Maintenance and Duplicate IP detection sub-functions. The 393 following sections describe each individual sub-function. 395 3.2. Learning Sub-Function 397 A Proxy-ARP/ND implementation in an EVPN BD MUST support dynamic and 398 EVPN-learned entries, and SHOULD support static entries. 400 Static entries are provisioned from the management plane. A static 401 entry is configured on the PE attached to the host using the IP 402 address in that entry. The provisioned static IP->MAC entry MUST be 403 advertised in EVPN with an ARP/ND Extended Community where the 404 Immutable ARP/ND Binding Flag (I) is set to 1, as per 405 [I-D.ietf-bess-evpn-na-flags]. When the I flag in the ARP/ND 406 Extended Community is 1, the advertising PE indicates that the IP 407 address must not be associated to a MAC, other than the one included 408 in the EVPN MAC/IP Advertisement route. The advertisement of I=1 in 409 the ARP/ND Extended Community is compatible with any value of the 410 Sticky bit (S) or Sequence Number in the [RFC7432] MAC Mobility 411 Extended Community. Note that the I bit in the ARP/ND Extended 412 Community refers to the immutable configured association between the 413 IP and the MAC address in the IP->MAC binding, whereas the S bit in 414 the MAC Mobility Extended Community refers to the fact that the 415 advertised MAC address is not subject to the [RFC7432] mobility 416 procedures. 418 An entry may associate a configured static IP to a list of potential 419 MACs, i.e. IP1->(MAC1,MAC2..MACN). Until a frame (including local 420 ARP/NA message) is received from the CE, the PE will not advertise 421 any IP1->MAC in EVPN. Upon receiving traffic from the CE, the PE 422 will check that the source MAC, E.g., MAC1, is included in the list 423 of allowed MACs. Only in that case, the PE will activate the 424 IP1->MAC1 and advertise only that IP1 and MAC1 in an EVPN MAC/IP 425 Advertisement route. 427 The PE MUST create EVPN-learned entries from the received valid EVPN 428 MAC/IP Advertisement routes containing a MAC and IP address. 430 Dynamic entries are learned in different ways depending on whether 431 the entry contains an IPv4 or IPv6 address: 433 a. Proxy-ARP dynamic entries: 435 The PE MUST snoop all ARP packets (that is, all frames with 436 Ethertype 0x0806) received from the CEs attached to the BD in 437 order to learn dynamic entries. ARP packets received from 438 remote EVPN PEs attached to the same BD are not snooped. The 439 Learning function will add the Sender MAC and Sender IP of the 440 snooped ARP packet to the Proxy-ARP table. Note that a MAC or 441 an IP address with value 0 SHOULD NOT be learned. 443 b. Proxy-ND dynamic entries: 445 The PE MUST snoop the NA messages (Ethertype 0x86dd, ICMPv6 446 type 136) received from the CEs attached to the BD and learn 447 dynamic entries from the Target Address and TLLA information. 448 NA messages received from remote EVPN PEs are not snooped. A 449 PE implementing Proxy-ND as in this document MUST NOT create 450 dynamic IP->MAC entries from NS messages, since they don't 451 contain the R Flag required by the Proxy-ND reply function. 452 See Section 3.2.1 for more information about the R Flag. 454 This document specifies an "anycast" capability that can be 455 configured for the proxy-ND function of the PE, and affects 456 how dynamic Proxy-ND entries are learned based on the O Flag 457 of the snooped NA messages. If the O Flag is zero in the 458 received NA message, the IP->MAC SHOULD only be learned in 459 case the IPv6 "anycast" capability is enabled in the BD. 460 Irrespective, an NA message with O Flag = 0 will be normally 461 forwarded by the PE based on a MAC DA lookup. 463 The following procedure associated to the Learning sub-function is 464 RECOMMENDED: 466 o When a new Proxy-ARP/ND EVPN or static active entry is learned (or 467 provisioned), the PE SHOULD send a GARP or unsolicited-NA message 468 to all the connected access CEs. The PE SHOULD send a GARP or 469 unsolicited-NA message for dynamic entries only if the ARP/NA 470 message that previously created the entry on the PE was NOT 471 flooded to all the local connected CEs before. This GARP/ 472 unsolicited-NA message makes sure the CE ARP/ND caches are updated 473 even if the ARP/NS/NA messages from CEs connected to remote PEs 474 are not flooded in the EVPN network. 476 Note that if a Static entry is provisioned with the same IP as an 477 existing EVPN-learned or Dynamic entry, the Static entry takes 478 precedence. 480 In case of a PE reboot, the static and EVPN entries will be re-added 481 as soon as the PE is back online and receives all the EVPN routes for 482 the BD. However, the dynamic entries will be gone. Due to that 483 reason, new NS and ARP Requests will be flooded by the PE to remote 484 PEs and dynamic entries gradually re-learned again. 486 3.2.1. Proxy-ND and the NA Flags 488 [RFC4861] describes the use of the R Flag in IPv6 address resolution: 490 o Nodes capable of routing IPv6 packets must reply to NS messages 491 with NA messages where the R Flag is set (R Flag=1). 493 o Hosts that are not able to route IPv6 packets must indicate that 494 inability by replying with NA messages that contain R Flag=0. 496 The use of the R Flag in NA messages has an impact on how hosts 497 select their default gateways when sending packets off-link, as per 498 [RFC4861]: 500 o Hosts build a Default Router List based on the received RAs and 501 NAs with R Flag=1. Each cache entry has an IsRouter flag, which 502 must be set for received RAs and is set based on the R flag in the 503 received NAs. A host can choose one or more Default Routers when 504 sending packets off-link. 506 o In those cases where the IsRouter flag changes from TRUE to FALSE 507 as a result of a NA update, the node must remove that router from 508 the Default Router List and update the Destination Cache entries 509 for all destinations using that neighbor as a router, as specified 510 in [RFC4861] section 7.3.3. This is needed to detect when a node 511 that is used as a router stops forwarding packets due to being 512 configured as a host. 514 The R Flag and O Flag for a Proxy-ARP/ND entry will be learned in the 515 following ways: 517 o The R Flag information SHOULD be added to the Static entries by 518 the management interface. The O Flag information MAY also be 519 added by the management interface. If the R and O Flags are not 520 configured, the default value is 1. 522 o Dynamic entries SHOULD learn the R Flag and MAY learn the O Flag 523 from the snooped NA messages used to learn the IP->MAC itself. 525 o EVPN-learned entries SHOULD learn the R Flag and MAY learn the O 526 Flag from the ARP/ND Extended Community 527 [I-D.ietf-bess-evpn-na-flags] received from EVPN along with the 528 RT2 used to learn the IP->MAC itself. If no ARP/ND Extended 529 Community is received, the PE will add a configured R Flag/O Flag 530 to the entry. These configured R and O Flags MAY be an 531 administrative choice with a default value of 1. The 532 configuration of this administrative choice provides a backwards 533 compatible option with EVPN PEs that follow [RFC7432] but do not 534 support this specification. 536 Note that, typically, IP->MAC entries with O=0 will not be learned, 537 and therefore the Proxy-ND function will reply to NS messages with NA 538 messages that contain O=1. However, this document allows the 539 configuration of the "anycast" capability in the BD where the Proxy- 540 ND function is enabled. If "anycast" is enabled in the BD and an NA 541 message with O=0 is received, the associated IP->MAC entry will be 542 learned with O=0. If this "anycast" capability is enabled in the BD, 543 Duplicate IP Detection must be disabled so that the PE is able to 544 learn the same IP mapped to different MACs in the same Proxy-ND 545 table. If the "anycast" capability is disabled, NA messages with O 546 Flag = 0 will not create a Proxy-ND entry (although they will be 547 forwarded normally), hence no EVPN advertisement with ARP/ND Extended 548 Community will be generated. 550 3.3. Reply Sub-Function 552 This sub-function will reply to address resolution requests/ 553 solicitations upon successful lookup in the Proxy-ARP/ND table for a 554 given IP address. The following considerations should be taken into 555 account, assuming that the ARP Request/NS lookup hits a Proxy-ARP/ND 556 entry IP1->MAC1: 558 a. When replying to ARP Request or NS messages: 560 - the PE SHOULD use the Proxy-ARP/ND entry MAC address MAC1 as 561 MAC SA. This is RECOMMENDED so that the resolved MAC can be 562 learned in the MAC FIB of potential layer-2 switches sitting 563 between the PE and the CE requesting the address resolution. 565 - for an ARP reply, the PE MUST use the Proxy-ARP entry IP1 and 566 MAC1 addresses in the Sender Protocol Address and Hardware 567 Address fields, respectively. 569 - for an NA message in response to an address resolution NS or 570 DAD NS, the PE MUST use IP1 as the IP SA and Target Address. 571 M1 MUST be used as the Target Link Local Address (TLLA). 573 b. A PE SHOULD NOT reply to a request/solicitation received on the 574 same attachment circuit over which the IP->MAC is learned. In 575 this case the requester and the requested IP are assumed to be 576 connected to the same layer-2 CE/access network linked to the 577 PE's attachment circuit, and therefore the requested IP owner 578 will receive the request directly. 580 c. A PE SHOULD reply to broadcast/multicast address resolution 581 messages, that is, ARP-Request, NS messages as well as DAD NS 582 messages. A PE SHOULD NOT reply to unicast address resolution 583 requests (for instance, NUD NS messages). 585 d. When replying to an NS, a PE SHOULD set the Flags in the NA 586 messages as follows: 588 - The R-bit is set as it was learned for the IP->MAC entry in 589 the NA messages that created the entry (see Section 3.2.1). 591 - The S Flag will be set/unset as per [RFC4861]. 593 - The O Flag will be set in all the NA messages issued by the 594 PE, except in the case the BD is configured with the "anycast" 595 capability and the entry was previously learned with O=0. If 596 "anycast" is enabled and there are more than one MAC for a 597 given IP in the Proxy-ND table, the PE will reply to NS 598 messages with as many NA responses as 'anycast' entries there 599 are in the Proxy-ND table. 601 e. A PE MUST NOT reply to ARP probes received from the CEs. An ARP 602 probe is an ARP request constructed with an all-zero sender IP 603 address that may be used by hosts for IPv4 Address Conflict 604 Detection [RFC5227]. 606 f. For Proxy-ARP, a PE MUST only reply to ARP-Request with the 607 format specified in [RFC0826]. For Proxy-ND, a PE MUST reply to 608 NS messages with the format and options specified in [RFC4861], 609 and MAY reply to NS messages containing other options. Received 610 NS messages with unknown options MAY be forwarded (as unicast 611 packets) to the owner of the requested IP (assuming the MAC is 612 known in the Proxy-ARP/ND table and BD). An administrative 613 choice to control the behavior for received NS messages with 614 unknown options ('unicast-forward', 'discard' or 'forward') MAY 615 be supported. The 'forward' option implies flooding the NS 616 message based on the MAC DA. The 'unicast-forward' option is 617 described in Section 3.4. If 'discard' is available, the 618 operator should assess if flooding NS unknown options may be a 619 security risk for the EVPN BD (and is so, enable 'discard'), or 620 if, on the contrary, not forwarding NS unknown options may 621 disrupt connectivity. 623 3.4. Unicast-forward Sub-Function 625 As discussed in Section 3.3, in some cases the operator may want to 626 'unicast-forward' certain ARP-Request and NS messages as opposed to 627 reply to them. The implementation of a 'unicast-forward' function is 628 RECOMMENDED. This option can be enabled with one of the following 629 parameters: 631 a. unicast-forward always 633 b. unicast-forward unknown-options 635 If 'unicast-forward always' is enabled, the PE will perform a Proxy- 636 ARP/ND table lookup and in case of a hit, the PE will forward the 637 packet to the owner of the MAC found in the Proxy-ARP/ND table. This 638 is irrespective of the options carried in the ARP/ND packet. This 639 option provides total transparency in the BD and yet reduces the 640 amount of flooding significantly. 642 If 'unicast-forward unknown-options' is enabled, upon a successful 643 Proxy-ARP/ND lookup, the PE will perform a 'unicast-forward' action 644 only if the ARP-Request or NS messages carry unknown options, as 645 explained in Section 3.3. The 'unicast-forward unknown-options' 646 configuration allows the support of new applications using ARP/ND in 647 the BD while still reducing the flooding. 649 Irrespective of the enabled option, if there is no successful Proxy- 650 ARP/ND lookup, the unknown ARP-Request/NS will be flooded in the 651 context of the BD, as per Section 3.6. 653 3.5. Maintenance Sub-Function 655 The Proxy-ARP/ND tables SHOULD follow a number of maintenance 656 procedures so that the dynamic IP->MAC entries are kept if the owner 657 is active and flushed (and the associated RT2 withdrawn) if the owner 658 is no longer in the network. The following procedures are 659 RECOMMENDED: 661 a. Age-time 663 A dynamic Proxy-ARP/ND entry MUST be flushed out of the table if 664 the IP->MAC has not been refreshed within a given age-time. The 665 entry is refreshed if an ARP or NA message is received for the 666 same IP->MAC entry. The age-time is an administrative option and 667 its value should be carefully chosen depending on the specific 668 use case: in IXP networks (where the CE routers are fairly 669 static) the age-time may normally be longer than in DC networks 670 (where mobility is required). 672 b. Send-refresh option 674 The PE MAY send periodic refresh messages (ARP/ND "probes") to 675 the owners of the dynamic Proxy-ARP/ND entries, so that the 676 entries can be refreshed before they age out. The owner of the 677 IP->MAC entry would reply to the ARP/ND probe and the 678 corresponding entry age-time reset. The periodic send-refresh 679 timer is an administrative option and is RECOMMENDED to be a 680 third of the age-time or a half of the age-time in scaled 681 networks. 683 An ARP refresh issued by the PE will be an ARP-Request message 684 with the Sender's IP = 0 sent from the PE's MAC SA. If the PE 685 has an IP address in the subnet, for instance on an Integrated 686 Routing and Bridging (IRB) interface, then it MAY use it as a 687 source for the ARP request (instead of Sender's IP = 0). An ND 688 refresh will be a NS message issued from the PE's MAC SA and a 689 Link Local Address associated to the PE's MAC. 691 The refresh request messages SHOULD be sent only for dynamic 692 entries and not for static or EVPN-learned entries. Even though 693 the refresh request messages are broadcast or multicast, the PE 694 SHOULD only send the message to the attachment circuit associated 695 to the MAC in the IP->MAC entry. 697 The age-time and send-refresh options are used in EVPN networks to 698 avoid unnecessary EVPN RT2 withdrawals: if refresh messages are sent 699 before the corresponding BD FIB and Proxy-ARP/ND age-time for a given 700 entry expires, inactive but existing hosts will reply, refreshing the 701 entry and therefore avoiding unnecessary EVPN MAC/IP Advertisement 702 withdrawals in EVPN. Both entries (MAC in the BD and IP->MAC in 703 Proxy-ARP/ND) are reset when the owner replies to the ARP/ND probe. 704 If there is no response to the ARP/ND probe, the MAC and IP->MAC 705 entries will be legitimately flushed and the RT2s withdrawn. 707 3.6. Flood (to Remote PEs) Handling 709 The Proxy-ARP/ND function implicitly helps reducing the flooding of 710 ARP Request and NS messages to remote PEs in an EVPN network. 711 However, in certain use cases, the flooding of ARP/NS/NA messages 712 (and even the unknown unicast flooding) to remote PEs can be 713 suppressed completely in an EVPN network. 715 For instance, in an IXP network, since all the participant CEs are 716 well known and will not move to a different PE, the IP->MAC entries 717 for the local CEs may be all provisioned on the PEs by a management 718 system. Assuming the entries for the CEs are all provisioned on the 719 local PE, a given Proxy-ARP/ND table will only contain static and 720 EVPN-learned entries. In this case, the operator may choose to 721 suppress the flooding of ARP/NS/NA from the local PE to the remote 722 PEs completely. 724 The flooding may also be suppressed completely in IXP networks with 725 dynamic Proxy-ARP/ND entries assuming that all the CEs are directly 726 connected to the PEs and they all advertise their presence with a 727 GARP/unsolicited-NA when they connect to the network. If any of 728 those two assumptions is not true and any of the PEs may not learn 729 all the local Proxy-ARP/ND entries, flooding of the ARP/NS/NA 730 messages from the local PE to the remote PEs SHOULD NOT be 731 suppressed, or the address resolution process for some CEs will not 732 be completed. 734 In networks where fast mobility is expected (DC use case), it is NOT 735 RECOMMENDED to suppress the flooding of unknown ARP-Requests/NS or 736 GARPs/unsolicited-NAs. Unknown ARP-Requests/NS refer to those ARP- 737 Request/NS messages for which the Proxy-ARP/ND lookups for the 738 requested IPs do not succeed. 740 In order to give the operator the choice to suppress/allow the 741 flooding to remote PEs, a PE MAY support administrative options to 742 individually suppress/allow the flooding of: 744 o Unknown ARP-Request and NS messages. 746 o GARP and unsolicited-NA messages. 748 The operator will use these options based on the expected behavior on 749 the CEs. 751 3.7. Duplicate IP Detection 753 The Proxy-ARP/ND function MUST support duplicate IP detection as per 754 this section so that ARP/ND-spoofing attacks or duplicate IPs due to 755 human errors can be detected. For IPv6 addresses, CEs will continue 756 to carry out the DAD procedures as per [RFC4862]. The solution 757 described in this section is an additional security mechanism carried 758 out by the PEs that guarantees IPv6 address moves between PEs are 759 legit and not the result of an attack. [RFC6957] describes a 760 solution for IPv6 Duplicate Address Detection Proxy, however, it is 761 defined for point-to-multipoint topologies with a split-horizon 762 forwarding, where the 'CEs' have no direct communication within the 763 same L2 link and therefore it is not suitable for EVPN Broadcast 764 Domains. In addition, the solution described in this section 765 includes the use of the AS-MAC for additional security. 767 ARP/ND spoofing is a technique whereby an attacker sends "fake" ARP/ 768 ND messages onto a broadcast domain. Generally the aim is to 769 associate the attacker's MAC address with the IP address of another 770 host causing any traffic meant for that IP address to be sent to the 771 attacker instead. 773 The distributed nature of EVPN and Proxy-ARP/ND allows the easy 774 detection of duplicated IPs in the network, in a similar way to the 775 MAC duplication detection function supported by [RFC7432] for MAC 776 addresses. 778 Duplicate IP detection monitors "IP-moves" in the Proxy-ARP/ND table 779 in the following way: 781 a. When an existing active IP1->MAC1 entry is modified, a PE starts 782 an M-second timer (default value of M=180), and if it detects N 783 IP moves before the timer expires (default value of N=5), it 784 concludes that a duplicate IP situation has occurred. An IP move 785 is considered when, for instance, IP1->MAC1 is replaced by 786 IP1->MAC2 in the Proxy-ARP/ND table. Static IP->MAC entries, 787 that is, locally provisioned or EVPN-learned entries with I=1 in 788 the ARP/ND Extended Community, are not subject to this procedure. 789 Static entries MUST NOT be overridden by dynamic Proxy-ARP/ND 790 entries. 792 b. In order to detect the duplicate IP faster, the PE SHOULD send a 793 Confirm message to the former owner of the IP. A Confirm message 794 is a unicast ARP-Request/NS message sent by the PE to the MAC 795 addresses that previously owned the IP, when the MAC changes in 796 the Proxy-ARP/ND table. The Confirm message uses a sender's IP 797 0.0.0.0 in case of ARP (if the PE has an IP address in the subnet 798 then it MAY use it) and an IPv6 Link Local Address in case of NS. 799 If the PE does not receive an answer within a given time, the new 800 entry will be confirmed and activated. The default RECOMMENDED 801 time to receive the confirmation is 30 seconds. In case of 802 spoofing, for instance, if IP1->MAC1 moves to IP1->MAC2, the PE 803 may send a unicast ARP-Request/NS message for IP1 with MAC DA= 804 MAC1 and MAC SA= PE's MAC. This will force the legitimate owner 805 to respond if the move to MAC2 was spoofed, and make the PE issue 806 another Confirm message, this time to MAC DA= MAC2. If both, 807 legitimate owner and spoofer keep replying to the Confirm 808 message, the PE will detect the duplicate IP within the M-second 809 timer: 811 - If the IP1->MAC1 pair was previously owned by the spoofer and 812 the new IP1->MAC2 was from a valid CE, then the issued Confirm 813 message would trigger a response from the spoofer. 815 - If it were the other way around, that is, IP1->MAC1 was 816 previously owned by a valid CE, the Confirm message would 817 trigger a response from the CE. 819 Either way, if this process continues, then duplicate 820 detection will kick in. 822 c. Upon detecting a duplicate IP situation: 824 1. The entry in duplicate detected state cannot be updated with 825 new dynamic or EVPN-learned entries for the same IP. The 826 operator MAY override the entry, though, with a static 827 IP->MAC. 829 2. The PE SHOULD alert the operator and stop responding to ARP/ 830 NS for the duplicate IP until a corrective action is taken. 832 3. Optionally the PE MAY associate an "anti-spoofing-mac" (AS- 833 MAC) to the duplicate IP in the Proxy-ARP/ND table. The PE 834 will send a GARP/unsolicited-NA message with IP1->AS-MAC to 835 the local CEs as well as an RT2 (with IP1->AS-MAC) to the 836 remote PEs. This will update the ARP/ND caches on all the 837 CEs in the BD, and hence all the CEs in the BD will use the 838 AS-MAC as MAC DA when sending traffic to IP1. This procedure 839 prevents the spoofer from attracting any traffic for IP1. 840 Since the AS-MAC is a managed MAC address known by all the 841 PEs in the BD, all the PEs MAY apply filters to drop and/or 842 log any frame with MAC DA= AS-MAC. The advertisement of the 843 AS-MAC as a "black-hole MAC" (by using an indication in the 844 RT2) that can be used directly in the BD to drop frames is 845 for further study. 847 d. The duplicate IP situation will be cleared when a corrective 848 action is taken by the operator, or alternatively after a HOLD- 849 DOWN timer (default value of 540 seconds). 851 The values of M, N and HOLD-DOWN timer SHOULD be a configurable 852 administrative option to allow for the required flexibility in 853 different scenarios. 855 For Proxy-ND, the Duplicate IP Detection described in this section 856 SHOULD only monitor IP moves for IP->MACs learned from NA messages 857 with O Flag=1. NA messages with O Flag=0 would not override the ND 858 cache entries for an existing IP, and therefore the procedure in this 859 section would not detect duplicate IPs. This Duplicate IP Detection 860 for IPv6 SHOULD be disabled when the IPv6 "anycast" capability is 861 activated in a given BD. 863 4. Solution Benefits 865 The solution described in this document provides the following 866 benefits: 868 a. The solution may suppress completely the flooding of the ARP/ND 869 messages in the EVPN network, assuming that all the CE IP->MAC 870 addresses local to the PEs are known or provisioned on the PEs 871 from a management system. Note that in this case, the unknown 872 unicast flooded traffic can also be suppressed, since all the 873 expected unicast traffic will be destined to known MAC addresses 874 in the PE BDs. 876 b. The solution reduces significantly the flooding of the ARP/ND 877 messages in the EVPN network, assuming that some or all the CE 878 IP->MAC addresses are learned on the data plane by snooping ARP/ 879 ND messages issued by the CEs. 881 c. The solution provides a way to refresh periodically the CE 882 IP->MAC entries learned through the data plane, so that the 883 IP->MAC entries are not withdrawn by EVPN when they age out 884 unless the CE is not active anymore. This option helps reducing 885 the EVPN control plane overhead in a network with active CEs that 886 do not send packets frequently. 888 d. Provides a mechanism to detect duplicate IP addresses and avoid 889 ARP/ND-spoof attacks or the effects of duplicate addresses due to 890 human errors. 892 5. Deployment Scenarios 894 Four deployment scenarios with different levels of ARP/ND control are 895 available to operators using this solution, depending on their 896 requirements to manage ARP/ND: all dynamic learning, all dynamic 897 learning with Proxy-ARP/ND, hybrid dynamic learning and static 898 provisioning with Proxy-ARP/ND, and all static provisioning with 899 Proxy-ARP/ND. 901 5.1. All Dynamic Learning 903 In this scenario for minimum security and mitigation, EVPN is 904 deployed in the BD with the Proxy-ARP/ND function shutdown. PEs do 905 not intercept ARP/ND requests and flood all requests issued by the 906 CEs, as a conventional layer-2 network among those CEs would do. 907 While no ARP/ND mitigation is used in this scenario, the operator can 908 still take advantage of EVPN features such as control plane learning 909 and all-active multihoming in the peering network. 911 Although this option does not require any of the procedures described 912 in this document, it is added as baseline/default option for 913 completeness. This option is equivalent to VPLS as far as ARP/ND is 914 concerned. The options described in Section 5.2, Section 5.3 and 915 Section 5.4 are only possible in EVPN networks in combination with 916 their Proxy-ARP/ND capabilities. 918 5.2. Dynamic Learning with Proxy-ARP/ND 920 This scenario minimizes flooding while enabling dynamic learning of 921 IP->MAC entries. The Proxy-ARP/ND function is enabled in the BDs of 922 the EVPN PEs, so that the PEs snoop ARP/ND messages issued by the CEs 923 and respond to CE ARP-requests/NS messages. 925 PEs will flood requests if the entry is not in their Proxy table. 926 Any unknown source IP->MAC entries will be learned and advertised in 927 EVPN, and traffic to unknown entries is discarded at the ingress PE. 929 This scenario makes use of the Learning, Reply and Maintenance sub- 930 functions, with an optional use of the Unicast-forward and Duplicate 931 IP detection sub-functions. The Flood handling sub-function uses 932 default flooding for unknown ARP-Request/NS messages. 934 5.3. Hybrid Dynamic Learning and Static Provisioning with Proxy-ARP/ND 936 Some IXPs and other operators want to protect particular hosts on the 937 BD while allowing dynamic learning of CE addresses. For example, an 938 operator may want to configure static IP->MAC entries for management 939 and infrastructure hosts that provide critical services. In this 940 scenario, static entries are provisioned from the management plane 941 for protected IP->MAC addresses, and dynamic learning with Proxy-ARP/ 942 ND is enabled as described in Section 5.2 on the BD. 944 This scenario makes use of the same sub-functions as in Section 5.2, 945 but adding static entries added by the Learning sub-function. 947 5.4. All Static Provisioning with Proxy-ARP/ND 949 For a solution that maximizes security and eliminates flooding and 950 unknown unicast in the peering network, all IP->MAC entries are 951 provisioned from the management plane. The Proxy-ARP/ND function is 952 enabled in the BDs of the EVPN PEs, so that the PEs intercept and 953 respond to CE requests. Dynamic learning and ARP/ND snooping is 954 disabled so that ARP-Requests and NS to unknown IPs are discarded at 955 the ingress PE. This scenario provides an operator the most control 956 over IP->MAC entries and allows an operator to manage all entries 957 from a management system. 959 In this scenario, the Learning sub-function is limited to static 960 entries, the Maintenance sub-function will not require any procedures 961 due to the static entries, and the Flood handling sub-function will 962 completely suppress Unknown ARP-Requests/NS messages as well as GARP 963 and unsolicited-NA messages. 965 5.5. Example of Deployment in Internet Exchange Points 967 Nowadays, almost all IXPs install some security rules in order to 968 protect the peering network (BD). These rules are often called port 969 security. Port security summarizes different operational steps that 970 limit the access to the IXP-LAN and the customer router, and controls 971 the kind of traffic that the routers are allowed to exchange (e.g., 972 Ethernet, IPv4, IPv6). Due to this, the deployment scenario as 973 described in Section 5.4 "All Static Provisioning with Proxy-ARP/ND" 974 is the predominant scenario for IXPs. 976 In addition to the "All Static Provisioning" behavior, in IXP 977 networks it is recommended to configure the Reply Sub-Function to 978 'discard' ARP-Requests/NS messages with unrecognized options. 980 At IXPs, customers usually follow a certain operational life-cycle. 981 For each step of the operational life-cycle specific operational 982 procedures are executed. 984 The following describes the operational procedures that are needed to 985 guarantee port security throughout the life-cycle of a customer with 986 focus on EVPN features: 988 1. A new customer is connected the first time to the IXP: 990 Before the connection between the customer router and the IXP-LAN 991 is activated, the MAC of the router is allow-listed on the IXP's 992 switch port. All other MAC addresses are blocked. Pre-defined 993 IPv4 and IPv6 addresses of the IXP peering network space are 994 configured at the customer router. The IP->MAC static entries 995 (IPv4 and IPv6) are configured in the management system of the 996 IXP for the customer's port in order to support Proxy-ARP/ND. 998 In case a customer uses multiple ports aggregated to a single 999 logical port (LAG) some vendors randomly select the MAC address 1000 of the LAG from the different MAC addresses assigned to the 1001 ports. In this case the static entry will be used associated to 1002 a list of allowed MACs. 1004 2. Replacement of customer router: 1006 If a customer router is about to be replaced, the new MAC 1007 address(es) must be installed in the management system besides 1008 the MAC address(es) of the currently connected router. This 1009 allows the customer to replace the router without any active 1010 involvement of the IXP operator. For this, static entries are 1011 also used. After the replacement takes place, the MAC 1012 address(es) of the replaced router can be removed. 1014 3. Decommissioning a customer router 1016 If a customer router is decommissioned, the router is 1017 disconnected from the IXP PE. Right after that, the MAC 1018 address(es) of the router and IP->MAC bindings can be removed 1019 from the management system. 1021 5.6. Example of Deployment in Data Centers 1023 DCs normally have different requirements than IXPs in terms of Proxy- 1024 ARP/ND. Some differences are listed below: 1026 a. The required mobility in virtualized DCs makes the "Dynamic 1027 Learning" or "Hybrid Dynamic and Static Provisioning" models more 1028 appropriate than the "All Static Provisioning" model. 1030 b. IPv6 'anycast' may be required in DCs, while it is typically not 1031 a requirement in IXP networks. Therefore if the DC needs IPv6 1032 anycast addresses, the "anycast" capability will be explicitly 1033 enabled in the Proxy-ND function, hence the Proxy-ND sub- 1034 functions modified accordingly. For instance, if IPv6 'anycast' 1035 is enabled in the Proxy-ND function, the Duplicate IP Detection 1036 procedure in Section 3.7 must be disabled. 1038 c. DCs may require special options on ARP/ND as opposed to the 1039 address resolution function, which is the only one typically 1040 required in IXPs. Based on that, the Reply Sub-function may be 1041 modified to forward or discard unknown options. 1043 6. Security Considerations 1045 The security considerations of [RFC7432] and 1046 [I-D.ietf-bess-evpn-na-flags] apply to this document too. Note that 1047 EVPN does not inherently provide cryptographic protection (including 1048 confidentiality protection). 1050 The procedures in this document reduce the amount of ARP/ND message 1051 flooding, which in itself provides a protection to "slow path" 1052 software processors of routers and Tenant Systems in large BDs. The 1053 ARP/ND requests that are replied by the Proxy-ARP/ND function (hence 1054 not flooded) are normally targeted to existing hosts in the BD. ARP/ 1055 ND requests targeted to absent hosts are still normally flooded; 1056 however, the suppression of Unknown ARP-Requests and NS messages 1057 described in Section 3.6 can provide an additional level of security 1058 against ARP-Requests/NS messages issued to non-existing hosts. 1060 While the unicast-forward and/or flood suppression sub-functions 1061 provide an added security mechanism for the BD, they can also 1062 increase the risk of blocking the service for a CE if the EVPN PEs 1063 cannot provide the ARP/ND resolution that the CE needs. 1065 The solution also provides protection against Denial Of Service 1066 attacks that use ARP/ND-spoofing as a first step. The Duplicate IP 1067 Detection and the use of an AS-MAC as explained in Section 3.7 1068 protects the BD against ARP/ND spoofing. 1070 The Proxy-ARP/ND function specified in this document does not allow 1071 the learning of an IP address mapped to multiple MAC addresses in the 1072 same table, unless the "anycast" capability is enabled (and only in 1073 case of Proxy-ND). When "anycast" is enabled in the Proxy-ND 1074 function, the number of allowed entries for the same IP address MUST 1075 be limited by the operator to prevent DoS attacks that attempt to 1076 fill the Proxy-ND table with a significant number of entries for the 1077 same IP. 1079 The document provides some examples and guidelines that can be used 1080 by IXPs in their EVPN BDs. When EVPN and its associated Proxy-ARP/ND 1081 function are used in IXP networks, they provide ARP/ND security and 1082 mitigation. IXPs must still employ additional security mechanisms 1083 that protect the peering network as per the established BCPs such as 1084 the ones described in [Euro-IX-BCP]. For example, IXPs should 1085 disable all unneeded control protocols, and block unwanted protocols 1086 from CEs so that only IPv4, ARP and IPv6 Ethertypes are permitted on 1087 the peering network. In addition, port security features and ACLs 1088 can provide an additional level of security. 1090 Finally, it is worth noting that the Proxy-ARP/ND solution in this 1091 document will not work if there is a mechanism securing ARP/ND 1092 exchanges among CEs, because the PE is not able to secure the 1093 "proxied" ND messages. 1095 7. IANA Considerations 1097 No IANA considerations. 1099 8. Acknowledgments 1101 The authors want to thank Ranganathan Boovaraghavan, Sriram 1102 Venkateswaran, Manish Krishnan, Seshagiri Venugopal, Tony Przygienda, 1103 Robert Raszuk and Iftekhar Hussain for their review and 1104 contributions. Thank you to Oliver Knapp as well, for his detailed 1105 review. 1107 9. Contributors 1109 In addition to the authors listed on the front page, the following 1110 co-authors have also contributed to this document: 1112 Wim Henderickx 1113 Nokia 1115 Daniel Melzer 1116 DE-CIX Management GmbH 1118 Erik Nordmark 1119 Zededa 1121 10. References 1123 10.1. Normative References 1125 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 1126 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 1127 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 1128 2015, . 1130 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1131 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1132 DOI 10.17487/RFC4861, September 2007, 1133 . 1135 [RFC0826] Plummer, D., "An Ethernet Address Resolution Protocol: Or 1136 Converting Network Protocol Addresses to 48.bit Ethernet 1137 Address for Transmission on Ethernet Hardware", STD 37, 1138 RFC 826, DOI 10.17487/RFC0826, November 1982, 1139 . 1141 [RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227, 1142 DOI 10.17487/RFC5227, July 2008, 1143 . 1145 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1146 Requirement Levels", BCP 14, RFC 2119, 1147 DOI 10.17487/RFC2119, March 1997, 1148 . 1150 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1151 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1152 May 2017, . 1154 [I-D.ietf-bess-evpn-na-flags] 1155 Rabadan, J., Sathappan, S., Nagaraj, K., and W. Lin, 1156 "Propagation of ARP/ND Flags in EVPN", draft-ietf-bess- 1157 evpn-na-flags-09 (work in progress), December 2020. 1159 10.2. Informative References 1161 [Euro-IX-BCP] 1162 Euro-IX, "European Internet Exchange Association Best 1163 Practises - 1164 https://www.euro-ix.net/en/forixps/set-ixp/ixp-bcops/". 1166 [RFC6820] Narten, T., Karir, M., and I. Foo, "Address Resolution 1167 Problems in Large Data Center Networks", RFC 6820, 1168 DOI 10.17487/RFC6820, January 2013, 1169 . 1171 [RFC6957] Costa, F., Combes, J-M., Ed., Pougnard, X., and H. Li, 1172 "Duplicate Address Detection Proxy", RFC 6957, 1173 DOI 10.17487/RFC6957, June 2013, 1174 . 1176 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1177 Address Autoconfiguration", RFC 4862, 1178 DOI 10.17487/RFC4862, September 2007, 1179 . 1181 Authors' Addresses 1183 Jorge Rabadan (editor) 1184 Nokia 1185 777 Middlefield Road 1186 Mountain View, CA 94043 1187 USA 1189 Email: jorge.rabadan@nokia.com 1191 Senthil Sathappan 1192 Nokia 1193 701 E. Middlefield Road 1194 Mountain View, CA 94043 USA 1196 Email: senthil.sathappan@nokia.com 1197 Kiran Nagaraj 1198 Nokia 1199 701 E. Middlefield Road 1200 Mountain View, CA 94043 USA 1202 Email: kiran.nagaraj@nokia.com 1204 Greg Hankins 1205 Nokia 1207 Email: greg.hankins@nokia.com 1209 Thomas King 1210 DE-CIX Management GmbH 1212 Email: thomas.king@de-cix.net