ARP:

Address Resolution Protocol

AS-MAC:

Anti-spoofing MAC. It is a special MAC configured on all the PEs attached to the same BD and used for the duplicate IP detection procedures.

BD:

Broadcast Domain

BUM:

Broadcast, Unknown Unicast, and Multicast Layer 2 traffic

CE:

Customer Edge router

DAD:

Duplicate Address Detection, as per [RFC 4861]

DC:

Data Center

EVI:

EVPN Instance

EVPN:

Ethernet Virtual Private Network, as per [RFC 7432]

GARP:

Gratuitous ARP

IP->MAC:

An IP address associated to a MAC address. IP->MAC entries are programmed in Proxy ARP/ND tables and may be of three different types: dynamic, static, or EVPN-learned.

IXP:

Internet Exchange Point

IXP-LAN:

The IXP's large Broadcast Domain to where Internet routers are connected.

LAG:

Link Aggregation Group

MAC or IP DA:

MAC or IP Destination Address

MAC or IP SA:

MAC or IP Source Address

ND:

Neighbor Discovery

NS:

Neighbor Solicitation

NA:

Neighbor Advertisement

NUD:

Neighbor Unreachability Detection, as per [RFC 4861]

O Flag:

Override Flag in NA messages, as per [RFC 4861]

PE:

Provider Edge router

R Flag:

Router Flag in NA messages, as per [RFC 4861]

RT2:

EVPN Route type 2 or EVPN MAC/IP Advertisement route, as per [RFC 7432]

S Flag:

Solicited Flag in NA messages, as per [RFC 4861]

SN-multicast address:

Solicited-Node IPv6 multicast address used by NS messages

TLLA:

Target Link Layer Address, as per [RFC 4861]

VPLS:

Virtual Private LAN Service

                                                      BD1
                                                  Proxy ARP/ND
                                                 +------------+
IP1/M1          +----------------------------+   |IP1->M1 EVPN|
 GARP --->Proxy ARP/ND                       |   |IP2->M2 EVPN|
+---+      +--------+   RT2(IP1/M1)          |   |IP3->M3 sta |
|CE1+------|   BD1  |    ------>      +------+---|IP4->M4 dyn |
+---+      +--------+                 |          +------------+
               PE1                    | +--------+ Who has IP1?
                |           EVPN      | |   BD1  | <-----  +---+
                |           EVI1      | |        | ----->  |CE3|
IP2/M2          |                     | |        | IP1->M1 +---+
 GARP  --->Proxy ARP/ND               | +--------+   |    IP3/M3
  +---+    +--------+   RT2(IP2/M2)   |              |
  |CE2+----|   BD1  |    ------>      +--------------+
  +---+    +--------+                       PE3|    +---+
               PE2                           | +----+CE4|
                +----------------------------+      +---+
                                              <---IP4/M4 GARP

Dynamic entries:

Learned by snooping a CE's ARP and ND messages; for instance, see IP4->M4 in Figure 1.

Static entries:

Provisioned on the PE by the management system; for instance, see IP3->M3 in Figure 1.

EVPN-learned entries:

Learned from the IP/MAC information encoded in the received RT2's coming from remote PEs; for instance, see IP1->M1 and IP2->M2 in Figure 1.

1. Proxy ARP/ND is enabled in BD1 of PE1, PE2, and PE3.
2. The PEs start adding dynamic, static, and EVPN-learned entries to their Proxy tables:
   1. PE3 adds IP1->M1 and IP2->M2 based on the EVPN routes received from PE1 and PE2. Those entries were previously learned as dynamic entries in PE1 and PE2, respectively, and advertised in BGP EVPN.
   2. PE3 adds IP4->M4 as dynamic. This entry is learned by snooping the corresponding ARP messages sent by CE4.
   3. An operator also provisions the static entry IP3->M3.
3. When CE3 sends an ARP Request asking for the MAC address of IP1, PE3 will:
   1. Intercept the ARP Request and perform a Proxy ARP lookup for IP1.
   2. If the lookup is successful (as in Figure 1), PE3 will send an ARP Reply with IP1->M1. The ARP Request will not be flooded to the EVPN network or any other local CEs.
   3. If the lookup is not successful, PE3 will flood the ARP Request in the EVPN network and the other local CEs.

