EVPN ARP/ND Flags: Propagation of ARP/ND Flags in an Ethernet Virtual Private Network (EVPN)
A small BGP tag that lets EVPN edge routers answer ARP and IPv6 Neighbor Discovery requests with the right flags.
Rabadan, J., Ed., Sathappan, S., Nagaraj, K., 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>.
@misc{rfc9047,
series = {Request for Comments},
number = 9047,
howpublished = {RFC 9047},
publisher = {RFC Editor},
doi = {10.17487/RFC9047},
url = {https://www.rfc-editor.org/info/rfc9047},
author = {J. Rabadan and S. Sathappan and K. Nagaraj and W. Lin},
title = {{Propagation of ARP/ND Flags in an Ethernet Virtual Private Network (EVPN)}},
pagetotal = 10,
year = 2021,
month = jun,
} RFC text
Contents
Internet Engineering Task Force (IETF) J. Rabadan, Ed.
Request for Comments: 9047 S. Sathappan
Category: Standards Track K. Nagaraj
ISSN: 2070-1721 Nokia
W. Lin
Juniper
June 2021
Propagation of ARP/ND Flags in an Ethernet Virtual Private Network
(EVPN)
Abstract
This document defines an Extended Community that is advertised along
with an Ethernet Virtual Private Network (EVPN) Media Access Control
(MAC) / IP Advertisement route and carries information relevant to
the Address Resolution Protocol (ARP) / Neighbor Discovery (ND)
resolution so that an EVPN Provider Edge (PE) implementing a proxy-
ARP/ND function in broadcast domains (BDs) or an ARP/ND function on
Integrated Routing and Bridging (IRB) interfaces can reply to ARP
Requests or Neighbor Solicitation (NS) messages with the correct
information.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9047.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction
1.1. Terminology and Conventions
2. The EVPN ARP/ND Extended Community
3. Use of the EVPN ARP/ND Extended Community
3.1. Transmission of the EVPN ARP/ND Extended Community
3.2. Reception of the EVPN ARP/ND Extended Community
4. Security Considerations
5. IANA Considerations
6. References
6.1. Normative References
6.2. Informative References
Acknowledgments
Authors' Addresses
1. Introduction
An EVPN MAC/IP Advertisement route can optionally carry IPv4 or IPv6
addresses associated with a MAC address. Remote PE routers can use
this information to populate their ARP or ND tables on IRB interfaces
or their proxy-ARP/ND tables in BDs. PEs can then reply locally (act
as an ARP/ND proxy, as per [RFC7432]) to IPv4 ARP Requests and IPv6
Neighbor Solicitation messages and reduce or suppress the flooding
produced by the address resolution procedure. However, the
information conveyed in the EVPN MAC/IP Advertisement route may not
be enough for the remote PE to reply to local ARP or ND requests.
For example, if a PE learns an IPv6 address and MAC address
combination ND entry via EVPN (denoted by IPv6->MAC), the PE would
not know if that particular IPv6->MAC pair belongs to a router or a
host or if that address is an anycast address, as this information is
not carried in the EVPN MAC/IP Advertisement routes.
This document defines an Extended Community that is advertised along
with an EVPN MAC/IP Advertisement route and carries information
relevant to the ARP/ND resolution so that an EVPN PE implementing a
proxy-ARP/ND function can reply to ARP Requests or Neighbor
Solicitations with the correct information. In particular, the flags
defined in [RFC4861] can now be conveyed along with a MAC/IP
Advertisement route so that an egress EVPN PE can issue Neighbor
Advertisement (NA) messages with the correct flag information.
The flags are carried in the EVPN Address Resolution Protocol and
Neighbor Discovery (ARP/ND) Extended Community, as described in the
following sections.
1.1. Terminology and Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
EVPN: Ethernet Virtual Private Networks, as in [RFC7432]
BD: Broadcast Domain, also described in [RFC7432]
ARP: Address Resolution Protocol
ND: Neighbor Discovery protocol, specified in [RFC4861]
PE: Provider Edge router
CE: Customer Edge router
IRB: Integrated Routing and Bridging interface
Proxy-ARP/ND: A function on the EVPN PEs by which received ARP
Requests or NS messages are replied to locally by the PE,
without the need to flood the requests to remote PEs in the
BD. In order to reply to ARP Requests or NS messages, the PE
does a lookup on an ARP/ND table, which is a collection of
IP->MAC entries learned by the PE.
IP->MAC: An IP address and MAC address combination that represents a
given host and is added to an ARP table or ND table. This
document uses IP->MAC generically for IPv4 and IPv6
addresses. When something is specific to IPv4, the document
will use IPv4->MAC; likewise, IPv6->MAC will be used when
something is specific to IPv6 entries only.
Familiarity with the terminology in [RFC4861] and [RFC7432] is
expected.
2. The EVPN ARP/ND Extended Community
This document defines a transitive EVPN Extended Community (Type
field value of 0x06) with a Sub-Type of 0x08, as allocated by IANA.
It is advertised along with EVPN MAC/IP Advertisement routes that
carry an IPv4 or IPv6 address.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x06 | Sub-Type=0x08 |Flags (1 octet)| Reserved=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags field:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| |I| |O|R|
+-+-+-+-+-+-+-+-+
The following flags are defined in the Flags field, the third octet
of the Extended Community:
R: Router flag (corresponds to Bit 23 of the Extended Community)
Bit 7 of the Flags field is defined as the "Router flag". When
set, the R flag indicates that the IPv6->MAC pair advertised in
the MAC/IP Advertisement route, along with the Extended
Community, belongs to an IPv6 router. If the R flag is zero,
the IPv6->MAC pair belongs to a host. The receiving PE
implementing the ND function will use this information in
Neighbor Advertisement messages for the associated IPv6 address.
This flag has no meaning for ARP IPv4->MAC entries and MUST be
ignored when the Extended Community is received with an EVPN
MAC/IP Advertisement route for an IPv4->MAC pair.
O: Override flag (corresponds to Bit 22 of the Extended Community)
Bit 6 of the Flags field is defined as the "Override flag". An
egress PE will normally advertise IPv6->MAC pairs with the O
flag set, and only when IPv6 "anycast" is enabled in the BD or
interface will the PE send an IPv6->MAC pair with the O flag =
0. The ingress PE will install the ND entry with the received O
flag and will always use this O flag value when replying to a
Neighbor Solicitation for the IPv6 address. Similarly to the
Router Flag, the Override flag has no meaning for ARP IPv4->MAC
entries and MUST be ignored when the Extended Community is
received with an EVPN MAC/IP Advertisement route for an
IPv4->MAC pair.
I: Immutable ARP/ND Binding flag (corresponds to Bit 20 of the
Extended Community)
Bit 4 of the Flags field is defined as the "Immutable ARP/ND
Binding flag". When set, the egress PE indicates that the
IP->MAC pair that was sent in an EVPN MAC/IP Advertisement route
(along with the Extended Community) is a configured ARP/ND
entry. In this case, the IP address in the EVPN MAC/IP
Advertisement route can only be bound together with the MAC
address specified in the same route, and not with any other MAC
addresses received in a different route without the I flag set.
Bits 0-3 and 5 are not assigned by this document. They MUST be set
to zero and ignored on receipt.
The reserved fields are set to 0 and ignored by the receiver.
3. Use of the EVPN ARP/ND Extended Community
This section describes the relevant procedures when advertising and
processing the EVPN ARP/ND Extended Community. In all the procedures
below, a "PE" must be interpreted as a "PE that supports the proxy-
ARP/ND (introduced by [RFC7432]) and implements the propagation of
the ARP/ND flags that this document specifies".
3.1. Transmission of the EVPN ARP/ND Extended Community
When an IP->MAC entry is not learned via EVPN, a PE may learn IP->MAC
pairs in the management plane (this will create static entries in the
ARP/ND or proxy-ARP/ND table) or by snooping ARP or NA messages
coming from the CE (this will create dynamic entries). Those static
and dynamic IP->MAC entries will be advertised in EVPN MAC/IP
Advertisement routes that use the EVPN ARP/ND Extended Community as
follows:
* 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. Those flag values
are either dynamically learned (from NA messages) or configured in
case of static entries.
* MAC/IP Advertisement routes for IPv4->MAC entries MAY include one
ARP/ND Extended Community. If the EVPN ARP/ND Extended Community
is advertised along with an EVPN IPv4/MAC Advertisement route, the
R and O flags SHOULD be set to zero.
* If an IP->MAC pair is static (it has been configured), the
corresponding MAC/IP Advertisement route MUST be sent along with
an ARP/ND Extended Community with the I flag set.
* This Extended Community does not change the procedures described
in [RFC7432]. Specifically, the procedures for advertising the
MAC Mobility Extended Community along with the MAC/IP
Advertisement route are not changed.
3.2. Reception of the EVPN ARP/ND Extended Community
In addition to the procedures specified in [RFC7432], a PE receiving
a MAC/IP Advertisement route will process the EVPN ARP/ND Extended
Community as follows:
* Only one EVPN ARP/ND Extended Community is expected to be received
along with an EVPN MAC/IP Advertisement route. If more than one
ARP/ND Extended Community is received, the PE MUST consider only
the first one on the list for processing purposes and MUST NOT
propagate the rest of the ARP/ND Extended Communities.
* The R, O, and I flags MUST be ignored if they are advertised along
with an EVPN MAC/IP Advertisement route that does not contain an
IP (IPv4 or IPv6) address. Otherwise, they are processed as
follows.
* R and O flag processing:
- 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 in the ND or proxy-ND table
and propagate the value of the R and O flags from the ARP/ND
Extended Community to the Neighbor Advertisements when replying
to a solicitation for the IPv6 address.
- If no EVPN ARP/ND Extended Community is received along with the
route, the PE will add the default R and O flags to the entry.
The default R flag SHOULD be an administrative choice. The
default O flag SHOULD be 1.
- A PE MUST ignore the received R and O flags for an EVPN MAC/IP
Advertisement route that contains an IPv4->MAC pair.
* I flag processing:
- A PE receiving an EVPN MAC/IP Advertisement route containing an
IP->MAC and the I flag set SHOULD install the IP->MAC entry in
the ARP/ND or proxy-ARP/ND table as an "immutable binding".
This immutable binding entry will override an existing non-
immutable binding for the same IP->MAC. The absence of the
EVPN ARP/ND Extended Community in a MAC/IP Advertisement route
indicates that the IP->MAC entry is not an "immutable binding".
- Receiving multiple EVPN MAC/IP Advertisement routes with the I
flag set to 1 for the same IP but a different MAC address is
considered a misconfiguration or a transient error condition.
If this happens in the network, a PE receiving multiple routes
(with the I flag set to 1 for the same IP and a different MAC
address) SHOULD update the IP->MAC entry with the latest
received information. Note that if a configured IP1->MAC1
changes to point to a new MAC address, i.e., IP1->MAC2, the
EVPN MAC/IP Advertisement route for IP1->MAC1 will be withdrawn
before the EVPN MAC/IP Advertisement route for IP1->MAC2 is
advertised.
- A PE originating an EVPN MAC/IP Advertisement route for
IP1->MAC1 with the I flag set to 1 MAY also originate the route
with the "Sticky/static flag" set (in the MAC Mobility Extended
Community). In such a case, the IP1->MAC1 binding is not only
immutable but it cannot move as well. Even so, if an update
for the same immutable and static IP1->MAC1 is received from a
different PE, one of the two routes will be selected. This is
analogous to the case described in Section 15.2 of [RFC7432]
when two MAC/IP routes with the static flag set are received,
and the PE likewise MUST alert the operator of such a
situation.
In a situation where a host (with an IP->MAC that is configured as
immutable binding in the attached PE) is allowed to move between PEs
(that is, the associated MAC is non-static), PEs can receive multiple
MAC/IP Advertisement routes for the same IP->MAC. In such
situations, MAC mobility procedures as in [RFC7432] dictate the
reachability of the MAC.
As an example of the use of the I flag, consider PE1, PE2, and PE3
attached to the same BD. PE1 originates an EVPN MAC/IP Advertisement
route for IP1->MAC1 with the I flag set to 1 later on, PE2 also
originates an EVPN MAC/IP Advertisement route IP1->MAC1 with a higher
sequence number and the I flag set to 1. Then all the EVPN PEs
attached to the same BD SHOULD retain their IP1->MAC1 ARP/ND binding
but update MAC1's forwarding destination to PE2. For some reason, if
PE3 originates an EVPN MAC/IP Advertisement route for IP1->MAC2 with
the I flag set to 0 (even with a higher sequence number), then the
EVPN PEs in the BD will not update their IP1->MAC1 ARP/ND bindings
since IP1 is bound to MAC1 (MAC2 SHOULD still be programmed in the
Layer 2 BDs). This is considered a misconfiguration in PE3.
When the I flag is set to 1, a given IP is assumed to be always bound
to the same MAC address; therefore, the mobility procedures described
in [EXTENDED-MOBILITY] for "Host IP move to a new MAC" will not
apply.
4. Security Considerations
The same security considerations described in [RFC7432] apply to this
document. In general, it is worth noting that the use of proxy-ARP/
ND in EVPN BDs may add some security risks. Attackers can make use
of ARP/ND messages to create state in all the PEs attached to the
same BD as the attacker and exhaust resources in those PEs.
Therefore, additional security mechanisms may be needed. Some
examples of such additional security mechanisms are limiting the
number of proxy-ARP/ND entries per BD and/or per port or closely
monitoring the rate at which hosts create dynamic proxy-ARP/ND
entries.
In addition, this document adds pieces of information that impact the
way ARP/ND entries are installed in ARP/ND and/or proxy-ARP/ND tables
and, therefore, impacts the resolution protocols for IPv4 and IPv6
addresses. For instance, if a given IPv6->MAC binding is configured
with the wrong R or O flags (intentionally or not) on a given PE, the
rest of the PEs attached to the same BD will install the wrong
information for the IPv6->MAC. This will cause all the PEs in the BD
to reply to Neighbor Solicitations for the IPv6 with NA messages
containing the wrong R and O flags. For example, as specified in
[RFC4861], the receiver of an NA message with O not set will not
update its existing cache entry for the IP->MAC; hence, the
communication between the owner of the IP address and the receiver of
the NA message with the wrong O flag will fail. Similarly, the
receiver of an NA message with the wrong R flag may update its
Default Router List by incorrectly adding or removing an entry, which
could, for example, lead to sending traffic to a node that is not a
router, causing the traffic to be dropped.
The I flag, or Immutable ARP/ND Binding flag, is a useful security
tool, allowing an operator to ensure a given IP address is always
bound to the same MAC and that information is distributed to all the
PEs attached to the same BD. ARP/ND spoofing attacks, in which a
malicious host injects Gratuitous ARPs or unsolicited NAs for that IP
address with a different MAC address, will not succeed in programming
the ARP/ND and proxy-ARP/ND tables and therefore the spoofer will not
receive the traffic.
5. IANA Considerations
IANA has changed the name for Sub-Type Value 0x08 in the "EVPN
Extended Community Sub-Types" registry [IANA-BGP-EXT-COMM] to the
following:
+================+===========================+===========+
| Sub-Type Value | Name | Reference |
+================+===========================+===========+
| 0x08 | ARP/ND Extended Community | RFC 9047 |
+----------------+---------------------------+-----------+
Table 1: Updated Value in the "EVPN Extended Community
Sub-Types" Registry
IANA has created the "ARP/ND Extended Community Flags" registry,
where the following initial allocations have been made:
+===============+===================================+===========+
| Flag Position | Name | Reference |
+===============+===================================+===========+
| 0-3 | Unassigned | |
+---------------+-----------------------------------+-----------+
| 4 | Immutable ARP/ND Binding Flag (I) | RFC 9047 |
+---------------+-----------------------------------+-----------+
| 5 | Unassigned | |
+---------------+-----------------------------------+-----------+
| 6 | Override Flag (O) | RFC 9047 |
+---------------+-----------------------------------+-----------+
| 7 | Router Flag (R) | RFC 9047 |
+---------------+-----------------------------------+-----------+
Table 2: Initial Values of the "ARP/ND Extended Community
Flags" Registry
The registration policy for this registry is Standards Action
[RFC8126]. This registry is located in the "Border Gateway Protocol
(BGP) Extended Communities" registry [IANA-BGP-EXT-COMM].
Note that the flag position 5 is left unassigned and not used in this
specification since it was previously requested by
[EVPN-IP-MAC-PROXY].
6. References
6.1. Normative References
[RFC2119] Bradner, S., "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] Narten, T., Nordmark, E., Simpson, W., 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>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC8174] Leiba, B., "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>.
6.2. Informative References
[EVPN-IP-MAC-PROXY]
Bickhart, R., Lin, W., Drake, J., Rabadan, J., and A. Lo,
"Proxy IP->MAC Advertisement in EVPNs", Work in Progress,
Internet-Draft, draft-rbickhart-evpn-ip-mac-proxy-adv-01,
24 January 2020, <https://tools.ietf.org/html/draft-
rbickhart-evpn-ip-mac-proxy-adv-01>.
[EXTENDED-MOBILITY]
Malhotra, N., Ed., Sajassi, A., Pattekar, A., Lingala, A.,
Rabadan, J., and J. Drake, "Extended Mobility Procedures
for EVPN-IRB", Work in Progress, Internet-Draft, draft-
ietf-bess-evpn-irb-extended-mobility-05, 15 March 2021,
<https://tools.ietf.org/html/draft-ietf-bess-evpn-irb-
extended-mobility-05>.
[IANA-BGP-EXT-COMM]
IANA, "Border Gateway Protocol (BGP) Extended
Communities", <https://www.iana.org/assignments/bgp-
extended-communities>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
Acknowledgments
The authors would like to thank Ali Sajassi for his feedback.
Authors' Addresses
Jorge Rabadan (editor)
Nokia
777 Middlefield Road
Mountain View, CA 94043
United States of America
Email: jorge.rabadan@nokia.com
Senthil Sathappan
Nokia
701 E. Middlefield Road
Mountain View, CA 94043
United States of America
Email: senthil.sathappan@nokia.com
Kiran Nagaraj
Nokia
701 E. Middlefield Road
Mountain View, CA 94043
United States of America
Email: kiran.nagaraj@nokia.com
Wen Lin
Juniper Networks
Email: wlin@juniper.net
AI ELI5
On this page
§1The Problem With Proxy ARP and ND
In an Ethernet VPN (EVPN), an EVPN MAC/IP Advertisement route can optionally carry the IPv4 or IPv6 addresses tied to a MAC address. Remote Provider Edge (PE) routers use this to fill their ARP or ND tables on IRB interfaces, or their proxy-ARP/ND tables in broadcast domains (BDs). A PE can then answer ARP Requests and IPv6 Neighbor Solicitation messages itself and reduce or suppress flooding.
The catch is that the route may not hold enough information for a correct answer. If a PE learns an IPv6-to-MAC pair through EVPN, it cannot tell whether that pair belongs to a router or a host, or whether the address is an anycast address. That information is simply not in the route.
The RFC fixes this with an Extended Community sent alongside the route. It conveys the flags defined in RFC 4861 so that the answering PE can send Neighbor Advertisement (NA) messages with the correct flag information. It builds on the procedures of RFC 7432.
A helper who answers questions for others sometimes does not know basic facts, like whether an address belongs to a grown-up or a kid. This document adds a small note so the helper knows.
§2The ARP/ND Extended Community
The document defines a transitive EVPN Extended Community with a Type field value of 0x06 and a Sub-Type of 0x08, as allocated by IANA. It is sent along with EVPN MAC/IP Advertisement routes that carry an IPv4 or IPv6 address.
The community is 8 octets long. After the Type and Sub-Type comes a one-octet Flags field (the third octet), then reserved fields that are set to 0 and ignored by the receiver.
Bits 0-3 and 5 of the Flags field are not assigned. They MUST be set to zero and ignored on receipt.
It is a tiny label stuck onto a message. The label has a few on/off switches, and the rest of it is left blank for now.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
TYPE | Type | 1 byte | 0x06 | Transitive EVPN Extended Community type. |
SUB-TYPE | Sub-Type | 1 byte | 0x08 | ARP/ND Extended Community sub-type. |
FLAGS | Flags | 1 byte | Holds the I, O and R flags. | |
RESERVED-1 | Reserved | 1 byte | 0 | Set to 0 and ignored by the receiver. |
RESERVED-2 | Reserved | 4 bytes | 0 | Set to 0 and ignored by the receiver. |
§2.1The R, O and I Flags
Three flags are defined:
- R, the Router flag (Bit 7 of the Flags field). When set, the IPv6-to-MAC pair belongs to an IPv6 router. If zero, it belongs to a host. The receiving PE uses it in Neighbor Advertisement messages for that address.
- O, the Override flag (Bit 6). An egress PE normally advertises IPv6-to-MAC pairs with O set. Only when IPv6 anycast is enabled in the BD or interface does the PE send a pair with O equal to 0. The ingress PE installs the ND entry with the received O flag and always uses that value when replying to a Neighbor Solicitation.
- I, the Immutable ARP/ND Binding flag (Bit 4). When set, the egress PE says the pair is a configured ARP/ND entry. That IP address can only be bound to the MAC address in the same route, not to any other MAC address received in a route without the I flag set.
The R and O flags have no meaning for IPv4 ARP entries and MUST be ignored when received with a route for an IPv4-to-MAC pair.
There are three switches. One says 'this is a grown-up router', one says 'my answer should replace what you remember', and one says 'this name always belongs to this exact phone, never change it'.
- Bit 7R, Router — IPv6-to-MAC pair belongs to a router when set, a host when zero.
- Bit 6O, Override — Zero only when IPv6 anycast is enabled in the BD or interface.
- Bit 4I, Immutable ARP/ND Binding — The IP-to-MAC pair is a configured entry that other MACs cannot replace.
- 0-3, 5Unassigned — Set to zero and ignored on receipt.
§3.1Sending the Community
A PE may learn IP-to-MAC pairs in the management plane, which creates static entries, or by snooping ARP or NA messages from the CE, which creates dynamic entries. These are advertised in MAC/IP Advertisement routes as follows:
- Routes for IPv6-to-MAC entries MUST include one, and only one, ARP/ND Extended Community with the R and O flag values of the entry. Those values are learned from NA messages or configured for static entries.
- Routes for IPv4-to-MAC entries MAY include one such community. If they do, the R and O flags SHOULD be set to zero.
- If a pair is static (configured), the route MUST carry the community with the I flag set.
The community does not change the procedures of RFC 7432, including those for the MAC Mobility Extended Community.
When a router tells the others about an address, it attaches the label. Addresses that were set up by hand always get the 'never change me' switch turned on.
§3.2Receiving and Applying the Flags
Only one ARP/ND Extended Community is expected per route. If more than one arrives, the PE MUST consider only the first and MUST NOT propagate the rest. The R, O and I flags MUST be ignored when the route has no IP address.
For R and O: if the route has an IPv6 address and the community, the PE MUST add the flag values to the ND entry and propagate them in Neighbor Advertisements sent in reply to a solicitation. If no community arrives, the PE adds default flags; the default R flag SHOULD be an administrative choice and the default O flag SHOULD be 1.
For I: a PE receiving a route with the I flag set SHOULD install the entry as an immutable binding, which overrides an existing non-immutable binding. Receiving several routes with I set for the same IP but different MAC addresses is a misconfiguration or transient error, and the PE SHOULD update the entry with the latest information. A PE originating an immutable route MAY also set the Sticky/static flag in the MAC Mobility Extended Community, so the binding cannot move either. If two such routes arrive from different PEs, one is selected and the PE MUST alert the operator.
When the I flag is 1, the IP is assumed to be always bound to the same MAC address, so the mobility procedures in [EXTENDED-MOBILITY] for 'Host IP move to a new MAC' do not apply.
The router that receives a labelled message writes the label next to the address in its notebook. Later, when someone asks about that address, it answers using what the label said. If the label says 'never change', later claims about that address are ignored.
§3.3An Immutable Binding Example
The RFC gives an example with PE1, PE2 and PE3 attached to the same BD. PE1 originates a route for IP1-to-MAC1 with the I flag set to 1. Later PE2 also originates a route for IP1-to-MAC1 with a higher sequence number and I set to 1. All the PEs in the BD SHOULD keep their IP1-to-MAC1 binding but update MAC1's forwarding destination to PE2.
If PE3 then originates a route for IP1-to-MAC2 with I set to 0, even with a higher sequence number, the PEs do not change their IP1-to-MAC1 bindings. MAC2 SHOULD still be programmed in the Layer 2 BDs. The RFC treats this as a misconfiguration in PE3.
A name tag that says 'locked' stays on the same person, even if that person moves to another seat. Someone else trying to claim the tag without the lock is told no.
§4Security Considerations
The security considerations of RFC 7432 apply. Proxy-ARP/ND in EVPN BDs may add risk: attackers can use ARP/ND messages to create state in all PEs attached to the same BD and exhaust their resources. Additional mechanisms may be needed, for example limiting the number of proxy-ARP/ND entries per BD or per port, or monitoring the rate at which hosts create dynamic entries.
Wrong flags also cause harm. If an IPv6-to-MAC binding is configured with the wrong R or O flags, every PE in the BD installs and repeats the wrong information. Per RFC 4861, the receiver of an NA with O not set will not update its cache entry, so communication fails. A wrong R flag could add or remove an entry in a Default Router List, so traffic may be sent to a node that is not a router and dropped.
The I flag is a useful security tool. ARP/ND spoofing attacks that inject Gratuitous ARPs or unsolicited NAs with a different MAC address will not succeed in programming the tables, so the spoofer will not receive the traffic.
A wrong label makes every helper repeat the same mistake. But the 'locked' label stops tricksters from pretending to own someone else's name.
§5IANA Registrations
IANA changed the name of Sub-Type Value 0x08 in the 'EVPN Extended Community Sub-Types' registry to 'ARP/ND Extended Community', referencing this RFC. IANA also created the 'ARP/ND Extended Community Flags' registry, with the I flag at position 4, the O flag at 6 and the R flag at 7. Positions 0-3 and 5 are unassigned. The policy for new entries is Standards Action.
Position 5 is left unassigned and unused because it was previously requested by a separate Internet-Draft, [EVPN-IP-MAC-PROXY].
A public list keeps track of which switch means what, so nobody reuses the same switch for a different meaning.