Propagation of ARP/ND Flags in an Ethernet Virtual Private Network (EVPN)
Extracted elements (26)
Flag bit position 5 is deliberately left unassigned (not used in this specification) because it was previously requested by a separate draft (draft-rbickhart-evpn-ip-mac-proxy-adv-01), reserving it to avoid conflicts.
The EVPN MAC/IP Advertisement route alone does not convey whether an IPv6->MAC pair belongs to a router or a host, or whether the address is anycast. The ARP/ND Extended Community was defined to carry this additional context so that proxy-ND PEs can issue Neighbor Advertisements with correct flag information.
The I (Immutable Binding) flag enables an operator-controlled security mechanism: a configured IP->MAC binding is distributed to all PEs in the BD, preventing ARP/ND spoofing attacks where a malicious host injects Gratuitous ARPs or unsolicited NAs with a different MAC for the same IP.
This Extended Community does not change the base EVPN procedures in RFC 7432; specifically, the procedures for advertising the MAC Mobility Extended Community alongside a MAC/IP Advertisement route are unaffected.
A PE MUST ignore received R and O flags for an EVPN MAC/IP Advertisement route containing an IPv4->MAC pair.
A PE receiving an EVPN MAC/IP Advertisement route with an IP->MAC and the I flag set SHOULD install that entry as an 'immutable binding', overriding an existing non-immutable binding for the same IP->MAC.
Advertised MAC/IP Advertisement routes for IPv6->MAC entries MUST include one (and only one) ARP/ND Extended Community with the R and O flag values associated with the entry, whether dynamically learned from NA messages or statically configured.
Bits 0-3 and 5 of the Flags field are not assigned; they MUST be set to zero on transmission and ignored on receipt.
If an immutable and static IP->MAC update is received from a different PE, one of the two routes will be selected and the PE MUST alert the operator, analogous to the dual-static-flag case in RFC 7432 Section 15.2.
If an IP->MAC pair is static (configured), the corresponding MAC/IP Advertisement route MUST be sent along with an ARP/ND Extended Community with the I flag set.
If more than one ARP/ND Extended Community is received along with an EVPN MAC/IP Advertisement route, the PE MUST consider only the first one for processing and MUST NOT propagate the rest of the ARP/ND Extended Communities.
If no EVPN ARP/ND Extended Community is received with the route, the PE adds default R and O flags: the default R flag SHOULD be an administrative choice, and the default O flag SHOULD be 1.
If the EVPN MAC/IP Advertisement route contains an IPv6 address and the EVPN ARP/ND Extended Community, the PE MUST add the R and O flag values to the ND entry and propagate those flag values to Neighbor Advertisements when replying to solicitations for the IPv6 address.
MAC/IP Advertisement routes for IPv4->MAC entries MAY include one ARP/ND Extended Community; if included, the R and O flags SHOULD be set to zero.
The R, O, and I flags MUST be ignored if advertised along with an EVPN MAC/IP Advertisement route that does not contain an IP (IPv4 or IPv6) address.
When multiple EVPN MAC/IP Advertisement routes with I=1 are received for the same IP but different MAC addresses (a misconfiguration), a PE SHOULD update the IP->MAC entry with the latest received information.
The EVPN ARP/ND Extended Community is a transitive BGP Extended Community (Type 0x06, Sub-Type 0x08) advertised alongside EVPN MAC/IP Advertisement routes carrying IPv4 or IPv6 addresses. It carries a Flags octet (third octet) with R, O, and I flag bits, with the remaining octets reserved and set to zero.
The Immutable ARP/ND Binding flag (I, bit 4 of Flags) indicates that the IP->MAC pair is a statically configured ARP/ND entry. When set, the IP address can only be bound to the MAC address specified in the same route, not to any other MAC address received in a route without the I flag.
The Override flag (O, bit 6 of Flags) is normally set to 1 for IPv6->MAC pairs and set to 0 only when IPv6 anycast is enabled. The ingress PE installs the ND entry with the received O flag value and uses it when replying to Neighbor Solicitations.
The Router flag (R, bit 7 of Flags) indicates whether the IPv6->MAC pair advertised belongs to an IPv6 router (R=1) or a host (R=0). This flag is used by the receiving PE to set the Router flag in Neighbor Advertisement messages for the associated IPv6 address.
IANA created the 'ARP/ND Extended Community Flags' registry under the BGP Extended Communities registry with initial allocations: bit 4 = Immutable ARP/ND Binding Flag (I), bit 6 = Override Flag (O), bit 7 = Router Flag (R), bits 0-3 and 5 = Unassigned. Registration policy is Standards Action.
IANA updated the 'EVPN Extended Community Sub-Types' registry to rename Sub-Type Value 0x08 to 'ARP/ND Extended Community' per this document.
Misconfigured or maliciously set R or O flags on one PE will cause all PEs in the BD to reply to Neighbor Solicitations with incorrect NA messages. A wrong O flag can break communication (receiver won't update its cache), and a wrong R flag can corrupt the Default Router List, causing traffic to be dropped.
Proxy-ARP/ND in EVPN BDs introduces resource exhaustion risk: attackers can inject ARP/ND messages to create state across all PEs in a BD. Mitigations include limiting the number of proxy-ARP/ND entries per BD and/or per port, and rate-limiting dynamic entry creation.
The I (Immutable ARP/ND Binding) flag serves as a security tool against ARP/ND spoofing: when an IP->MAC is marked immutable, gratuitous ARPs or unsolicited NAs with a different MAC for that IP will not update the ARP/ND or proxy-ARP/ND tables on remote PEs.
The Extended Community is 8 octets: Type=0x06 (1 octet), Sub-Type=0x08 (1 octet), Flags (1 octet), Reserved=0 (1 octet), Reserved=0 (4 octets). The Flags octet uses bit 7 (R), bit 6 (O), and bit 4 (I); bits 0-3 and 5 are unassigned and MUST be set to zero.