1. PEs will start adding entries in a similar way as they would for IPv4; however, there are some differences:
   1. IP1->M1 and IP2->M2 are learned as dynamic entries in PE1 and PE2, respectively, by snooping NA messages and not by snooping NS messages. In the IPv4 case, any ARP frame can be snooped to learn the dynamic Proxy ARP entry. When learning the dynamic entries, the R and O Flags contained in the snooped NA messages will be added to the Proxy ND entries too.
   2. PE1 and PE2 will advertise those entries in EVPN MAC/IP Advertisement routes, including the corresponding learned R and O Flags in the ARP/ND Extended Community.
   3. PE3 also adds IP4->M4 as dynamic after snooping an NA message sent by CE4.
2. When CE3 sends an NS message asking for the MAC address of IP1, PE3 behaves as in the IPv4 example, by intercepting the NS, performing a lookup on the IP, and replying with an NA if the lookup is successful. If it is successful, the NS is not flooded to the EVPN PEs or any other local CEs.
3. If the lookup is not successful, PE3 will flood the NS to remote EVPN PEs attached to the same BD and the other local CEs as in the IPv4 case.

1. Learning sub-function
2. Reply sub-function
3. Unicast-forward sub-function
4. Maintenance sub-function
5. Flood handling sub-function
6. Duplicate IP detection sub-function

Proxy ARP dynamic entries:

The PE MUST snoop all ARP packets (that is, all frames with Ethertype 0x0806) received from the CEs attached to the BD in order to learn dynamic entries. ARP packets received from remote EVPN PEs attached to the same BD are not snooped. The Learning function will add the sender MAC and sender IP of the snooped ARP packet to the Proxy ARP table. Note that a MAC or an IP address with value 0 SHOULD NOT be learned.

Proxy ND dynamic entries:

The PE MUST snoop the NA messages (Ethertype 0x86dd, ICMPv6 type 136) received from the CEs attached to the BD and learn dynamic entries from the Target Address and TLLA information. NA messages received from remote EVPN PEs are not snooped. A PE implementing Proxy ND as in this document MUST NOT create dynamic IP->MAC entries from NS messages because they don't contain the R Flag required by the Proxy ND reply function. See Section 3.2.1 for more information about the R Flag.

This document specifies an "anycast" capability that can be configured for the Proxy ND function of the PE and affects how dynamic Proxy ND entries are learned based on the O Flag of the snooped NA messages. If the O Flag is zero in the received NA message, the IP->MAC SHOULD only be learned in case the IPv6 "anycast" capability is enabled in the BD. Irrespective, an NA message with O Flag = 0 will be normally forwarded by the PE based on a MAC DA lookup.

• When a new Proxy ARP/ND EVPN or static active entry is learned (or provisioned), the PE SHOULD send a GARP or unsolicited-NA message to all the connected access CEs. The PE SHOULD send a GARP or unsolicited-NA message for dynamic entries only if the ARP/NA message that previously created the entry on the PE was NOT flooded to all the local connected CEs before. This GARP/unsolicited-NA message makes sure the CE ARP/ND caches are updated even if the ARP/NS/NA messages from CEs connected to remote PEs are not flooded in the EVPN network.

• Nodes capable of routing IPv6 packets must reply to NS messages with NA messages where the R Flag is set (R Flag = 1).
• Hosts that are not able to route IPv6 packets must indicate that inability by replying with NA messages that contain R Flag = 0.

• Hosts build a Default Router List based on the received RAs and NAs with R Flag = 1. Each cache entry has an IsRouter flag, which must be set for received RAs and is set based on the R Flag in the received NAs. A host can choose one or more Default Routers when sending packets off-link.
• In those cases where the IsRouter flag changes from TRUE to FALSE as a result of an NA update, the node must remove that router from the Default Router List and update the Destination Cache entries for all destinations using that neighbor as a router, as specified in Section 7.3.3 of RFC 4861. This is needed to detect when a node that is used as a router stops forwarding packets due to being configured as a host.

• The R Flag information SHOULD be added to the static entries by the management interface. The O Flag information MAY also be added by the management interface. If the R and O Flags are not configured, the default value is 1.
• Dynamic entries SHOULD learn the R Flag and MAY learn the O Flag from the snooped NA messages used to learn the IP->MAC itself.
• EVPN-learned entries SHOULD learn the R Flag and MAY learn the O Flag from the ARP/ND Extended Community [RFC 9047] received from EVPN along with the RT2 used to learn the IP->MAC itself. If no ARP/ND Extended Community is received, the PE will add a configured R Flag / O Flag to the entry. These configured R and O Flags MAY be an administrative choice with a default value of 1. The configuration of this administrative choice provides a backwards-compatible option with EVPN PEs that follow [RFC 7432] but do not support this specification.

