idnits 2.17.1 draft-ietf-bess-evpn-proxy-arp-nd-16.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 (October 6, 2021) is 933 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: April 9, 2022 Nokia 7 T. King 8 DE-CIX 9 October 6, 2021 11 Operational Aspects of Proxy-ARP/ND in Ethernet Virtual Private Networks 12 draft-ietf-bess-evpn-proxy-arp-nd-16 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 April 9, 2022. 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 . . . . . . . . . . . . . . 14 71 3.5. Maintenance Sub-Function . . . . . . . . . . . . . . . . 14 72 3.6. Flood (to Remote PEs) Handling . . . . . . . . . . . . . 16 73 3.7. Duplicate IP Detection . . . . . . . . . . . . . . . . . 17 74 4. Solution Benefits . . . . . . . . . . . . . . . . . . . . . . 19 75 5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 20 76 5.1. All Dynamic Learning . . . . . . . . . . . . . . . . . . 20 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 . . . . . . . . 21 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 . . . . . . . . . . . . . . . . . . . 23 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 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 . . . . . . . . . . . . . . . . . . . . . . . 26 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 [RFC9047]. From that perspective this document updates 188 [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]. For IPv6, the fact that IPv6 CEs have more than one 248 IPv6 address contributes to the growth of ND flooding in the network. 249 The amount of ARP/ND flooded traffic grows linearly with the number 250 of IXP participants, therefore the issue can only grow worse as new 251 CEs are added. 253 In order to deal with this issue, IXPs have developed certain 254 solutions over the past years. While these solutions may mitigate 255 the issues of address resolution in large broadcasts domains, EVPN 256 provides new more efficient possibilities to IXPs. EVPN and its 257 Proxy-ARP/ND function may help solve the issue in a distributed and 258 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 In a network where CEs move between PEs, the Proxy-ARP/ND function 370 relies on the CE signaling its new location via GARP or unsolicited- 371 NA messages so that tables are immediately updated. If a CE moves 372 "silently", that is, without issuing any GARP or NA message upon 373 getting attached to the destination PE, the mechanisms described in 374 Section 3.5 make sure that the Proxy-ARP/ND tables are eventually 375 updated. 377 3.1. Proxy-ARP/ND Sub-Functions 379 The Proxy-ARP/ND function can be structured in six sub-functions or 380 procedures: 382 1. Learning sub-function 384 2. Reply sub-function 386 3. Unicast-forward sub-function 387 4. Maintenance sub-function 389 5. Flood handling sub-function 391 6. Duplicate IP detection sub-function 393 A Proxy-ARP/ND implementation MUST at least support the Learning, 394 Reply, Maintenance, and Duplicate IP detection sub-functions. The 395 following sections describe each individual sub-function. 397 3.2. Learning Sub-Function 399 A Proxy-ARP/ND implementation in an EVPN BD MUST support dynamic and 400 EVPN-learned entries, and SHOULD support static entries. 402 Static entries are provisioned from the management plane. A static 403 entry is configured on the PE attached to the host using the IP 404 address in that entry. The provisioned static IP->MAC entry MUST be 405 advertised in EVPN with an ARP/ND Extended Community where the 406 Immutable ARP/ND Binding Flag (I) is set to 1, as per [RFC9047]. 407 When the I flag in the ARP/ND Extended Community is 1, the 408 advertising PE indicates that the IP address must not be associated 409 to a MAC, other than the one included in the EVPN MAC/IP 410 Advertisement route. The advertisement of I=1 in the ARP/ND Extended 411 Community is compatible with any value of the Sticky bit (S) or 412 Sequence Number in the [RFC7432] MAC Mobility Extended Community. 413 Note that the I bit in the ARP/ND Extended Community refers to the 414 immutable configured association between the IP and the MAC address 415 in the IP->MAC binding, whereas the S bit in the MAC Mobility 416 Extended Community refers to the fact that the advertised MAC address 417 is not subject to the [RFC7432] mobility procedures. 419 An entry may associate a configured static IP to a list of potential 420 MACs, i.e. IP1->(MAC1,MAC2..MACN). Until a frame (including local 421 ARP/NA message) is received from the CE, the PE will not advertise 422 any IP1->MAC in EVPN. Upon receiving traffic from the CE, the PE 423 will check that the source MAC, E.g., MAC1, is included in the list 424 of allowed MACs. Only in that case, the PE will activate the 425 IP1->MAC1 and advertise only that IP1 and MAC1 in an EVPN MAC/IP 426 Advertisement route. 428 The PE MUST create EVPN-learned entries from the received valid EVPN 429 MAC/IP Advertisement routes containing a MAC and IP address. 431 Dynamic entries are learned in different ways depending on whether 432 the entry contains an IPv4 or IPv6 address: 434 a. Proxy-ARP dynamic entries: 436 The PE MUST snoop all ARP packets (that is, all frames with 437 Ethertype 0x0806) received from the CEs attached to the BD in 438 order to learn dynamic entries. ARP packets received from 439 remote EVPN PEs attached to the same BD are not snooped. The 440 Learning function will add the Sender MAC and Sender IP of the 441 snooped ARP packet to the Proxy-ARP table. Note that a MAC or 442 an IP address with value 0 SHOULD NOT be learned. 444 b. Proxy-ND dynamic entries: 446 The PE MUST snoop the NA messages (Ethertype 0x86dd, ICMPv6 447 type 136) received from the CEs attached to the BD and learn 448 dynamic entries from the Target Address and TLLA information. 449 NA messages received from remote EVPN PEs are not snooped. A 450 PE implementing Proxy-ND as in this document MUST NOT create 451 dynamic IP->MAC entries from NS messages, since they don't 452 contain the R Flag required by the Proxy-ND reply function. 453 See Section 3.2.1 for more information about the R Flag. 455 This document specifies an "anycast" capability that can be 456 configured for the proxy-ND function of the PE, and affects 457 how dynamic Proxy-ND entries are learned based on the O Flag 458 of the snooped NA messages. If the O Flag is zero in the 459 received NA message, the IP->MAC SHOULD only be learned in 460 case the IPv6 "anycast" capability is enabled in the BD. 461 Irrespective, an NA message with O Flag = 0 will be normally 462 forwarded by the PE based on a MAC DA lookup. 464 The following procedure associated to the Learning sub-function is 465 RECOMMENDED: 467 o When a new Proxy-ARP/ND EVPN or static active entry is learned (or 468 provisioned), the PE SHOULD send a GARP or unsolicited-NA message 469 to all the connected access CEs. The PE SHOULD send a GARP or 470 unsolicited-NA message for dynamic entries only if the ARP/NA 471 message that previously created the entry on the PE was NOT 472 flooded to all the local connected CEs before. This GARP/ 473 unsolicited-NA message makes sure the CE ARP/ND caches are updated 474 even if the ARP/NS/NA messages from CEs connected to remote PEs 475 are not flooded in the EVPN network. 477 Note that if a Static entry is provisioned with the same IP as an 478 existing EVPN-learned or Dynamic entry, the Static entry takes 479 precedence. 481 In case of a PE reboot, the static and EVPN entries will be re-added 482 as soon as the PE is back online and receives all the EVPN routes for 483 the BD. However, the dynamic entries will be gone. Due to that 484 reason, new NS and ARP Requests will be flooded by the PE to remote 485 PEs and dynamic entries gradually re-learned again. 487 3.2.1. Proxy-ND and the NA Flags 489 [RFC4861] describes the use of the R Flag in IPv6 address resolution: 491 o Nodes capable of routing IPv6 packets must reply to NS messages 492 with NA messages where the R Flag is set (R Flag=1). 494 o Hosts that are not able to route IPv6 packets must indicate that 495 inability by replying with NA messages that contain R Flag=0. 497 The use of the R Flag in NA messages has an impact on how hosts 498 select their default gateways when sending packets off-link, as per 499 [RFC4861]: 501 o Hosts build a Default Router List based on the received RAs and 502 NAs with R Flag=1. Each cache entry has an IsRouter flag, which 503 must be set for received RAs and is set based on the R flag in the 504 received NAs. A host can choose one or more Default Routers when 505 sending packets off-link. 507 o In those cases where the IsRouter flag changes from TRUE to FALSE 508 as a result of a NA update, the node must remove that router from 509 the Default Router List and update the Destination Cache entries 510 for all destinations using that neighbor as a router, as specified 511 in [RFC4861] section 7.3.3. This is needed to detect when a node 512 that is used as a router stops forwarding packets due to being 513 configured as a host. 515 The R Flag and O Flag for a Proxy-ARP/ND entry will be learned in the 516 following ways: 518 o The R Flag information SHOULD be added to the Static entries by 519 the management interface. The O Flag information MAY also be 520 added by the management interface. If the R and O Flags are not 521 configured, the default value is 1. 523 o Dynamic entries SHOULD learn the R Flag and MAY learn the O Flag 524 from the snooped NA messages used to learn the IP->MAC itself. 526 o EVPN-learned entries SHOULD learn the R Flag and MAY learn the O 527 Flag from the ARP/ND Extended Community [RFC9047] received from 528 EVPN along with the RT2 used to learn the IP->MAC itself. If no 529 ARP/ND Extended Community is received, the PE will add a 530 configured R Flag/O Flag to the entry. These configured R and O 531 Flags MAY be an administrative choice with a default value of 1. 533 The configuration of this administrative choice provides a 534 backwards compatible option with EVPN PEs that follow [RFC7432] 535 but do not support this specification. 537 Note that, typically, IP->MAC entries with O=0 will not be learned, 538 and therefore the Proxy-ND function will reply to NS messages with NA 539 messages that contain O=1. However, this document allows the 540 configuration of the "anycast" capability in the BD where the Proxy- 541 ND function is enabled. If "anycast" is enabled in the BD and an NA 542 message with O=0 is received, the associated IP->MAC entry will be 543 learned with O=0. If this "anycast" capability is enabled in the BD, 544 Duplicate IP Detection must be disabled so that the PE is able to 545 learn the same IP mapped to different MACs in the same Proxy-ND 546 table. If the "anycast" capability is disabled, NA messages with O 547 Flag = 0 will not create a Proxy-ND entry (although they will be 548 forwarded normally), hence no EVPN advertisement with ARP/ND Extended 549 Community will be generated. 551 3.3. Reply Sub-Function 553 This sub-function will reply to address resolution requests/ 554 solicitations upon successful lookup in the Proxy-ARP/ND table for a 555 given IP address. The following considerations should be taken into 556 account, assuming that the ARP Request/NS lookup hits a Proxy-ARP/ND 557 entry IP1->MAC1: 559 a. When replying to ARP Request or NS messages: 561 - the PE SHOULD use the Proxy-ARP/ND entry MAC address MAC1 as 562 MAC SA. This is RECOMMENDED so that the resolved MAC can be 563 learned in the MAC forwarding database of potential layer-2 564 switches sitting between the PE and the CE requesting the 565 address resolution. 567 - for an ARP reply, the PE MUST use the Proxy-ARP entry IP1 and 568 MAC1 addresses in the Sender Protocol Address and Hardware 569 Address fields, respectively. 571 - for an NA message in response to an address resolution NS or 572 DAD NS, the PE MUST use IP1 as the IP SA and Target Address. 573 M1 MUST be used as the Target Link Local Address (TLLA). 575 b. A PE SHOULD NOT reply to a request/solicitation received on the 576 same attachment circuit over which the IP->MAC is learned. In 577 this case the requester and the requested IP are assumed to be 578 connected to the same layer-2 CE/access network linked to the 579 PE's attachment circuit, and therefore the requested IP owner 580 will receive the request directly. 582 c. A PE SHOULD reply to broadcast/multicast address resolution 583 messages, that is, ARP-Request, ARP probes, NS messages as well 584 as DAD NS messages. An ARP probe is an ARP request constructed 585 with an all-zero sender IP address that may be used by hosts for 586 IPv4 Address Conflict Detection as specified in [RFC5227]. A PE 587 SHOULD NOT reply to unicast address resolution requests (for 588 instance, NUD NS messages). 590 d. When replying to an NS, a PE SHOULD set the Flags in the NA 591 messages as follows: 593 - The R-bit is set as it was learned for the IP->MAC entry in 594 the NA messages that created the entry (see Section 3.2.1). 596 - The S Flag will be set/unset as per [RFC4861]. 598 - The O Flag will be set in all the NA messages issued by the 599 PE, except in the case the BD is configured with the "anycast" 600 capability and the entry was previously learned with O=0. If 601 "anycast" is enabled and there are more than one MAC for a 602 given IP in the Proxy-ND table, the PE will reply to NS 603 messages with as many NA responses as 'anycast' entries there 604 are in the Proxy-ND table. 606 e. For Proxy-ARP, a PE MUST only reply to ARP-Request with the 607 format specified in [RFC0826]. 609 f. For Proxy-ND, a PE MUST reply to NS messages with known options 610 with the format and options specified in [RFC4861], and MAY 611 reply, discard, forward or unicast-forward NS messages containing 612 other options. An administrative choice to control the behavior 613 for received NS messages with unknown options ('reply', 614 'discard', 'unicast-forward' or 'forward') MAY be supported. 616 - The 'reply' option implies that the PE ignores the unknown 617 options and replies with NA messages, assuming a successful 618 lookup on the Proxy-ND table. An unsuccessful lookup will 619 result in a 'forward' behavior (i.e., flood the NS message 620 based on the MAC DA. 622 - If 'discard' is available, the operator should assess if 623 flooding NS unknown options may be a security risk for the 624 EVPN BD (and if so, enable 'discard'), or if, on the contrary, 625 not forwarding/flooding NS unknown options may disrupt 626 connectivity. This option discards NS messages with unknown 627 options, irrespective of the result of the lookup on the 628 Proxy-ND table. 630 - The 'unicast-forward' option is described in Section 3.4. 632 - The 'forward' option implies flooding the NS message based on 633 the MAC DA. This option forwards NS messages with unknown 634 options, irrespective of the result of the lookup on the 635 Proxy-ND table. The 'forward' option is RECOMMENDED by this 636 document. 638 3.4. Unicast-forward Sub-Function 640 As discussed in Section 3.3, in some cases the operator may want to 641 'unicast-forward' certain ARP-Request and NS messages as opposed to 642 reply to them. The implementation of a 'unicast-forward' function is 643 RECOMMENDED. This option can be enabled with one of the following 644 parameters: 646 a. unicast-forward always 648 b. unicast-forward unknown-options 650 If 'unicast-forward always' is enabled, the PE will perform a Proxy- 651 ARP/ND table lookup and in case of a hit, the PE will forward the 652 packet to the owner of the MAC found in the Proxy-ARP/ND table. This 653 is irrespective of the options carried in the ARP/ND packet. This 654 option provides total transparency in the BD and yet reduces the 655 amount of flooding significantly. 657 If 'unicast-forward unknown-options' is enabled, upon a successful 658 Proxy-ARP/ND lookup, the PE will perform a 'unicast-forward' action 659 only if the ARP-Request or NS messages carry unknown options, as 660 explained in Section 3.3. The 'unicast-forward unknown-options' 661 configuration allows the support of new applications using ARP/ND in 662 the BD while still reducing the flooding. 664 Irrespective of the enabled option, if there is no successful Proxy- 665 ARP/ND lookup, the unknown ARP-Request/NS will be flooded in the 666 context of the BD, as per Section 3.6. 668 3.5. Maintenance Sub-Function 670 The Proxy-ARP/ND tables SHOULD follow a number of maintenance 671 procedures so that the dynamic IP->MAC entries are kept if the owner 672 is active and flushed (and the associated RT2 withdrawn) if the owner 673 is no longer in the network. The following procedures are 674 RECOMMENDED: 676 a. Age-time 677 A dynamic Proxy-ARP/ND entry MUST be flushed out of the table if 678 the IP->MAC has not been refreshed within a given age-time. The 679 entry is refreshed if an ARP or NA message is received for the 680 same IP->MAC entry. The age-time is an administrative option and 681 its value should be carefully chosen depending on the specific 682 use case: in IXP networks (where the CE routers are fairly 683 static) the age-time may normally be longer than in DC networks 684 (where mobility is required). 686 b. Send-refresh option 688 The PE MAY send periodic refresh messages (ARP/ND "probes") to 689 the owners of the dynamic Proxy-ARP/ND entries, so that the 690 entries can be refreshed before they age out. The owner of the 691 IP->MAC entry would reply to the ARP/ND probe and the 692 corresponding entry age-time reset. The periodic send-refresh 693 timer is an administrative option and is RECOMMENDED to be a 694 third of the age-time or a half of the age-time in scaled 695 networks. 697 An ARP refresh issued by the PE will be an ARP-Request message 698 with the Sender's IP = 0 sent from the PE's MAC SA. If the PE 699 has an IP address in the subnet, for instance on an Integrated 700 Routing and Bridging (IRB) interface, then it MAY use it as a 701 source for the ARP request (instead of Sender's IP = 0). An ND 702 refresh will be a NS message issued from the PE's MAC SA and a 703 Link Local Address associated to the PE's MAC. 705 The refresh request messages SHOULD be sent only for dynamic 706 entries and not for static or EVPN-learned entries. Even though 707 the refresh request messages are broadcast or multicast, the PE 708 SHOULD only send the message to the attachment circuit associated 709 to the MAC in the IP->MAC entry. 711 The age-time and send-refresh options are used in EVPN networks to 712 avoid unnecessary EVPN RT2 withdrawals: if refresh messages are sent 713 before the corresponding BD Bridge-Table and Proxy-ARP/ND age-time 714 for a given entry expires, inactive but existing hosts will reply, 715 refreshing the entry and therefore avoiding unnecessary EVPN MAC/IP 716 Advertisement withdrawals in EVPN. Both entries (MAC in the BD and 717 IP->MAC in Proxy-ARP/ND) are reset when the owner replies to the ARP/ 718 ND probe. If there is no response to the ARP/ND probe, the MAC and 719 IP->MAC entries will be legitimately flushed and the RT2s withdrawn. 721 3.6. Flood (to Remote PEs) Handling 723 The Proxy-ARP/ND function implicitly helps reducing the flooding of 724 ARP Request and NS messages to remote PEs in an EVPN network. 725 However, in certain use cases, the flooding of ARP/NS/NA messages 726 (and even the unknown unicast flooding) to remote PEs can be 727 suppressed completely in an EVPN network. 729 For instance, in an IXP network, since all the participant CEs are 730 well known and will not move to a different PE, the IP->MAC entries 731 for the local CEs may be all provisioned on the PEs by a management 732 system. Assuming the entries for the CEs are all provisioned on the 733 local PE, a given Proxy-ARP/ND table will only contain static and 734 EVPN-learned entries. In this case, the operator may choose to 735 suppress the flooding of ARP/NS/NA from the local PE to the remote 736 PEs completely. 738 The flooding may also be suppressed completely in IXP networks with 739 dynamic Proxy-ARP/ND entries assuming that all the CEs are directly 740 connected to the PEs and they all advertise their presence with a 741 GARP/unsolicited-NA when they connect to the network. If any of 742 those two assumptions is not true and any of the PEs may not learn 743 all the local Proxy-ARP/ND entries, flooding of the ARP/NS/NA 744 messages from the local PE to the remote PEs SHOULD NOT be 745 suppressed, or the address resolution process for some CEs will not 746 be completed. 748 In networks where fast mobility is expected (DC use case), it is NOT 749 RECOMMENDED to suppress the flooding of unknown ARP-Requests/NS or 750 GARPs/unsolicited-NAs. Unknown ARP-Requests/NS refer to those ARP- 751 Request/NS messages for which the Proxy-ARP/ND lookups for the 752 requested IPs do not succeed. 754 In order to give the operator the choice to suppress/allow the 755 flooding to remote PEs, a PE MAY support administrative options to 756 individually suppress/allow the flooding of: 758 o Unknown ARP-Request and NS messages. 760 o GARP and unsolicited-NA messages. 762 The operator will use these options based on the expected behavior on 763 the CEs. 765 3.7. Duplicate IP Detection 767 The Proxy-ARP/ND function MUST support duplicate IP detection as per 768 this section so that ARP/ND-spoofing attacks or duplicate IPs due to 769 human errors can be detected. For IPv6 addresses, CEs will continue 770 to carry out the DAD procedures as per [RFC4862]. The solution 771 described in this section is an additional security mechanism carried 772 out by the PEs that guarantees IPv6 address moves between PEs are 773 legitimate and not the result of an attack. [RFC6957] describes a 774 solution for IPv6 Duplicate Address Detection Proxy, however, it is 775 defined for point-to-multipoint topologies with a split-horizon 776 forwarding, where the 'CEs' have no direct communication within the 777 same L2 link and therefore it is not suitable for EVPN Broadcast 778 Domains. In addition, the solution described in this section 779 includes the use of the AS-MAC for additional security. 781 ARP/ND spoofing is a technique whereby an attacker sends "fake" ARP/ 782 ND messages onto a broadcast domain. Generally the aim is to 783 associate the attacker's MAC address with the IP address of another 784 host causing any traffic meant for that IP address to be sent to the 785 attacker instead. 787 The distributed nature of EVPN and Proxy-ARP/ND allows the easy 788 detection of duplicated IPs in the network, in a similar way to the 789 MAC duplication detection function supported by [RFC7432] for MAC 790 addresses. 792 Duplicate IP detection monitors "IP-moves" in the Proxy-ARP/ND table 793 in the following way: 795 a. When an existing active IP1->MAC1 entry is modified, a PE starts 796 an M-second timer (default value of M=180), and if it detects N 797 IP moves before the timer expires (default value of N=5), it 798 concludes that a duplicate IP situation has occurred. An IP move 799 is considered when, for instance, IP1->MAC1 is replaced by 800 IP1->MAC2 in the Proxy-ARP/ND table. Static IP->MAC entries, 801 that is, locally provisioned or EVPN-learned entries with I=1 in 802 the ARP/ND Extended Community, are not subject to this procedure. 803 Static entries MUST NOT be overridden by dynamic Proxy-ARP/ND 804 entries. 806 b. In order to detect the duplicate IP faster, the PE SHOULD send a 807 Confirm message to the former owner of the IP. A Confirm message 808 is a unicast ARP-Request/NS message sent by the PE to the MAC 809 addresses that previously owned the IP, when the MAC changes in 810 the Proxy-ARP/ND table. The Confirm message uses a sender's IP 811 0.0.0.0 in case of ARP (if the PE has an IP address in the subnet 812 then it MAY use it) and an IPv6 Link Local Address in case of NS. 814 If the PE does not receive an answer within a given time, the new 815 entry will be confirmed and activated. The default RECOMMENDED 816 time to receive the confirmation is 30 seconds. In case of 817 spoofing, for instance, if IP1->MAC1 moves to IP1->MAC2, the PE 818 may send a unicast ARP-Request/NS message for IP1 with MAC DA= 819 MAC1 and MAC SA= PE's MAC. This will force the legitimate owner 820 to respond if the move to MAC2 was spoofed, and make the PE issue 821 another Confirm message, this time to MAC DA= MAC2. If both, 822 legitimate owner and spoofer keep replying to the Confirm 823 message, the PE will detect the duplicate IP within the M-second 824 timer: 826 - If the IP1->MAC1 pair was previously owned by the spoofer and 827 the new IP1->MAC2 was from a valid CE, then the issued Confirm 828 message would trigger a response from the spoofer. 830 - If it were the other way around, that is, IP1->MAC1 was 831 previously owned by a valid CE, the Confirm message would 832 trigger a response from the CE. 834 Either way, if this process continues, then duplicate 835 detection will kick in. 837 c. Upon detecting a duplicate IP situation: 839 1. The entry in duplicate detected state cannot be updated with 840 new dynamic or EVPN-learned entries for the same IP. The 841 operator MAY override the entry, though, with a static 842 IP->MAC. 844 2. The PE SHOULD alert the operator and stop responding to ARP/ 845 NS for the duplicate IP until a corrective action is taken. 847 3. Optionally the PE MAY associate an "anti-spoofing-mac" (AS- 848 MAC) to the duplicate IP in the Proxy-ARP/ND table. The PE 849 will send a GARP/unsolicited-NA message with IP1->AS-MAC to 850 the local CEs as well as an RT2 (with IP1->AS-MAC) to the 851 remote PEs. This will update the ARP/ND caches on all the 852 CEs in the BD, and hence all the CEs in the BD will use the 853 AS-MAC as MAC DA when sending traffic to IP1. This procedure 854 prevents the spoofer from attracting any traffic for IP1. 855 Since the AS-MAC is a managed MAC address known by all the 856 PEs in the BD, all the PEs MAY apply filters to drop and/or 857 log any frame with MAC DA= AS-MAC. The advertisement of the 858 AS-MAC as a "black-hole MAC" (by using an indication in the 859 RT2) that can be used directly in the BD to drop frames is 860 for further study. 862 d. The duplicate IP situation will be cleared when a corrective 863 action is taken by the operator, or alternatively after a HOLD- 864 DOWN timer (default value of 540 seconds). 866 The values of M, N and HOLD-DOWN timer SHOULD be a configurable 867 administrative option to allow for the required flexibility in 868 different scenarios. 870 For Proxy-ND, the Duplicate IP Detection described in this section 871 SHOULD only monitor IP moves for IP->MACs learned from NA messages 872 with O Flag=1. NA messages with O Flag=0 would not override the ND 873 cache entries for an existing IP, and therefore the procedure in this 874 section would not detect duplicate IPs. This Duplicate IP Detection 875 for IPv6 SHOULD be disabled when the IPv6 "anycast" capability is 876 activated in a given BD. 878 4. Solution Benefits 880 The solution described in this document provides the following 881 benefits: 883 a. The solution may suppress completely the flooding of the ARP/ND 884 messages in the EVPN network, assuming that all the CE IP->MAC 885 addresses local to the PEs are known or provisioned on the PEs 886 from a management system. Note that in this case, the unknown 887 unicast flooded traffic can also be suppressed, since all the 888 expected unicast traffic will be destined to known MAC addresses 889 in the PE BDs. 891 b. The solution reduces significantly the flooding of the ARP/ND 892 messages in the EVPN network, assuming that some or all the CE 893 IP->MAC addresses are learned on the data plane by snooping ARP/ 894 ND messages issued by the CEs. 896 c. The solution provides a way to refresh periodically the CE 897 IP->MAC entries learned through the data plane, so that the 898 IP->MAC entries are not withdrawn by EVPN when they age out 899 unless the CE is not active anymore. This option helps reducing 900 the EVPN control plane overhead in a network with active CEs that 901 do not send packets frequently. 903 d. Provides a mechanism to detect duplicate IP addresses and avoid 904 ARP/ND-spoof attacks or the effects of duplicate addresses due to 905 human errors. 907 5. Deployment Scenarios 909 Four deployment scenarios with different levels of ARP/ND control are 910 available to operators using this solution, depending on their 911 requirements to manage ARP/ND: all dynamic learning, all dynamic 912 learning with Proxy-ARP/ND, hybrid dynamic learning and static 913 provisioning with Proxy-ARP/ND, and all static provisioning with 914 Proxy-ARP/ND. 916 5.1. All Dynamic Learning 918 In this scenario for minimum security and mitigation, EVPN is 919 deployed in the BD with the Proxy-ARP/ND function shutdown. PEs do 920 not intercept ARP/ND requests and flood all requests issued by the 921 CEs, as a conventional layer-2 network among those CEs would do. 922 While no ARP/ND mitigation is used in this scenario, the operator can 923 still take advantage of EVPN features such as control plane learning 924 and all-active multihoming in the peering network. 926 Although this option does not require any of the procedures described 927 in this document, it is added as baseline/default option for 928 completeness. This option is equivalent to VPLS as far as ARP/ND is 929 concerned. The options described in Section 5.2, Section 5.3 and 930 Section 5.4 are only possible in EVPN networks in combination with 931 their Proxy-ARP/ND capabilities. 933 5.2. Dynamic Learning with Proxy-ARP/ND 935 This scenario minimizes flooding while enabling dynamic learning of 936 IP->MAC entries. The Proxy-ARP/ND function is enabled in the BDs of 937 the EVPN PEs, so that the PEs snoop ARP/ND messages issued by the CEs 938 and respond to CE ARP-requests/NS messages. 940 PEs will flood requests if the entry is not in their Proxy table. 941 Any unknown source IP->MAC entries will be learned and advertised in 942 EVPN, and traffic to unknown entries is discarded at the ingress PE. 944 This scenario makes use of the Learning, Reply and Maintenance sub- 945 functions, with an optional use of the Unicast-forward and Duplicate 946 IP detection sub-functions. The Flood handling sub-function uses 947 default flooding for unknown ARP-Request/NS messages. 949 5.3. Hybrid Dynamic Learning and Static Provisioning with Proxy-ARP/ND 951 Some IXPs and other operators want to protect particular hosts on the 952 BD while allowing dynamic learning of CE addresses. For example, an 953 operator may want to configure static IP->MAC entries for management 954 and infrastructure hosts that provide critical services. In this 955 scenario, static entries are provisioned from the management plane 956 for protected IP->MAC addresses, and dynamic learning with Proxy-ARP/ 957 ND is enabled as described in Section 5.2 on the BD. 959 This scenario makes use of the same sub-functions as in Section 5.2, 960 but adding static entries added by the Learning sub-function. 962 5.4. All Static Provisioning with Proxy-ARP/ND 964 For a solution that maximizes security and eliminates flooding and 965 unknown unicast in the peering network, all IP->MAC entries are 966 provisioned from the management plane. The Proxy-ARP/ND function is 967 enabled in the BDs of the EVPN PEs, so that the PEs intercept and 968 respond to CE requests. Dynamic learning and ARP/ND snooping is 969 disabled so that ARP-Requests and NS to unknown IPs are discarded at 970 the ingress PE. This scenario provides an operator the most control 971 over IP->MAC entries and allows an operator to manage all entries 972 from a management system. 974 In this scenario, the Learning sub-function is limited to static 975 entries, the Maintenance sub-function will not require any procedures 976 due to the static entries, and the Flood handling sub-function will 977 completely suppress Unknown ARP-Requests/NS messages as well as GARP 978 and unsolicited-NA messages. 980 5.5. Example of Deployment in Internet Exchange Points 982 Nowadays, almost all IXPs install some security rules in order to 983 protect the peering network (BD). These rules are often called port 984 security. Port security summarizes different operational steps that 985 limit the access to the IXP-LAN and the customer router, and controls 986 the kind of traffic that the routers are allowed to exchange (e.g., 987 Ethernet, IPv4, IPv6). Due to this, the deployment scenario as 988 described in Section 5.4 "All Static Provisioning with Proxy-ARP/ND" 989 is the predominant scenario for IXPs. 991 In addition to the "All Static Provisioning" behavior, in IXP 992 networks it is recommended to configure the Reply Sub-Function to 993 'discard' ARP-Requests/NS messages with unrecognized options. 995 At IXPs, customers usually follow a certain operational life-cycle. 996 For each step of the operational life-cycle specific operational 997 procedures are executed. 999 The following describes the operational procedures that are needed to 1000 guarantee port security throughout the life-cycle of a customer with 1001 focus on EVPN features: 1003 1. A new customer is connected the first time to the IXP: 1005 Before the connection between the customer router and the IXP-LAN 1006 is activated, the MAC of the router is allow-listed on the IXP's 1007 switch port. All other MAC addresses are blocked. Pre-defined 1008 IPv4 and IPv6 addresses of the IXP peering network space are 1009 configured at the customer router. The IP->MAC static entries 1010 (IPv4 and IPv6) are configured in the management system of the 1011 IXP for the customer's port in order to support Proxy-ARP/ND. 1013 In case a customer uses multiple ports aggregated to a single 1014 logical port (LAG) some vendors randomly select the MAC address 1015 of the LAG from the different MAC addresses assigned to the 1016 ports. In this case the static entry will be used associated to 1017 a list of allowed MACs. 1019 2. Replacement of customer router: 1021 If a customer router is about to be replaced, the new MAC 1022 address(es) must be installed in the management system besides 1023 the MAC address(es) of the currently connected router. This 1024 allows the customer to replace the router without any active 1025 involvement of the IXP operator. For this, static entries are 1026 also used. After the replacement takes place, the MAC 1027 address(es) of the replaced router can be removed. 1029 3. Decommissioning a customer router 1031 If a customer router is decommissioned, the router is 1032 disconnected from the IXP PE. Right after that, the MAC 1033 address(es) of the router and IP->MAC bindings can be removed 1034 from the management system. 1036 5.6. Example of Deployment in Data Centers 1038 DCs normally have different requirements than IXPs in terms of Proxy- 1039 ARP/ND. Some differences are listed below: 1041 a. The required mobility in virtualized DCs makes the "Dynamic 1042 Learning" or "Hybrid Dynamic and Static Provisioning" models more 1043 appropriate than the "All Static Provisioning" model. 1045 b. IPv6 'anycast' may be required in DCs, while it is typically not 1046 a requirement in IXP networks. Therefore if the DC needs IPv6 1047 anycast addresses, the "anycast" capability will be explicitly 1048 enabled in the Proxy-ND function, hence the Proxy-ND sub- 1049 functions modified accordingly. For instance, if IPv6 'anycast' 1050 is enabled in the Proxy-ND function, the Duplicate IP Detection 1051 procedure in Section 3.7 must be disabled. 1053 c. DCs may require special options on ARP/ND as opposed to the 1054 address resolution function, which is the only one typically 1055 required in IXPs. Based on that, the Reply Sub-function may be 1056 modified to forward or discard unknown options. 1058 6. Security Considerations 1060 The security considerations of [RFC7432] and [RFC9047] apply to this 1061 document too. Note that EVPN does not inherently provide 1062 cryptographic protection (including confidentiality protection). 1064 The procedures in this document reduce the amount of ARP/ND message 1065 flooding, which in itself provides a protection to "slow path" 1066 software processors of routers and Tenant Systems in large BDs. The 1067 ARP/ND requests that are replied by the Proxy-ARP/ND function (hence 1068 not flooded) are normally targeted to existing hosts in the BD. ARP/ 1069 ND requests targeted to absent hosts are still normally flooded; 1070 however, the suppression of Unknown ARP-Requests and NS messages 1071 described in Section 3.6 can provide an additional level of security 1072 against ARP-Requests/NS messages issued to non-existing hosts. 1074 While the unicast-forward and/or flood suppression sub-functions 1075 provide an added security mechanism for the BD, they can also 1076 increase the risk of blocking the service for a CE if the EVPN PEs 1077 cannot provide the ARP/ND resolution that the CE needs. 1079 The solution also provides protection against Denial Of Service 1080 attacks that use ARP/ND-spoofing as a first step. The Duplicate IP 1081 Detection and the use of an AS-MAC as explained in Section 3.7 1082 protects the BD against ARP/ND spoofing. 1084 The Proxy-ARP/ND function specified in this document does not allow 1085 the learning of an IP address mapped to multiple MAC addresses in the 1086 same table, unless the "anycast" capability is enabled (and only in 1087 case of Proxy-ND). When "anycast" is enabled in the Proxy-ND 1088 function, the number of allowed entries for the same IP address MUST 1089 be limited by the operator to prevent DoS attacks that attempt to 1090 fill the Proxy-ND table with a significant number of entries for the 1091 same IP. 1093 The document provides some examples and guidelines that can be used 1094 by IXPs in their EVPN BDs. When EVPN and its associated Proxy-ARP/ND 1095 function are used in IXP networks, they provide ARP/ND security and 1096 mitigation. IXPs must still employ additional security mechanisms 1097 that protect the peering network as per the established BCPs such as 1098 the ones described in [Euro-IX-BCP]. For example, IXPs should 1099 disable all unneeded control protocols, and block unwanted protocols 1100 from CEs so that only IPv4, ARP and IPv6 Ethertypes are permitted on 1101 the peering network. In addition, port security features and ACLs 1102 can provide an additional level of security. 1104 Finally, it is worth noting that the Proxy-ARP/ND solution in this 1105 document will not work if there is a mechanism securing ARP/ND 1106 exchanges among CEs, because the PE is not able to secure the 1107 "proxied" ND messages. 1109 7. IANA Considerations 1111 No IANA considerations. 1113 8. Acknowledgments 1115 The authors want to thank Ranganathan Boovaraghavan, Sriram 1116 Venkateswaran, Manish Krishnan, Seshagiri Venugopal, Tony Przygienda, 1117 Robert Raszuk and Iftekhar Hussain for their review and 1118 contributions. Thank you to Oliver Knapp as well, for his detailed 1119 review. 1121 9. Contributors 1123 In addition to the authors listed on the front page, the following 1124 co-authors have also contributed to this document: 1126 Wim Henderickx 1127 Nokia 1129 Daniel Melzer 1130 DE-CIX Management GmbH 1132 Erik Nordmark 1133 Zededa 1135 10. References 1137 10.1. Normative References 1139 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 1140 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 1141 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 1142 2015, . 1144 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1145 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1146 DOI 10.17487/RFC4861, September 2007, 1147 . 1149 [RFC0826] Plummer, D., "An Ethernet Address Resolution Protocol: Or 1150 Converting Network Protocol Addresses to 48.bit Ethernet 1151 Address for Transmission on Ethernet Hardware", STD 37, 1152 RFC 826, DOI 10.17487/RFC0826, November 1982, 1153 . 1155 [RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227, 1156 DOI 10.17487/RFC5227, July 2008, 1157 . 1159 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1160 Requirement Levels", BCP 14, RFC 2119, 1161 DOI 10.17487/RFC2119, March 1997, 1162 . 1164 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1165 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1166 May 2017, . 1168 [RFC9047] Rabadan, J., Ed., Sathappan, S., Nagaraj, K., and W. Lin, 1169 "Propagation of ARP/ND Flags in an Ethernet Virtual 1170 Private Network (EVPN)", RFC 9047, DOI 10.17487/RFC9047, 1171 June 2021, . 1173 10.2. Informative References 1175 [Euro-IX-BCP] 1176 Euro-IX, "European Internet Exchange Association Best 1177 Practises - 1178 https://www.euro-ix.net/en/forixps/set-ixp/ixp-bcops/". 1180 [RFC6820] Narten, T., Karir, M., and I. Foo, "Address Resolution 1181 Problems in Large Data Center Networks", RFC 6820, 1182 DOI 10.17487/RFC6820, January 2013, 1183 . 1185 [RFC6957] Costa, F., Combes, J-M., Ed., Pougnard, X., and H. Li, 1186 "Duplicate Address Detection Proxy", RFC 6957, 1187 DOI 10.17487/RFC6957, June 2013, 1188 . 1190 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1191 Address Autoconfiguration", RFC 4862, 1192 DOI 10.17487/RFC4862, September 2007, 1193 . 1195 Authors' Addresses 1197 Jorge Rabadan (editor) 1198 Nokia 1199 777 Middlefield Road 1200 Mountain View, CA 94043 1201 USA 1203 Email: jorge.rabadan@nokia.com 1205 Senthil Sathappan 1206 Nokia 1207 701 E. Middlefield Road 1208 Mountain View, CA 94043 USA 1210 Email: senthil.sathappan@nokia.com 1212 Kiran Nagaraj 1213 Nokia 1214 701 E. Middlefield Road 1215 Mountain View, CA 94043 USA 1217 Email: kiran.nagaraj@nokia.com 1219 Greg Hankins 1220 Nokia 1222 Email: greg.hankins@nokia.com 1224 Thomas King 1225 DE-CIX Management GmbH 1227 Email: thomas.king@de-cix.net