draft-ietf-bess-evpn-na-flags-04.txt   draft-ietf-bess-evpn-na-flags-05.txt 
BESS Workgroup J. Rabadan, Ed. BESS Workgroup J. Rabadan, Ed.
Internet Draft S. Sathappan Internet-Draft S. Sathappan
K. Nagaraj Intended status: Standards Track K. Nagaraj
Intended status: Standards Track Nokia Expires: January 28, 2021 Nokia
W. Lin W. Lin
Juniper Juniper
July 27, 2020
Expires: January 4, 2020 July 3, 2019
Propagation of ARP/ND Flags in EVPN Propagation of ARP/ND Flags in EVPN
draft-ietf-bess-evpn-na-flags-04 draft-ietf-bess-evpn-na-flags-05
Abstract Abstract
An EVPN MAC/IP Advertisement route can optionally carry an IPv4 or An EVPN MAC/IP Advertisement route can optionally carry an IPv4 or
IPv6 addresses associated with a MAC address. Remote PEs can use this IPv6 addresses associated with a MAC address. Remote PEs can use
information to reply locally (act as proxy) to IPv4 ARP requests and this information to populate their ARP/ND tables on IRB interfaces or
IPv6 Neighbor Solicitation messages and reduce/suppress the flooding their proxy-ARP/ND tables in Broadcast Domains (BD). PEs can then
produced by the Address Resolution procedure. The information reply locally (act as an ARP/ND proxy) to IPv4 ARP requests and IPv6
conveyed in the MAC/IP route may not be enough for the remote PE to Neighbor Solicitation messages and reduce/suppress the flooding
reply to local ARP or ND requests. For example, if a PE learns an produced by the Address Resolution procedure. However, the
IPv6->MAC ND entry via EVPN, the PE would not know if that particular information conveyed in the MAC/IP route may not be enough for the
IPv6->MAC pair belongs to a host, a router or a host with an anycast remote PE to reply to local ARP or ND requests. For example, if a PE
address, as this information is not carried in the MAC/IP route learns an IPv6->MAC ND entry via EVPN, the PE would not know if that
advertisements. Similarly, other information relevant to the IP->MAC particular IPv6->MAC pair belongs to a host, a router or a host with
ARP/ND entries may be needed. This document defines an extended an anycast address, as this information is not carried in the EVPN
community that is advertised along with an EVPN MAC/IP Advertisement MAC/IP Advertisement routes. Similarly, other information relevant
route and carries information relevant to the ARP/ND resolution, so to the IP->MAC ARP/ND entries may be needed. This document defines
that an EVPN PE implementing a proxy-ARP/ND function can reply to ARP an Extended Community that is advertised along with an EVPN MAC/IP
Requests or Neighbor Solicitations with the correct information. 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.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 28, 2021.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on January 4, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Terminology and Conventions . . . . . . . . . . . . . . . . 3 1.1. Terminology and Conventions . . . . . . . . . . . . . . . 3
2. The EVPN ARP/ND Extended Community . . . . . . . . . . . . . . 4 2. The EVPN ARP/ND Extended Community . . . . . . . . . . . . . 4
3. Use of the EVPN ARP/ND Extended Community . . . . . . . . . . . 5 3. Use of the EVPN ARP/ND Extended Community . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 3.1. Transmission of the EVPN ARP/ND Extended Community . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Reception of the EVPN ARP/ND Extended Community . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . . 8 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
An EVPN MAC/IP Advertisement route can optionally carry an IPv4 or An EVPN MAC/IP Advertisement route can optionally carry an IPv4 or
IPv6 addresses associated with a MAC address. Remote PEs can use this IPv6 addresses associated with a MAC address. Remote PEs can use
information to reply locally (act as proxy) to IPv4 ARP requests and this information to populate their ARP/ND tables on IRB interfaces or
IPv6 Neighbor Solicitation messages and reduce/suppress the flooding their proxy-ARP/ND tables in Broadcast Domains (BD). PEs can then
produced by the Address Resolution procedure. The information reply locally (act as an ARP/ND proxy, as per [RFC7432]) to IPv4 ARP
conveyed in the MAC/IP route may not be enough for the remote PE to requests and IPv6 Neighbor Solicitation messages and reduce/suppress
reply to local ARP or ND requests. For example, if a PE learns an the flooding produced by the Address Resolution procedure. However,
IPv6->MAC ND entry via EVPN, the PE would not know if that particular the information conveyed in the EVPN MAC/IP Advertisement route may
IPv6->MAC pair belongs to a host, a router or a host with an anycast not be enough for the remote PE to reply to local ARP or ND requests.
address, as this information is not carried in the MAC/IP route For example, if a PE learns an IPv6->MAC ND entry via EVPN, the PE
advertisements. Similarly, other information relevant to the host would not know if that particular IPv6->MAC pair belongs to a host, a
advertised in the MAC/IP Advertisement route may be needed. router or a host with an anycast address, as this information is not
carried in the EVPN MAC/IP Advertisement routes. Similarly, other
information relevant to the host advertised in the MAC/IP
Advertisement route may be needed.
This document defines an extended community that is advertised along This document defines an Extended Community that is advertised along
with an EVPN MAC/IP Advertisement route and carries information with an EVPN MAC/IP Advertisement route and carries information
relevant to the ARP/ND resolution, so that an EVPN PE implementing a relevant to the ARP/ND resolution, so that an EVPN PE implementing a
proxy-ARP/ND function can reply to ARP Requests or Neighbor proxy-ARP/ND function can reply to ARP Requests or Neighbor
Solicitations with the correct information. In particular, the Flags Solicitations with the correct information. In particular, the Flags
defined in [RFC4861] can now be conveyed along with a MAC/IP defined in [RFC4861] can now be conveyed along with a MAC/IP
Advertisement route, so that an egress EVPN PE can issue Neighbor Advertisement route, so that an egress EVPN PE can issue Neighbor
Advertisement messages with the correct Flag information. Advertisement messages with the correct Flag information.
The Flags are carried in the EVPN Address Resolution Protocol (ARP) The Flags are carried in the EVPN Address Resolution Protocol (ARP)
and Neighbor Discovery (ND) Extended Community, as described in the and Neighbor Discovery (ND) Extended Community, as described in the
following sections. following sections.
1.1 Terminology and Conventions 1.1. Terminology and Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
EVPN: Ethernet Virtual Private Networks, as in [RFC7432]. EVPN: Ethernet Virtual Private Networks, as in [RFC7432].
BD: Broadcast Domain, also described in [RFC7432]. BD: Broadcast Domain, also described in [RFC7432].
IP->MAC: refers to an IP address and MAC address combination that ARP: refers to the Address Resolution Protocol.
represents a given host and is added to an Address Resolution
Protocol table or Neighbor Discovery table. This document uses IP- ND: refers to the Neighbor Discovery protocol.
>MAC generically for IPv4 and IPv6 addresses. When something is
specific to IPv4, the document will use IPv4->MAC and likewise, IPv6-
>MAC will be used when something is specific to IPv6 entries only.
Proxy-ARP/ND: refers to a function on the EVPN PEs by which received Proxy-ARP/ND: refers to a function on the EVPN PEs by which received
Address Resolution Protocol (ARP) Requests or Neighbor Solicitation Address Resolution Protocol (ARP) Requests or Neighbor Solicitation
(NS) messages are replied locally by the PE, without the need to (NS) messages are replied locally by the PE, without the need to
flood the requests to remote PEs in the BD. In order to reply to ARP 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, Requests or NS messages, the PE does a lookup on an ARP/ND table,
that is a collection of IP->MAC entries learned by the PE. that is a collection of IP->MAC entries learned by the PE.
IP->MAC: refers to an IP address and MAC address combination that
represents a given host and is added to an Address Resolution
Protocol table or Neighbor Discovery table. This document uses
IP->MAC generically for IPv4 and IPv6 addresses. When something is
specific to IPv4, the document will use IPv4->MAC and likewise,
IPv6->MAC will be used when something is specific to IPv6 entries
only.
Familiarity with the terminology in [RFC7432] and [RFC4861] is Familiarity with the terminology in [RFC7432] and [RFC4861] is
expected. expected.
2. The EVPN ARP/ND Extended Community 2. The EVPN ARP/ND Extended Community
This document defines a new EVPN Extended Community with a Type field This document defines a new EVPN Extended Community (Type field value
value of 0x06 and a Sub-Type 0x08, as allocated by IANA. It is 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 advertised along with EVPN MAC/IP Advertisement routes that carry an
IPv4 or IPv6 address. 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 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= TBD |Flags (1 octet)| Reserved=0 | | Type=0x06 | Sub-Type=0x08 |Flags (1 octet)| Reserved=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved=0 | | Reserved=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags field: Flags field:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| |I| |O|R| | |I| |O|R|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
The following Flags are defined in the Flags field, third octet of The following Flags are defined in the Flags field, third octet of
the Extended Community: the Extended Community:
R - Router Flag (corresponds to Bit 23 of the extended community) R - Router Flag (corresponds to Bit 23 of the Extended Community)
Bit 7 of the Flags octet is defined as the "Router flag". When set, Bit 7 of the Flags field is defined as the "Router Flag". When set,
the R-bit indicates that the IPv6->MAC pair advertised in the MAC/IP the R Flag indicates that the IPv6->MAC pair advertised in the MAC/IP
Advertisement route along with the extended community belongs to a Advertisement route along with the Extended Community belongs to a
router. If the R-bit is zero, the IPv6->MAC pair belongs to a "host". 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 The receiving PE implementing the ND function will use this
information in Neighbor Advertisement messages for the associated information in Neighbor Advertisement messages for the associated
IPv6 address. This flag is ignored when the extended community is IPv6 address. This Flag has no meaning for ARP IPv4->MAC entries and
advertised with a MAC/IP route for an IPv4->MAC pair. 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) O - Override Flag (corresponds to Bit 22 of the Extended Community)
Bit 6 of the Flags octet is defined as the "Override flag". An egress Bit 6 of the Flags field is defined as the "Override Flag". An
PE will normally advertise IPv6->MAC pairs with the O-bit set, and egress PE will normally advertise IPv6->MAC pairs with the O Flag
only when IPv6 "anycast" is enabled in the BD, the PE will send an set, and only when IPv6 "anycast" is enabled in the BD or interface,
IPv6->MAC pair with the O-bit = 0. The ingress PE will install the ND the PE will send an IPv6->MAC pair with the O Flag = 0. The ingress
entry with the received O-bit and will use this information when PE will install the ND entry with the received O Flag and will use
replying to a Neighbor Solicitation for the IPv6 address. This flag this information when replying to a Neighbor Solicitation for the
is ignored when the extended community is advertised with a MAC/IP 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. route for an IPv4->MAC pair.
I - Immutable ARP/ND Binding Flag (corresponds to Bit 20 of the I - Immutable ARP/ND Binding Flag (corresponds to Bit 20 of the
extended community) Extended Community)
Bit 4 of the Flags octet is defined as the "Immutable ARP/ND binding 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 sent Flag". When set, the egress PE indicates that the IP->MAC pair sent
in a MAC/IP route along with the extended community is a configured in an EVPN MAC/IP Advertisement route along with the Extended
ARP/ND entry, and the IP address in the MAC/IP route can only be Community is a configured ARP/ND entry, and the IP address in the
bound together with the MAC address specified in the same route. EVPN MAC/IP Advertisement route can only be bound together with the
MAC address specified in the same route.
Bits 0-3 and 5 are not assigned by this document. Bits 0-3 and 5 are not assigned by this document.
3. Use of the EVPN ARP/ND Extended Community 3. Use of the EVPN ARP/ND Extended Community
An EVPN PE supporting a ND/ARP function and implementing the This section describes the relevant procedures when advertising and
propagation of the ARP/ND Flags MUST follow this procedure: processing the EVPN ARP/ND Extended Community. In all the procedures
below a "PE" must be interpreted as a "PE which supports the ND/ARP
proxy function (introduced by [RFC7432]) and implements the
propagation of the ARP/ND Flags that this document specifies".
a) Transmission of the EVPN ARP/ND Extended Community 3.1. Transmission of the EVPN ARP/ND Extended Community
A PE may learn the IPv6->MAC pair and its associated ND Flags in the When an IP->MAC entry is not learned via EVPN, a PE may learn IP->MAC
management plane or by snooping Neighbor Advertisement messages pairs in the management plane (this will create static entries in the
coming from the CE. Either way, the PE sends a MAC/IP Advertisement ARP/ND or proxy-ARP/ND table) or by snooping ARP or Neighbor
route including the learned IPv6->MAC pair and MUST send the ARP/ND Advertisement (NA) messages coming from the CE (this will create
Extended Community carrying its associated "R" and "O" Flags. 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:
If an IPv4->MAC or IPv6->MAC pair has been learned in the management o Advertised MAC/IP Advertisement routes for IPv6->MAC entries MUST
plane (it has been configured) the corresponding MAC/IP Advertisement include the ARP/ND Extended Community with the R and O Flag values
route SHOULD be sent along with an ARP/ND extended community with the associated with the entry. Those Flag values are either
flag I set. dynamically learned (from NA messages) or configured in case of
static entries.
This Extended Community does not have any impact on the rest of the o MAC/IP Advertisement routes for IPv4->MAC entries MAY include the
procedures described in [RFC7432], including the advertisement of the ARP/ND Extended Community. If the EVPN ARP/ND Extended Community
MAC Mobility Extended Community along with the MAC/IP Advertisement is advertised along with an EVPN IPv4/MAC Advertisement route, the
route. R and O Flags SHOULD be set to zero.
b) Reception of the EVPN ARP/ND Extended Community o 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.
o This Extended Community does not have any impact on the procedures
described in [RFC7432], including the advertisement of the MAC
Mobility Extended Community along with the MAC/IP Advertisement
route.
3.2. Reception of the EVPN ARP/ND Extended Community
In addition to the procedures specified in [RFC7432] a PE receiving a In addition to the procedures specified in [RFC7432] a PE receiving a
MAC/IP Advertisement route containing an IPv6 address and the ND MAC/IP Advertisement route will process the EVPN ARP/ND Extended
Extended Community MUST add the R and O Flags to the ND entry for the Community as follows:
IPv6->MAC entry and use that information in Neighbor Advertisements
when replying to a Solicitation for the IPv6 address.
A PE that implements a proxy-ND function SHOULD have an o R and O Flags processing:
administrative option to define the default Flag to be used in case
no EVPN ND Extended Community is received for a given IPv6->MAC
entry. A PE MUST ignore the received R and O Flags for a MAC/IP route
that contains an IPv4 address.
A PE receiving a MAC/IP Advertisement route containing an IPv4 or * If the EVPN MAC/IP Advertisement route contains an IPv6 address
IPv6 address and the I flag set, SHOULD install the IP->MAC entry in and the EVPN ARP/ND Extended Community, the PE MUST add the R
the ARP/ND table as "Immutable binding" entry. and O Flags to the ND entry in the ND or proxy-ND table and use
that information in Neighbor Advertisements when replying to a
Solicitation for the IPv6 address.
In a situation where a host (with a IP->MAC configured as Immutable * If no EVPN ARP/ND Extended Community is received along with the
binding) is allowed to move between PEs (that is, the associated MAC route, the PE will add the default R and O Flags to the entry.
is non-static), PEs can receive multiple MAC/IP advertisement routes The default R Flag SHOULD be an administrative choice. The
for the same IP->MAC. In such situations, MAC mobility procedures default O Flag SHOULD be 1.
dictate the reachability of the MAC. Receiving multiple MAC/IP routes
with I=1 for the same IP but different MAC is considered a
misconfiguration.
For example, consider PE1, PE2 and PE3 are attached to the same BD. * A PE MUST ignore the received R and O Flags for an EVPN MAC/IP
PE1 originates a MAC/IP route for IP1->MAC1 with I=1; later on, PE2 Advertisement route that contains an IPv4->MAC pair.
also originates a MAC/IP route IP1->MAC1 with a higher sequence
number and I=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. If for some reason, PE3 originates a MAC/IP route
for IP1->MAC2 (even with a higher sequence number), then the EVPN PEs
in the BD SHOULD 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.
A PE originating a MAC/IP route for IP1->MAC1 with I=1 MAY also o I Flag processing:
originate the route with the Static bit 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. Also, note that the use of
the flag I=1 assumes that a given IP is always bound to the same MAC
address, and therefore some of the mobility procedures described in
[EXT-MOBILITY] will not apply.
The flags SHOULD be ignored if they are advertised along with a * A PE receiving an EVPN MAC/IP Advertisement route containing an
MAC/IP Advertisement route that does not contain an IP address. 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 absense of the
EVPN ARP/ND Extended Community in a MAC/IP Advertisment route
indicates that the IP->MAC entry is not an "Immutable binding".
4. Security Considerations * 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.
* Receiving multiple EVPN MAC/IP Advertisement routes with I=1
for the same IP but different MAC is considered a
misconfiguration.
* As an example, consider PE1, PE2 and PE3 are attached to the
same BD. PE1 originates an EVPN MAC/IP Advertisement route for
IP1->MAC1 with I=1; later on, PE2 also originates an EVPN MAC/
IP Advertisement route IP1->MAC1 with a higher sequence number
and I=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. If for some reason, PE3
originates an EVPN MAC/IP Advertisement route for IP1->MAC2
(even with a higher sequence number), then the EVPN PEs in the
BD SHOULD 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.
* A PE originating an EVPN MAC/IP Advertisement route for
IP1->MAC1 with I=1 MAY also originate the route with the Static
bit 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 IP1->MAC1
immutable and static, is received from a different PE, one of
the two routes will be selected, as in the [RFC7432] case where
two MAC/IP routes with Static bit are received for the same MAC
from different PEs.
* The use of the Flag I=1 assumes that a given IP is always bound
to the same MAC address, and therefore the mobility procedures
described in [I-D.ietf-bess-evpn-irb-extended-mobility] for
"Host IP move to a new MAC" will not apply.
o 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.
4. Security Considerations
The same security considerations described in [RFC7432] apply to this The same security considerations described in [RFC7432] apply to this
document. document.
5. IANA Considerations In addition, this document adds pieces of information that impact on
the way ARP/ND entries are installed in ARP/ND and/or proxy-ARP/ND
tables, and therefore 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 Neighbor Solicitations for the IPv6 with Neighbor
Advertisement messages containing the wrong R and O Flags.
This document requests the registration of a new EVPN Extended The I Flag, or Immutable ARP/ND Binding Flag, introduces a useful
Community sub-type: security tool so that an operator makes sure 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 from
hosts injecting Gratuitous ARPs or unsolicited Neighbor Advertisement
messages for that IP address with a different MAC address will not
succeed to be programmed in ARP/ND and proxy-ARP/ND tables and
therefore will avoid attracting traffic to the spoofer.
Sub-Type Name Reference 5. IANA Considerations
0x08 ARP/ND Extended Community [this document] This document request that the Name of the currently registered value
for Sub-Type 0x08 in the EVPN Extended Community Sub-Types registry
(https://www.iana.org/assignments/bgp-extended-communities/bgp-
extended-communities.xhtml#evpn) be changed to:
+----------+---------------------------+-----------------+
| Sub-Type | Name | Reference |
+----------+---------------------------+-----------------+
| 0x08 | ARP/ND Extended Community | [this document] |
+----------+---------------------------+-----------------+
This document also requests the creation of a registry called "ARP/ND This document also requests the creation of a registry called "ARP/ND
Extended Community Flags octet" where the following allocations are Extended Community Flags" where the following initial allocations are
made: made:
Flag position Name Reference +---------------+---------------------------------+-----------------+
| Flag position | Name | Reference |
0-3 Unassigned +---------------+---------------------------------+-----------------+
4 Immutable ARP/ND Binding Flag (I) [this document] | 0-3 | Unassigned | - |
5 Unassigned | 4 | Immutable ARP/ND Binding Flag | [this document] |
6 Override Flag (O) [this document] | | (I) | |
7 Router Flag (R) [this document] | 5 | Unassigned | - |
| 6 | Override Flag (O) | [this document] |
| 7 | Router Flag (R) | [this document] |
+---------------+---------------------------------+-----------------+
The registration procedure for this registry is Standards Action. The registration procedure for this registry is Standards Action.
This registry should be located in the Border Gateway Protocol (BGP)
Extended Communities general registry
(https://www.iana.org/assignments/bgp-extended-communities/bgp-
extended-communities.xhtml).
6. References 6. Acknowledgments
6.1. Normative References The authors would like to thank Ali Sajassi for his feedback.
7. References
7.1. Normative References
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
10.17487/RFC4861, September 2007, <https://www.rfc- DOI 10.17487/RFC4861, September 2007,
editor.org/info/rfc4861>. <https://www.rfc-editor.org/info/rfc4861>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
<https://www.rfc-editor.org/info/rfc7432>. 2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March Requirement Levels", BCP 14, RFC 2119,
1997, <https://www.rfc-editor.org/info/rfc2119>. DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC2119
Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
6.2. Informative References
[EXT-MOBILITY] Malhotra, N. et al., "Extended Mobility Procedures for [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
EVPN-IRB", Work in Progress, draft-ietf-bess-evpn-irb-extended- 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
mobility-01, June 2019. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
7. Acknowledgments 7.2. Informative References
The authors would like to thank Ali Sajassi for his feedback. [I-D.ietf-bess-evpn-irb-extended-mobility]
Malhotra, N., Sajassi, A., Pattekar, A., Lingala, A.,
Rabadan, J., and J. Drake, "Extended Mobility Procedures
for EVPN-IRB", draft-ietf-bess-evpn-irb-extended-
mobility-03 (work in progress), May 2020.
Authors' Addresses Authors' Addresses
Jorge Rabadan (Editor) Jorge Rabadan (editor)
Nokia Nokia
777 E. Middlefield Road 777 Middlefield Road
Mountain View, CA 94043 USA Mountain View, CA 94043
USA
Email: jorge.rabadan@nokia.com Email: jorge.rabadan@nokia.com
Senthil Sathappan Senthil Sathappan
Nokia Nokia
701 E. Middlefield Road 701 E. Middlefield Road
Mountain View, CA 94043 USA Mountain View, CA 94043 USA
Email: senthil.sathappan@nokia.com
Email: senthil.sathappan@nokia.com
Kiran Nagaraj Kiran Nagaraj
Nokia Nokia
701 E. Middlefield Road 701 E. Middlefield Road
Mountain View, CA 94043 USA Mountain View, CA 94043 USA
Email: kiran.nagaraj@nokia.com Email: kiran.nagaraj@nokia.com
Wen Lin Wen Lin
Juniper Networks Juniper Networks
Email: wlin@juniper.net Email: wlin@juniper.net
 End of changes. 64 change blocks. 
192 lines changed or deleted 279 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/