1. When replying to ARP Requests or NS messages:
   • The PE SHOULD use the Proxy ARP/ND entry MAC address MAC1 as MAC SA. This is RECOMMENDED so that the resolved MAC can be learned in the MAC forwarding database of potential Layer 2 switches sitting between the PE and the CE requesting the address resolution.
   • For an ARP reply, the PE MUST use the Proxy ARP entry IP1 and MAC1 addresses in the sender Protocol Address and Hardware Address fields, respectively.
   • For an NA message in response to an address resolution NS or DAD NS, the PE MUST use IP1 as the IP SA and Target Address. M1 MUST be used as the Target Link Local Address (TLLA).
2. A PE SHOULD NOT reply to a request/solicitation received on the same attachment circuit over which the IP->MAC is learned. In this case, the requester and the requested IP are assumed to be connected to the same Layer 2 CE/access network linked to the PE's attachment circuit; therefore, the requested IP owner will receive the request directly.
3. A PE SHOULD reply to broadcast/multicast address resolution messages, i.e., ARP Requests, ARP probes, NS messages, as well as DAD NS messages. An ARP probe is an ARP Request constructed with an all-zero sender IP address that may be used by hosts for IPv4 Address Conflict Detection as specified in [RFC 5227]. A PE SHOULD NOT reply to unicast address resolution requests (for instance, NUD NS messages).
4. When replying to an NS, a PE SHOULD set the Flags in the NA messages as follows:
   • The R bit is set as it was learned for the IP->MAC entry in the NA messages that created the entry (see Section 3.2.1).
   • The S Flag will be set/unset as per [RFC 4861].
   • The O Flag will be set in all the NA messages issued by the PE except in the case in which the BD is configured with the "anycast" capability and the entry was previously learned with O = 0. If "anycast" is enabled and there is more than one MAC for a given IP in the Proxy ND table, the PE will reply to NS messages with as many NA responses as "anycast" entries there are in the Proxy ND table.
5. For Proxy ARP, a PE MUST only reply to ARP Requests with the format specified in [RFC 0826].
6. For Proxy ND, a PE MUST reply to NS messages with known options with the format and options specified in [RFC 4861] and MAY reply, discard, forward, or unicast-forward NS messages containing other options. An administrative choice to control the behavior for received NS messages with unknown options ("reply", "discard", "unicast-forward", or "forward") MAY be supported.
   • The "reply" option implies that the PE ignores the unknown options and replies with NA messages, assuming a successful lookup on the Proxy ND table. An unsuccessful lookup will result in a "forward" behavior (i.e., flood the NS message based on the MAC DA).
   • If "discard" is available, the operator should assess if flooding NS unknown options may be a security risk for the EVPN BD (and if so, enable "discard") or, on the contrary, if not forwarding/flooding NS unknown options may disrupt connectivity. This option discards NS messages with unknown options irrespective of the result of the lookup on the Proxy ND table.
   • The "unicast-forward" option is described in Section 3.4.
   • The "forward" option implies flooding the NS message based on the MAC DA. This option forwards NS messages with unknown options irrespective of the result of the lookup on the Proxy ND table. The "forward" option is RECOMMENDED by this document.

1. unicast-forward always
2. unicast-forward unknown-options

Age-time:

A dynamic Proxy ARP/ND entry MUST be flushed out of the table if the IP->MAC has not been refreshed within a given age-time. The entry is refreshed if an ARP or NA message is received for the same IP->MAC entry. The age-time is an administrative option, and its value should be carefully chosen depending on the specific use case; in IXP networks (where the CE routers are fairly static), the age-time may normally be longer than in DC networks (where mobility is required).

Send-refresh option:

The PE MAY send periodic refresh messages (ARP/ND "probes") to the owners of the dynamic Proxy ARP/ND entries, so that the entries can be refreshed before they age out. The owner of the IP->MAC entry would reply to the ARP/ND probe and the corresponding entry age-time reset. The periodic send-refresh timer is an administrative option and is RECOMMENDED to be a third of the age-time or a half of the age-time in scaled networks.

