Operational Aspects of Proxy ARP/ND in Ethernet Virtual Private Networks
updates
- rfc-7432 — BGP MPLS-Based Ethernet VPN
Extracted elements (28)
Dynamic Proxy ND entries must not be learned from NS messages because NS messages do not carry the R Flag needed by the Reply sub-function to correctly set the router/host indication in NA responses. This is why only NA messages are snooped for dynamic Proxy ND learning.
In Data Center deployments, the required VM mobility makes 'Dynamic Learning' or 'Hybrid' models more appropriate than all-static provisioning, and IPv6 anycast support may be needed; these requirements differ fundamentally from IXP deployments.
IXP networks predominantly use the 'All Static Provisioning' deployment model (Section 5.4) because all participant CEs are well known, enabling complete suppression of ARP/ND flooding while maximizing security; dynamic learning is unnecessary when the management system can provision all IP->MAC entries.
RFC 6957 (Duplicate Address Detection Proxy) is not suitable for EVPN BDs because it is defined for point-to-multipoint topologies with split-horizon forwarding where CEs have no direct L2 communication, which does not match EVPN Broadcast Domain topology.
For EVPN-learned entries, if no ARP/ND Extended Community is received with the RT2, the PE adds a configured R Flag and O Flag (MAY default to 1), providing backwards compatibility with RFC 7432 PEs that do not support the ARP/ND Extended Community of RFC 9047.
The Proxy ARP/ND solution will not function if there is a mechanism securing ARP/ND exchanges among CEs (e.g., SEND), because the PE cannot secure the proxied ND messages on behalf of the original sender.
A dynamic Proxy ARP/ND entry MUST be flushed from the table if the IP->MAC has not been refreshed within a configured age-time; the entry is refreshed upon receipt of an ARP or NA message for the same IP->MAC.
A provisioned static IP->MAC entry MUST be advertised in EVPN with an ARP/ND Extended Community where the Immutable ARP/ND Binding Flag (I) is set to 1, indicating the IP must not be associated to any other MAC.
A Proxy ARP/ND implementation in an EVPN BD MUST support dynamic and EVPN-learned entries and SHOULD support static entries.
A Proxy ARP/ND implementation MUST at least support the Learning, Reply, Maintenance, and duplicate IP detection sub-functions.
For an NA message in response to an address resolution NS or DAD NS, the PE MUST use IP1 as IP SA and Target Address, and M1 MUST be used as the Target Link Layer Address (TLLA).
For Proxy ARP, the PE MUST snoop all ARP packets (Ethertype 0x0806) received from local CEs to learn dynamic entries; ARP packets from remote EVPN PEs are not snooped.
For Proxy ND, the PE MUST snoop NA messages (Ethertype 0x86dd, ICMPv6 type 136) from local CEs and MUST NOT create dynamic IP->MAC entries from NS messages because NS messages do not contain the R Flag required by the reply function.
Static IP->MAC entries (locally provisioned or EVPN-learned with I=1) MUST NOT be overridden by dynamic Proxy ARP/ND entries.
The PE MUST create EVPN-learned entries from received valid EVPN MAC/IP Advertisement routes (RT2) containing both a MAC and IP address.
The Proxy ARP/ND function MUST support duplicate IP detection so that ARP/ND-spoofing attacks or duplicate IPs due to human errors can be detected.
When replying to an ARP Request, the PE MUST use the Proxy ARP entry IP1 and MAC1 in the sender Protocol Address and Hardware Address fields respectively, per RFC 826.
When the anycast capability is enabled in Proxy ND, the number of allowed entries for the same IP address MUST be limited by the operator to prevent DoS attacks that attempt to fill the Proxy ND table.
A Proxy ARP/ND table contains three types of entries: dynamic (snooped from CE ARP/ND messages), static (provisioned by management), and EVPN-learned (derived from received RT2 MAC/IP Advertisement routes from remote PEs).
An anycast capability may be configured for the Proxy ND function: when enabled, NA messages with O Flag=0 are used to create IP->MAC entries mapped to multiple MACs; when anycast is enabled, duplicate IP detection must be disabled.
Duplicate IP detection monitors IP-moves: when an existing IP1->MAC1 entry is replaced, the PE starts an M-second timer (default 180s); if N IP moves occur before expiry (default N=5), a duplicate IP situation is declared. Upon detection, the PE sends an AS-MAC GARP/unsolicited-NA to redirect traffic away from the disputed IP.
The Maintenance sub-function includes an age-time procedure (flush dynamic entries that are not refreshed) and an optional send-refresh procedure in which the PE periodically sends ARP probe or NS messages to dynamic entry owners; refresh timer is RECOMMENDED to be one-third to one-half of the age-time.
The Proxy ARP/ND function comprises six sub-functions: Learning, Reply, Unicast-Forward, Maintenance, Flood handling, and Duplicate IP detection. Implementations must support at minimum the Learning, Reply, Maintenance, and duplicate IP detection sub-functions.
The R Flag (Router) and O Flag (Override) from snooped NA messages are stored per Proxy ND entry. When replying to NS messages, the PE sets the R Flag as learned, sets the S Flag per RFC 4861, and sets the O Flag to 1 except when anycast is enabled and the entry was learned with O=0.
The Unicast-Forward sub-function allows a PE to forward ARP Requests or NS messages directly to the MAC owner (unicast) rather than flooding or replying. It can be configured as 'unicast-forward always' or 'unicast-forward unknown-options', the latter forwarding only when ARP/ND packets carry unrecognized options.
Proxy ARP/ND flood reduction protects 'slow path' software processors in routers and Tenant Systems in large BDs from being overwhelmed by ARP/ND traffic. Suppression of unknown ARP Requests and NS messages (Section 3.6) provides additional protection against requests targeting non-existing hosts.
The duplicate IP detection function and AS-MAC mechanism protect the BD against ARP/ND spoofing attacks. Upon duplicate detection, the PE may advertise IP1->AS-MAC via GARP and RT2 so all CEs address traffic to a managed drop MAC, preventing the spoofer from attracting traffic for the duplicated IP.
The unicast-forward and flood-suppression sub-functions add BD security but increase the risk of blocking service for a CE if the EVPN PEs cannot provide the ARP/ND resolution that the CE requires, making correct table completeness critical.