idnits 2.17.1 draft-snr-bess-evpn-proxy-arp-nd-00.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 abstract seems to contain references ([RFC6820], [RFC7432]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 9, 2015) is 3335 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC7432' is mentioned on line 535, but not defined == Missing Reference: 'RFC6820' is mentioned on line 150, but not defined == Missing Reference: 'RFC4861' is mentioned on line 438, but not defined == Missing Reference: 'RFC5227' is mentioned on line 183, but not defined == Missing Reference: 'EVPN-NA-FLAGS' is mentioned on line 407, but not defined == Missing Reference: 'RFC2119' is mentioned on line 616, but not defined == Unused Reference: 'EVPN-ND-FLAGS' is defined on line 658, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-snr-bess-evpn-na-flags-00 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Workgroup J. Rabadan, Ed. 3 Internet Draft S. Sathappan 4 K. Nagaraj 5 Intended status: Informational W. Henderickx 6 Alcatel-Lucent 8 T. King 9 D. Melzer 10 DE-CIX 12 Expires: September 10, 2015 March 9, 2015 14 Proxy-ARP/ND function in EVPN networks 15 draft-snr-bess-evpn-proxy-arp-nd-00 17 Abstract 19 The MAC/IP Advertisement route specified in [RFC7432] can optionally 20 carry IPv4 and IPv6 addresses associated with a MAC address. Remote 21 PEs can use this information to reply locally (act as proxy) to IPv4 22 ARP requests and IPv6 Neighbor Solicitation messages and 23 reduce/suppress the flooding produced by the Address Resolution 24 procedure. This EVPN capability is extremely useful in Internet 25 Exchange Points (IXPs) with large broadcast domains, where the amount 26 of ARP/ND flooded traffic causes issues on routers and CEs, as 27 explained in [RFC6820]. This document describes how the [RFC7432] 28 EVPN proxy-ARP/ND function should be implemented to help IXPs and 29 other operators deal with the issues derived from Address Resolution 30 in large broadcast domains. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF), its areas, and its working groups. Note that 39 other groups may also distribute working documents as Internet- 40 Drafts. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." The list 46 of current Internet-Drafts can be accessed at 47 http://www.ietf.org/ietf/1id-abstracts.txt 49 The list of Internet-Draft Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html 52 This Internet-Draft will expire on September 10, 2015. 54 Copyright Notice 56 Copyright (c) 2015 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2.1. The IXP use-case . . . . . . . . . . . . . . . . . . . . . 4 74 3. Solution requirements . . . . . . . . . . . . . . . . . . . . . 5 75 4. Solution description . . . . . . . . . . . . . . . . . . . . . 5 76 4.1. Learning sub-function . . . . . . . . . . . . . . . . . . . 7 77 4.1.1. Proxy-ND and the NA Flags . . . . . . . . . . . . . . . 8 78 4.2. Reply sub-function . . . . . . . . . . . . . . . . . . . . 9 79 4.3. Maintenance sub-function . . . . . . . . . . . . . . . . . 10 80 4.4. Flooding (to remote PEs) reduction/suppression . . . . . . 11 81 4.5. Duplicate IP detection . . . . . . . . . . . . . . . . . . 12 82 5. Solution benefits . . . . . . . . . . . . . . . . . . . . . . . 13 83 6. Conventions used in this document . . . . . . . . . . . . . . . 13 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 14 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 87 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 88 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 89 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 92 1. Terminology 94 BUM: Broadcast, Unknown unicast and Multicast layer-2 traffic. 96 ARP: Address Resolution Protocol. 98 GARP: Gratuitous ARP message. 100 ND: Neighbor Discovery Protocol. 102 NS: Neighbor Solicitation message. 104 NA: Neighbor Advertisement. 106 IXP: Internet eXchange Point. 108 IP->MAC: refers to an IP address associated to a MAC address. The 109 entries may be of three different types: dynamic, static or EVPN- 110 learnt. 112 SN-multicast address: Refers to the Solicited-Node IPv6 multicast 113 address used by NS messages. 115 NUD: Neighbor Unreachability Detection, as per [RFC4861]. 117 DAD: Duplicate Address Detection, as per [RFC4861]. 119 SLLA: Source Link Layer Address, as per [RFC4861]. 121 TLLA: Target Link Layer Address, as per [RFC4861]. 123 R-bit: Router Flag in NA messages, as per [RFC4861]. 125 O-bit: Override Flag in NA messages, as per [RFC4861]. 127 S-bit: Solicited Flag in NA messages, as per [RFC4861]. 129 RT2: EVPN Route type 2 or MAC/IP Advertisement route, as per 130 [RFC7432]. 132 MAC or IP DA: MAC or IP Destination Address. 134 MAC or IP SA: MAC or IP Source Address. 136 AS-MAC: Anti-spoofing MAC. 138 2. Introduction 139 As specified in [RFC7432] the IP Address field in the MAC/IP 140 Advertisement route may optionally carry one of the IP addresses 141 associated with the MAC address. A PE may learn local IP->MAC pairs 142 and advertise them in EVPN MAC/IP routes. The remote PEs may add 143 those IP->MAC pairs to their Proxy-ARP/ND tables and reply to local 144 ARP requests or Neighbor Solicitations, reducing and even suppressing 145 in some cases the flooding in the EVPN network. 147 EVPN and its associated Proxy-ARP/ND function are extremely useful in 148 Data Centers (DCs) or Internet Exchange Points (IXPs) with large 149 broadcast domains, where the amount of ARP/ND flooded traffic causes 150 issues on routers and CEs. [RFC6820] describes the Address Resolution 151 problems in Large Data Center networks. 153 This document describes how the [RFC7432] proxy-ARP/ND function 154 should be implemented to help IXPs and other operators deal with the 155 issues derived from Address Resolution in large broadcast domains. 157 2.1. The IXP use-case 159 The implementation described in this document is especially useful in 160 IXP networks. 162 A typical IXP provides access to a large layer-2 peering network, 163 where (hundreds of) Internet routers are connected. This peering 164 network is transparent to the Customer Edge (CE) devices and 165 therefore floods any ARP request or NS messages to all the CEs in the 166 network. Unsolicited GARP and NA messages are flooded to all the CEs 167 too. 169 In these IXP networks, most of the CEs are typically peering routers 170 and roughly all the BUM traffic is originated by the ARP and ND 171 address resolution procedures. This ARP/ND BUM traffic causes 172 significant data volumes that reach every single router in the 173 peering network. Since the ARP/ND messages are processed in software 174 processors and they take high priority in the routers, heavy loads of 175 ARP/ND traffic can cause some routers to run out of resources. CEs 176 disappearing from the network may cause Address Resolution explosions 177 that can make a router with limited processing power fail to keep BGP 178 sessions running. 180 The issue may be better in IPv6 routers, since ND uses SN-multicast 181 address in NS messages, however ARP uses broadcast and has to be 182 processed by all the routers in the network. Some routers may also be 183 configured to broadcast periodic GARPs [RFC5227]. The amount of 184 ARP/ND flooded traffic grows exponentially with the number of IXP 185 participants, therefore the issue can only go worse as new CEs are 186 added. 188 In order to deal with this issue, IXPs have developed certain 189 solutions over the past years. One example is the ARP-Sponge daemon 190 [ARP-Sponge]. While these solutions may mitigate the issues of 191 Address Resolution in large broadcasts domains, EVPN provides new 192 more efficient possibilities to IXPs. EVPN and its proxy-ARP/ND 193 function may help solve the issue in a distributed and scalable way, 194 fully integrated with the PE network. 196 3. Solution requirements 198 The distributed EVPN proxy-ARP/ND function described in this document 199 SHOULD meet the following requirements: 201 o The solution SHOULD support the learning of the CE IP->MAC entries 202 on the EVPN PEs via the management, control or data planes. An 203 implementation SHOULD allow to intentionally enable or disable 204 those possible learning mechanisms. 206 o The solution MAY suppress completely the flooding of the ARP/ND 207 messages in the EVPN network, assuming that all the CE IP->MAC 208 addresses local to the PEs are known or provisioned on the PEs from 209 a management system. Note that in this case, the unknown unicast 210 traffic can also be suppressed, since all the expected unicast 211 traffic will be destined to known MAC addresses in the PE MAC-VRFs. 213 o The solution MAY reduce significantly the flooding of the ARP/ND 214 messages in the EVPN network, assuming that some or all the CE 215 IP->MAC addresses are learnt on the data plane by snooping ARP/ND 216 messages issued by the CEs. 218 o The solution MAY provide a way to refresh periodically the CE 219 IP->MAC entries learnt through the data plane, so that the IP->MAC 220 entries are not withdrawn by EVPN when they age out unless the CE 221 is not active anymore. This option helps reducing the EVPN control 222 plane overhead in a network with active CEs that do not send 223 packets frequently. 225 o The solution SHOULD provide a mechanism to detect duplicate IP 226 addresses. In case of duplication, the detecting PE should not 227 reply to requests for the duplicate IP. Instead, the PE should 228 alert the operator and may optionally prevent any other CE from 229 sending traffic to the duplicate IP. 231 4. Solution description 233 Figure 1 illustrates an example EVPN network where the Proxy-ARP/ND 234 function is enabled. 236 MAC-VRF1 237 Proxy-ARP/ND 238 +------------+ 239 IP1/M1 +----------------------------+ |IP1->M1 EVPN| 240 GARP --->Proxy-ARP/ND | |IP2->M2 EVPN| 241 +---+ +----+---+ RT2(IP1/M1) | |IP3->M3 sta | 242 |CE1+------+MAC-VRF1| ------> +------+---|IP4->M4 dyn | 243 +---+ +--------+ | +------------+ 244 PE1 | +--------+ Who has IP1? 245 | EVPN | |MAC-VRF1| <----- +---+ 246 | EVI1 | | | | |CE3| 247 IP2/M2 | | | | -----> +---+ 248 GARP --->Proxy-ARP/ND | +--------+ | IP1->M1 249 +---+ +--------+ RT2(IP2/M2) | | 250 |CE2+----+MAC-VRF1| ------> +--------------+ 251 +---+ +--------+ PE3| +---+ 252 PE2 | +----+CE4| 253 +----------------------------+ +---+ 254 <---IP4/M4 GARP 256 Figure 1 Proxy-ARP/ND network example 258 When the Proxy-ARP/ND function is enabled in the MAC-VRFs of the EVPN 259 PEs, each PE creates a Proxy table specific to that MAC-VRF that can 260 contain three types of Proxy-ARP/ND entries: 262 a) Dynamic entries: learnt by snooping CE's ARP and ND messages. For 263 instance, IP4->M4 in Figure 1. 265 b) Static entries: provisioned on the PE by the management system. 266 For instance, IP3->M3 in Figure 1. 268 c) EVPN-learnt entries: learnt from the IP/MAC information encoded in 269 the received RT2's coming from remote PEs. For instance, IP1->M1 270 and IP2->M2 in Figure 1. 272 As a high level example, the operation of the EVPN Proxy-ARP/ND 273 function in the network of Figure 1 is described below. In this 274 example we assume IP1, IP2 and IP3 are IPv4 addresses: 276 1. Proxy-ARP/ND is enabled in MAC-VRF1 of PE1, PE2 and PE3. 278 2. The PEs start adding dynamic, static and EVPN-learnt entries to 279 their Proxy tables: 281 a. PE3 adds IP1->M1 and IP2->M2 based on the EVPN routes received 282 from PE1 and PE2. Those entries were previously learnt as 283 dynamic entries in PE1 and PE2 respectively, and advertised in 284 BGP EVPN. 285 b. PE3 adds IP4->M4 as dynamic. This entry is learnt by snooping 286 the corresponding ARP messages sent by CE4. 287 c. An operator also provisions the static entry IP3->M3. 289 3. When CE3 sends an ARP Request asking for IP1, PE3 will: 291 a. Intercept the ARP Request and perform a Proxy-ARP lookup for 292 IP1. 293 b. If the lookup is successful (as in Figure 1), PE3 will send an 294 ARP Reply with IP1->M1. The ARP Request will not be flooded to 295 the EVPN network or any other local CEs. 296 c. If the lookup is not successful, PE3 will flood the ARP Request 297 in the EVPN network and the other local CEs. 299 As PE3 learns more and more host entries in the Proxy-ARP/ND table, 300 the flooding of ARP Request messages is reduced and in some cases it 301 can even be suppressed. In a network where most of the participant 302 CEs are not moving between PEs and they advertise their presence with 303 GARPs or unsolicited NA messages, the ARP/ND flooding as well as the 304 unknown unicast flooding can practically be suppressed. In an EVPN- 305 based IXP network, where all the entries are Static, the ARP/ND 306 flooding is in fact totally suppressed. 308 The Proxy-ARP/ND function can be structured in five sub-functions or 309 procedures: 311 1. Learning sub-function 312 2. Reply sub-function 313 3. Maintenance sub-function 314 4. Flooding reduction/suppression sub-function 315 5. Duplicate IP detection sub-function 317 A Proxy-ARP/ND implementation MAY support all those sub-functions or 318 only a subset of them. The following sections describe each 319 individual sub-function. 321 4.1. Learning sub-function 323 A Proxy-ARP/ND implementation SHOULD support static, dynamic and 324 EVPN-learnt entries. 326 Static entries are provisioned from the management plane. The 327 provisioned static IP->MAC entry SHOULD be advertised in EVPN with a 328 MAC Mobility extended community where the static flag is set to 1, as 329 per [RFC7432]. 331 EVPN-learnt entries MUST be learnt from received valid EVPN MAC/IP 332 Advertisement routes containing a MAC and IP address. 334 Dynamic entries are learnt in different ways depending on whether the 335 entry contains an IPv4 or IPv6 address: 337 a) Proxy-ARP dynamic entries: 339 They SHOULD be learnt by snooping any ARP packet (Ethertype 340 0x0806) received from the CEs attached to the MAC-VRF. The 341 Learning function will add the Sender MAC and Sender IP of the 342 snooped ARP packet to the Proxy-ARP table. 344 b) Proxy-ND dynamic entries: 346 They SHOULD be learnt out of the Target Address and TLLA 347 information in NA messages (Ethertype 0x86DD, ICMPv6 type 136) 348 received from the CEs attached to the MAC-VRF. A Proxy-ND 349 implementation SHOULD NOT learn IP->MAC entries from NS messages, 350 since they don't contain the R-bit Flag required by the Proxy-ND 351 reply function. See section 4.1.1 for more information about the 352 R-bit flag. 354 Note that if the O-bit is zero in the received NA message, the 355 IP->MAC SHOULD NOT be learnt. 357 The following procedure associated to the Learning sub-function is 358 recommended: 360 o When a new Proxy-ARP/ND EVPN or static active entry is learnt (or 361 provisioned) the PE SHOULD send an unsolicited GARP or NA message 362 to the access CEs. This makes sure the CE ARP/ND caches are updated 363 even if the ARP/NS/NA messages from remote CEs are not flooded in 364 the EVPN network. 366 Note that if a Static entry is provisioned with the same IP as an 367 existing EVPN-learnt or Dynamic entry, the Static entry takes 368 precedence. 370 4.1.1. Proxy-ND and the NA Flags 372 [RFC4861] describes the use of the R-bit flag in IPv6 Address 373 Resolution: 375 o Nodes capable of routing IPv6 packets must reply to NS messages 376 with NA messages where the R-bit flag is set (R-bit=1). 378 o Hosts that are not able to route IPv6 packets must indicate that 379 inability by replying with NA messages that contain R-bit=0. 381 The use of the R-bit flag in NA messages has an impact on how hosts 382 select their default gateways when sending packets off-link: 384 o Hosts build a Default Router List based on the received RAs and NAs 385 with R-bit=1. Each cache entry has an IsRouter flag, which must be 386 set based on the R-bit flag in the received NAs. A host can choose 387 one or more Default Routers when sending packets off-link. 389 o In those cases where the IsRouter flag changes from TRUE to FALSE 390 as a result of a NA update, the node MUST remove that router from 391 the Default Router List and update the Destination Cache entries 392 for all destinations using that neighbor as a router, as specified 393 in [RFC4861] section 7.3.3. This is needed to detect when a node 394 that is used as a router stops forwarding packets due to being 395 configured as a host. 397 The R-bit will be learnt in the following ways: 399 o Static entries SHOULD have the R-bit information added by the 400 management interface. 402 o Dynamic entries SHOULD learn the R-bit from the snooped NA messages 403 used to learn the IP->MAC itself. 405 o EVPN-learnt entries SHOULD learn the R-bit from the ND Extended 406 Community received from EVPN along with the RT2 used to learn the 407 IP->MAC itself. Please refer to [EVPN-NA-FLAGS]. If no ND extended 408 community is received, the PE will add the default R-bit to the 409 entry. The default R-bit SHOULD be an administrative choice. 411 4.2. Reply sub-function 413 This sub-function will reply to Address Resolution 414 requests/solicitations upon successful lookup in the Proxy-ARP/ND 415 table for a given IP address. The following considerations should 416 be taken into account: 418 a) When replying to ARP Request or NS messages, the PE SHOULD use the 419 Proxy-ARP/ND entry MAC address as MAC SA. This is recommended so 420 that the resolved MAC can be learnt in the MAC FIB of potential 421 Layer-2 switches seating between the PE and the CE requesting the 422 Address Resolution. 424 b) A PE SHOULD NOT reply to a request/solicitation received on the 425 same attachment circuit over which the IP->MAC is learnt. In this 426 case the requester and the requested IP are assumed to be 427 connected to the same layer-2 switch/access network linked to the 428 PE's attachment circuit, and therefore the requested IP owner will 429 receive the request directly. 431 c) A PE SHOULD reply to broadcast/multicast Address Resolution 432 messages, that is, ARP-Request, NS messages as well as DAD NS 433 messages. A PE SHOULD NOT reply to unicast Address Resolution 434 requests (for instance, NUD NS messages). 436 d) A PE SHOULD include the R-bit learnt for the IP->MAC entry in the 437 NA messages (see section 4.1.1). The S-bit and O-bit will be 438 set/unset as per [RFC4861]. 440 4.3. Maintenance sub-function 442 The Proxy-ARP/ND tables SHOULD follow a number of maintenance 443 procedures so that the dynamic IP->MAC entries are kept if the owner 444 is active and flushed if the owner is no longer in the network. The 445 following procedures are recommended: 447 a) Age-time 449 A dynamic Proxy-ARP/ND entry SHOULD be flushed out of the table if 450 the IP->MAC has not been refreshed within a given age-time. The 451 entry is refreshed if an ARP or NA message is received for the 452 same IP->MAC entry. The age-time is an administrative option. 454 b) Send-refresh option 456 The PE MAY send periodic refresh messages (ARP/ND "probes") to the 457 owners of the dynamic Proxy-ARP/ND entries, so that the entries 458 can be refreshed before they age out. The owner of the IP->MAC 459 entry would reply to the ARP/ND probe and the corresponding entry 460 age-time reset. The periodic send-refresh timer is an 461 administrative option and is recommended to be a third of the age- 462 time or a half of the age-time in scaled networks. 464 An ARP refresh issued by the PE will be an ARP-Request message 465 with the Sender's IP = 0 sent from the PE's MAC SA. An ND refresh 466 will be a NS message issued from the PE's MAC SA and a Link Local 467 Address associated to the PE's MAC. 469 The refresh request messages should be sent only for dynamic 470 entries and not for static or EVPN-learnt entries. Even though the 471 refresh request messages are broadcast or multicast, the PE SHOULD 472 only send the message to the attachment circuit associated to the 473 MAC in the IP->MAC entry. 475 The age-time and send-refresh options are used in EVPN networks to 476 avoid unnecessary EVPN RT2 withdrawals: if refresh messages are sent 477 before the corresponding MAC-VRF FIB and Proxy-ARP/ND age-time for a 478 given entry expires, inactive but existing hosts will reply, 479 refreshing the entry and therefore avoiding unnecessary MAC and MAC- 480 IP withdrawals in EVPN. Both entries (MAC in the MAC-VRF and IP->MAC 481 in Proxy-ARP/ND) are reset when the owner replies to the ARP/ND 482 probe. If there is no response to the ARP/ND probe, the MAC and 483 IP->MAC entries will be legitimately flushed and the RT2s withdrawn. 485 4.4. Flooding (to remote PEs) reduction/suppression 487 The Proxy-ARP/ND function implicitly helps reducing the flooding of 488 ARP Request and NS messages to remote PEs in an EVPN network. 489 However, in certain use-cases, the flooding of ARP/NS/NA messages 490 (and even the unknown unicast flooding) to remote PEs can be 491 suppressed completely in an EVPN network. 493 For instance, in an IXP network, since all the participant CEs are 494 well known and will not move to a different PE, the IP->MAC entries 495 may be all provisioned by a management system. Assuming the entries 496 for the CEs are all provisioned on the local PE, a given Proxy-ARP/ND 497 table will only contain static and EVPN-learnt entries. In this case, 498 the operator may choose to suppress the flooding of ARP/NS/NA to 499 remote PEs completely. 501 The flooding may also be suppressed completely in IXP networks with 502 dynamic Proxy-ARP/ND entries assuming that all the CEs are directly 503 connected to the PEs and they all advertise their presence with a 504 GARP/unsolicited-NA when they connect to the network. 506 In networks where fast mobility is expected, it is not recommended to 507 suppress the flooding of unknown ARP-Requests/NS or 508 GARPs/unsolicited-NAs. 510 In order to give the operator the choice to suppress/allow the 511 flooding to remote PEs, a PE MAY support administrative options to 512 individually suppress/allow the flooding of: 514 o Unknown ARP-Request and NS messages (unknown means that the lookups 515 for the requested IPs do not succeed). o GARP and unsolicited-NA 516 messages. 518 The operator will use these options based on the expected behavior in 519 the CEs. 521 4.5. Duplicate IP detection 523 The Proxy-ARP/ND function SHOULD support duplicate IP detection so 524 that ARP/ND-spoofing attacks or duplicate IPs due to human errors can 525 be detected. 527 ARP/ND spoofing is a technique whereby an attacker sends "fake" 528 ARP/ND messages onto a broadcast domain. Generally the aim is to 529 associate the attacker's MAC address with the IP address of another 530 host causing any traffic meant for that IP address to be sent to the 531 attacker instead. 533 The distributed nature of EVPN and proxy-ARP/ND allows the easy 534 detection of duplicated IPs in the network, in a similar way to the 535 MAC duplication function supported by [RFC7432] for MAC addresses. 537 Duplicate IP detection monitors "IP-moves" in the Proxy-ARP/ND table 538 in the following way: 540 o When a new active IP1->MAC1 entry is learnt, a PE starts an 541 M-second timer (default value of M=180), and if it detects N IP 542 moves before the timer expires (default value of N=5), it concludes 543 that a duplicate IP situation has occurred. An IP move is 544 considered when, for instance, IP1->MAC1 is replaced by IP1->MAC2 545 in the Proxy-ARP/ND table. 547 o In order to detect the duplicate IP faster, the PE MAY send a 548 CONFIRM message to the former owner of the IP. If the PE does not 549 receive an answer within a given timer, the new entry will be 550 confirmed and activated. For instance, if IP1->MAC1 moves to 551 IP1->MAC2, the PE may send a unicast ARP-Request/NS message for IP1 552 with MAC DA= MAC1 and MAC SA= PE's MAC. This will force the 553 legitimate owner and the spoofer to reply so that the PE can detect 554 the duplicate IP within the M timer. 556 o Upon detecting a duplicate IP situation: 558 a) The entry in duplicate detected state cannot be updated with new 559 dynamic or EVPN-learnt entries for the same IP. The operator MAY 560 override the entry though with a static IP->MAC. 562 b) The PE SHOULD alert the operator and stop responding ARP/NS for 563 the duplicate IP until a corrective action is taken. 565 c) Optionally the PE MAY associate an "anti-spoofing-mac" (AS-MAC) 566 to the duplicate IP. The PE will send a GARP/unsolicited-NA 567 message with IP1->AS-MAC to the local CEs as well as an RT2 568 (with IP1->AS-MAC as well) to the remote PEs. This will force 569 all the CEs in the EVI to use the AS-MAC as MAC DA for IP1, and 570 prevent the spoofer from attracting any traffic for IP1. Since 571 the AS-MAC is a managed MAC address known by all the PEs in the 572 EVI, all the PEs MAY apply filters to drop/log any frame with 573 MAC DA= AS-MAC. The advertisement of the AS-MAC as a "black-hole 574 MAC" that can be used directly in the MAC-VRF to drop frames is 575 for further study. 577 o The duplicate IP situation will be cleared when a corrective action 578 is taken by the operator, or alternatively after a HOLD-DOWN timer 579 (default value of 540 seconds). 581 The values of M, N and HOLD-DOWN timer SHOULD be a configurable 582 administrative option to allow for the required flexibility in 583 different scenarios. 585 For Proxy-ND, Duplicate IP Detection SHOULD only monitor IP moves for 586 IP->MACs learnt from NA messages with O-bit=1. NA messages with 587 O-bit=0 would not override the ND cache entries for an existing IP. 589 5. Solution benefits 591 The solution described in this document provides the following 592 benefits: 594 a) The solution may suppress completely the flooding of the ARP/ND 595 and unknown-unicast messages in the EVPN network, in cases where 596 all the CE IP->MAC addresses local to the PEs are known and 597 provisioned on the PEs from a management system. 599 b) The solution reduces significantly the flooding of the ARP/ND 600 messages in the EVPN network, in cases where some or all the CE 601 IP->MAC addresses are learnt on the data plane by snooping ARP/ND 602 messages issued by the CEs. 604 c) The solution reduces the control plane overhead and unnecessary 605 BGP MAC/IP Advertisements and Withdrawals in a network with active 606 CEs that do not send packets frequently. 608 d) The solution provides a mechanism to detect duplicate IP addresses 609 and avoid ARP/ND-spoof attacks or the effects of duplicate 610 addresses due to human errors. 612 6. Conventions used in this document 613 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 614 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 615 document are to be interpreted as described in RFC-2119 [RFC2119]. 617 In this document, these words will appear with that interpretation 618 only when in ALL CAPS. Lower case uses of these words are not to be 619 interpreted as carrying RFC-2119 significance. 621 In this document, the characters ">>" preceding an indented line(s) 622 indicates a compliance requirement statement using the key words 623 listed above. This convention aids reviewers in quickly identifying 624 or finding the explicit compliance requirements of this RFC. 626 7. Security Considerations 628 They will be added in future revisions. 630 8. IANA Considerations 632 9. References 634 9.1. Normative References 636 [RFC7432]Sajassi A., Aggarwal R. et al, "BGP MPLS-Based Ethernet 637 VPN", RFC 7432, February 2015, . 640 [RFC4861]Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 641 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 642 2007, . 644 [RFC6820]Narten, T., Karir, M., and I. Foo, "Address Resolution 645 Problems in Large Data Center Networks", RFC 6820, January 2013, 646 . 648 [RFC7342]Dunbar, L., Kumari, W., and I. Gashinsky, "Practices for 649 Scaling ARP and Neighbor Discovery (ND) in Large Data Centers", 650 RFC 7342, August 2014, . 652 9.2. Informative References 654 [ARP-Sponge] Wessel M. and Sijm N., Universiteit van Amsterdam, 655 "Effects of IPv4 and IPv6 address resolution on AMS-IX and the ARP 656 Sponge", July 2009. 658 [EVPN-ND-FLAGS] Sathappan S., Nagaraj K. and Rabadan J., "Propagation 659 of IPv6 Neighbor Advertisement Flags in EVPN", draft-snr-bess-evpn- 660 na-flags-00, Work in Progress, March 2015. 662 10. Acknowledgments 664 The authors want to thank Ranganathan Boovaraghavan, Sriram 665 Venkateswaran, Manish Krishnan and Seshagiri Venugopal for their 666 review and contributions. Thank you to Oliver Knapp as well, for his 667 detailed review. 669 Authors' Addresses 671 Jorge Rabadan (Editor) 672 Alcatel-Lucent 673 777 E. Middlefield Road 674 Mountain View, CA 94043 USA 675 Email: jorge.rabadan@alcatel-lucent.com 677 Senthil Sathappan 678 Alcatel-Lucent 679 Email: senthil.sathappan@alcatel-lucent.com 681 Kiran Nagaraj 682 Alcatel-Lucent 683 Email: kiran.nagaraj@alcatel-lucent.com 685 Wim Henderickx 686 Alcatel-Lucent 687 Email: wim.henderickx@alcatel-lucent.com 689 Thomas King 690 DE-CIX 691 Email: thomas.king@de-cix.net 693 Daniel Melzer 694 DE-CIX 695 Email: daniel.melzer@de-cix.net