An ARP refresh issued by the PE will be an ARP Request message with the sender's IP = 0 sent from the PE's MAC SA. If the PE has an IP address in the subnet, for instance, on an Integrated Routing and Bridging (IRB) interface, then it MAY use it as a source for the ARP Request (instead of sender's IP = 0). An ND refresh will be an NS message issued from the PE's MAC SA and a Link Local Address associated to the PE's MAC.

The refresh request messages SHOULD be sent only for dynamic entries and not for static or EVPN-learned entries. Even though the refresh request messages are broadcast or multicast, the PE SHOULD only send the message to the attachment circuit associated to the MAC in the IP->MAC entry.

• Unknown ARP Requests and NS messages.
• GARP and unsolicited-NA messages.

1. When an existing active IP1->MAC1 entry is modified, a PE starts an M-second timer (default value of M = 180), and if it detects N IP moves before the timer expires (default value of N = g5), it concludes that a duplicate IP situation has occurred. An IP move is considered when, for instance, IP1->MAC1 is replaced by IP1->MAC2 in the Proxy ARP/ND table. Static IP->MAC entries, i.e., locally provisioned or EVPN-learned entries with I = 1 in the ARP/ND Extended Community, are not subject to this procedure. Static entries MUST NOT be overridden by dynamic Proxy ARP/ND entries.
2. In order to detect the duplicate IP faster, the PE SHOULD send a Confirm message to the former owner of the IP. A Confirm message is a unicast ARP Request / NS message sent by the PE to the MAC addresses that previously owned the IP, when the MAC changes in the Proxy ARP/ND table. The Confirm message uses a sender's IP 0.0.0.0 in case of ARP (if the PE has an IP address in the subnet, then it MAY use it) and an IPv6 Link Local Address in case of NS. If the PE does not receive an answer within a given time, the new entry will be confirmed and activated. The default RECOMMENDED time to receive the confirmation is 30 seconds. In case of spoofing, for instance, if IP1->MAC1 moves to IP1->MAC2, the PE may send a unicast ARP Request / NS message for IP1 with MAC DA = MAC1 and MAC SA = PE's MAC. This will force the legitimate owner to respond if the move to MAC2 was spoofed and make the PE issue another Confirm message, this time to MAC DA = MAC2. If both, the legitimate owner and spoofer keep replying to the Confirm message. The PE would then detect the duplicate IP within the M-second timer, and a response would be triggered as follows:
   • If the IP1->MAC1 pair was previously owned by the spoofer and the new IP1->MAC2 was from a valid CE, then the issued Confirm message would trigger a response from the spoofer.
   • If it were the other way around, that is, IP1->MAC1 was previously owned by a valid CE, the Confirm message would trigger a response from the CE.
   • Either way, if this process continues, then duplicate detection will kick in.
3. Upon detecting a duplicate IP situation:
   1. The entry in duplicate detected state cannot be updated with new dynamic or EVPN-learned entries for the same IP. The operator MAY override the entry, though, with a static IP->MAC.
   2. The PE SHOULD alert the operator and stop responding to ARP/NS for the duplicate IP until a corrective action is taken.
   3. Optionally, the PE MAY associate an "anti-spoofing-mac" (AS-MAC) to the duplicate IP in the Proxy ARP/ND table. The PE will send a GARP/unsolicited-NA message with IP1->AS-MAC to the local CEs as well as an RT2 (with IP1->AS-MAC) to the remote PEs. This will update the ARP/ND caches on all the CEs in the BD; hence, all the CEs in the BD will use the AS-MAC as MAC DA when sending traffic to IP1. This procedure prevents the spoofer from attracting any traffic for IP1. Since the AS-MAC is a managed MAC address known by all the PEs in the BD, all the PEs MAY apply filters to drop and/or log any frame with MAC DA = AS-MAC. The advertisement of the AS-MAC as a "drop-MAC" (by using an indication in the RT2) that can be used directly in the BD to drop frames is for further study.
4. The duplicate IP situation will be cleared when a corrective action is taken by the operator or, alternatively, after a HOLD-DOWN timer (default value of 540 seconds).

1. May completely suppress the flooding of the ARP/ND messages in the EVPN network, assuming that all the CE IP->MAC addresses local to the PEs are known or provisioned on the PEs from a management system. Note that in this case, the unknown unicast flooded traffic can also be suppressed, since all the expected unicast traffic will be destined to known MAC addresses in the PE BDs.
2. Significantly reduces the flooding of the ARP/ND messages in the EVPN network, assuming that some or all the CE IP->MAC addresses are learned on the data plane by snooping ARP/ND messages issued by the CEs.
3. Provides a way to refresh periodically the CE IP->MAC entries learned through the data plane so that the IP->MAC entries are not withdrawn by EVPN when they age out unless the CE is not active anymore. This option helps reducing the EVPN control plane overhead in a network with active CEs that do not send packets frequently.
4. Provides a mechanism to detect duplicate IP addresses and avoid ARP/ND-spoof attacks or the effects of duplicate addresses due to human errors.

1. A new customer is connected the first time to the IXP: Before the connection between the customer router and the IXP-LAN is activated, the MAC of the router is allowlisted on the IXP's switch port. All other MAC addresses are blocked. Pre-defined IPv4 and IPv6 addresses of the IXP peering network space are configured at the customer router. The IP->MAC static entries (IPv4 and IPv6) are configured in the management system of the IXP for the customer's port in order to support Proxy ARP/ND. In case a customer uses multiple ports aggregated to a single logical port (LAG), some vendors randomly select the MAC address of the LAG from the different MAC addresses assigned to the ports. In this case, the static entry will be used and associated to a list of allowed MACs.
2. Replacement of customer router: If a customer router is about to be replaced, the new MAC address(es) must be installed in the management system in addition to the MAC address(es) of the currently connected router. This allows the customer to replace the router without any active involvement of the IXP operator. For this, static entries are also used. After the replacement takes place, the MAC address(es) of the replaced router can be removed.
3. Decommissioning a customer router: If a customer router is decommissioned, the router is disconnected from the IXP PE. Right after that, the MAC address(es) of the router and IP->MAC bindings can be removed from the management system.

1. The required mobility in virtualized DCs makes the "Dynamic Learning" or "Hybrid Dynamic and Static Provisioning" models more appropriate than the "All Static Provisioning" model.
2. IPv6 "anycast" may be required in DCs, while it is typically not a requirement in IXP networks. Therefore, if the DC needs IPv6 anycast addresses, the "anycast" capability will be explicitly enabled in the Proxy ND function and hence the Proxy ND sub-functions modified accordingly. For instance, if IPv6 "anycast" is enabled in the Proxy ND function, the duplicate IP detection procedure in Section 3.7 must be disabled.
3. DCs may require special options on ARP/ND as opposed to the address resolution function, which is the only one typically required in IXPs. Based on that, the Reply sub-function may be modified to forward or discard unknown options.

[RFC0826]

D. Plummer, "An Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, DOI 10.17487/RFC0826, November 1982,
<https://www.rfc-editor.org/info/rfc826>.

[RFC2119]

S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC4861]

