rfc9161xml2.original.xml   rfc9161.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc [
<!ENTITY RFC7432 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <!ENTITY nbsp "&#160;">
C.7432.xml"> <!ENTITY zwsp "&#8203;">
<!ENTITY RFC4861 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <!ENTITY nbhy "&#8209;">
C.4861.xml"> <!ENTITY wj "&#8288;">
<!ENTITY RFC0826 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.0826.xml">
<!ENTITY RFC6820 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6820.xml">
<!ENTITY RFC5227 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5227.xml">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2119.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8174.xml">
<!ENTITY RFC6957 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6957.xml">
<!ENTITY RFC4862 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4862.xml">
<!ENTITY RFC9047 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.9047.xml">
]> ]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-bess-evpn-proxy-arp-nd-16"
ipr="trust200902" submissionType="IETF" updates="7432">
<!-- Generated by id2xml 1.5.0 on 2020-07-14T16:18:41Z -->
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
tf-bess-evpn-proxy-arp-nd-16" number="9161" consensus="true" ipr="trust200902" s
<?rfc sortrefs="no"?> ubmissionType="IETF" updates="7432" obsoletes="" xml:lang="en" tocInclude="true"
tocDepth="3" symRefs="true" sortRefs="true" version="3">
<?rfc text-list-symbols="o-*+"?>
<?rfc toc="yes"?>
<front> <front>
<title abbrev="EVPN Proxy-ARP/ND">Operational Aspects of Proxy-ARP/ND in <title abbrev="EVPN Proxy ARP/ND">Operational Aspects of Proxy ARP/ND in
Ethernet Virtual Private Networks</title> Ethernet Virtual Private Networks</title>
<seriesInfo name="RFC" value="9161"/>
<author fullname="Jorge Rabadan" initials="J." role="editor" <author fullname="Jorge Rabadan" initials="J." role="editor" surname="Rabada
surname="Rabadan"> n">
<organization>Nokia</organization> <organization>Nokia</organization>
<address> <address>
<postal> <postal>
<street>777 Middlefield Road</street> <street>777 Middlefield Road</street>
<city>Mountain View</city> <city>Mountain View</city>
<region>CA</region> <region>CA</region>
<code>94043</code> <code>94043</code>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<email>jorge.rabadan@nokia.com</email> <email>jorge.rabadan@nokia.com</email>
</address> </address>
</author> </author>
<author fullname="Senthil Sathappan" initials="S." surname="Sathappan"> <author fullname="Senthil Sathappan" initials="S." surname="Sathappan">
<organization>Nokia</organization> <organization>Nokia</organization>
<address> <address>
<postal> <postal>
<street>701 E. Middlefield Road</street> <street>701 E. Middlefield Road</street>
<city>Mountain View</city>
<street>Mountain View, CA 94043 USA</street> <region>CA</region>
</postal> <code>94043</code>
<country>United States of America</country>
</postal>
<email>senthil.sathappan@nokia.com</email> <email>senthil.sathappan@nokia.com</email>
</address> </address>
</author> </author>
<author fullname="Kiran Nagaraj" initials="K." surname="Nagaraj"> <author fullname="Kiran Nagaraj" initials="K." surname="Nagaraj">
<organization>Nokia</organization> <organization>Nokia</organization>
<address> <address>
<postal> <postal>
<street>701 E. Middlefield Road</street> <street>701 E. Middlefield Road</street>
<city>Mountain View</city>
<street>Mountain View, CA 94043 USA</street> <region>CA</region>
<code>94043</code>
<country>United States of America</country>
</postal> </postal>
<email>kiran.nagaraj@nokia.com</email> <email>kiran.nagaraj@nokia.com</email>
</address> </address>
</author> </author>
<author fullname="Greg Hankins" initials="G." surname="Hankins"> <author fullname="Greg Hankins" initials="G." surname="Hankins">
<organization>Nokia</organization> <organization>Nokia</organization>
<address> <address>
<email>greg.hankins@nokia.com</email> <email>greg.hankins@nokia.com</email>
</address> </address>
</author> </author>
<author fullname="Thomas King" initials="T." surname="King"> <author fullname="Thomas King" initials="T." surname="King">
<organization abbrev="DE-CIX">DE-CIX Management GmbH</organization> <organization abbrev="DE-CIX">DE-CIX Management GmbH</organization>
<address> <address>
<email>thomas.king@de-cix.net</email> <email>thomas.king@de-cix.net</email>
</address> </address>
</author> </author>
<date month="January" year="2022"/>
<workgroup>BESS Workgroup</workgroup>
<date day="6" month="October" year="2021"/> <keyword>ARP suppression
</keyword>
<workgroup>BESS Workgroup</workgroup> <keyword>flood suppression
</keyword>
<keyword>ARP unicast-forward
</keyword>
<keyword>Duplicate IP Detection
</keyword>
<abstract> <abstract>
<t>This document describes the Ethernet Virtual Private Networks (EVPN) <t>This document describes the Ethernet Virtual Private Network (EVPN)
Proxy-ARP/ND function, augmented by the capability of the ARP/ND Proxy ARP/ND function augmented by the capability of the ARP/ND
Extended Community. From that perspective this document updates the EVPN Extended Community. From that perspective, this document updates the EVPN
specification to provide more comprehensive documentation of the specification to provide more comprehensive documentation of the
operation of the Proxy-ARP/ND function. The EVPN Proxy-ARP/ND function operation of the Proxy ARP/ND function. The EVPN Proxy ARP/ND function
and the ARP/ND Extended Community help operators of Internet Exchange and the ARP/ND Extended Community help operators of Internet Exchange
Points, Data Centers, and other networks deal with IPv4 and IPv6 address Points, Data Centers, and other networks deal with IPv4 and IPv6 address
resolution issues associated with large Broadcast Domains by reducing resolution issues associated with large Broadcast Domains by reducing
and even suppressing the flooding produced by address resolution in the and even suppressing the flooding produced by address resolution in the
EVPN network.</t> EVPN network.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="sect-1" title="Terminology">
<t>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 BCP14
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when,
they appear in all capitals, as shown here.</t>
<t>ARP: Address Resolution Protocol.</t>
<t>AS-MAC: Anti-spoofing MAC. It is a especial MAC configured on all the
PEs attached to the same BD and used for the Duplicate IP Detection
procedures.</t>
<t>BD: Broadcast Domain.</t> <section anchor="sect-2" numbered="true" toc="default">
<name>Introduction</name>
<t>BUM: Broadcast, Unknown unicast and Multicast layer-2 traffic.</t> <t>As specified in <xref target="RFC7432" format="default"/>, the IP
Address field in the Ethernet Virtual Private Network (EVPN) Media
<t>CE: Customer Edge router.</t> Access Control (MAC) / IP Advertisement route may optionally carry one
of the IP addresses associated with the MAC address. A Provider Edge (PE)
<t>DAD: Duplicate Address Detection, as per <xref may learn
target="RFC4861"/>.</t> local IP-&gt;MAC pairs and advertise them in EVPN MAC/IP Advertisement
routes. Remote PEs importing those routes in the same Broadcast Domain
<t>DC: Data Center.</t> (BD) may add those IP-&gt;MAC pairs to their Proxy ARP/ND tables and
reply to local ARP Requests or Neighbor Solicitations (or
<t>EVI: EVPN Instance.</t> "unicast-forward" those packets to the owner MAC), reducing and even
suppressing, in some cases, the flooding in the EVPN network.</t>
<t>EVPN and its associated Proxy ARP/ND function are extremely useful in
Data Centers (DCs) or Internet Exchange Points (IXPs) with large Broadcast
Domains,
where the amount of ARP/ND flooded traffic causes issues on connected
routers and Customer Edges (CEs). <xref target="RFC6820" format="default"/
> describes the address
resolution problems in large DC networks.</t>
<t>This document describes the Proxy ARP/ND function in <xref
target="RFC7432" format="default"/> networks, augmented by the
capability of the ARP/ND Extended Community <xref target="RFC9047"
format="default"/>. From that perspective, this document updates <xref
target="RFC7432" format="default"/>.</t>
<t>Proxy ARP/ND may be implemented to help IXPs, DCs, and other operators
deal with the issues derived from address resolution in large Broadcast
Domains.</t>
<t>EVPN: Ethernet Virtual Private Networks, as per <xref <section anchor="sect-2.1" numbered="true" toc="default">
target="RFC7432"/>.</t> <name>The Data Center Use Case</name>
<t>As described in <xref target="RFC6820" format="default"/>, the IPv4
and IPv6 address resolution can create a lot of issues in large
DCs. In particular, the issues created by IPv4 Address
Resolution Protocol procedures may be significant.</t>
<t>On one hand, ARP Requests use broadcast MAC addresses; therefore,
any Tenant System in a large Broadcast Domain will see a large amount
of ARP traffic, which is not addressed to most of the receivers.</t>
<t>On the other hand, the flooding issue becomes even worse if some
Tenant Systems disappear from the Broadcast Domain, since some
implementations will persistently retry sending ARP Requests. As <xref
target="RFC6820" format="default"/> states, there are no clear
requirements for retransmitting ARP Requests in the absence of
replies; hence, an implementation may choose to keep retrying endlessly
even if there are no replies.</t>
<t>The amount of flooding that address resolution creates can be
mitigated by the use of EVPN and its Proxy ARP/ND function.</t>
</section>
<section anchor="sect-2.2" numbered="true" toc="default">
<name>The Internet Exchange Point Use Case</name>
<t>The implementation described in this document is especially useful
in IXP networks.</t>
<t>A typical IXP provides access to a large Layer 2 Broadcast Domain
for peering purposes (referred to as "the peering network"), where
(hundreds of) Internet routers are connected. We refer to these
Internet routers as CE devices in this section.
Because of the requirement to connect all routers to a single Layer 2
network, the peering networks use IPv4 addresses in length ranges from
/21 to /24 (and even bigger for IPv6), which can create very large
Broadcast Domains.
<t>GARP: Gratuitous ARP message.</t> This peering network is transparent to the CEs and
therefore floods any ARP Requests or NS messages to all the CEs in the
network. Gratuitous ARP and NA messages are flooded to all the CEs
too.</t>
<t>In these IXP networks, most of the CEs are typically peering
routers and roughly all the Broadcast, Unknown Unicast, and Multicast
(BUM) traffic is originated by the ARP and ND address resolution
procedures. This ARP/ND BUM traffic causes significant data volumes
that reach every single router in the peering network. Since the
ARP/ND messages are processed in "slow path" software processors and
they take high priority in the routers, heavy loads of ARP/ND traffic
can cause some routers to run out of resources. CEs disappearing from
the network may cause address resolution explosions that can make a
router with limited processing power fail to keep BGP sessions
running.</t>
<t>The issue might be better in IPv6 routers if Multicast Listener
Discovery (MLD) snooping was enabled, since ND uses an SN-multicast
address in NS messages; however, ARP uses broadcast and has to be
processed by all the routers in the network. Some routers may also be
configured to broadcast periodic Gratuitous ARPs (GARPs) <xref
target="RFC5227" format="default"/>. For IPv6, the fact that IPv6 CEs
have more than one IPv6 address contributes to the growth of ND
flooding in the network. The amount of ARP/ND flooded traffic grows
linearly with the number of IXP participants; therefore, the issue can
only grow worse as new CEs are added.</t>
<t>In order to deal with this issue, IXPs have developed certain
solutions over the past years. While these solutions may mitigate the
issues of address resolution in large broadcast domains, EVPN
provides new more efficient possibilities to IXPs. EVPN and its
Proxy ARP/ND function may help solve the issue in a distributed and
scalable way, fully integrated with the PE network.</t>
</section>
</section>
<t>IP-&gt;MAC: an IP address associated to a MAC address. IP-&gt;MAC <section anchor="sect-1" numbered="true" toc="default">
entries are programmed in Proxy-ARP/ND tables and may be of three <name>Terminology</name>
different types: dynamic, static or EVPN-learned.</t>
<t>IXP: Internet eXchange Point.</t> <t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<t>IXP-LAN: the IXP's large Broadcast Domain to where Internet routers <dl indent="12">
are connected.</t> <dt>ARP:
</dt>
<dd>Address Resolution Protocol
</dd>
<t>LAG: Link Aggregation Group.</t> <dt>AS-MAC:
</dt>
<dd>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.
</dd>
<t>MAC or IP DA: MAC or IP Destination Address.</t> <dt>BD:
</dt>
<dd>Broadcast Domain
</dd>
<t>MAC or IP SA: MAC or IP Source Address.</t> <dt>BUM:
</dt>
<dd>Broadcast, Unknown Unicast, and Multicast Layer 2 traffic
</dd>
<t>ND: Neighbor Discovery Protocol.</t> <dt>CE:
</dt>
<dd>Customer Edge router
</dd>
<t>NS: Neighbor Solicitation message.</t> <dt>DAD:
</dt>
<dd>Duplicate Address Detection, as per <xref target="RFC4861"/>
</dd>
<t>NA: Neighbor Advertisement.</t> <dt>DC:
</dt>
<dd>Data Center
</dd>
<t>NUD: Neighbor Unreachability Detection, as per <xref <dt>EVI:
target="RFC4861"/>.</t> </dt>
<dd>EVPN Instance
</dd>
<t>O Flag: Override Flag in NA messages, as per <xref <dt>EVPN:
target="RFC4861"/>.</t> </dt>
<dd>Ethernet Virtual Private Network, as per <xref target="RFC7432"/>
</dd>
<t>PE: Provider Edge router.</t> <dt>GARP:
</dt>
<dd>Gratuitous ARP
</dd>
<t>R Flag: Router Flag in NA messages, as per <xref <dt>IP->MAC:
target="RFC4861"/>.</t> </dt>
<dd>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.
</dd>
<t>RT2: EVPN Route type 2 or EVPN MAC/IP Advertisement route, as per <dt>IXP:
<xref target="RFC7432"/>.</t> </dt>
<dd>Internet Exchange Point
</dd>
<t>S Flag: Solicited Flag in NA messages, as per <xref <dt>IXP-LAN:
target="RFC4861"/>.</t> </dt>
<dd>The IXP's large Broadcast Domain to where Internet routers are conn
ected.
</dd>
<t>SN-multicast address: Solicited-Node IPv6 multicast address used by <dt>LAG:
NS messages.</t> </dt>
<dd>Link Aggregation Group
</dd>
<t>TLLA: Target Link Layer Address, as per <xref target="RFC4861"/>.</t> <dt>MAC or IP DA:
</dt>
<dd>MAC or IP Destination Address
</dd>
<t>VPLS: Virtual Private LAN Service.</t> <dt>MAC or IP SA:
</dt>
<dd>MAC or IP Source Address
</dd>
<t>This document assumes familiarity with the terminology used in <xref <dt>ND:
target="RFC7432"/>.</t> </dt>
</section> <dd>Neighbor Discovery
</dd>
<section anchor="sect-2" title="Introduction"> <dt>NS:
<t>As specified in <xref target="RFC7432"/> the IP Address field in the </dt>
Ethernet Virtual Private Networks (EVPN) MAC/IP Advertisement route may <dd>Neighbor Solicitation
optionally carry one of the IP addresses associated with the MAC </dd>
address. A PE may learn local IP-&gt;MAC pairs and advertise them in
EVPN MAC/IP Advertisement routes. Remote PEs importing those routes in
the same Broadcast Domain (BD) may add those IP-&gt;MAC pairs to their
Proxy-ARP/ND tables and reply to local ARP requests or Neighbor
Solicitations (or 'unicast-forward' those packets to the owner MAC),
reducing and even suppressing in some cases the flooding in the EVPN
network.</t>
<t>EVPN and its associated Proxy-ARP/ND function are extremely useful in <dt>NA:
DCs or Internet Exchange Points (IXPs) with large broadcast domains, </dt>
where the amount of ARP/ND flooded traffic causes issues on connected <dd>Neighbor Advertisement
routers and CEs. <xref target="RFC6820"/> describes the address </dd>
resolution problems in large DC networks.</t>
<t>This document describes the Proxy-ARP/ND function in <xref <dt>NUD:
target="RFC7432"/> networks, augmented by the capability of the ARP/ND </dt>
Extended Community <xref target="RFC9047"/>. From that perspective this <dd>Neighbor Unreachability Detection, as per <xref target="RFC4861"/>
document updates <xref target="RFC7432"/>.</t> </dd>
<t>Proxy-ARP/ND may be implemented to help IXPs, DCs and other operators <dt>O Flag:
deal with the issues derived from address resolution in large broadcast </dt>
domains.</t> <dd>Override Flag in NA messages, as per <xref target="RFC4861"/>
</dd>
<section anchor="sect-2.1" title="The Data Center Use-Case"> <dt>PE:
<t>As described in <xref target="RFC6820"/> the IPv4 and IPv6 address </dt>
resolution can create a lot of issues in large DCs. In particular, the <dd>Provider Edge router
issues created by the IPv4 Address Resolution Protocol procedures may </dd>
be significant.</t>
<t>On one hand, ARP Requests use broadcast MAC addresses, therefore <dt>R Flag:
any Tenant System in a large Broadcast Domain will see a large amount </dt>
of ARP traffic, which is not addressed to most of the receivers.</t> <dd>Router Flag in NA messages, as per <xref target="RFC4861" format="d
efault"/>
</dd>
<t>On the other hand, the flooding issue becomes even worse if some <dt>RT2:
Tenant Systems disappear from the broadcast domain, since some </dt>
implementations will persistently retry sending ARP Requests. As <xref <dd>EVPN Route type 2 or EVPN MAC/IP Advertisement route, as per
target="RFC6820"/> states, there are no clear requirements for <xref target="RFC7432" format="default"/>
retransmitting ARP Requests in the absence of replies, hence an </dd>
implementation may choose to keep retrying endlessly even if there are
no replies.</t>
<t>The amount of flooding that address resolution creates can be <dt>S Flag:
mitigated by the use of EVPN and its Proxy-ARP/ND function.</t> </dt>
</section> <dd>Solicited Flag in NA messages, as per <xref target="RFC4861"
format="default"/>
</dd>
<section anchor="sect-2.2" title="The Internet Exchange Point Use-Case"> <dt>SN-multicast address:
<t>The implementation described in this document is especially useful </dt>
in IXP networks.</t> <dd>Solicited-Node IPv6 multicast address used by NS messages
</dd>
<t>A typical IXP provides access to a large layer-2 Broadcast Domain <dt>TLLA:
for peering purposes (referred to as 'the peering network'), where </dt>
(hundreds of) Internet routers are connected. We refer to these <dd>Target Link Layer Address, as per <xref target="RFC4861" format="de
Internet routers as Customer Edge (CE) devices in this section. fault"/>
Because of the requirement to connect all routers to a single layer-2 </dd>
network the peering networks use IPv4 addresses in length ranges from
/21 to /24 (and even bigger for IPv6), which can create very large
broadcast domains. This peering network is transparent to the CEs, and
therefore, floods any ARP request or NS messages to all the CEs in the
network. Gratuitous ARP and NA messages are flooded to all the CEs
too.</t>
<t>In these IXP networks, most of the CEs are typically peering <dt>VPLS:
routers and roughly all the BUM traffic is originated by the ARP and </dt>
ND address resolution procedures. This ARP/ND BUM traffic causes <dd>Virtual Private LAN Service
significant data volumes that reach every single router in the peering </dd>
network. Since the ARP/ND messages are processed in "slow path"
software processors and they take high priority in the routers, heavy
loads of ARP/ND traffic can cause some routers to run out of
resources. CEs disappearing from the network may cause address
resolution explosions that can make a router with limited processing
power fail to keep BGP sessions running.</t>
<t>The issue might be better in IPv6 routers if MLD-snooping was </dl>
enabled, since ND uses SN-multicast address in NS messages; however,
ARP uses broadcast and has to be processed by all the routers in the
network. Some routers may also be configured to broadcast periodic
GARPs <xref target="RFC5227"/>. For IPv6, the fact that IPv6 CEs have
more than one IPv6 address contributes to the growth of ND flooding in
the network. The amount of ARP/ND flooded traffic grows linearly with
the number of IXP participants, therefore the issue can only grow
worse as new CEs are added.</t>
<t>In order to deal with this issue, IXPs have developed certain <t>This document assumes familiarity with the terminology used in <xref ta
solutions over the past years. While these solutions may mitigate the rget="RFC7432" format="default"/>.</t>
issues of address resolution in large broadcasts domains, EVPN
provides new more efficient possibilities to IXPs. EVPN and its
Proxy-ARP/ND function may help solve the issue in a distributed and
scalable way, fully integrated with the PE network.</t>
</section>
</section> </section>
<section anchor="sect-4" title="Solution Description"> <section anchor="sect-4" numbered="true" toc="default">
<t><xref target="ure-proxy-arp-nd-network-example"/> illustrates an <name>Solution Description</name>
example EVPN network where the Proxy-ARP/ND function is enabled.</t> <t><xref target="ure-proxy-arp-nd-network-example" format="default"/> illu
strates an
<figure anchor="ure-proxy-arp-nd-network-example" example EVPN network where the Proxy ARP/ND function is enabled.</t>
title="Proxy-ARP/ND network example"> <figure anchor="ure-proxy-arp-nd-network-example">
<artwork><![CDATA[ <name>Proxy ARP/ND Network Example</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
BD1 BD1
Proxy-ARP/ND Proxy ARP/ND
+------------+ +------------+
IP1/M1 +----------------------------+ |IP1->M1 EVPN| IP1/M1 +----------------------------+ |IP1->M1 EVPN|
GARP --->Proxy-ARP/ND | |IP2->M2 EVPN| GARP --->Proxy ARP/ND | |IP2->M2 EVPN|
+---+ +--------+ RT2(IP1/M1) | |IP3->M3 sta | +---+ +--------+ RT2(IP1/M1) | |IP3->M3 sta |
|CE1+------| BD1 | ------> +------+---|IP4->M4 dyn | |CE1+------| BD1 | ------> +------+---|IP4->M4 dyn |
+---+ +--------+ | +------------+ +---+ +--------+ | +------------+
PE1 | +--------+ Who has IP1? PE1 | +--------+ Who has IP1?
| EVPN | | BD1 | <----- +---+ | EVPN | | BD1 | <----- +---+
| EVI1 | | | -----> |CE3| | EVI1 | | | -----> |CE3|
IP2/M2 | | | | IP1->M1 +---+ IP2/M2 | | | | IP1->M1 +---+
GARP --->Proxy-ARP/ND | +--------+ | IP3/M3 GARP --->Proxy ARP/ND | +--------+ | IP3/M3
+---+ +--------+ RT2(IP2/M2) | | +---+ +--------+ RT2(IP2/M2) | |
|CE2+----| BD1 | ------> +--------------+ |CE2+----| BD1 | ------> +--------------+
+---+ +--------+ PE3| +---+ +---+ +--------+ PE3| +---+
PE2 | +----+CE4| PE2 | +----+CE4|
+----------------------------+ +---+ +----------------------------+ +---+
<---IP4/M4 GARP <---IP4/M4 GARP
]]></artwork> ]]></artwork>
</figure> </figure>
<t>When the Proxy ARP/ND function is enabled in a BD (Broadcast Domain)
<t>When the Proxy-ARP/ND function is enabled in a BD (Broadcast Domain)
of the EVPN PEs, each PE creates a Proxy table specific to that BD that of the EVPN PEs, each PE creates a Proxy table specific to that BD that
can contain three types of Proxy-ARP/ND entries:</t> can contain three types of Proxy ARP/ND entries:</t>
<t><list style="letters">
<t>Dynamic entries: learned by snooping CE's ARP and ND messages.
For instance, IP4-&gt;M4 in <xref
target="ure-proxy-arp-nd-network-example"/>.</t>
<t>Static entries: provisioned on the PE by the management system.
For instance, IP3-&gt;M3 in <xref
target="ure-proxy-arp-nd-network-example"/>.</t>
<t>EVPN-learned entries: learned from the IP/MAC information encoded <dl newline="true">
in the received RT2's coming from remote PEs. For instance,
IP1-&gt;M1 and IP2-&gt;M2 in <xref
target="ure-proxy-arp-nd-network-example"/>.</t>
</list></t>
<t>As a high level example, the operation of the EVPN Proxy-ARP/ND <dt>Dynamic entries:
function in the network of <xref </dt>
target="ure-proxy-arp-nd-network-example"/> is described below. In this <dd>Learned by snooping a CE's ARP and ND messages; for instance,
example we assume IP1, IP2 and IP3 are IPv4 addresses:</t> see IP4-&gt;M4 in <xref target="ure-proxy-arp-nd-network-example"
format="default"/>.
</dd>
<t><list style="numbers"> <dt>Static entries:
<t>Proxy-ARP/ND is enabled in BD1 of PE1, PE2 and PE3.</t> </dt>
<dd>Provisioned on the PE by the management system; for instance,
see IP3-&gt;M3 in <xref target="ure-proxy-arp-nd-network-example"
format="default"/>.
</dd>
<t>The PEs start adding dynamic, static and EVPN-learned entries to <dt>EVPN-learned entries:
their Proxy tables:<list style="letters"> </dt>
<?rfc subcompact="yes"?> <dd>Learned from the IP/MAC information encoded in the received RT2's
coming from remote PEs; for instance, see IP1-&gt;M1 and IP2-&gt;M2 in
<xref target="ure-proxy-arp-nd-network-example" format="default"/>.
</dd>
</dl>
<t>PE3 adds IP1-&gt;M1 and IP2-&gt;M2 based on the EVPN routes <t>As a high-level example, the operation of the EVPN Proxy ARP/ND function in
the network of <xref target="ure-proxy-arp-nd-network-example"
format="default"/> is described below. In this example, we assume IP1, IP2, and
IP3 are IPv4 addresses:</t>
<ol spacing="normal" type="1">
<li>Proxy ARP/ND is enabled in BD1 of PE1, PE2, and PE3.</li>
<li>
<t>The PEs start adding dynamic, static, and EVPN-learned entries to
their Proxy tables:</t>
<ol spacing="normal" type="a">
<li>PE3 adds IP1-&gt;M1 and IP2-&gt;M2 based on the EVPN routes
received from PE1 and PE2. Those entries were previously learned received from PE1 and PE2. Those entries were previously learned
as dynamic entries in PE1 and PE2 respectively, and advertised as dynamic entries in PE1 and PE2, respectively, and advertised
in BGP EVPN.</t> in BGP EVPN.</li>
<li>PE3 adds IP4-&gt;M4 as dynamic. This entry is learned by
<t>PE3 adds IP4-&gt;M4 as dynamic. This entry is learned by snooping the corresponding ARP messages sent by CE4.</li>
snooping the corresponding ARP messages sent by CE4.</t> <li>An operator also provisions the static entry IP3-&gt;M3.</li>
</ol>
<t>An operator also provisions the static entry IP3-&gt;M3.</t> </li>
<li>
<?rfc subcompact="no"?>
</list></t>
<t>When CE3 sends an ARP Request asking for the MAC address of IP1, <t>When CE3 sends an ARP Request asking for the MAC address of IP1,
PE3 will:<list style="letters"> PE3 will:</t>
<?rfc subcompact="yes"?> <ol spacing="normal" type="a">
<li>Intercept the ARP Request and perform a Proxy ARP lookup for
<t>Intercept the ARP Request and perform a Proxy-ARP lookup for IP1.</li>
IP1.</t> <li>If the lookup is successful (as in <xref target="ure-proxy-arp-n
d-network-example" format="default"/>), PE3 will send an
<t>If the lookup is successful (as in <xref
target="ure-proxy-arp-nd-network-example"/>), PE3 will send an
ARP Reply with IP1-&gt;M1. The ARP Request will not be flooded ARP Reply with IP1-&gt;M1. The ARP Request will not be flooded
to the EVPN network or any other local CEs.</t> to the EVPN network or any other local CEs.</li>
<li>If the lookup is not successful, PE3 will flood the ARP
<t>If the lookup is not successful, PE3 will flood the ARP Request in the EVPN network and the other local CEs.</li>
Request in the EVPN network and the other local CEs.</t> </ol>
</li>
<?rfc subcompact="no"?> </ol>
</list></t> <t>In the same example, if we assume IP1, IP2, IP3, and IP4 are now IPv6
</list></t> addresses and Proxy ARP/ND is enabled in BD1:</t>
<ol spacing="normal" type="1"><li>
<t>In the same example, if we assume IP1, IP2, IP3 and IP4 are now IPv6 <t>PEs will start adding entries in a similar way as they would for IP
addresses and Proxy-ARP/ND is enabled in BD1:</t> v4;
however, there are some differences:</t>
<t><list style="numbers"> <ol spacing="normal" type="a"><li>IP1-&gt;M1 and IP2-&gt;M2 are
<t>PEs will start adding entries in a similar way as for IPv4, learned as dynamic entries in PE1 and PE2, respectively, by snooping
however there are some differences:<list style="letters"> NA messages and not by snooping NS messages. In the IPv4 case, any
<t>IP1-&gt;M1 and IP2-&gt;M2 are learned as dynamic entries in ARP frame can be snooped to learn the dynamic Proxy ARP entry. When
PE1 and PE2 respectively, by snooping NA messages and not by learning the dynamic entries, the R and O Flags contained in the
snooping NS messages. In the IPv4 case, any ARP frame can be snooped NA messages will be added to the Proxy ND entries too.</li>
snooped to learn the dynamic Proxy-ARP entry. When learning the <li>PE1 and PE2 will advertise those entries in EVPN MAC/IP
dynamic entries, the R and O Flags contained in the snooped NA
messages will be added to the Proxy-ND entries too.</t>
<t>PE1 and PE2 will advertise those entries in EVPN MAC/IP
Advertisement routes, including the corresponding learned R and Advertisement routes, including the corresponding learned R and
O Flags in the ARP/ND Extended Community.</t> O Flags in the ARP/ND Extended Community.</li>
<li>PE3 also adds IP4-&gt;M4 as dynamic after snooping an NA
<t>PE3 also adds IP4-&gt;M4 as dynamic, after snooping an NA message sent by CE4.</li>
message sent by CE4.</t> </ol>
</list></t> </li>
<li>When CE3 sends an NS message asking for the MAC address of IP1,
<t>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
PE3 behaves as in the IPv4 example, by intercepting the NS, doing a a
lookup on the IP and replying with an NA if the lookup is 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 successful. If it is successful, the NS is not flooded to the EVPN
PEs or any other local CEs.</t> PEs or any other local CEs.</li>
<li>If the lookup is not successful, PE3 will flood the NS to remote
<t>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 EVPN PEs attached to the same BD and the other local CEs as in the
IPv4 case.</t> IPv4 case.</li>
</list></t> </ol>
<t>As PE3 learns more and more host entries in the Proxy ARP/ND table,
<t>As PE3 learns more and more host entries in the Proxy-ARP/ND table,
the flooding of ARP Request messages among PEs is reduced and in some the flooding of ARP Request messages among PEs is reduced and in some
cases it can even be suppressed. In a network where most of the cases, it can even be suppressed. In a network where most of the
participant CEs are not moving between PEs and they advertise their participant CEs are not moving between PEs and are advertising their
presence with GARPs or unsolicited-NA messages, the ARP/ND flooding presence with GARPs or unsolicited-NA messages, the ARP/ND flooding
among PEs, as well as the unknown unicast flooding, can practically be among PEs, as well as the unknown unicast flooding, can practically be
suppressed. In an EVPN-based IXP network, where all the entries are suppressed. In an EVPN-based IXP network, where all the entries are
Static, the ARP/ND flooding among PEs is in fact totally suppressed.</t> static, the ARP/ND flooding among PEs is in fact totally suppressed.</t>
<t>In a network where CEs move between PEs, the Proxy ARP/ND function
<t>In a network where CEs move between PEs, the Proxy-ARP/ND function
relies on the CE signaling its new location via GARP or unsolicited-NA relies on the CE signaling its new location via GARP or unsolicited-NA
messages so that tables are immediately updated. If a CE moves messages so that tables are immediately updated. If a CE moves
"silently", that is, without issuing any GARP or NA message upon getting "silently", that is, without issuing any GARP or NA message upon getting
attached to the destination PE, the mechanisms described in <xref attached to the destination PE, the mechanisms described in <xref target="
target="sect-4.4"/> make sure that the Proxy-ARP/ND tables are sect-4.4" format="default"/> make sure that the Proxy ARP/ND tables are
eventually updated.</t> eventually updated.</t>
<section numbered="true" toc="default">
<section title="Proxy-ARP/ND Sub-Functions"> <name>Proxy ARP/ND Sub-functions</name>
<t>The Proxy-ARP/ND function can be structured in six sub-functions or <t>The Proxy ARP/ND function can be structured in six sub-functions or
procedures:</t> procedures:</t>
<ol spacing="normal" type="1"><li>Learning sub-function</li>
<t><list style="numbers"> <li>Reply sub-function</li>
<t>Learning sub-function</t> <li>Unicast-forward sub-function</li>
<li>Maintenance sub-function</li>
<t>Reply sub-function</t> <li>Flood handling sub-function</li>
<li>Duplicate IP detection sub-function</li>
<t>Unicast-forward sub-function</t> </ol>
<t>A Proxy ARP/ND implementation <bcp14>MUST</bcp14> at least support
<t>Maintenance sub-function</t> the Learning, Reply, Maintenance, and duplicate IP detection
sub-functions. The following sections describe each individual
<t>Flood handling sub-function</t> sub-function.</t>
<t>Duplicate IP detection sub-function</t>
</list></t>
<t>A Proxy-ARP/ND implementation MUST at least support the Learning,
Reply, Maintenance, and Duplicate IP detection sub-functions. The
following sections describe each individual sub-function.</t>
</section> </section>
<section anchor="sect-4.1" numbered="true" toc="default">
<section anchor="sect-4.1" title="Learning Sub-Function"> <name>Learning Sub-function</name>
<t>A Proxy-ARP/ND implementation in an EVPN BD MUST support dynamic <t>A Proxy ARP/ND implementation in an EVPN BD <bcp14>MUST</bcp14>
and EVPN-learned entries, and SHOULD support static entries.</t> support dynamic and EVPN-learned entries and <bcp14>SHOULD</bcp14>
support static entries.</t>
<t>Static entries are provisioned from the management plane. A static <t>Static entries are provisioned from the management plane. A static
entry is configured on the PE attached to the host using the IP entry is configured on the PE attached to the host using the IP
address in that entry. The provisioned static IP-&gt;MAC entry MUST be address in that entry. The provisioned static IP-&gt;MAC entry
advertised in EVPN with an ARP/ND Extended Community where the <bcp14>MUST</bcp14> be advertised in EVPN with an ARP/ND Extended
Immutable ARP/ND Binding Flag (I) is set to 1, as per <xref Community where the Immutable ARP/ND Binding Flag (I) is set to 1, as
target="RFC9047"/>. When the I flag in the ARP/ND Extended Community per <xref target="RFC9047" format="default"/>. When the I Flag in the
is 1, the advertising PE indicates that the IP address must not be ARP/ND Extended Community is 1, the advertising PE indicates that the
associated to a MAC, other than the one included in the EVPN MAC/IP IP address must not be associated to a MAC other than the one included
Advertisement route. The advertisement of I=1 in the ARP/ND Extended in the EVPN MAC/IP Advertisement route. The advertisement of I = 1 in
Community is compatible with any value of the Sticky bit (S) or the ARP/ND Extended Community is compatible with any value of the
Sequence Number in the <xref target="RFC7432"/> MAC Mobility Extended Sticky bit (S) or sequence number in the <xref target="RFC7432"
Community. Note that the I bit in the ARP/ND Extended Community refers format="default"/> MAC Mobility Extended Community. Note that the
to the immutable configured association between the IP and the MAC I bit in the ARP/ND Extended Community refers to the immutable
address in the IP-&gt;MAC binding, whereas the S bit in the MAC configured association between the IP and the MAC address in the
Mobility Extended Community refers to the fact that the advertised MAC IP-&gt;MAC binding, whereas the S bit in the MAC Mobility Extended
address is not subject to the <xref target="RFC7432"/> mobility Community refers to the fact that the advertised MAC address is not
subject to the <xref target="RFC7432" format="default"/> mobility
procedures.</t> procedures.</t>
<t>An entry may associate a configured static IP to a list of <t>An entry may associate a configured static IP to a list of
potential MACs, i.e. IP1-&gt;(MAC1,MAC2..MACN). Until a frame potential MACs, i.e., IP1-&gt;(MAC1,MAC2..MACN). Until a frame
(including local ARP/NA message) is received from the CE, the PE will (including a local ARP/NA message) is received from the CE, the PE will
not advertise any IP1-&gt;MAC in EVPN. Upon receiving traffic from the not advertise any IP1-&gt;MAC in EVPN. Upon receiving traffic from the
CE, the PE will check that the source MAC, E.g., MAC1, is included in CE, the PE will check that the source MAC, e.g., MAC1, is included in
the list of allowed MACs. Only in that case, the PE will activate the the list of allowed MACs. Only in that case, the PE will activate the
IP1-&gt;MAC1 and advertise only that IP1 and MAC1 in an EVPN MAC/IP IP1-&gt;MAC1 and advertise only that IP1 and MAC1 in an EVPN MAC/IP
Advertisement route.</t> Advertisement route.</t>
<t>The PE <bcp14>MUST</bcp14> create EVPN-learned entries from the recei
<t>The PE MUST create EVPN-learned entries from the received valid ved valid
EVPN MAC/IP Advertisement routes containing a MAC and IP address.</t> EVPN MAC/IP Advertisement routes containing a MAC and IP address.</t>
<t>Dynamic entries are learned in different ways depending on whether <t>Dynamic entries are learned in different ways depending on whether
the entry contains an IPv4 or IPv6 address:</t> the entry contains an IPv4 or IPv6 address:</t>
<t><list style="letters"> <dl newline="true">
<t>Proxy-ARP dynamic entries: <list style="empty">
<t>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.</t>
</list></t>
<t>Proxy-ND dynamic entries:<list style="empty"> <dt>Proxy ARP dynamic entries:
<t>The PE MUST snoop the NA messages (Ethertype 0x86dd, ICMPv6 </dt>
type 136) received from the CEs attached to the BD and learn <dd>The PE <bcp14>MUST</bcp14> snoop all ARP packets (that is, all
dynamic entries from the Target Address and TLLA information. frames with Ethertype 0x0806) received from the CEs attached to the
NA messages received from remote EVPN PEs are not snooped. A BD in order to learn dynamic entries. ARP packets received from
PE implementing Proxy-ND as in this document MUST NOT create remote EVPN PEs attached to the same BD are not snooped. The
dynamic IP-&gt;MAC entries from NS messages, since they don't Learning function will add the sender MAC and sender IP of the
contain the R Flag required by the Proxy-ND reply function. snooped ARP packet to the Proxy ARP table. Note that a MAC or an IP
See <xref target="sect-4.1.1"/> for more information about the address with value 0 <bcp14>SHOULD NOT</bcp14> be learned.
R Flag.</t> </dd>
<t>This document specifies an "anycast" capability that can be <dt>Proxy ND dynamic entries:
configured for the proxy-ND function of the PE, and affects </dt>
how dynamic Proxy-ND entries are learned based on the O Flag <dd>
of the snooped NA messages. If the O Flag is zero in the <t>The PE <bcp14>MUST</bcp14> snoop the NA messages (Ethertype
received NA message, the IP-&gt;MAC SHOULD only be learned in 0x86dd, ICMPv6 type 136) received from the CEs attached to the BD
case the IPv6 "anycast" capability is enabled in the BD. and learn dynamic entries from the Target Address and TLLA
Irrespective, an NA message with O Flag = 0 will be normally information. NA messages received from remote EVPN PEs are not
forwarded by the PE based on a MAC DA lookup.</t> snooped. A PE implementing Proxy ND as in this document
</list></t> <bcp14>MUST NOT</bcp14> create dynamic IP-&gt;MAC entries from NS
</list></t> messages because they don't contain the R Flag required by the
Proxy ND reply function. See <xref target="sect-4.1.1"
format="default"/> for more information about the R Flag.</t>
<t>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-&gt;MAC <bcp14>SHOULD</bcp14> 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.
</t>
</dd>
<t>The following procedure associated to the Learning sub-function is </dl>
RECOMMENDED:</t>
<t><list style="symbols"> <t>The following procedure associated to the Learning sub-function is
<t>When a new Proxy-ARP/ND EVPN or static active entry is learned <bcp14>RECOMMENDED</bcp14>:</t>
(or provisioned), the PE SHOULD send a GARP or unsolicited-NA <ul spacing="normal">
message to all the connected access CEs. The PE SHOULD send a GARP <li>When a new Proxy ARP/ND EVPN or static active entry is learned
(or provisioned), the PE <bcp14>SHOULD</bcp14> send a GARP or unsoli
cited-NA
message to all the connected access CEs. The PE <bcp14>SHOULD</bcp14
> send a GARP
or unsolicited-NA message for dynamic entries only if the ARP/NA or unsolicited-NA message for dynamic entries only if the ARP/NA
message that previously created the entry on the PE was NOT message that previously created the entry on the PE was NOT
flooded to all the local connected CEs before. This flooded to all the local connected CEs before. This
GARP/unsolicited-NA message makes sure the CE ARP/ND caches are GARP/unsolicited-NA message makes sure the CE ARP/ND caches are
updated even if the ARP/NS/NA messages from CEs connected to updated even if the ARP/NS/NA messages from CEs connected to
remote PEs are not flooded in the EVPN network.</t> remote PEs are not flooded in the EVPN network.</li>
</list></t> </ul>
<t>Note that if a Static entry is provisioned with the same IP as an <t>Note that if a static entry is provisioned with the same IP as an
existing EVPN-learned or Dynamic entry, the Static entry takes existing EVPN-learned or dynamic entry, the static entry takes
precedence.</t> precedence.</t>
<t>In case of a PE reboot, the static and EVPN entries will be <t>In case of a PE reboot, the static and EVPN entries will be
re-added as soon as the PE is back online and receives all the EVPN re-added as soon as the PE is back online and receives all the EVPN
routes for the BD. However, the dynamic entries will be gone. Due to routes for the BD. However, the dynamic entries will be gone. Due to
that reason, new NS and ARP Requests will be flooded by the PE to that reason, new NS and ARP Requests will be flooded by the PE to
remote PEs and dynamic entries gradually re-learned again.</t> remote PEs and dynamic entries gradually relearned again.</t>
<section anchor="sect-4.1.1" title="Proxy-ND and the NA Flags"> <section anchor="sect-4.1.1" numbered="true" toc="default">
<t><xref target="RFC4861"/> describes the use of the R Flag in IPv6 <name>Proxy ND and the NA Flags</name>
<t><xref target="RFC4861" format="default"/> describes the use of the
R Flag in IPv6
address resolution:</t> address resolution:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Nodes capable of routing IPv6 packets must reply to NS
<t>Nodes capable of routing IPv6 packets must reply to NS messages with NA messages where the R Flag is set (R Flag = 1).</li>
messages with NA messages where the R Flag is set (R <li>Hosts that are not able to route IPv6 packets must indicate
Flag=1).</t>
<t>Hosts that are not able to route IPv6 packets must indicate
that inability by replying with NA messages that contain R that inability by replying with NA messages that contain R
Flag=0.</t> Flag = 0.</li>
</list></t> </ul>
<t>The use of the R Flag in NA messages has an impact on how hosts <t>The use of the R Flag in NA messages has an impact on how hosts
select their default gateways when sending packets off-link, as per select their default gateways when sending packets off-link, as per
<xref target="RFC4861"/>:</t> <xref target="RFC4861" format="default"/>:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Hosts build a Default Router List based on the received RAs
<t>Hosts build a Default Router List based on the received RAs and NAs with R Flag = 1. Each cache entry has an IsRouter flag,
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 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 Flag in the received NAs. A host can choose one or more Default
Routers when sending packets off-link.</t> Routers when sending packets off-link.</li>
<li>In those cases where the IsRouter flag changes from TRUE to
<t>In those cases where the IsRouter flag changes from TRUE to FALSE as a result of an NA update, the node must remove that
FALSE as a result of a NA update, the node must remove that router from the Default Router List and update the Destination
router from the Default Router List and update the Destination Cache entries for all destinations using that neighbor as a
Cache entries for all destinations using that neighbor as a router, as specified in <xref target="RFC4861" sectionFormat="of"
router, as specified in <xref target="RFC4861"/> section 7.3.3. section="7.3.3" format="default"/>. This is needed to detect when
This is needed to detect when a node that is used as a router a node that is used as a router stops forwarding packets due to
stops forwarding packets due to being configured as a host.</t> being configured as a host.</li>
</list></t> </ul>
<t>The R and O Flags for a Proxy ARP/ND entry will be learned in
<t>The R Flag and O Flag for a Proxy-ARP/ND entry will be learned in
the following ways:</t> the following ways:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>The R Flag information <bcp14>SHOULD</bcp14> be added to the
<t>The R Flag information SHOULD be added to the Static entries static entries by the management interface. The O Flag information
by the management interface. The O Flag information MAY also be <bcp14>MAY</bcp14> also be added by the management interface. If
added by the management interface. If the R and O Flags are not the R and O Flags are not configured, the default value is 1.</li>
configured, the default value is 1.</t> <li>Dynamic entries <bcp14>SHOULD</bcp14> learn the R Flag and
<bcp14>MAY</bcp14> learn the O Flag from the snooped NA messages
<t>Dynamic entries SHOULD learn the R Flag and MAY learn the O used to learn the IP-&gt;MAC itself.</li>
Flag from the snooped NA messages used to learn the IP-&gt;MAC <li>EVPN-learned entries <bcp14>SHOULD</bcp14> learn the R Flag
itself.</t> and <bcp14>MAY</bcp14> learn the O Flag from the ARP/ND Extended
Community <xref target="RFC9047" format="default"/> received from
<t>EVPN-learned entries SHOULD learn the R Flag and MAY learn EVPN along with the RT2 used to learn the IP-&gt;MAC itself. If no
the O Flag from the ARP/ND Extended Community <xref ARP/ND Extended Community is received, the PE will add a
target="RFC9047"/> received from EVPN along with the RT2 used to configured R Flag / O Flag to the entry. These configured R and O
learn the IP-&gt;MAC itself. If no ARP/ND Extended Community is Flags <bcp14>MAY</bcp14> be an administrative choice with a
received, the PE will add a configured R Flag/O Flag to the default value of 1. The configuration of this administrative
entry. These configured R and O Flags MAY be an administrative choice provides a backwards-compatible option with EVPN PEs that
choice with a default value of 1. The configuration of this follow <xref target="RFC7432" format="default"/> but do not
administrative choice provides a backwards compatible option support this specification.</li>
with EVPN PEs that follow <xref target="RFC7432"/> but do not </ul>
support this specification.</t> <t>Note that, typically, IP-&gt;MAC entries with O = 0 will not be
</list></t> learned; therefore, the Proxy ND function will reply to NS
messages with NA messages that contain O = 1. However, this document
<t>Note that, typically, IP-&gt;MAC entries with O=0 will not be
learned, and therefore the Proxy-ND function will reply to NS
messages with NA messages that contain O=1. However, this document
allows the configuration of the "anycast" capability in the BD where allows the configuration of the "anycast" capability in the BD where
the Proxy-ND function is enabled. If "anycast" is enabled in the BD the Proxy ND function is enabled. If "anycast" is enabled in the BD
and an NA message with O=0 is received, the associated IP-&gt;MAC and an NA message with O = 0 is received, the associated IP-&gt;MAC
entry will be learned with O=0. If this "anycast" capability is entry will be learned with O = 0. If this "anycast" capability is
enabled in the BD, Duplicate IP Detection must be disabled so that enabled in the BD, duplicate IP detection must be disabled so that
the PE is able to learn the same IP mapped to different MACs in the the PE is able to learn the same IP mapped to different MACs in the
same Proxy-ND table. If the "anycast" capability is disabled, NA same Proxy ND table. If the "anycast" capability is disabled, NA
messages with O Flag = 0 will not create a Proxy-ND entry (although messages with O Flag = 0 will not create a Proxy ND entry (although
they will be forwarded normally), hence no EVPN advertisement with they will be forwarded normally); hence, no EVPN advertisement with
ARP/ND Extended Community will be generated.</t> ARP/ND Extended Community will be generated.</t>
</section> </section>
</section> </section>
<section anchor="sect-4.2" numbered="true" toc="default">
<section anchor="sect-4.2" title="Reply Sub-Function"> <name>Reply Sub-function</name>
<t>This sub-function will reply to address resolution <t>This sub-function will reply to address resolution
requests/solicitations upon successful lookup in the Proxy-ARP/ND requests/solicitations upon successful lookup in the Proxy ARP/ND
table for a given IP address. The following considerations should be table for a given IP address. The following considerations should be
taken into account, assuming that the ARP Request/NS lookup hits a taken into account, assuming that the ARP Request / NS lookup hits a
Proxy-ARP/ND entry IP1-&gt;MAC1:</t> Proxy ARP/ND entry IP1-&gt;MAC1:</t>
<ol spacing="normal" type="a"><li>
<t><list style="letters"> <t>When replying to ARP Requests or NS messages:</t>
<t>When replying to ARP Request or NS messages:<list <ul spacing="normal">
style="symbols"> <li>The PE <bcp14>SHOULD</bcp14> use the Proxy ARP/ND entry MAC
<t>the PE SHOULD use the Proxy-ARP/ND entry MAC address MAC1 address MAC1 as MAC SA. This is <bcp14>RECOMMENDED</bcp14> so
as MAC SA. This is RECOMMENDED so that the resolved MAC can be that the resolved MAC can be learned in the MAC forwarding
learned in the MAC forwarding database of potential layer-2 database of potential Layer 2 switches sitting between the PE
switches sitting between the PE and the CE requesting the and the CE requesting the address resolution.</li>
address resolution.</t> <li>For an ARP reply, the PE <bcp14>MUST</bcp14> use the
Proxy ARP entry IP1 and MAC1 addresses in the sender Protocol
<t>for an ARP reply, the PE MUST use the Proxy-ARP entry IP1 Address and Hardware Address fields, respectively.</li>
and MAC1 addresses in the Sender Protocol Address and Hardware <li>For an NA message in response to an address resolution NS or
Address fields, respectively.</t> DAD NS, the PE <bcp14>MUST</bcp14> use IP1 as the IP SA and
Target Address. M1 <bcp14>MUST</bcp14> be used as the Target
<t>for an NA message in response to an address resolution NS Link Local Address (TLLA).</li>
or DAD NS, the PE MUST use IP1 as the IP SA and Target </ul>
Address. M1 MUST be used as the Target Link Local Address </li>
(TLLA).</t> <li>A PE <bcp14>SHOULD NOT</bcp14> reply to a request/solicitation rec
</list></t> eived on the
<t>A PE SHOULD NOT reply to a request/solicitation received on the
same attachment circuit over which the IP-&gt;MAC is learned. In same attachment circuit over which the IP-&gt;MAC is learned. In
this case the requester and the requested IP are assumed to be 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 connected to the same Layer 2 CE/access network linked to the PE's
attachment circuit, and therefore the requested IP owner will attachment circuit; therefore, the requested IP owner will
receive the request directly.</t> receive the request directly.</li>
<li>A PE <bcp14>SHOULD</bcp14> reply to broadcast/multicast address re
<t>A PE SHOULD reply to broadcast/multicast address resolution solution
messages, that is, ARP-Request, ARP probes, NS messages as well as messages, i.e., ARP Requests, ARP probes, NS messages, as well as
DAD NS messages. An ARP probe is an ARP request constructed with 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 an all-zero sender IP address that may be used by hosts for IPv4
Address Conflict Detection as specified in <xref Address Conflict Detection as specified in <xref target="RFC5227" fo
target="RFC5227"/>. A PE SHOULD NOT reply to unicast address rmat="default"/>. A PE <bcp14>SHOULD NOT</bcp14> reply to unicast address
resolution requests (for instance, NUD NS messages).</t> resolution requests (for instance, NUD NS messages).</li>
<li>
<t>When replying to an NS, a PE SHOULD set the Flags in the NA <t>When replying to an NS, a PE <bcp14>SHOULD</bcp14> set the Flags
messages as follows:<list style="symbols"> in the NA
<t>The R-bit is set as it was learned for the IP-&gt;MAC entry messages as follows:</t>
in the NA messages that created the entry (see <xref <ul spacing="normal">
target="sect-4.1.1"/>).</t> <li>The R bit is set as it was learned for the IP-&gt;MAC entry
in the NA messages that created the entry (see <xref target="sec
<t>The S Flag will be set/unset as per <xref t-4.1.1" format="default"/>).</li>
target="RFC4861"/>.</t> <li>The S Flag will be set/unset as per <xref target="RFC4861" for
mat="default"/>.</li>
<t>The O Flag will be set in all the NA messages issued by the <li>The O Flag will be set in all the NA messages issued by the
PE, except in the case the BD is configured with the "anycast" PE except in the case in which the BD is configured with the
capability and the entry was previously learned with O=0. If "anycast" capability and the entry was previously learned with
"anycast" is enabled and there are more than one MAC for a O = 0. If "anycast" is enabled and there is more than one MAC for
given IP in the Proxy-ND table, the PE will reply to NS a given IP in the Proxy ND table, the PE will reply to NS
messages with as many NA responses as 'anycast' entries there messages with as many NA responses as "anycast" entries there
are in the Proxy-ND table.</t> are in the Proxy ND table.</li>
</list></t> </ul>
</li>
<t>For Proxy-ARP, a PE MUST only reply to ARP-Request with the <li>For Proxy ARP, a PE <bcp14>MUST</bcp14> only reply to ARP Requests
format specified in <xref target="RFC0826"/>.</t> with the
format specified in <xref target="RFC0826" format="default"/>.</li>
<t>For Proxy-ND, a PE MUST reply to NS messages with known options <li>
with the format and options specified in <xref target="RFC4861"/>, <t>For Proxy ND, a PE <bcp14>MUST</bcp14> reply to NS messages
and MAY reply, discard, forward or unicast-forward NS messages with known options with the format and options specified in <xref
containing other options. An administrative choice to control the target="RFC4861" format="default"/> and <bcp14>MAY</bcp14> reply,
behavior for received NS messages with unknown options ('reply', discard, forward, or unicast-forward NS messages containing other
'discard', 'unicast-forward' or 'forward') MAY be supported. <list options. An administrative choice to control the behavior for
style="symbols"> received NS messages with unknown options ("reply", "discard",
<t>The 'reply' option implies that the PE ignores the unknown "unicast-forward", or "forward") <bcp14>MAY</bcp14> be
supported. </t>
<ul spacing="normal">
<li>The "reply" option implies that the PE ignores the unknown
options and replies with NA messages, assuming a successful options and replies with NA messages, assuming a successful
lookup on the Proxy-ND table. An unsuccessful lookup will lookup on the Proxy ND table. An unsuccessful lookup will
result in a &lsquo;forward&rsquo; behavior (i.e., flood the NS result in a "forward" behavior (i.e., flood the NS
message based on the MAC DA.</t> message based on the MAC DA).</li>
<li>If "discard" is available, the operator should assess if
<t>If 'discard' is available, the operator should assess if flooding NS unknown options may be a security risk for the EVPN
flooding NS unknown options may be a security risk for the BD (and if so, enable "discard") or, on the contrary, if not
EVPN BD (and if so, enable 'discard'), or if, on the contrary, forwarding/flooding NS unknown options may disrupt
not forwarding/flooding NS unknown options may disrupt connectivity. This option discards NS messages with unknown
connectivity. This option discards NS messages with unknown options irrespective of the result of the lookup on the
options, irrespective of the result of the lookup on the Proxy ND table.</li>
Proxy-ND table.</t> <li>The "unicast-forward" option is described in <xref target="sec
t-4.3" format="default"/>.</li>
<t>The 'unicast-forward' option is described in <xref <li>The "forward" option implies flooding the NS message based
target="sect-4.3"/>.</t>
<t>The 'forward' option implies flooding the NS message based
on the MAC DA. This option forwards NS messages with unknown on the MAC DA. This option forwards NS messages with unknown
options, irrespective of the result of the lookup on the options irrespective of the result of the lookup on the
Proxy-ND table. The 'forward' option is RECOMMENDED by this Proxy ND table. The "forward" option is <bcp14>RECOMMENDED</bcp1
document.</t> 4> by this
</list></t> document.</li>
</list></t> </ul>
</li>
</ol>
</section> </section>
<section anchor="sect-4.3" numbered="true" toc="default">
<section anchor="sect-4.3" title="Unicast-forward Sub-Function"> <name>Unicast-Forward Sub-function</name>
<t>As discussed in <xref target="sect-4.2"/>, in some cases the <t>As discussed in <xref target="sect-4.2" format="default"/>, in some c
operator may want to 'unicast-forward' certain ARP-Request and NS ases, the
operator may want to "unicast-forward" certain ARP Requests and NS
messages as opposed to reply to them. The implementation of a messages as opposed to reply to them. The implementation of a
'unicast-forward' function is RECOMMENDED. This option can be enabled "unicast-forward" function is <bcp14>RECOMMENDED</bcp14>. This option ca n be enabled
with one of the following parameters:</t> with one of the following parameters:</t>
<ol spacing="normal" type="a"><li>unicast-forward always</li>
<t><list style="letters"> <li>unicast-forward unknown-options</li>
<t>unicast-forward always</t> </ol>
<t>If "unicast-forward always" is enabled, the PE will perform a
<t>unicast-forward unknown-options</t> Proxy ARP/ND table lookup and, in case of a hit, the PE will forward
</list></t> the packet to the owner of the MAC found in the Proxy ARP/ND table.
<t>If 'unicast-forward always' is enabled, the PE will perform a
Proxy-ARP/ND table lookup and in case of a hit, the PE will forward
the packet to the owner of the MAC found in the Proxy-ARP/ND table.
This is irrespective of the options carried in the ARP/ND packet. This This is irrespective of the options carried in the ARP/ND packet. This
option provides total transparency in the BD and yet reduces the option provides total transparency in the BD and yet reduces the
amount of flooding significantly.</t> amount of flooding significantly.</t>
<t>If "unicast-forward unknown-options" is enabled, upon a successful
<t>If 'unicast-forward unknown-options' is enabled, upon a successful Proxy ARP/ND lookup, the PE will perform a "unicast-forward" action
Proxy-ARP/ND lookup, the PE will perform a 'unicast-forward' action only if the ARP Requests or NS messages carry unknown options, as
only if the ARP-Request or NS messages carry unknown options, as explained in <xref target="sect-4.2" format="default"/>. The "unicast-fo
explained in <xref target="sect-4.2"/>. The 'unicast-forward rward
unknown-options' configuration allows the support of new applications unknown-options" configuration allows the support of new applications
using ARP/ND in the BD while still reducing the flooding.</t> using ARP/ND in the BD while still reducing the flooding.</t>
<t>Irrespective of the enabled option, if there is no successful <t>Irrespective of the enabled option, if there is no successful
Proxy-ARP/ND lookup, the unknown ARP-Request/NS will be flooded in the Proxy ARP/ND lookup, the unknown ARP Request / NS message will be floode
context of the BD, as per <xref target="sect-4.5"/>.</t> d in the
context of the BD, as per <xref target="sect-4.5" format="default"/>.</t
>
</section> </section>
<section anchor="sect-4.4" numbered="true" toc="default">
<section anchor="sect-4.4" title="Maintenance Sub-Function"> <name>Maintenance Sub-function</name>
<t>The Proxy-ARP/ND tables SHOULD follow a number of maintenance <t>The Proxy ARP/ND tables <bcp14>SHOULD</bcp14> follow a number of main
tenance
procedures so that the dynamic IP-&gt;MAC entries are kept if the procedures so that the dynamic IP-&gt;MAC entries are kept if the
owner is active and flushed (and the associated RT2 withdrawn) if the owner is active and flushed (and the associated RT2 withdrawn) or if the
owner is no longer in the network. The following procedures are owner is no longer in the network. The following procedures are
RECOMMENDED:</t> <bcp14>RECOMMENDED</bcp14>:</t>
<t><list style="letters"> <dl newline="true">
<t>Age-time <vspace blankLines="1"/>A dynamic Proxy-ARP/ND entry
MUST be flushed out of the table if the IP-&gt;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-&gt;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).</t>
<t>Send-refresh option<vspace blankLines="1"/>The PE MAY send <dt>Age-time:
periodic refresh messages (ARP/ND "probes") to the owners of the </dt>
dynamic Proxy-ARP/ND entries, so that the entries can be refreshed <dd>A dynamic Proxy ARP/ND entry <bcp14>MUST</bcp14> be flushed out
before they age out. The owner of the IP-&gt;MAC entry would reply of the table if the IP-&gt;MAC has not been refreshed within a given
to the ARP/ND probe and the corresponding entry age-time reset. age-time. The entry is refreshed if an ARP or NA message is received
The periodic send-refresh timer is an administrative option and is for the same IP-&gt;MAC entry. The age-time is an administrative
RECOMMENDED to be a third of the age-time or a half of the option, and its value should be carefully chosen depending on the
age-time in scaled networks. <vspace blankLines="1"/>An ARP specific use case; in IXP networks (where the CE routers are fairly
refresh issued by the PE will be an ARP-Request message with the static), the age-time may normally be longer than in DC networks
Sender's IP = 0 sent from the PE's MAC SA. If the PE has an IP (where mobility is required).
address in the subnet, for instance on an Integrated Routing and </dd>
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 a
NS message issued from the PE's MAC SA and a Link Local Address
associated to the PE's MAC. <vspace blankLines="1"/>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-&gt;MAC entry.</t>
</list></t>
<t>The age-time and send-refresh options are used in EVPN networks to <dt>Send-refresh option:
avoid unnecessary EVPN RT2 withdrawals: if refresh messages are sent </dt>
before the corresponding BD Bridge-Table and Proxy-ARP/ND age-time for <dd>
a given entry expires, inactive but existing hosts will reply,
refreshing the entry and therefore avoiding unnecessary EVPN MAC/IP
Advertisement withdrawals in EVPN. Both entries (MAC in the BD and
IP-&gt;MAC in Proxy-ARP/ND) are reset when the owner replies to the
ARP/ND probe. If there is no response to the ARP/ND probe, the MAC and
IP-&gt;MAC entries will be legitimately flushed and the RT2s
withdrawn.</t>
</section>
<section anchor="sect-4.5" title="Flood (to Remote PEs) Handling"> <t>The PE <bcp14>MAY</bcp14> send periodic refresh messages
<t>The Proxy-ARP/ND function implicitly helps reducing the flooding of (ARP/ND "probes") to the owners of the dynamic Proxy ARP/ND
ARP Request and NS messages to remote PEs in an EVPN network. However, entries, so that the entries can be refreshed before they age
out. The owner of the IP-&gt;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
<bcp14>RECOMMENDED</bcp14> to be a third of the age-time or a half
of the age-time in scaled networks. </t>
<t>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 <bcp14>MAY</bcp14> 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. </t>
<t>The refresh request messages <bcp14>SHOULD</bcp14> 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 <bcp14>SHOULD</bcp14> only send the message to
the attachment circuit associated to the MAC in the IP-&gt;MAC
entry.</t>
</dd>
</dl>
<t>The age-time and send-refresh options are used in EVPN networks to avoid
unnecessary EVPN RT2 withdrawals; if refresh messages are sent before the
corresponding BD Bridge-Table and Proxy ARP/ND age-time for a given entry
expires, inactive but existing hosts will reply, refreshing the entry and
therefore avoiding unnecessary EVPN MAC/IP Advertisement withdrawals in
EVPN. Both entries (MAC in the BD and IP-&gt;MAC in the Proxy ARP/ND) are reset
when the owner replies to the ARP/ND probe. If there is no response to the
ARP/ND probe, the MAC and IP-&gt;MAC entries will be legitimately flushed and
the RT2s withdrawn.</t>
</section>
<section anchor="sect-4.5" numbered="true" toc="default">
<name>Flood (to Remote PEs) Handling</name>
<t>The Proxy ARP/ND function implicitly helps reduce the flooding of
ARP Requests and NS messages to remote PEs in an EVPN network. However,
in certain use cases, the flooding of ARP/NS/NA messages (and even the in certain use cases, the flooding of ARP/NS/NA messages (and even the
unknown unicast flooding) to remote PEs can be suppressed completely unknown unicast flooding) to remote PEs can be suppressed completely
in an EVPN network.</t> in an EVPN network.</t>
<t>For instance, in an IXP network, since all the participant CEs are <t>For instance, in an IXP network, since all the participant CEs are
well known and will not move to a different PE, the IP-&gt;MAC entries well known and will not move to a different PE, the IP-&gt;MAC entries
for the local CEs may be all provisioned on the PEs by a management for the local CEs may be all provisioned on the PEs by a management
system. Assuming the entries for the CEs are all provisioned on the system. Assuming the entries for the CEs are all provisioned on the
local PE, a given Proxy-ARP/ND table will only contain static and local PE, a given Proxy ARP/ND table will only contain static and
EVPN-learned entries. In this case, the operator may choose to EVPN-learned entries. In this case, the operator may choose to
suppress the flooding of ARP/NS/NA from the local PE to the remote PEs suppress the flooding of ARP/NS/NA from the local PE to the remote PEs
completely.</t> completely.</t>
<t>The flooding may also be suppressed completely in IXP networks with <t>The flooding may also be suppressed completely in IXP networks with
dynamic Proxy-ARP/ND entries assuming that all the CEs are directly dynamic Proxy ARP/ND entries assuming that all the CEs are directly
connected to the PEs and they all advertise their presence with a connected to the PEs and that they all advertise their presence with a
GARP/unsolicited-NA when they connect to the network. If any of those GARP/unsolicited-NA when they connect to the network. If any of those
two assumptions is not true and any of the PEs may not learn all the two assumptions are not true and any of the PEs may not learn all the
local Proxy-ARP/ND entries, flooding of the ARP/NS/NA messages from local Proxy ARP/ND entries, flooding of the ARP/NS/NA messages from
the local PE to the remote PEs SHOULD NOT be suppressed, or the the local PE to the remote PEs <bcp14>SHOULD NOT</bcp14> be suppressed,
or the
address resolution process for some CEs will not be completed.</t> address resolution process for some CEs will not be completed.</t>
<t>In networks where fast mobility is expected (DC use case), it is <t>In networks where fast mobility is expected (DC use case), it is
NOT RECOMMENDED to suppress the flooding of unknown ARP-Requests/NS or <bcp14>NOT RECOMMENDED</bcp14> to suppress the flooding of unknown ARP R
GARPs/unsolicited-NAs. Unknown ARP-Requests/NS refer to those equests / NS messages or
ARP-Request/NS messages for which the Proxy-ARP/ND lookups for the GARPs/unsolicited-NAs. Unknown ARP Requests / NS messages refer to those
ARP Requests / NS messages for which the Proxy ARP/ND lookups for the
requested IPs do not succeed.</t> requested IPs do not succeed.</t>
<t>In order to give the operator the choice to suppress/allow the <t>In order to give the operator the choice to suppress/allow the
flooding to remote PEs, a PE MAY support administrative options to flooding to remote PEs, a PE <bcp14>MAY</bcp14> support administrative o ptions to
individually suppress/allow the flooding of:</t> individually suppress/allow the flooding of:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Unknown ARP Requests and NS messages.</li>
<t>Unknown ARP-Request and NS messages.</t> <li>GARP and unsolicited-NA messages.</li>
</ul>
<t>GARP and unsolicited-NA messages.</t>
</list></t>
<t>The operator will use these options based on the expected behavior <t>The operator will use these options based on the expected behavior
on the CEs.</t> on the CEs.</t>
</section> </section>
<section anchor="sect-4.6" numbered="true" toc="default">
<section anchor="sect-4.6" title="Duplicate IP Detection"> <name>Duplicate IP Detection</name>
<t>The Proxy-ARP/ND function MUST support duplicate IP detection as <t>The Proxy ARP/ND function <bcp14>MUST</bcp14> support duplicate IP
per this section so that ARP/ND-spoofing attacks or duplicate IPs due detection as per this section so that ARP/ND-spoofing attacks or
to human errors can be detected. For IPv6 addresses, CEs will continue duplicate IPs due to human errors can be detected. For IPv6 addresses,
to carry out the DAD procedures as per <xref target="RFC4862"/>. The CEs will continue to carry out the DAD procedures as per <xref
solution described in this section is an additional security mechanism target="RFC4862" format="default"/>. The solution described in this
carried out by the PEs that guarantees IPv6 address moves between PEs section is an additional security mechanism carried out by the PEs
are legitimate and not the result of an attack. <xref that guarantees IPv6 address moves between PEs are legitimate and not
target="RFC6957"/> describes a solution for IPv6 Duplicate Address the result of an attack. <xref target="RFC6957" format="default"/>
Detection Proxy, however, it is defined for point-to-multipoint describes a solution for the IPv6 Duplicate Address Detection Proxy;
topologies with a split-horizon forwarding, where the however, it is defined for point-to-multipoint topologies with a
&lsquo;CEs&rsquo; have no direct communication within the same L2 link split-horizon forwarding, where the "CEs" have no direct communication
and therefore it is not suitable for EVPN Broadcast Domains. In within the same L2 link; therefore, it is not suitable for EVPN
addition, the solution described in this section includes the use of Broadcast Domains. In addition, the solution described in this section
the AS-MAC for additional security.</t> includes the use of the AS-MAC for additional security.</t>
<t>ARP/ND spoofing is a technique whereby an attacker sends "fake" <t>ARP/ND spoofing is a technique whereby an attacker sends "fake"
ARP/ND messages onto a broadcast domain. Generally the aim is to ARP/ND messages onto a Broadcast Domain. Generally, the aim is to
associate the attacker's MAC address with the IP address of another associate the attacker's MAC address with the IP address of another
host causing any traffic meant for that IP address to be sent to the host causing any traffic meant for that IP address to be sent to the
attacker instead.</t> attacker instead.</t>
<t>The distributed nature of EVPN and Proxy ARP/ND allows the easy
<t>The distributed nature of EVPN and Proxy-ARP/ND allows the easy detection of duplicated IPs in the network in a similar way to the
detection of duplicated IPs in the network, in a similar way to the MAC duplication detection function supported by <xref target="RFC7432" f
MAC duplication detection function supported by <xref ormat="default"/> for MAC addresses.</t>
target="RFC7432"/> for MAC addresses.</t> <t>Duplicate IP detection monitors "IP-moves" in the Proxy ARP/ND
table in the following way:
<t>Duplicate IP detection monitors "IP-moves" in the Proxy-ARP/ND </t>
table in the following way:<!----><list style="letters"> <ol spacing="normal" type="a"><li>When an existing active IP1-&gt;MAC1
<t>When an existing active IP1-&gt;MAC1 entry is modified, a PE entry is modified, a PE starts an M-second timer (default value of
starts an M-second timer (default value of M=180), and if it M = 180), and if it detects N IP moves before the timer expires (default
detects N IP moves before the timer expires (default value of value of N = g5), it concludes that a duplicate IP situation has
N=5), it concludes that a duplicate IP situation has occurred. An occurred. An IP move is considered when, for instance, IP1-&gt;MAC1 is
IP move is considered when, for instance, IP1-&gt;MAC1 is replaced replaced by IP1-&gt;MAC2 in the Proxy ARP/ND table. Static IP-&gt;MAC
by IP1-&gt;MAC2 in the Proxy-ARP/ND table. Static IP-&gt;MAC entries, i.e., locally provisioned or EVPN-learned entries with I = 1
entries, that is, locally provisioned or EVPN-learned entries with in the ARP/ND Extended Community, are not subject to this
I=1 in the ARP/ND Extended Community, are not subject to this procedure. Static entries <bcp14>MUST NOT</bcp14> be overridden by
procedure. Static entries MUST NOT be overridden by dynamic dynamic Proxy ARP/ND entries.</li>
Proxy-ARP/ND entries.</t> <li>
<t>In order to detect the duplicate IP faster, the PE
<t>In order to detect the duplicate IP faster, the PE SHOULD send <bcp14>SHOULD</bcp14> send a Confirm message to the former owner
a Confirm message to the former owner of the IP. A Confirm message of the IP. A Confirm message is a unicast ARP Request / NS message
is a unicast ARP-Request/NS message sent by the PE to the MAC sent by the PE to the MAC addresses that previously owned the IP,
addresses that previously owned the IP, when the MAC changes in when the MAC changes in the Proxy ARP/ND table. The Confirm
the Proxy-ARP/ND table. The Confirm message uses a sender's IP message uses a sender's IP 0.0.0.0 in case of ARP (if the PE has
0.0.0.0 in case of ARP (if the PE has an IP address in the subnet an IP address in the subnet, then it <bcp14>MAY</bcp14> use it)
then it MAY use it) and an IPv6 Link Local Address in case of NS. and an IPv6 Link Local Address in case of NS. If the PE does not
If the PE does not receive an answer within a given time, the new receive an answer within a given time, the new entry will be
entry will be confirmed and activated. The default RECOMMENDED confirmed and activated. The default <bcp14>RECOMMENDED</bcp14>
time to receive the confirmation is 30 seconds. In case of time to receive the confirmation is 30 seconds. In case of
spoofing, for instance, if IP1-&gt;MAC1 moves to IP1-&gt;MAC2, the spoofing, for instance, if IP1-&gt;MAC1 moves to IP1-&gt;MAC2, the
PE may send a unicast ARP-Request/NS message for IP1 with MAC DA= 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 = MAC1 and MAC SA = PE's MAC. This will force the legitimate owner
respond if the move to MAC2 was spoofed, and make the PE issue 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, another Confirm message, this time to MAC DA = MAC2.
legitimate owner and spoofer keep replying to the Confirm message,
the PE will detect the duplicate IP within the M-second If both, the legitimate owner and spoofer keep replying to the
timer:<list style="symbols"> Confirm message. The PE would then detect the duplicate IP within the
<t>If the IP1-&gt;MAC1 pair was previously owned by the M-second timer, and a response would be triggered as follows:</t>
<ul spacing="normal">
<li>If the IP1-&gt;MAC1 pair was previously owned by the
spoofer and the new IP1-&gt;MAC2 was from a valid CE, then the spoofer and the new IP1-&gt;MAC2 was from a valid CE, then the
issued Confirm message would trigger a response from the issued Confirm message would trigger a response from the
spoofer.</t> spoofer.</li>
<li>If it were the other way around, that is, IP1-&gt;MAC1 was
<t>If it were the other way around, that is, IP1-&gt;MAC1 was
previously owned by a valid CE, the Confirm message would previously owned by a valid CE, the Confirm message would
trigger a response from the CE.</t> trigger a response from the CE.</li>
</list><list style="empty"> </ul>
<t hangText="">Either way, if this process continues, then <ul empty="true" spacing="normal">
duplicate detection will kick in.</t> <li>Either way, if this process continues, then
</list></t> duplicate detection will kick in.</li>
</ul>
<t>Upon detecting a duplicate IP situation:<list style="numbers"> </li>
<t>The entry in duplicate detected state cannot be updated <li>
with new dynamic or EVPN-learned entries for the same IP. The <t>Upon detecting a duplicate IP situation:</t>
operator MAY override the entry, though, with a static <ol spacing="normal" type="1"><li>The entry in duplicate detected
IP-&gt;MAC.</t> state cannot be updated with new dynamic or EVPN-learned entries
for the same IP. The operator <bcp14>MAY</bcp14> override the
<t>The PE SHOULD alert the operator and stop responding to entry, though, with a static IP-&gt;MAC.</li>
<li>The PE <bcp14>SHOULD</bcp14> alert the operator and stop respo
nding to
ARP/NS for the duplicate IP until a corrective action is ARP/NS for the duplicate IP until a corrective action is
taken.</t> taken.</li>
<li>Optionally, the PE <bcp14>MAY</bcp14> associate an
<t>Optionally the PE MAY associate an "anti-spoofing-mac" "anti-spoofing-mac" (AS-MAC) to the duplicate IP in the
(AS-MAC) to the duplicate IP in the Proxy-ARP/ND table. The PE Proxy ARP/ND table. The PE will send a GARP/unsolicited-NA
will send a GARP/unsolicited-NA message with IP1-&gt;AS-MAC to message with IP1-&gt;AS-MAC to the local CEs as well as an RT2
the local CEs as well as an RT2 (with IP1-&gt;AS-MAC) to the (with IP1-&gt;AS-MAC) to the remote PEs. This will update the
remote PEs. This will update the ARP/ND caches on all the CEs ARP/ND caches on all the CEs in the BD; hence, all the CEs in
in the BD, and hence all the CEs in the BD will use the AS-MAC the BD will use the AS-MAC as MAC DA when sending traffic to
as MAC DA when sending traffic to IP1. This procedure prevents IP1. This procedure prevents the spoofer from attracting any
the spoofer from attracting any traffic for IP1. Since the traffic for IP1. Since the AS-MAC is a managed MAC address known
AS-MAC is a managed MAC address known by all the PEs in the by all the PEs in the BD, all the PEs <bcp14>MAY</bcp14> apply
BD, all the PEs MAY apply filters to drop and/or log any frame filters to drop and/or log any frame with MAC DA = AS-MAC. The
with MAC DA= AS-MAC. The advertisement of the AS-MAC as a advertisement of the AS-MAC as a "drop-MAC" (by using an
"black-hole MAC" (by using an indication in the RT2) that can indication in the RT2) that can be used directly in the BD to
be used directly in the BD to drop frames is for further drop frames is for further study.</li>
study.</t> </ol>
</list></t> </li>
<li>The duplicate IP situation will be cleared when a corrective
<t>The duplicate IP situation will be cleared when a corrective action is taken by the operator or, alternatively, after a
action is taken by the operator, or alternatively after a HOLD-DOWN timer (default value of 540 seconds).</li>
HOLD-DOWN timer (default value of 540 seconds).</t>
</list></t>
<t>The values of M, N and HOLD-DOWN timer SHOULD be a configurable </ol>
<t>The values of M, N, and HOLD-DOWN timer <bcp14>SHOULD</bcp14> be a co
nfigurable
administrative option to allow for the required flexibility in administrative option to allow for the required flexibility in
different scenarios.</t> different scenarios.</t>
<t>For Proxy ND, the duplicate IP detection described in this section
<t>For Proxy-ND, the Duplicate IP Detection described in this section <bcp14>SHOULD</bcp14> only monitor IP moves for IP-&gt;MACs learned from
SHOULD only monitor IP moves for IP-&gt;MACs learned from NA messages NA messages
with O Flag=1. NA messages with O Flag=0 would not override the ND with O Flag = 1. NA messages with O Flag = 0 would not override the ND
cache entries for an existing IP, and therefore the procedure in this cache entries for an existing IP; therefore, the procedure in this
section would not detect duplicate IPs. This Duplicate IP Detection section would not detect duplicate IPs. This duplicate IP detection
for IPv6 SHOULD be disabled when the IPv6 "anycast" capability is for IPv6 <bcp14>SHOULD</bcp14> be disabled when the IPv6 "anycast" capab
ility is
activated in a given BD.</t> activated in a given BD.</t>
</section> </section>
</section> </section>
<section anchor="sect-5" title="Solution Benefits"> <section anchor="sect-5" numbered="true" toc="default">
<name>Solution Benefits</name>
<t>The solution described in this document provides the following <t>The solution described in this document provides the following
benefits:<list style="letters"> benefits:</t>
<t>The solution may suppress completely the flooding of the ARP/ND <ol spacing="normal" type="a">
messages in the EVPN network, assuming that all the CE IP-&gt;MAC <li>May completely suppress
addresses local to the PEs are known or provisioned on the PEs from the flooding of the ARP/ND messages in the EVPN network, assuming that
a management system. Note that in this case, the unknown unicast all the CE IP-&gt;MAC addresses local to the PEs are known or
flooded traffic can also be suppressed, since all the expected provisioned on the PEs from a management system. Note that in this case,
unicast traffic will be destined to known MAC addresses in the PE the unknown unicast flooded traffic can also be suppressed, since all
BDs.</t> the expected unicast traffic will be destined to known MAC addresses in
the PE BDs.</li>
<t>The solution reduces significantly the flooding of the ARP/ND <li>Significantly reduces the flooding of the ARP/ND
messages in the EVPN network, assuming that some or all the CE messages in the EVPN network, assuming that some or all the CE
IP-&gt;MAC addresses are learned on the data plane by snooping IP-&gt;MAC addresses are learned on the data plane by snooping
ARP/ND messages issued by the CEs.</t> ARP/ND messages issued by the CEs.</li>
<li>Provides a way to refresh periodically the CE
<t>The solution provides a way to refresh periodically the CE IP-&gt;MAC entries learned through the data plane so that the
IP-&gt;MAC entries learned through the data plane, so that the
IP-&gt;MAC entries are not withdrawn by EVPN when they age out IP-&gt;MAC entries are not withdrawn by EVPN when they age out
unless the CE is not active anymore. This option helps reducing the 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 EVPN control plane overhead in a network with active CEs that do not
send packets frequently.</t> send packets frequently.</li>
<li>Provides a mechanism to detect duplicate IP addresses and avoid
<t>Provides a mechanism to detect duplicate IP addresses and avoid
ARP/ND-spoof attacks or the effects of duplicate addresses due to ARP/ND-spoof attacks or the effects of duplicate addresses due to
human errors.</t> human errors.</li>
</list></t> </ol>
</section> </section>
<section anchor="sect-6" numbered="true" toc="default">
<section anchor="sect-6" title="Deployment Scenarios"> <name>Deployment Scenarios</name>
<t>Four deployment scenarios with different levels of ARP/ND control are <t>Four deployment scenarios with different levels of ARP/ND control are
available to operators using this solution, depending on their available to operators using this solution depending on their
requirements to manage ARP/ND: all dynamic learning, all dynamic requirements to manage ARP/ND: all dynamic learning, all dynamic
learning with Proxy-ARP/ND, hybrid dynamic learning and static learning with Proxy ARP/ND, hybrid dynamic learning and static
provisioning with Proxy-ARP/ND, and all static provisioning with provisioning with Proxy ARP/ND, and all static provisioning with
Proxy-ARP/ND.</t> Proxy ARP/ND.</t>
<section anchor="sect-6.1" numbered="true" toc="default">
<section anchor="sect-6.1" title="All Dynamic Learning"> <name>All Dynamic Learning</name>
<t>In this scenario for minimum security and mitigation, EVPN is <t>In this scenario for minimum security and mitigation, EVPN is
deployed in the BD with the Proxy-ARP/ND function shutdown. PEs do not deployed in the BD with the Proxy ARP/ND function shutdown. PEs do not
intercept ARP/ND requests and flood all requests issued by the CEs, as intercept ARP/ND requests and flood all requests issued by the CEs as
a conventional layer-2 network among those CEs would do. While no a conventional Layer 2 network among those CEs would suffice. While no
ARP/ND mitigation is used in this scenario, the operator can still ARP/ND mitigation is used in this scenario, the operator can still
take advantage of EVPN features such as control plane learning and take advantage of EVPN features such as control plane learning and
all-active multihoming in the peering network.</t> all-active multihoming in the peering network.</t>
<t>Although this option does not require any of the procedures <t>Although this option does not require any of the procedures
described in this document, it is added as baseline/default option for described in this document, it is added as a baseline/default option for
completeness. This option is equivalent to VPLS as far as ARP/ND is completeness. This option is equivalent to VPLS as far as ARP/ND is
concerned. The options described in <xref target="sect-6.2"/>, <xref concerned. The options described in Sections <xref target="sect-6.2" for
target="sect-6.3"/> and <xref target="sect-6.4"/> are only possible in mat="counter"/>, <xref target="sect-6.3" format="counter"/>, and <xref target="s
EVPN networks in combination with their Proxy-ARP/ND capabilities.</t> ect-6.4" format="counter"/> are only possible in
EVPN networks in combination with their Proxy ARP/ND capabilities.</t>
</section> </section>
<section anchor="sect-6.2" numbered="true" toc="default">
<section anchor="sect-6.2" title="Dynamic Learning with Proxy-ARP/ND"> <name>Dynamic Learning with Proxy ARP/ND</name>
<t>This scenario minimizes flooding while enabling dynamic learning of <t>This scenario minimizes flooding while enabling dynamic learning of
IP-&gt;MAC entries. The Proxy-ARP/ND function is enabled in the BDs of IP-&gt;MAC entries. The Proxy ARP/ND function is enabled in the BDs of
the EVPN PEs, so that the PEs snoop ARP/ND messages issued by the CEs the EVPN PEs so that the PEs snoop ARP/ND messages issued by the CEs
and respond to CE ARP-requests/NS messages.</t> and respond to CE ARP Requests / NS messages.</t>
<t>PEs will flood requests if the entry is not in their Proxy table. <t>PEs will flood requests if the entry is not in their Proxy table.
Any unknown source IP-&gt;MAC entries will be learned and advertised Any unknown source IP-&gt;MAC entries will be learned and advertised
in EVPN, and traffic to unknown entries is discarded at the ingress in EVPN, and traffic to unknown entries is discarded at the ingress
PE.</t> PE.</t>
<t>This scenario makes use of the Learning, Reply, and Maintenance
<t>This scenario makes use of the Learning, Reply and Maintenance
sub-functions, with an optional use of the Unicast-forward and sub-functions, with an optional use of the Unicast-forward and
Duplicate IP detection sub-functions. The Flood handling sub-function duplicate IP detection sub-functions. The Flood handling sub-function
uses default flooding for unknown ARP-Request/NS messages.</t> uses default flooding for unknown ARP Requests / NS messages.</t>
</section> </section>
<section anchor="sect-6.3" numbered="true" toc="default">
<section anchor="sect-6.3" <name>Hybrid Dynamic Learning and Static Provisioning with Proxy ARP/ND<
title="Hybrid Dynamic Learning and Static Provisioning with Proxy /name>
-ARP/ND">
<t>Some IXPs and other operators want to protect particular hosts on <t>Some IXPs and other operators want to protect particular hosts on
the BD while allowing dynamic learning of CE addresses. For example, the BD while allowing dynamic learning of CE addresses. For example,
an operator may want to configure static IP-&gt;MAC entries for an operator may want to configure static IP-&gt;MAC entries for
management and infrastructure hosts that provide critical services. In management and infrastructure hosts that provide critical services. In
this scenario, static entries are provisioned from the management this scenario, static entries are provisioned from the management
plane for protected IP-&gt;MAC addresses, and dynamic learning with plane for protected IP-&gt;MAC addresses, and dynamic learning with
Proxy-ARP/ND is enabled as described in <xref target="sect-6.2"/> on Proxy ARP/ND is enabled as described in <xref target="sect-6.2" format=" default"/> on
the BD.</t> the BD.</t>
<t>This scenario makes use of the same sub-functions as in <xref <t>This scenario makes use of the same sub-functions as in <xref
target="sect-6.2"/>, but adding static entries added by the Learning target="sect-6.2" format="default"/> but with static entries added by
sub-function.</t> the Learning sub-function.</t>
</section> </section>
<section anchor="sect-6.4" numbered="true" toc="default">
<section anchor="sect-6.4" <name>All Static Provisioning with Proxy ARP/ND</name>
title="All Static Provisioning with Proxy-ARP/ND">
<t>For a solution that maximizes security and eliminates flooding and <t>For a solution that maximizes security and eliminates flooding and
unknown unicast in the peering network, all IP-&gt;MAC entries are unknown unicast in the peering network, all IP-&gt;MAC entries are
provisioned from the management plane. The Proxy-ARP/ND function is provisioned from the management plane. The Proxy ARP/ND function is
enabled in the BDs of the EVPN PEs, so that the PEs intercept and enabled in the BDs of the EVPN PEs so that the PEs intercept and
respond to CE requests. Dynamic learning and ARP/ND snooping is respond to CE requests.
disabled so that ARP-Requests and NS to unknown IPs are discarded at Dynamic learning and ARP/ND snooping is
disabled so that ARP Requests and NS messages to unknown IPs are discard
ed at
the ingress PE. This scenario provides an operator the most control the ingress PE. This scenario provides an operator the most control
over IP-&gt;MAC entries and allows an operator to manage all entries over IP-&gt;MAC entries and allows an operator to manage all entries
from a management system.</t> from a management system.</t>
<t>In this scenario, the Learning sub-function is limited to static <t>In this scenario, the Learning sub-function is limited to static
entries, the Maintenance sub-function will not require any procedures entries, the Maintenance sub-function will not require any procedures
due to the static entries, and the Flood handling sub-function will due to the static entries, and the Flood handling sub-function will
completely suppress Unknown ARP-Requests/NS messages as well as GARP completely suppress unknown ARP Requests / NS messages as well as GARP
and unsolicited-NA messages.</t> and unsolicited-NA messages.</t>
</section> </section>
<section anchor="sect-6.5" numbered="true" toc="default">
<section anchor="sect-6.5" <name>Example of Deployment in Internet Exchange Points</name>
title="Example of Deployment in Internet Exchange Points">
<t>Nowadays, almost all IXPs install some security rules in order to <t>Nowadays, almost all IXPs install some security rules in order to
protect the peering network (BD). These rules are often called port protect the peering network (BD). These rules are often called port
security. Port security summarizes different operational steps that security. Port security summarizes different operational steps that
limit the access to the IXP-LAN and the customer router, and controls limit the access to the IXP-LAN and the customer router and controls
the kind of traffic that the routers are allowed to exchange (e.g., the kind of traffic that the routers are allowed to exchange (e.g.,
Ethernet, IPv4, IPv6). Due to this, the deployment scenario as Ethernet, IPv4, and IPv6). Due to this, the deployment scenario as
described in <xref target="sect-6.4"/> "All Static Provisioning with described in <xref target="sect-6.4" format="default"/>, "All Static
Proxy-ARP/ND" is the predominant scenario for IXPs.</t> Provisioning with Proxy ARP/ND", is the predominant scenario for
IXPs.</t>
<t>In addition to the "All Static Provisioning" behavior, in IXP <t>In addition to the "All Static Provisioning" behavior, in IXP
networks it is recommended to configure the Reply Sub-Function to networks it is recommended to configure the Reply sub-function to
'discard' ARP-Requests/NS messages with unrecognized options.</t> "discard" ARP Requests / NS messages with unrecognized options.</t>
<t>At IXPs, customers usually follow a certain operational life cycle.
<t>At IXPs, customers usually follow a certain operational life-cycle. For each step of the operational life cycle, specific operational
For each step of the operational life-cycle specific operational
procedures are executed.</t> procedures are executed.</t>
<t>The following describes the operational procedures that are needed <t>The following describes the operational procedures that are needed
to guarantee port security throughout the life-cycle of a customer to guarantee port security throughout the life cycle of a customer
with focus on EVPN features:</t> with focus on EVPN features:</t>
<ol spacing="normal" type="1"><li>
<t><list style="numbers"> <t>A new customer is connected the first time to the IXP:</t>
<t>A new customer is connected the first time to the IXP:<vspace <t>Before the connection between the customer router
blankLines="1"/>Before the connection between the customer router
and the IXP-LAN is activated, the MAC of the router is and the IXP-LAN is activated, the MAC of the router is
allow-listed on the IXP's switch port. All other MAC addresses are allowlisted on the IXP's switch port. All other MAC addresses are
blocked. Pre-defined IPv4 and IPv6 addresses of the IXP peering blocked. Pre-defined IPv4 and IPv6 addresses of the IXP peering
network space are configured at the customer router. The network space are configured at the customer router. The
IP-&gt;MAC static entries (IPv4 and IPv6) are configured in the IP-&gt;MAC static entries (IPv4 and IPv6) are configured in the
management system of the IXP for the customer's port in order to management system of the IXP for the customer's port in order to
support Proxy-ARP/ND. <vspace blankLines="1"/> In case a customer support Proxy ARP/ND. </t>
uses multiple ports aggregated to a single logical port (LAG) some <t>In case a customer uses multiple ports aggregated to a single
vendors randomly select the MAC address of the LAG from the logical port (LAG), some vendors randomly select the MAC address of
different MAC addresses assigned to the ports. In this case the the LAG from the different MAC addresses assigned to the ports. In
static entry will be used associated to a list of allowed this case, the static entry will be used and associated to a list of
MACs.</t> allowed MACs.</t>
</li>
<t>Replacement of customer router:<vspace blankLines="1"/>If a <li>
customer router is about to be replaced, the new MAC address(es) <t>Replacement of customer router:</t>
must be installed in the management system besides 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.</t>
<t>Decommissioning a customer router<vspace blankLines="1"/>If a <t>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.</t>
</li>
<li>
<t>Decommissioning a customer router:</t>
<t>If a
customer router is decommissioned, the router is disconnected from customer router is decommissioned, the router is disconnected from
the IXP PE. Right after that, the MAC address(es) of the router the IXP PE. Right after that, the MAC address(es) of the router
and IP-&gt;MAC bindings can be removed from the management and IP-&gt;MAC bindings can be removed from the management
system.</t> system.</t>
</list></t> </li>
</ol>
</section> </section>
<section anchor="sect-6.6" numbered="true" toc="default">
<section anchor="sect-6.6" title="Example of Deployment in Data Centers"> <name>Example of Deployment in Data Centers</name>
<t>DCs normally have different requirements than IXPs in terms of <t>DCs normally have different requirements than IXPs in terms of
Proxy- ARP/ND. Some differences are listed below:<list style="letters"> Proxy ARP/ND. Some differences are listed below:</t>
<t>The required mobility in virtualized DCs makes the "Dynamic <ol spacing="normal" type="a"><li>The required mobility in virtualized
Learning" or "Hybrid Dynamic and Static Provisioning" models more DCs makes the "Dynamic Learning" or "Hybrid Dynamic and Static
appropriate than the "All Static Provisioning" model.</t> Provisioning" models more appropriate than the "All Static
Provisioning" model.</li>
<t>IPv6 'anycast' may be required in DCs, while it is typically <li>IPv6 "anycast" may be required in DCs, while it is typically not
not a requirement in IXP networks. Therefore if the DC needs IPv6 a requirement in IXP networks. Therefore, if the DC needs IPv6
anycast addresses, the "anycast" capability will be explicitly anycast addresses, the "anycast" capability will be explicitly
enabled in the Proxy-ND function, hence the Proxy-ND sub-functions enabled in the Proxy ND function and hence the Proxy ND sub-functions
modified accordingly. For instance, if IPv6 'anycast' is enabled modified accordingly. For instance, if IPv6 "anycast" is enabled in
in the Proxy-ND function, the Duplicate IP Detection procedure in the Proxy ND function, the duplicate IP detection procedure in <xref
<xref target="sect-4.6"/> must be disabled.</t> target="sect-4.6" format="default"/> must be disabled.</li>
<li>DCs may require special options on ARP/ND as opposed to the
<t>DCs may require special options on ARP/ND as opposed to the
address resolution function, which is the only one typically address resolution function, which is the only one typically
required in IXPs. Based on that, the Reply Sub-function may be required in IXPs. Based on that, the Reply sub-function may be
modified to forward or discard unknown options.</t> modified to forward or discard unknown options.</li>
</list></t> </ol>
</section> </section>
</section> </section>
<section anchor="sect-7" title="Security Considerations"> <section anchor="sect-7" numbered="true" toc="default">
<t>The security considerations of <xref target="RFC7432"/> and <xref <name>Security Considerations</name>
target="RFC9047"/> apply to this document too. Note that EVPN does not <t>The security considerations of <xref target="RFC7432" format="default"/
> and <xref target="RFC9047" format="default"/> apply to this document too. Note
that EVPN does not
inherently provide cryptographic protection (including confidentiality inherently provide cryptographic protection (including confidentiality
protection).</t> protection).</t>
<t>The procedures in this document reduce the amount of ARP/ND message <t>The procedures in this document reduce the amount of ARP/ND message
flooding, which in itself provides a protection to "slow path" software flooding, which in itself provides a protection to "slow path" software
processors of routers and Tenant Systems in large BDs. The ARP/ND processors of routers and Tenant Systems in large BDs. The ARP/ND
requests that are replied by the Proxy-ARP/ND function (hence not requests that are replied to by the Proxy ARP/ND function (hence not
flooded) are normally targeted to existing hosts in the BD. ARP/ND flooded) are normally targeted to existing hosts in the BD. ARP/ND
requests targeted to absent hosts are still normally flooded; however, requests targeted to absent hosts are still normally flooded; however,
the suppression of Unknown ARP-Requests and NS messages described in the suppression of unknown ARP Requests and NS messages described in
<xref target="sect-4.5"/> can provide an additional level of security <xref target="sect-4.5" format="default"/> can provide an additional
against ARP-Requests/NS messages issued to non-existing hosts.</t> level of security against ARP Requests / NS messages issued to
non-existing hosts.</t>
<t>While the unicast-forward and/or flood suppression sub-functions <t>While the unicast-forward and/or flood suppression sub-functions
provide an added security mechanism for the BD, they can also increase provide an added security mechanism for the BD, they can also increase
the risk of blocking the service for a CE if the EVPN PEs cannot provide the risk of blocking the service for a CE if the EVPN PEs cannot provide
the ARP/ND resolution that the CE needs.</t> the ARP/ND resolution that the CE needs.</t>
<t>The solution also provides protection against Denial-of-Service (DoS)
<t>The solution also provides protection against Denial Of Service attacks that use ARP/ND spoofing as a first step. The duplicate IP
attacks that use ARP/ND-spoofing as a first step. The Duplicate IP detection and the use of an AS-MAC as explained in <xref
Detection and the use of an AS-MAC as explained in <xref target="sect-4.6" format="default"/> protects the BD against ARP/ND
target="sect-4.6"/> protects the BD against ARP/ND spoofing.</t> spoofing.</t>
<t>The Proxy ARP/ND function specified in this document does not allow
<t>The Proxy-ARP/ND function specified in this document does not allow for the learning of an IP address mapped to multiple MAC addresses in
the learning of an IP address mapped to multiple MAC addresses in the the same table unless the "anycast" capability is enabled (and only in
same table, unless the "anycast" capability is enabled (and only in case case of Proxy ND). When "anycast" is enabled in the Proxy ND function,
of Proxy-ND). When "anycast" is enabled in the Proxy-ND function, the the number of allowed entries for the same IP address
number of allowed entries for the same IP address MUST be limited by the <bcp14>MUST</bcp14> be limited by the operator to prevent DoS attacks
operator to prevent DoS attacks that attempt to fill the Proxy-ND table that attempt to fill the Proxy ND table with a significant number of
with a significant number of entries for the same IP.</t> entries for the same IP.</t>
<t>This document provides some examples and guidelines that can be used
<t>The document provides some examples and guidelines that can be used by IXPs in their EVPN BDs. When EVPN and its associated Proxy ARP/ND
by IXPs in their EVPN BDs. When EVPN and its associated Proxy-ARP/ND
function are used in IXP networks, they provide ARP/ND security and function are used in IXP networks, they provide ARP/ND security and
mitigation. IXPs must still employ additional security mechanisms that mitigation. IXPs must still employ additional security mechanisms that
protect the peering network as per the established BCPs such as the ones protect the peering network as per the established BCPs such as the ones
described in <xref target="Euro-IX-BCP"/>. For example, IXPs should described in <xref target="EURO-IX-BCP" format="default"/>. For example,
disable all unneeded control protocols, and block unwanted protocols IXPs should disable all unneeded control protocols and block unwanted
from CEs so that only IPv4, ARP and IPv6 Ethertypes are permitted on the protocols from CEs so that only IPv4, ARP, and IPv6 Ethertypes are
peering network. In addition, port security features and ACLs can permitted on the peering network. In addition, port security features
provide an additional level of security.</t> and ACLs can provide an additional level of security.</t>
<t>Finally, it is worth noting that the Proxy ARP/ND solution in this
<t>Finally, it is worth noting that the Proxy-ARP/ND solution in this
document will not work if there is a mechanism securing ARP/ND exchanges document will not work if there is a mechanism securing ARP/ND exchanges
among CEs, because the PE is not able to secure the "proxied" ND among CEs because the PE is not able to secure the "proxied" ND
messages.</t> messages.</t>
</section> </section>
<section anchor="sect-8" numbered="true" toc="default">
<section anchor="sect-8" title="IANA Considerations"> <name>IANA Considerations</name>
<t>No IANA considerations.</t> <t>This document has no IANA actions.</t>
</section>
<section anchor="sect-10" title="Acknowledgments">
<t>The authors want to thank Ranganathan Boovaraghavan, Sriram
Venkateswaran, Manish Krishnan, Seshagiri Venugopal, Tony Przygienda,
Robert Raszuk and Iftekhar Hussain for their review and contributions.
Thank you to Oliver Knapp as well, for his detailed review.</t>
</section> </section>
<section anchor="sect-11" title="Contributors">
<t>In addition to the authors listed on the front page, the following
co-authors have also contributed to this document:</t>
<figure>
<artwork><![CDATA[
Wim Henderickx
Nokia
Daniel Melzer
DE-CIX Management GmbH
Erik Nordmark
Zededa
]]></artwork>
</figure>
</section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <references>
&RFC7432; <name>References</name>
<references>
&RFC4861; <name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&RFC0826; FC.7432.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&RFC5227; FC.4861.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&RFC2119; FC.0826.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5227.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.9047.xml"/>
</references>
<references>
<name>Informative References</name>
&RFC8174; <reference anchor="EURO-IX-BCP" target="https://www.euro-ix.net/en/forix
ps/set-ixp/ixp-bcops">
<front>
<title>European Internet Exchange Association</title>
<author fullname="Euro-IX"/>
<date/>
</front>
</reference>
&RFC9047; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6820.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6957.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4862.xml"/>
</references>
</references> </references>
<references title="Informative References"> <section anchor="sect-10" numbered="false" toc="default">
<reference anchor="Euro-IX-BCP"> <name>Acknowledgments</name>
<front> <t>The authors want to thank <contact fullname="Ranganathan
<title>European Internet Exchange Association Best Practises - Boovaraghavan"/>, <contact fullname="Sriram Venkateswaran"/>, <contact
https://www.euro-ix.net/en/forixps/set-ixp/ixp-bcops/</title> fullname="Manish Krishnan"/>, <contact fullname="Seshagiri Venugopal"/>,
<contact fullname="Tony Przygienda"/>, <contact fullname="Robert
Raszuk"/>, and <contact fullname="Iftekhar Hussain"/> for their review
and contributions. Thank you to <contact fullname="Oliver Knapp"/> as
well for his detailed review.</t>
</section>
<section anchor="sect-11" numbered="false" toc="default">
<name>Contributors</name>
<t>In addition to the authors listed on the front page, the following
coauthors have also contributed to this document:</t>
<author fullname="Euro-IX"/> <author fullname="Wim Henderickx" initials="W" surname="Henderickx">
<organization>Nokia</organization>
</author>
<date/> <author fullname="Daniel Melzer" initials="D" surname="Melzer">
</front> <organization>DE-CIX Management GmbH</organization>
</reference> </author>
&RFC6820; <author fullname="Erik Nordmark" initials="E" surname="Nordmark">
<organization>Zededa</organization>
</author>
&RFC6957; </section>;
&RFC4862;
</references>
</back> </back>
</rfc> </rfc>
 End of changes. 203 change blocks. 
960 lines changed or deleted 1007 lines changed or added

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