idnits 2.17.1 draft-ietf-bess-evpn-proxy-arp-nd-13.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 (April 8, 2021) is 1114 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: October 10, 2021 Nokia 7 T. King 8 DE-CIX 9 April 8, 2021 11 Operational Aspects of Proxy-ARP/ND in Ethernet Virtual Private Networks 12 draft-ietf-bess-evpn-proxy-arp-nd-13 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 October 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. Flooding (to Remote PEs) Reduction/Suppression . . . . . 15 73 3.7. Duplicate IP Detection . . . . . . . . . . . . . . . . . 16 74 4. Solution Benefits . . . . . . . . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . . . . . . 24 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. One example is the ARP-Sponge daemon 253 [ARP-Sponge], which can reduce significantly the amount of ARP 254 messages sent to an absent router. While these solutions may 255 mitigate the issues of address resolution in large broadcasts 256 domains, EVPN provides new more efficient possibilities to IXPs. 257 EVPN and its Proxy-ARP/ND function may help solve the issue in a 258 distributed and scalable way, fully integrated with the PE network. 260 3. Solution Description 262 Figure 1 illustrates an example EVPN network where the Proxy-ARP/ND 263 function is enabled. 265 BD1 266 Proxy-ARP/ND 267 +------------+ 268 IP1/M1 +----------------------------+ |IP1->M1 EVPN| 269 GARP --->Proxy-ARP/ND | |IP2->M2 EVPN| 270 +---+ +--------+ RT2(IP1/M1) | |IP3->M3 sta | 271 |CE1+------| BD1 | ------> +------+---|IP4->M4 dyn | 272 +---+ +--------+ | +------------+ 273 PE1 | +--------+ Who has IP1? 274 | EVPN | | BD1 | <----- +---+ 275 | EVI1 | | | -----> |CE3| 276 IP2/M2 | | | | IP1->M1 +---+ 277 GARP --->Proxy-ARP/ND | +--------+ | IP3/M3 278 +---+ +--------+ RT2(IP2/M2) | | 279 |CE2+----| BD1 | ------> +--------------+ 280 +---+ +--------+ PE3| +---+ 281 PE2 | +----+CE4| 282 +----------------------------+ +---+ 283 <---IP4/M4 GARP 285 Figure 1: Proxy-ARP/ND network example 287 When the Proxy-ARP/ND function is enabled in a BD (Broadcast Domain) 288 of the EVPN PEs, each PE creates a Proxy table specific to that BD 289 that can contain three types of Proxy-ARP/ND entries: 291 a. Dynamic entries: learned by snooping CE's ARP and ND messages. 292 For instance, IP4->M4 in Figure 1. 294 b. Static entries: provisioned on the PE by the management system. 295 For instance, IP3->M3 in Figure 1. 297 c. EVPN-learned entries: learned from the IP/MAC information encoded 298 in the received RT2's coming from remote PEs. For instance, 299 IP1->M1 and IP2->M2 in Figure 1. 301 As a high level example, the operation of the EVPN Proxy-ARP/ND 302 function in the network of Figure 1 is described below. In this 303 example we assume IP1, IP2 and IP3 are IPv4 addresses: 305 1. Proxy-ARP/ND is enabled in BD1 of PE1, PE2 and PE3. 307 2. The PEs start adding dynamic, static and EVPN-learned entries to 308 their Proxy tables: 310 A. PE3 adds IP1->M1 and IP2->M2 based on the EVPN routes 311 received from PE1 and PE2. Those entries were previously 312 learned as dynamic entries in PE1 and PE2 respectively, and 313 advertised in BGP EVPN. 314 B. PE3 adds IP4->M4 as dynamic. This entry is learned by 315 snooping the corresponding ARP messages sent by CE4. 316 C. An operator also provisions the static entry IP3->M3. 318 3. When CE3 sends an ARP Request asking for the MAC address of IP1, 319 PE3 will: 321 A. Intercept the ARP Request and perform a Proxy-ARP lookup for 322 IP1. 323 B. If the lookup is successful (as in Figure 1), PE3 will send 324 an ARP Reply with IP1->M1. The ARP Request will not be 325 flooded to the EVPN network or any other local CEs. 326 C. If the lookup is not successful, PE3 will flood the ARP 327 Request in the EVPN network and the other local CEs. 329 In the same example, if we assume IP1, IP2, IP3 and IP4 are now IPv6 330 addresses and Proxy-ARP/ND is enabled in BD1: 332 1. PEs will start adding entries in a similar way as for IPv4, 333 however there are some differences: 335 A. IP1->M1 and IP2->M2 are learned as dynamic entries in PE1 and 336 PE2 respectively, by snooping NA messages and not by snooping 337 NS messages. In the IPv4 case, any ARP frame can be snooped 338 to learn the dynamic Proxy-ARP entry. When learning the 339 dynamic entries, the R and O Flags contained in the snooped 340 NA messages will be added to the Proxy-ND entries too. 342 B. PE1 and PE2 will advertise those entries in EVPN MAC/IP 343 Advertisement routes, including the corresponding learned R 344 and O Flags in the ARP/ND Extended Community. 346 C. PE3 also adds IP4->M4 as dynamic, after snooping an NA 347 message sent by CE4. 349 2. When CE3 sends an NS message asking for the MAC address of IP1, 350 PE3 behaves as in the IPv4 example, by intercepting the NS, doing 351 a lookup on the IP and replying with an NA if the lookup is 352 successful. If it is successful the NS is not flooded to the 353 EVPN PEs or any other local CEs. 355 3. If the lookup is not successful, PE3 will flood the NS to remote 356 EVPN PEs attached to the same BD and the other local CEs as in 357 the IPv4 case. 359 As PE3 learns more and more host entries in the Proxy-ARP/ND table, 360 the flooding of ARP Request messages among PEs is reduced and in some 361 cases it can even be suppressed. In a network where most of the 362 participant CEs are not moving between PEs and they advertise their 363 presence with GARPs or unsolicited NA messages, the ARP/ND flooding 364 among PEs, as well as the unknown unicast flooding, can practically 365 be suppressed. In an EVPN-based IXP network, where all the entries 366 are Static, the ARP/ND flooding among PEs is in fact totally 367 suppressed. 369 3.1. Proxy-ARP/ND Sub-Functions 371 The Proxy-ARP/ND function can be structured in six sub-functions or 372 procedures: 374 1. Learning sub-function 376 2. Reply sub-function 378 3. Unicast-forward sub-function 380 4. Maintenance sub-function 382 5. Flooding reduction/suppression sub-function 384 6. Duplicate IP detection sub-function 385 A Proxy-ARP/ND implementation MUST at least support the Learning, 386 Reply and Maintenance sub-functions. The following sections describe 387 each individual sub-function. 389 3.2. Learning Sub-Function 391 A Proxy-ARP/ND implementation in an EVPN BD MUST support dynamic and 392 EVPN-learned entries, and SHOULD support static entries. 394 Static entries are provisioned from the management plane. A static 395 entry is configured on the PE attached to the host using the IP 396 address in that entry. The provisioned static IP->MAC entry MUST be 397 advertised in EVPN with an ARP/ND Extended Community where the 398 Immutable ARP/ND Binding Flag (I) is set to 1, as per 399 [I-D.ietf-bess-evpn-na-flags]. When the I flag in the ARP/ND 400 Extended Community is 1, the advertising PE indicates that the IP 401 address must not be associated to a MAC, other than the one included 402 in the EVPN MAC/IP Advertisement route. The advertisement of I=1 in 403 the ARP/ND Extended Community is compatible with any value of the 404 Sticky bit (S) or Sequence Number in the [RFC7432] MAC Mobility 405 Extended Community. Note that the I bit in the ARP/ND Extended 406 Community refers to the immutable configured association between the 407 IP and the MAC address in the IP->MAC binding, whereas the S bit in 408 the MAC Mobility Extended Community refers to the fact that the 409 advertised MAC address is not subject to the [RFC7432] mobility 410 procedures. 412 An entry may associate a configured static IP to a list of potential 413 MACs, i.e. IP1->(MAC1,MAC2..MACN). Until a frame (including local 414 ARP/NA message) is received from the CE, the PE will not advertise 415 any IP1->MAC in EVPN. Upon receiving traffic from the CE, the PE 416 will check that the source MAC, E.g., MAC1, is included in the list 417 of allowed MACs. Only in that case, the PE will activate the 418 IP1->MAC1 and advertise only that IP1 and MAC1 in an EVPN MAC/IP 419 Advertisement route. 421 The PE MUST create EVPN-learned entries from the received valid EVPN 422 MAC/IP Advertisement routes containing a MAC and IP address. 424 Dynamic entries are learned in different ways depending on whether 425 the entry contains an IPv4 or IPv6 address: 427 a. Proxy-ARP dynamic entries: 429 The PE MUST snoop all ARP packets (that is, all frames with 430 Ethertype 0x0806) received from the CEs attached to the BD in 431 order to learn dynamic entries. ARP packets received from 432 remote EVPN PEs attached to the same BD are not snooped. The 433 Learning function will add the Sender MAC and Sender IP of the 434 snooped ARP packet to the Proxy-ARP table. Note that MAC and 435 IPs with value 0 SHOULD NOT be learned. 437 b. Proxy-ND dynamic entries: 439 The PE MUST snoop the NA messages (Ethertype 0x86dd, ICMPv6 440 type 136) received from the CEs attached to the BD and learn 441 dynamic entries from the Target Address and TLLA information. 442 NA messages received from remote EVPN PEs are not snooped. A 443 PE implementing Proxy-ND as in this document MUST NOT create 444 dynamic IP->MAC entries from NS messages, since they don't 445 contain the R Flag required by the Proxy-ND reply function. 446 See Section 3.2.1 for more information about the R Flag. 448 This document specifies an "anycast" capability that can be 449 configured for the proxy-ND function of the PE, and affects 450 how dynamic Proxy-ND entries are learned based on the O Flag 451 of the snooped NA messages. If the O Flag is zero in the 452 received NA message, the IP->MAC SHOULD only be learned in 453 case the IPv6 "anycast" capability is enabled in the BD. 454 Irrespective, an NA message with O Flag = 0 will be normally 455 forwarded by the PE based on a MAC DA lookup. 457 The following procedure associated to the Learning sub-function is 458 RECOMMENDED: 460 o When a new Proxy-ARP/ND EVPN or static active entry is learned (or 461 provisioned), the PE SHOULD send an unsolicited GARP or NA message 462 to all the connected access CEs. The PE SHOULD send an 463 unsolicited GARP/NA message for dynamic entries only if the ARP/NA 464 message that previously created the entry on the PE was NOT 465 flooded to all the local connected CEs before. This unsolicited 466 GARP/NA message makes sure the CE ARP/ND caches are updated even 467 if the ARP/NS/NA messages from CEs connected to remote PEs are not 468 flooded in the EVPN network. 470 Note that if a Static entry is provisioned with the same IP as an 471 existing EVPN-learned or Dynamic entry, the Static entry takes 472 precedence. 474 In case of a PE reboot, the static and EVPN entries will be re-added 475 as soon as the PE is back online and receives all the EVPN routes for 476 the BD. However, the dynamic entries will be gone. Due to that 477 reason, new NS and ARP Requests will be flooded by the PE to remote 478 PEs and dynamic entries gradually re-learned again. 480 3.2.1. Proxy-ND and the NA Flags 482 [RFC4861] describes the use of the R Flag in IPv6 address resolution: 484 o Nodes capable of routing IPv6 packets must reply to NS messages 485 with NA messages where the R Flag is set (R Flag=1). 487 o Hosts that are not able to route IPv6 packets must indicate that 488 inability by replying with NA messages that contain R Flag=0. 490 The use of the R Flag in NA messages has an impact on how hosts 491 select their default gateways when sending packets off-link, as per 492 [RFC4861]: 494 o Hosts build a Default Router List based on the received RAs and 495 NAs with R Flag=1. Each cache entry has an IsRouter flag, which 496 must be set for received RAs and is set based on the R flag in the 497 received NAs. A host can choose one or more Default Routers when 498 sending packets off-link. 500 o In those cases where the IsRouter flag changes from TRUE to FALSE 501 as a result of a NA update, the node must remove that router from 502 the Default Router List and update the Destination Cache entries 503 for all destinations using that neighbor as a router, as specified 504 in [RFC4861] section 7.3.3. This is needed to detect when a node 505 that is used as a router stops forwarding packets due to being 506 configured as a host. 508 The R Flag and O Flag for a Proxy-ARP/ND entry will be learned in the 509 following ways: 511 o The R Flag information SHOULD be added to the Static entries by 512 the management interface. The O Flag information MAY also be 513 added by the management interface. If the R and O Flags are not 514 configured, the default value is 1. 516 o Dynamic entries SHOULD learn the R Flag and MAY learn the O Flag 517 from the snooped NA messages used to learn the IP->MAC itself. 519 o EVPN-learned entries SHOULD learn the R Flag and MAY learn the O 520 Flag from the ARP/ND Extended Community 521 [I-D.ietf-bess-evpn-na-flags] received from EVPN along with the 522 RT2 used to learn the IP->MAC itself. If no ARP/ND Extended 523 Community is received, the PE will add a configured R Flag/O Flag 524 to the entry. These configured R and O Flags MAY be an 525 administrative choice with a default value of 1. The 526 configuration of this administrative choice provides a backwards 527 compatible option with EVPN PEs that follow [RFC7432] but do not 528 support this specification. 530 Note that, typically, IP->MAC entries with O=0 will not be learned, 531 and therefore the Proxy-ND function will reply to NS messages with NA 532 messages that contain O=1. However, this document allows the 533 configuration of the "anycast" capability in the BD where the Proxy- 534 ND function is enabled. If "anycast" is enabled in the BD and an NA 535 message with O=0 is received, the associated IP->MAC entry will be 536 learned with O=0. If this "anycast" capability is enabled in the BD, 537 Duplicate IP Detection must be disabled so that the PE is able to 538 learn the same IP mapped to different MACs in the same Proxy-ND 539 table. If the "anycast" capability is disabled, NA messages with O 540 Flag = 0 will not create a Proxy-ND entry (although they will be 541 forwarded normally), hence no EVPN advertisement with ARP/ND Extended 542 Community will be generated. 544 3.3. Reply Sub-Function 546 This sub-function will reply to address resolution requests/ 547 solicitations upon successful lookup in the Proxy-ARP/ND table for a 548 given IP address. The following considerations should be taken into 549 account, assuming that the ARP Request/NS lookup hits a Proxy-ARP/ND 550 entry IP1->MAC1: 552 a. When replying to ARP Request or NS messages: 554 - the PE SHOULD use the Proxy-ARP/ND entry MAC address MAC1 as 555 MAC SA. This is RECOMMENDED so that the resolved MAC can be 556 learned in the MAC FIB of potential layer-2 switches sitting 557 between the PE and the CE requesting the address resolution. 559 - for an ARP reply, the PE MUST use the Proxy-ARP entry IP1 and 560 MAC1 addresses in the Sender Protocol Address and Hardware 561 Address fields, respectively. 563 - for an NA message in response to an address resolution NS or 564 DAD NS, the PE MUST use IP1 as the IP SA and Target Address. 565 M1 MUST be used as the Target Link Local Address (TLLA). 567 b. A PE SHOULD NOT reply to a request/solicitation received on the 568 same attachment circuit over which the IP->MAC is learned. In 569 this case the requester and the requested IP are assumed to be 570 connected to the same layer-2 CE/access network linked to the 571 PE's attachment circuit, and therefore the requested IP owner 572 will receive the request directly. 574 c. A PE SHOULD reply to broadcast/multicast address resolution 575 messages, that is, ARP-Request, NS messages as well as DAD NS 576 messages. A PE SHOULD NOT reply to unicast address resolution 577 requests (for instance, NUD NS messages). 579 d. When replying to an NS, a PE SHOULD set the Flags in the NA 580 messages as follows: 582 - The R-bit is set as it was learned for the IP->MAC entry in 583 the NA messages that created the entry (see Section 3.2.1). 585 - The S Flag will be set/unset as per [RFC4861]. 587 - The O Flag will be set in all the NA messages issued by the 588 PE, except in the case the BD is configured with the "anycast" 589 capability and the entry was previously learned with O=0. If 590 "anycast" is enabled and there are more than one MAC for a 591 given IP in the Proxy-ND table, the PE will reply to NS 592 messages with as many NA responses as 'anycast' entries there 593 are in the Proxy-ND table. 595 e. A PE MUST NOT reply to ARP probes received from the CEs. An ARP 596 probe is an ARP request constructed with an all-zero sender IP 597 address that may be used by hosts for IPv4 Address Conflict 598 Detection [RFC5227]. 600 f. For Proxy-ARP, a PE MUST only reply to ARP-Request with the 601 format specified in [RFC0826]. For Proxy-ND, a PE MUST reply to 602 NS messages with the format and options specified in [RFC4861], 603 and MAY reply to NS messages containing other options. Received 604 NS messages with unknown options SHOULD be forwarded (as unicast 605 packets) to the owner of the requested IP (assuming the MAC is 606 known in the Proxy-ARP/ND table and BD). An administrative 607 choice to control the behavior for received NS messages with 608 unknown options ('unicast-forward', 'discard' or 'forward') MAY 609 be supported. The 'unicast-forward' option is described in 610 Section 3.4. If 'discard' is available, the operator should 611 assess if flooding NS unknown options may be a security risk for 612 the EVPN BD (and is so, enable 'discard'), or if, on the 613 contrary, not forwarding NS unknown options may disrupt 614 connectivity. 616 3.4. Unicast-forward Sub-Function 618 As discussed in Section 3.3, in some cases the operator may want to 619 'unicast-forward' certain ARP-Request and NS messages as opposed to 620 reply to them. The implementation of a 'unicast-forward' function is 621 RECOMMENDED. This option can be enabled with one of the following 622 parameters: 624 a. unicast-forward always 626 b. unicast-forward unknown-options 628 If 'unicast-forward always' is enabled, the PE will perform a Proxy- 629 ARP/ND table lookup and in case of a hit, the PE will forward the 630 packet to the owner of the MAC found in the Proxy-ARP/ND table. This 631 is irrespective of the options carried in the ARP/ND packet. This 632 option provides total transparency in the BD and yet reduces the 633 amount of flooding significantly. 635 If 'unicast-forward unknown-options' is enabled, upon a successful 636 Proxy-ARP/ND lookup, the PE will perform a 'unicast-forward' action 637 only if the ARP-Request or NS messages carry unknown options, as 638 explained in Section 3.3. The 'unicast-forward unknown-options' 639 configuration allows the support of new applications using ARP/ND in 640 the BD while still reducing the flooding. 642 Irrespective of the enabled option, if there is no successful Proxy- 643 ARP/ND lookup, the unknown ARP-Request/NS will be flooded in the 644 context of the BD, as per Section 3.6. 646 3.5. Maintenance Sub-Function 648 The Proxy-ARP/ND tables SHOULD follow a number of maintenance 649 procedures so that the dynamic IP->MAC entries are kept if the owner 650 is active and flushed (and the associated RT2 withdrawn) if the owner 651 is no longer in the network. The following procedures are 652 RECOMMENDED: 654 a. Age-time 656 A dynamic Proxy-ARP/ND entry MUST be flushed out of the table if 657 the IP->MAC has not been refreshed within a given age-time. The 658 entry is refreshed if an ARP or NA message is received for the 659 same IP->MAC entry. The age-time is an administrative option and 660 its value should be carefully chosen depending on the specific 661 use case: in IXP networks (where the CE routers are fairly 662 static) the age-time may normally be longer than in DC networks 663 (where mobility is required). 665 b. Send-refresh option 667 The PE MAY send periodic refresh messages (ARP/ND "probes") to 668 the owners of the dynamic Proxy-ARP/ND entries, so that the 669 entries can be refreshed before they age out. The owner of the 670 IP->MAC entry would reply to the ARP/ND probe and the 671 corresponding entry age-time reset. The periodic send-refresh 672 timer is an administrative option and is RECOMMENDED to be a 673 third of the age-time or a half of the age-time in scaled 674 networks. 676 An ARP refresh issued by the PE will be an ARP-Request message 677 with the Sender's IP = 0 sent from the PE's MAC SA. If the PE 678 has an IP address in the subnet, for instance on an Integrated 679 Routing and Bridging (IRB) interface, then it MAY use it as a 680 source for the ARP request (instead of Sender's IP = 0). An ND 681 refresh will be a NS message issued from the PE's MAC SA and a 682 Link Local Address associated to the PE's MAC. 684 The refresh request messages SHOULD be sent only for dynamic 685 entries and not for static or EVPN-learned entries. Even though 686 the refresh request messages are broadcast or multicast, the PE 687 SHOULD only send the message to the attachment circuit associated 688 to the MAC in the IP->MAC entry. 690 The age-time and send-refresh options are used in EVPN networks to 691 avoid unnecessary EVPN RT2 withdrawals: if refresh messages are sent 692 before the corresponding BD FIB and Proxy-ARP/ND age-time for a given 693 entry expires, inactive but existing hosts will reply, refreshing the 694 entry and therefore avoiding unnecessary EVPN MAC/IP Advertisement 695 withdrawals in EVPN. Both entries (MAC in the BD and IP->MAC in 696 Proxy-ARP/ND) are reset when the owner replies to the ARP/ND probe. 697 If there is no response to the ARP/ND probe, the MAC and IP->MAC 698 entries will be legitimately flushed and the RT2s withdrawn. 700 3.6. Flooding (to Remote PEs) Reduction/Suppression 702 The Proxy-ARP/ND function implicitly helps reducing the flooding of 703 ARP Request and NS messages to remote PEs in an EVPN network. 704 However, in certain use cases, the flooding of ARP/NS/NA messages 705 (and even the unknown unicast flooding) to remote PEs can be 706 suppressed completely in an EVPN network. 708 For instance, in an IXP network, since all the participant CEs are 709 well known and will not move to a different PE, the IP->MAC entries 710 for the local CEs may be all provisioned on the PEs by a management 711 system. Assuming the entries for the CEs are all provisioned on the 712 local PE, a given Proxy-ARP/ND table will only contain static and 713 EVPN-learned entries. In this case, the operator may choose to 714 suppress the flooding of ARP/NS/NA from the local PE to the remote 715 PEs completely. 717 The flooding may also be suppressed completely in IXP networks with 718 dynamic Proxy-ARP/ND entries assuming that all the CEs are directly 719 connected to the PEs and they all advertise their presence with a 720 GARP/unsolicited-NA when they connect to the network. If any of 721 those two assumptions is not true and any of the PEs may not learn 722 all the local Proxy-ARP/ND entries, flooding of the ARP/NS/NA 723 messages from the local PE to the remote PEs SHOULD NOT be 724 suppressed, or the address resolution process for some CEs will not 725 be completed. 727 In networks where fast mobility is expected (DC use case), it is NOT 728 RECOMMENDED to suppress the flooding of unknown ARP-Requests/NS or 729 GARPs/unsolicited-NAs. Unknown ARP-Requests/NS refer to those ARP- 730 Request/NS messages for which the Proxy-ARP/ND lookups for the 731 requested IPs do not succeed. 733 In order to give the operator the choice to suppress/allow the 734 flooding to remote PEs, a PE MAY support administrative options to 735 individually suppress/allow the flooding of: 737 o Unknown ARP-Request and NS messages. 739 o GARP and unsolicited-NA messages. 741 The operator will use these options based on the expected behavior on 742 the CEs. 744 3.7. Duplicate IP Detection 746 The Proxy-ARP/ND function SHOULD support duplicate IP detection as 747 per this section so that ARP/ND-spoofing attacks or duplicate IPs due 748 to human errors can be detected. For IPv6 addresses, CEs will 749 continue to carry out the DAD procedures as per [RFC4862]. The 750 solution described in this section is an additional security 751 mechanism carried out by the PEs that guarantees IPv6 address moves 752 between PEs are legit and not the result of an attack. [RFC6957] 753 describes a solution for IPv6 Duplicate Address Detection Proxy, 754 however, it is defined for point-to-multipoint topologies with a 755 split-horizon forwarding, where the 'CEs' have no direct 756 communication within the same L2 link and therefore it is not 757 suitable for EVPN Broadcast Domains. In addition, the solution 758 described in this section includes the use of the AS-MAC for 759 additional security. 761 ARP/ND spoofing is a technique whereby an attacker sends "fake" ARP/ 762 ND messages onto a broadcast domain. Generally the aim is to 763 associate the attacker's MAC address with the IP address of another 764 host causing any traffic meant for that IP address to be sent to the 765 attacker instead. 767 The distributed nature of EVPN and Proxy-ARP/ND allows the easy 768 detection of duplicated IPs in the network, in a similar way to the 769 MAC duplication detection function supported by [RFC7432] for MAC 770 addresses. 772 Duplicate IP detection monitors "IP-moves" in the Proxy-ARP/ND table 773 in the following way: 775 a. When an existing active IP1->MAC1 entry is modified, a PE starts 776 an M-second timer (default value of M=180), and if it detects N 777 IP moves before the timer expires (default value of N=5), it 778 concludes that a duplicate IP situation has occurred. An IP move 779 is considered when, for instance, IP1->MAC1 is replaced by 780 IP1->MAC2 in the Proxy-ARP/ND table. Static IP->MAC entries, 781 that is, locally provisioned or EVPN-learned entries with I=1 in 782 the ARP/ND Extended Community, are not subject to this procedure. 783 Static entries MUST NOT be overridden by dynamic Proxy-ARP/ND 784 entries. 786 b. In order to detect the duplicate IP faster, the PE SHOULD send a 787 Confirm message to the former owner of the IP. A Confirm message 788 is a unicast ARP-Request/NS message sent by the PE to the MAC 789 addresses that previously owned the IP, when the MAC changes in 790 the Proxy-ARP/ND table. The Confirm message uses a sender's IP 791 0.0.0.0 in case of ARP (if the PE has an IP address in the subnet 792 then it MAY use it) and an IPv6 Link Local Address in case of NS. 793 If the PE does not receive an answer within a given time, the new 794 entry will be confirmed and activated. The default RECOMMENDED 795 time to receive the confirmation is 30 seconds. In case of 796 spoofing, for instance, if IP1->MAC1 moves to IP1->MAC2, the PE 797 may send a unicast ARP-Request/NS message for IP1 with MAC DA= 798 MAC1 and MAC SA= PE's MAC. This will force the legitimate owner 799 to respond if the move to MAC2 was spoofed, and make the PE issue 800 another Confirm message, this time to MAC DA= MAC2. If both, 801 legitimate owner and spoofer keep replying to the Confirm 802 message, the PE will detect the duplicate IP within the M-second 803 timer: 805 - If the IP1->MAC1 pair was previously owned by the spoofer and 806 the new IP1->MAC2 was from a valid CE, then the issued Confirm 807 message would trigger a response from the spoofer. 809 - If it were the other way around, that is, IP1->MAC1 was 810 previously owned by a valid CE, the Confirm message would 811 trigger a response from the CE. 813 Either way, if this process continues, then duplicate 814 detection will kick in. 816 c. Upon detecting a duplicate IP situation: 818 1. The entry in duplicate detected state cannot be updated with 819 new dynamic or EVPN-learned entries for the same IP. The 820 operator MAY override the entry, though, with a static 821 IP->MAC. 823 2. The PE SHOULD alert the operator and stop responding to ARP/ 824 NS for the duplicate IP until a corrective action is taken. 826 3. Optionally the PE MAY associate an "anti-spoofing-mac" (AS- 827 MAC) to the duplicate IP in the Proxy-ARP/ND table. The PE 828 will send a GARP/unsolicited-NA message with IP1->AS-MAC to 829 the local CEs as well as an RT2 (with IP1->AS-MAC) to the 830 remote PEs. This will update the ARP/ND caches on all the 831 CEs in the BD, and hence all the CEs in the BD will use the 832 AS-MAC as MAC DA when sending traffic to IP1. This procedure 833 prevents the spoofer from attracting any traffic for IP1. 834 Since the AS-MAC is a managed MAC address known by all the 835 PEs in the BD, all the PEs MAY apply filters to drop and/or 836 log any frame with MAC DA= AS-MAC. The advertisement of the 837 AS-MAC as a "black-hole MAC" (by using an indication in the 838 RT2) that can be used directly in the BD to drop frames is 839 for further study. 841 d. The duplicate IP situation will be cleared when a corrective 842 action is taken by the operator, or alternatively after a HOLD- 843 DOWN timer (default value of 540 seconds). 845 The values of M, N and HOLD-DOWN timer SHOULD be a configurable 846 administrative option to allow for the required flexibility in 847 different scenarios. 849 For Proxy-ND, the Duplicate IP Detection described in this section 850 SHOULD only monitor IP moves for IP->MACs learned from NA messages 851 with O Flag=1. NA messages with O Flag=0 would not override the ND 852 cache entries for an existing IP, and therefore the procedure in this 853 section would not detect duplicate IPs. This Duplicate IP Detection 854 for IPv6 SHOULD be disabled when the IPv6 "anycast" capability is 855 activated in a given BD. 857 4. Solution Benefits 859 The solution described in this document provides the following 860 benefits: 862 a. The solution may suppress completely the flooding of the ARP/ND 863 messages in the EVPN network, assuming that all the CE IP->MAC 864 addresses local to the PEs are known or provisioned on the PEs 865 from a management system. Note that in this case, the unknown 866 unicast flooded traffic can also be suppressed, since all the 867 expected unicast traffic will be destined to known MAC addresses 868 in the PE BDs. 870 b. The solution reduces significantly the flooding of the ARP/ND 871 messages in the EVPN network, assuming that some or all the CE 872 IP->MAC addresses are learned on the data plane by snooping ARP/ 873 ND messages issued by the CEs. 875 c. The solution provides a way to refresh periodically the CE 876 IP->MAC entries learned through the data plane, so that the 877 IP->MAC entries are not withdrawn by EVPN when they age out 878 unless the CE is not active anymore. This option helps reducing 879 the EVPN control plane overhead in a network with active CEs that 880 do not send packets frequently. 882 d. Provides a mechanism to detect duplicate IP addresses and avoid 883 ARP/ND-spoof attacks or the effects of duplicate addresses due to 884 human errors. 886 5. Deployment Scenarios 888 Four deployment scenarios with different levels of ARP/ND control are 889 available to operators using this solution, depending on their 890 requirements to manage ARP/ND: all dynamic learning, all dynamic 891 learning with Proxy-ARP/ND, hybrid dynamic learning and static 892 provisioning with Proxy-ARP/ND, and all static provisioning with 893 Proxy-ARP/ND. 895 5.1. All Dynamic Learning 897 In this scenario for minimum security and mitigation, EVPN is 898 deployed in the BD with the Proxy-ARP/ND function shutdown. PEs do 899 not intercept ARP/ND requests and flood all requests issued by the 900 CEs, as a conventional layer-2 network among those CEs would do. 901 While no ARP/ND mitigation is used in this scenario, the operator can 902 still take advantage of EVPN features such as control plane learning 903 and all-active multihoming in the peering network. Existing 904 mitigation solutions, such as the ARP-Sponge daemon [ARP-Sponge] may 905 also be used in this scenario. 907 Although this option does not require any of the procedures described 908 in this document, it is added as baseline/default option for 909 completeness. This option is equivalent to VPLS as far as ARP/ND is 910 concerned. The options described in Section 5.2, Section 5.3 and 911 Section 5.4 are only possible in EVPN networks in combination with 912 their Proxy-ARP/ND capabilities. 914 5.2. Dynamic Learning with Proxy-ARP/ND 916 This scenario minimizes flooding while enabling dynamic learning of 917 IP->MAC entries. The Proxy-ARP/ND function is enabled in the BDs of 918 the EVPN PEs, so that the PEs snoop ARP/ND messages issued by the CEs 919 and respond to CE ARP-requests/NS messages. 921 PEs will flood requests if the entry is not in their Proxy table. 922 Any unknown source IP->MAC entries will be learned and advertised in 923 EVPN, and traffic to unknown entries is discarded at the ingress PE. 925 This scenario makes use of the Learning, Reply and Maintenance sub- 926 functions, with an optional use of the Unicast-forward and Duplicate 927 IP detection sub-functions. The Flooding reduction sub-function uses 928 the default flooding for unknown ARP-Request/NS messages. 930 5.3. Hybrid Dynamic Learning and Static Provisioning with Proxy-ARP/ND 932 Some IXPs and other operators want to protect particular hosts on the 933 BD while allowing dynamic learning of CE addresses. For example, an 934 operator may want to configure static IP->MAC entries for management 935 and infrastructure hosts that provide critical services. In this 936 scenario, static entries are provisioned from the management plane 937 for protected IP->MAC addresses, and dynamic learning with Proxy-ARP/ 938 ND is enabled as described in Section 5.2 on the BD. 940 This scenario makes use of the same sub-functions as in Section 5.2, 941 but adding static entries added by the Learning sub-function. 943 5.4. All Static Provisioning with Proxy-ARP/ND 945 For a solution that maximizes security and eliminates flooding and 946 unknown unicast in the peering network, all IP->MAC entries are 947 provisioned from the management plane. The Proxy-ARP/ND function is 948 enabled in the BDs of the EVPN PEs, so that the PEs intercept and 949 respond to CE requests. Dynamic learning and ARP/ND snooping is 950 disabled so that ARP-Requests and NS to unknown IPs are discarded at 951 the ingress PE. This scenario provides an operator the most control 952 over IP->MAC entries and allows an operator to manage all entries 953 from a management system. 955 In this scenario, the Learning sub-function is limited to static 956 entries, the Maintenance sub-function will not require any procedures 957 due to the static entries, and the Flooding reduction sub-function 958 will completely suppress Unknown ARP-Requests/NS messages as well as 959 GARP and unsolicited-NA messages. 961 5.5. Example of Deployment in Internet Exchange Points 963 Nowadays, almost all IXPs install some security rules in order to 964 protect the peering network (BD). These rules are often called port 965 security. Port security summarizes different operational steps that 966 limit the access to the IXP-LAN and the customer router, and controls 967 the kind of traffic that the routers are allowed to exchange (e.g., 968 Ethernet, IPv4, IPv6). Due to this, the deployment scenario as 969 described in Section 5.4 "All Static Provisioning with Proxy-ARP/ND" 970 is the predominant scenario for IXPs. 972 In addition to the "All Static Provisioning" behavior, in IXP 973 networks it is recommended to configure the Reply Sub-Function to 974 'discard' ARP-Requests/NS messages with unrecognized options. 976 At IXPs, customers usually follow a certain operational life-cycle. 977 For each step of the operational life-cycle specific operational 978 procedures are executed. 980 The following describes the operational procedures that are needed to 981 guarantee port security throughout the life-cycle of a customer with 982 focus on EVPN features: 984 1. A new customer is connected the first time to the IXP: 986 Before the connection between the customer router and the IXP-LAN 987 is activated, the MAC of the router is allow-listed on the IXP's 988 switch port. All other MAC addresses are blocked. Pre-defined 989 IPv4 and IPv6 addresses of the IXP peering network space are 990 configured at the customer router. The IP->MAC static entries 991 (IPv4 and IPv6) are configured in the management system of the 992 IXP for the customer's port in order to support Proxy-ARP/ND. 994 In case a customer uses multiple ports aggregated to a single 995 logical port (LAG) some vendors randomly select the MAC address 996 of the LAG from the different MAC addresses assigned to the 997 ports. In this case the static entry will be used associated to 998 a list of allowed MACs. 1000 2. Replacement of customer router: 1002 If a customer router is about to be replaced, the new MAC 1003 address(es) must be installed in the management system besides 1004 the MAC address(es) of the currently connected router. This 1005 allows the customer to replace the router without any active 1006 involvement of the IXP operator. For this, static entries are 1007 also used. After the replacement takes place, the MAC 1008 address(es) of the replaced router can be removed. 1010 3. Decommissioning a customer router 1012 If a customer router is decommissioned, the router is 1013 disconnected from the IXP PE. Right after that, the MAC 1014 address(es) of the router and IP->MAC bindings can be removed 1015 from the management system. 1017 5.6. Example of Deployment in Data Centers 1019 DCs normally have different requirements than IXPs in terms of Proxy- 1020 ARP/ND. Some differences are listed below: 1022 a. The required mobility in virtualized DCs makes the "Dynamic 1023 Learning" or "Hybrid Dynamic and Static Provisioning" models more 1024 appropriate than the "All Static Provisioning" model. 1026 b. IPv6 'anycast' may be required in DCs, while it is typically not 1027 a requirement in IXP networks. Therefore if the DC needs IPv6 1028 anycast addresses, the "anycast" capability will be explicitly 1029 enabled in the Proxy-ND function, hence the Proxy-ND sub- 1030 functions modified accordingly. For instance, if IPv6 'anycast' 1031 is enabled in the Proxy-ND function, the Duplicate IP Detection 1032 procedure in Section 3.7 must be disabled. 1034 c. DCs may require special options on ARP/ND as opposed to the 1035 address resolution function, which is the only one typically 1036 required in IXPs. Based on that, the Reply Sub-function may be 1037 modified to forward or discard unknown options. 1039 6. Security Considerations 1041 The security considerations of [RFC7432] and 1042 [I-D.ietf-bess-evpn-na-flags] apply to this document too. Note that 1043 EVPN does not inherently provide cryptographic protection (including 1044 confidentiality protection). 1046 The procedures in this document reduce the amount of ARP/ND message 1047 flooding, which in itself provides a protection to "slow path" 1048 software processors of routers and Tenant Systems in large BDs. The 1049 ARP/ND requests that are replied by the Proxy-ARP/ND function (hence 1050 not flooded) are normally targeted to existing hosts in the BD. ARP/ 1051 ND requests targeted to absent hosts are still normally flooded; 1052 however, the suppression of Unknown ARP-Requests and NS messages 1053 described in Section 3.6 can provide an additional level of security 1054 against ARP-Requests/NS messages issued to non-existing hosts. 1056 While the unicast-forward and/or flooding suppression sub-functions 1057 provide an added security mechanism for the BD, they can also 1058 increase the risk of blocking the service for a CE if the EVPN PEs 1059 cannot provide the ARP/ND resolution that the CE needs. 1061 The solution also provides protection against Denial Of Service 1062 attacks that use ARP/ND-spoofing as a first step. The Duplicate IP 1063 Detection and the use of an AS-MAC as explained in Section 3.7 1064 protects the BD against ARP/ND spoofing. 1066 The Proxy-ARP/ND function specified in this document does not allow 1067 the learning of an IP address mapped to multiple MAC addresses in the 1068 same table, unless the "anycast" capability is enabled (and only in 1069 case of Proxy-ND). When "anycast" is enabled in the Proxy-ND 1070 function, the number of allowed entries for the same IP address MUST 1071 be limited by the operator to prevent DoS attacks that attempt to 1072 fill the Proxy-ND table with a significant number of entries for the 1073 same IP. 1075 The document provides some examples and guidelines that can be used 1076 by IXPs in their EVPN BDs. When EVPN and its associated Proxy-ARP/ND 1077 function are used in IXP networks, they provide ARP/ND security and 1078 mitigation. IXPs must still employ additional security mechanisms 1079 that protect the peering network as per the established BCPs such as 1080 the ones described in [Euro-IX-BCP]. For example, IXPs should 1081 disable all unneeded control protocols, and block unwanted protocols 1082 from CEs so that only IPv4, ARP and IPv6 Ethertypes are permitted on 1083 the peering network. In addition, port security features and ACLs 1084 can provide an additional level of security. 1086 Finally, it is worth noting that the Proxy-ARP/ND solution in this 1087 document will not work if there is a mechanism securing ARP/ND 1088 exchanges among CEs, because the PE is not able to secure the 1089 "proxied" ND messages. 1091 7. IANA Considerations 1093 No IANA considerations. 1095 8. Acknowledgments 1097 The authors want to thank Ranganathan Boovaraghavan, Sriram 1098 Venkateswaran, Manish Krishnan, Seshagiri Venugopal, Tony Przygienda, 1099 Robert Raszuk and Iftekhar Hussain for their review and 1100 contributions. Thank you to Oliver Knapp as well, for his detailed 1101 review. 1103 9. Contributors 1105 In addition to the authors listed on the front page, the following 1106 co-authors have also contributed to this document: 1108 Wim Henderickx 1109 Nokia 1111 Daniel Melzer 1112 DE-CIX Management GmbH 1114 Erik Nordmark 1115 Zededa 1117 10. References 1119 10.1. Normative References 1121 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 1122 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 1123 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 1124 2015, . 1126 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1127 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1128 DOI 10.17487/RFC4861, September 2007, 1129 . 1131 [RFC0826] Plummer, D., "An Ethernet Address Resolution Protocol: Or 1132 Converting Network Protocol Addresses to 48.bit Ethernet 1133 Address for Transmission on Ethernet Hardware", STD 37, 1134 RFC 826, DOI 10.17487/RFC0826, November 1982, 1135 . 1137 [RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227, 1138 DOI 10.17487/RFC5227, July 2008, 1139 . 1141 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1142 Requirement Levels", BCP 14, RFC 2119, 1143 DOI 10.17487/RFC2119, March 1997, 1144 . 1146 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1147 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1148 May 2017, . 1150 [I-D.ietf-bess-evpn-na-flags] 1151 Rabadan, J., Sathappan, S., Nagaraj, K., and W. Lin, 1152 "Propagation of ARP/ND Flags in EVPN", draft-ietf-bess- 1153 evpn-na-flags-09 (work in progress), December 2020. 1155 10.2. Informative References 1157 [ARP-Sponge] 1158 N., W. M. A. S., "Effects of IPv4 and IPv6 address 1159 resolution on AMS-IX and the ARP Sponge - 1160 https://delaat.net/rp/2008-2009/p23/report.pdf", July 1161 2009. 1163 [Euro-IX-BCP] 1164 Euro-IX, "European Internet Exchange Association Best 1165 Practises - 1166 https://www.euro-ix.net/en/forixps/set-ixp/ixp-bcops/". 1168 [RFC6820] Narten, T., Karir, M., and I. Foo, "Address Resolution 1169 Problems in Large Data Center Networks", RFC 6820, 1170 DOI 10.17487/RFC6820, January 2013, 1171 . 1173 [RFC6957] Costa, F., Combes, J-M., Ed., Pougnard, X., and H. Li, 1174 "Duplicate Address Detection Proxy", RFC 6957, 1175 DOI 10.17487/RFC6957, June 2013, 1176 . 1178 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1179 Address Autoconfiguration", RFC 4862, 1180 DOI 10.17487/RFC4862, September 2007, 1181 . 1183 Authors' Addresses 1184 Jorge Rabadan (editor) 1185 Nokia 1186 777 Middlefield Road 1187 Mountain View, CA 94043 1188 USA 1190 Email: jorge.rabadan@nokia.com 1192 Senthil Sathappan 1193 Nokia 1194 701 E. Middlefield Road 1195 Mountain View, CA 94043 USA 1197 Email: senthil.sathappan@nokia.com 1199 Kiran Nagaraj 1200 Nokia 1201 701 E. Middlefield Road 1202 Mountain View, CA 94043 USA 1204 Email: kiran.nagaraj@nokia.com 1206 Greg Hankins 1207 Nokia 1209 Email: greg.hankins@nokia.com 1211 Thomas King 1212 DE-CIX Management GmbH 1214 Email: thomas.king@de-cix.net