T. Narten, E. Nordmark, W. Simpson, and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.

[RFC5227]

S. Cheshire, "IPv4 Address Conflict Detection", RFC 5227, DOI 10.17487/RFC5227, July 2008,
<https://www.rfc-editor.org/info/rfc5227>.

[RFC7432]

A. Sajassi, R. Aggarwal, N. Bitar, A. Isaac, J. Uttaro, J. Drake, and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015,
<https://www.rfc-editor.org/info/rfc7432>.

[RFC8174]

B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.

[RFC9047]

J. Rabadan, S. Sathappan, K. Nagaraj, and W. Lin, "Propagation of ARP/ND Flags in an Ethernet Virtual Private Network (EVPN)", RFC 9047, DOI 10.17487/RFC9047, June 2021,
<https://www.rfc-editor.org/info/rfc9047>.

[EURO-IX-BCP]

, "European Internet Exchange Association",
<https://www.euro-ix.net/en/forixps/set-ixp/ixp-bcops>.

[RFC4862]

S. Thomson, T. Narten, and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>.

[RFC6820]

T. Narten, M. Karir, and I. Foo, "Address Resolution Problems in Large Data Center Networks", RFC 6820, DOI 10.17487/RFC6820, January 2013,
<https://www.rfc-editor.org/info/rfc6820>.

[RFC6957]

F. Costa, J-M. Combes, X. Pougnard, and H. Li, "Duplicate Address Detection Proxy", RFC 6957, DOI 10.17487/RFC6957, June 2013,
<https://www.rfc-editor.org/info/rfc6957>.

Wim Henderickx

Daniel Melzer

Erik Nordmark

Jorge Rabadan

Senthil Sathappan

Kiran Nagaraj

Greg Hankins

Thomas King