<?xml version="1.0" encoding="US-ASCII"?> version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY RFC7432 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7432.xml"> nbsp    "&#160;">
  <!ENTITY RFC4861 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml"> zwsp   "&#8203;">
  <!ENTITY RFC0826 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0826.xml"> nbhy   "&#8209;">
  <!ENTITY RFC6820 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6820.xml">
<!ENTITY RFC5227 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5227.xml">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC6957 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6957.xml">
<!ENTITY RFC4862 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4862.xml">
<!ENTITY RFC9047 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9047.xml"> wj     "&#8288;">
]>
<?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 xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-bess-evpn-proxy-arp-nd-16" number="9161" consensus="true" 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 sortrefs="no"?>

  <?rfc text-list-symbols="o-*+"?>

  <?rfc toc="yes"?> updates="7432" obsoletes="" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3">

  <front>
    <title abbrev="EVPN Proxy-ARP/ND">Operational Proxy ARP/ND">Operational Aspects of Proxy-ARP/ND Proxy ARP/ND in
    Ethernet Virtual Private Networks</title>
    <seriesInfo name="RFC" value="9161"/>
    <author fullname="Jorge Rabadan" initials="J." role="editor" surname="Rabadan">
      <organization>Nokia</organization>
      <address>
        <postal>
          <street>777 Middlefield Road</street>
          <city>Mountain View</city>
          <region>CA</region>
          <code>94043</code>

          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>jorge.rabadan@nokia.com</email>
      </address>
    </author>
    <author fullname="Senthil Sathappan" initials="S." surname="Sathappan">
      <organization>Nokia</organization>
      <address>
        <postal>
          <street>701 E. Middlefield Road</street>

          <street>Mountain View, CA 94043 USA</street>
          <city>Mountain View</city>
	   <region>CA</region>
            <code>94043</code>
	     <country>United States of America</country>
	</postal>
        <email>senthil.sathappan@nokia.com</email>
      </address>
    </author>
    <author fullname="Kiran Nagaraj" initials="K." surname="Nagaraj">
      <organization>Nokia</organization>
      <address>
        <postal>
          <street>701 E. Middlefield Road</street>

          <street>Mountain View, CA 94043 USA</street>
           <city>Mountain View</city>
	    <region>CA</region>
             <code>94043</code>
	      <country>United States of America</country>
        </postal>
        <email>kiran.nagaraj@nokia.com</email>
      </address>
    </author>
    <author fullname="Greg Hankins" initials="G." surname="Hankins">
      <organization>Nokia</organization>
      <address>
        <email>greg.hankins@nokia.com</email>
      </address>
    </author>
    <author fullname="Thomas King" initials="T." surname="King">
      <organization abbrev="DE-CIX">DE-CIX Management GmbH</organization>
      <address>
        <email>thomas.king@de-cix.net</email>
      </address>
    </author>
    <date day="6" month="October" year="2021"/> month="January" year="2022"/>
    <workgroup>BESS Workgroup</workgroup>

<keyword>ARP suppression
</keyword>

<keyword>flood suppression
</keyword>

<keyword>ARP unicast-forward
</keyword>

<keyword>Duplicate IP Detection
</keyword>

    <abstract>
      <t>This document describes the Ethernet Virtual Private Networks Network (EVPN)
      Proxy-ARP/ND function,
      Proxy ARP/ND function augmented by the capability of the ARP/ND
      Extended Community. From that perspective perspective, this document updates the EVPN
      specification to provide more comprehensive documentation of the
      operation of the Proxy-ARP/ND Proxy ARP/ND function. The EVPN Proxy-ARP/ND Proxy ARP/ND function
      and the ARP/ND Extended Community help operators of Internet Exchange
      Points, Data Centers, and other networks deal with IPv4 and IPv6 address
      resolution issues associated with large Broadcast Domains by reducing
      and even suppressing the flooding produced by address resolution in the
      EVPN network.</t>
    </abstract>
  </front>
  <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>

      <t>BUM: Broadcast, Unknown unicast and Multicast layer-2 traffic.</t>

      <t>CE: Customer Edge router.</t>

      <t>DAD: Duplicate Address Detection, as per <xref
      target="RFC4861"/>.</t>

      <t>DC: Data Center.</t>

      <t>EVI: EVPN Instance.</t>

      <t>EVPN: Ethernet Virtual Private Networks, as per <xref
      target="RFC7432"/>.</t>

      <t>GARP: Gratuitous ARP message.</t>

      <t>IP-&gt;MAC: an IP address associated to a MAC address. IP-&gt;MAC
      entries are programmed in Proxy-ARP/ND tables and may be of three
      different types: dynamic, static or EVPN-learned.</t>

      <t>IXP: Internet eXchange Point.</t>

      <t>IXP-LAN: the IXP's large Broadcast Domain to where Internet routers
      are connected.</t>

      <t>LAG: Link Aggregation Group.</t>

      <t>MAC or IP DA: MAC or IP Destination Address.</t>

      <t>MAC or IP SA: MAC or IP Source Address.</t>

      <t>ND: Neighbor Discovery Protocol.</t>

      <t>NS: Neighbor Solicitation message.</t>

      <t>NA: Neighbor Advertisement.</t>

      <t>NUD: Neighbor Unreachability Detection, as per <xref
      target="RFC4861"/>.</t>

      <t>O Flag: Override Flag in NA messages, as per <xref
      target="RFC4861"/>.</t>

      <t>PE: Provider Edge router.</t>

      <t>R Flag: Router Flag in NA messages, as per <xref
      target="RFC4861"/>.</t>

      <t>RT2: EVPN Route type 2 or EVPN MAC/IP Advertisement route, as per
      <xref target="RFC7432"/>.</t>

      <t>S Flag: Solicited Flag in NA messages, as per <xref
      target="RFC4861"/>.</t>

      <t>SN-multicast address: Solicited-Node IPv6 multicast address used by
      NS messages.</t>

      <t>TLLA: Target Link Layer Address, as per <xref target="RFC4861"/>.</t>

      <t>VPLS: Virtual Private LAN Service.</t>

      <t>This document assumes familiarity with the terminology used in <xref
      target="RFC7432"/>.</t>
    </section>

    <section anchor="sect-2" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>As specified in <xref target="RFC7432"/> target="RFC7432" format="default"/>, the IP
      Address field in the Ethernet Virtual Private Networks Network (EVPN) MAC/IP Media
      Access Control (MAC) / IP Advertisement route may optionally carry one
      of the IP addresses associated with the MAC address. A PE Provider Edge (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 Proxy ARP/ND tables and
      reply to local ARP requests Requests or Neighbor Solicitations (or 'unicast-forward'
      "unicast-forward" those packets to the owner MAC), reducing and even suppressing
      suppressing, in some cases cases, the flooding in the EVPN network.</t>
      <t>EVPN and its associated Proxy-ARP/ND Proxy ARP/ND function are extremely useful in
      DCs
      Data Centers (DCs) or Internet Exchange Points (IXPs) with large broadcast domains, Broadcast Domains,
      where the amount of ARP/ND flooded traffic causes issues on connected
      routers and CEs. Customer Edges (CEs). <xref target="RFC6820"/> target="RFC6820" format="default"/> describes the address
      resolution problems in large DC networks.</t>
      <t>This document describes the Proxy-ARP/ND Proxy ARP/ND function in <xref
      target="RFC7432"/>
      target="RFC7432" format="default"/> networks, augmented by the
      capability of the ARP/ND Extended Community <xref target="RFC9047"/>. target="RFC9047"
      format="default"/>. From that perspective perspective, this document updates <xref target="RFC7432"/>.</t>

      <t>Proxy-ARP/ND
      target="RFC7432" format="default"/>.</t>
      <t>Proxy ARP/ND may be implemented to help IXPs, DCs DCs, and other operators
      deal with the issues derived from address resolution in large broadcast
      domains.</t> Broadcast
      Domains.</t>

      <section anchor="sect-2.1" title="The numbered="true" toc="default">
        <name>The Data Center Use-Case"> Use Case</name>
        <t>As described in <xref target="RFC6820"/> 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 the IPv4 Address
        Resolution Protocol procedures may be significant.</t>
        <t>On one hand, ARP Requests use broadcast MAC addresses, therefore 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, Broadcast Domain, since some
        implementations will persistently retry sending ARP Requests. As <xref
        target="RFC6820"/>
        target="RFC6820" format="default"/> states, there are no clear
        requirements for retransmitting ARP Requests in the absence of replies, hence
        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 Proxy ARP/ND function.</t>
      </section>
      <section anchor="sect-2.2" title="The numbered="true" toc="default">
        <name>The Internet Exchange Point Use-Case"> 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 Layer 2 Broadcast Domain
        for peering purposes (referred to as 'the "the peering network'), network"), where
        (hundreds of) Internet routers are connected. We refer to these
        Internet routers as Customer Edge (CE) CE devices in this section.
        Because of the requirement to connect all routers to a single layer-2
        network 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.
        Broadcast Domains.

	This peering network is transparent to the CEs, CEs and
        therefore,
        therefore floods any ARP request 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 BUM 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 MLD-snooping 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
        GARPs Gratuitous ARPs (GARPs) <xref target="RFC5227"/>.
        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 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 broadcasts broadcast domains, EVPN
        provides new more efficient possibilities to IXPs. EVPN and its
        Proxy-ARP/ND
        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 anchor="sect-1" numbered="true" toc="default">
      <name>Terminology</name>

        <t>
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</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>

          <dl indent="12">
	  <dt>ARP:
	  </dt>
	  <dd>Address Resolution Protocol
	  </dd>

	  <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>

	  <dt>BD:
	  </dt>
	  <dd>Broadcast Domain
	  </dd>

	  <dt>BUM:
	  </dt>
	  <dd>Broadcast, Unknown Unicast, and Multicast Layer 2 traffic
	  </dd>

	  <dt>CE:
	  </dt>
	  <dd>Customer Edge router
	  </dd>

	  <dt>DAD:
	  </dt>
	  <dd>Duplicate Address Detection, as per <xref target="RFC4861"/>
	  </dd>

	  <dt>DC:
	  </dt>
	  <dd>Data Center
	  </dd>

	  <dt>EVI:
	  </dt>
	  <dd>EVPN Instance
	  </dd>

	  <dt>EVPN:
	  </dt>
	  <dd>Ethernet Virtual Private Network, as per <xref target="RFC7432"/>
	  </dd>

	  <dt>GARP:
	  </dt>
	  <dd>Gratuitous ARP
	  </dd>

	  <dt>IP->MAC:
	  </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>

	  <dt>IXP:
	  </dt>
	  <dd>Internet Exchange Point
	  </dd>

	  <dt>IXP-LAN:
	  </dt>
	  <dd>The IXP's large Broadcast Domain to where Internet routers are connected.
	  </dd>

	  <dt>LAG:
	  </dt>
	  <dd>Link Aggregation Group
	  </dd>

	  <dt>MAC or IP DA:
	  </dt>
	  <dd>MAC or IP Destination Address
	  </dd>

	  <dt>MAC or IP SA:
	  </dt>
	  <dd>MAC or IP Source Address
	  </dd>

	  <dt>ND:
	  </dt>
	  <dd>Neighbor Discovery
	  </dd>

	  <dt>NS:
	  </dt>
	  <dd>Neighbor Solicitation
	  </dd>

	  <dt>NA:
	  </dt>
	  <dd>Neighbor Advertisement
	  </dd>

	  <dt>NUD:
	  </dt>
	  <dd>Neighbor Unreachability Detection, as per <xref target="RFC4861"/>
	  </dd>

	  <dt>O Flag:
	  </dt>
	  <dd>Override Flag in NA messages, as per <xref target="RFC4861"/>
	  </dd>

	  <dt>PE:
	  </dt>
	  <dd>Provider Edge router
	  </dd>

	  <dt>R Flag:
	  </dt>
	  <dd>Router Flag in NA messages, as per <xref target="RFC4861" format="default"/>
	  </dd>

	  <dt>RT2:
	  </dt>
	  <dd>EVPN Route type 2 or EVPN MAC/IP Advertisement route, as per
	  <xref target="RFC7432" format="default"/>
	  </dd>

	  <dt>S Flag:
	  </dt>
	  <dd>Solicited Flag in NA messages, as per <xref target="RFC4861"
	  format="default"/>
	  </dd>

	  <dt>SN-multicast address:
	  </dt>
	  <dd>Solicited-Node IPv6 multicast address used by NS messages
	  </dd>

	  <dt>TLLA:
	  </dt>
	  <dd>Target Link Layer Address, as per <xref target="RFC4861" format="default"/>
	  </dd>

	  <dt>VPLS:
	  </dt>
	  <dd>Virtual Private LAN Service
	  </dd>

</dl>

      <t>This document assumes familiarity with the terminology used in <xref target="RFC7432" format="default"/>.</t>
    </section>

    <section anchor="sect-4" title="Solution Description"> numbered="true" toc="default">
      <name>Solution Description</name>
      <t><xref target="ure-proxy-arp-nd-network-example"/> target="ure-proxy-arp-nd-network-example" format="default"/> illustrates an
      example EVPN network where the Proxy-ARP/ND Proxy ARP/ND function is enabled.</t>
      <figure anchor="ure-proxy-arp-nd-network-example"
              title="Proxy-ARP/ND network example">
        <artwork><![CDATA[ anchor="ure-proxy-arp-nd-network-example">
        <name>Proxy ARP/ND Network Example</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
                                                      BD1
                                                  Proxy-ARP/ND
                                                  Proxy ARP/ND
                                                 +------------+
IP1/M1          +----------------------------+   |IP1->M1 EVPN|
 GARP --->Proxy-ARP/ND --->Proxy ARP/ND                       |   |IP2->M2 EVPN|
+---+      +--------+   RT2(IP1/M1)          |   |IP3->M3 sta |
|CE1+------|   BD1  |    ------>      +------+---|IP4->M4 dyn |
+---+      +--------+                 |          +------------+
               PE1                    | +--------+ Who has IP1?
                |           EVPN      | |   BD1  | <-----  +---+
                |           EVI1      | |        | ----->  |CE3|
IP2/M2          |                     | |        | IP1->M1 +---+
 GARP  --->Proxy-ARP/ND  --->Proxy ARP/ND               | +--------+   |    IP3/M3
  +---+    +--------+   RT2(IP2/M2)   |              |
  |CE2+----|   BD1  |    ------>      +--------------+
  +---+    +--------+                       PE3|    +---+
               PE2                           | +----+CE4|
                +----------------------------+      +---+
                                              <---IP4/M4 GARP
]]></artwork>
      </figure>
      <t>When the Proxy-ARP/ND 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
      can contain three types of Proxy-ARP/ND Proxy ARP/ND entries:</t>

      <t><list style="letters">
          <t>Dynamic

      <dl newline="true">

	<dt>Dynamic entries: learned
	</dt>
	<dd>Learned by snooping a CE's ARP and ND messages.
          For messages; for instance,
	see IP4-&gt;M4 in <xref
          target="ure-proxy-arp-nd-network-example"/>.</t>

          <t>Static target="ure-proxy-arp-nd-network-example"
	format="default"/>.
	</dd>

	<dt>Static entries: provisioned
	</dt>
	<dd>Provisioned on the PE by the management system.
          For system; for instance,
	see IP3-&gt;M3 in <xref
          target="ure-proxy-arp-nd-network-example"/>.</t>

          <t>EVPN-learned target="ure-proxy-arp-nd-network-example"
	format="default"/>.
	</dd>

	<dt>EVPN-learned entries: learned
	</dt>
	<dd>Learned from the IP/MAC information encoded in the received RT2's
	coming from remote PEs. For PEs; for instance, see IP1-&gt;M1 and IP2-&gt;M2 in
	<xref
          target="ure-proxy-arp-nd-network-example"/>.</t>
        </list></t> target="ure-proxy-arp-nd-network-example" format="default"/>.
	</dd>
</dl>

<t>As a high level high-level example, the operation of the EVPN Proxy-ARP/ND Proxy ARP/ND function in
the network of <xref
      target="ure-proxy-arp-nd-network-example"/> target="ure-proxy-arp-nd-network-example"
format="default"/> is described below. In this
      example example, we assume IP1, IP2 IP2, and
IP3 are IPv4 addresses:</t>

      <t><list style="numbers">
          <t>Proxy-ARP/ND
       <ol spacing="normal" type="1">
       <li>Proxy ARP/ND is enabled in BD1 of PE1, PE2 PE2, and PE3.</t> PE3.</li>
        <li>
          <t>The PEs start adding dynamic, static static, and EVPN-learned entries to
          their Proxy tables:<list style="letters">
              <?rfc subcompact="yes"?>

              <t>PE3 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
              as dynamic entries in PE1 and PE2 PE2, respectively, and advertised
              in BGP EVPN.</t>

              <t>PE3 EVPN.</li>
            <li>PE3 adds IP4-&gt;M4 as dynamic. This entry is learned by
              snooping the corresponding ARP messages sent by CE4.</t>

              <t>An CE4.</li>
            <li>An operator also provisions the static entry IP3-&gt;M3.</t>

              <?rfc subcompact="no"?>
            </list></t> IP3-&gt;M3.</li>
          </ol>
        </li>
        <li>
          <t>When CE3 sends an ARP Request asking for the MAC address of IP1,
          PE3 will:<list style="letters">
              <?rfc subcompact="yes"?>

              <t>Intercept will:</t>
          <ol spacing="normal" type="a">
            <li>Intercept the ARP Request and perform a Proxy-ARP Proxy ARP lookup for
              IP1.</t>

              <t>If
              IP1.</li>
            <li>If the lookup is successful (as in <xref
              target="ure-proxy-arp-nd-network-example"/>), target="ure-proxy-arp-nd-network-example" format="default"/>), PE3 will send an
              ARP Reply with IP1-&gt;M1. The ARP Request will not be flooded
              to the EVPN network or any other local CEs.</t>

              <t>If CEs.</li>
            <li>If the lookup is not successful, PE3 will flood the ARP
              Request in the EVPN network and the other local CEs.</t>

              <?rfc subcompact="no"?>
            </list></t>
        </list></t> CEs.</li>
          </ol>
        </li>
      </ol>
      <t>In the same example, if we assume IP1, IP2, IP3 IP3, and IP4 are now IPv6
      addresses and Proxy-ARP/ND Proxy ARP/ND is enabled in BD1:</t>

      <t><list style="numbers">
      <ol spacing="normal" type="1"><li>
          <t>PEs will start adding entries in a similar way as they would for IPv4,
          however IPv4;
          however, there are some differences:<list style="letters">
              <t>IP1-&gt;M1 differences:</t>
          <ol spacing="normal" type="a"><li>IP1-&gt;M1 and IP2-&gt;M2 are
          learned as dynamic entries in PE1 and PE2 PE2, respectively, by snooping
          NA messages and not by snooping NS messages. In the IPv4 case, any
          ARP frame can be snooped to learn the dynamic Proxy-ARP Proxy ARP entry. When
          learning the dynamic entries, the R and O Flags contained in the
          snooped NA messages will be added to the Proxy-ND Proxy ND entries too.</t>

              <t>PE1 too.</li>
            <li>PE1 and PE2 will advertise those entries in EVPN MAC/IP
              Advertisement routes, including the corresponding learned R and
              O Flags in the ARP/ND Extended Community.</t>

              <t>PE3 Community.</li>
            <li>PE3 also adds IP4-&gt;M4 as dynamic, dynamic after snooping an NA
              message sent by CE4.</t>
            </list></t>

          <t>When CE4.</li>
          </ol>
        </li>
        <li>When CE3 sends an NS message asking for the MAC address of IP1,
          PE3 behaves as in the IPv4 example, by intercepting the NS, doing performing a
          lookup on the IP IP, and replying with an NA if the lookup is
          successful. If it is successful successful, the NS is not flooded to the EVPN
          PEs or any other local CEs.</t>

          <t>If CEs.</li>
        <li>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
          IPv4 case.</t>
        </list></t> case.</li>
      </ol>
      <t>As PE3 learns more and more host entries in the Proxy-ARP/ND Proxy ARP/ND table,
      the flooding of ARP Request messages among PEs is reduced and in some
      cases
      cases, it can even be suppressed. In a network where most of the
      participant CEs are not moving between PEs and they advertise are advertising their
      presence with GARPs or unsolicited-NA messages, the ARP/ND flooding
      among PEs, as well as the unknown unicast flooding, can practically be
      suppressed. In an EVPN-based IXP network, where all the entries are
      Static,
      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 Proxy ARP/ND function
      relies on the CE signaling its new location via GARP or unsolicited-NA
      messages so that tables are immediately updated. If a CE moves
      "silently", that is, without issuing any GARP or NA message upon getting
      attached to the destination PE, the mechanisms described in <xref
      target="sect-4.4"/> target="sect-4.4" format="default"/> make sure that the Proxy-ARP/ND Proxy ARP/ND tables are
      eventually updated.</t>
      <section title="Proxy-ARP/ND Sub-Functions"> numbered="true" toc="default">
        <name>Proxy ARP/ND Sub-functions</name>
        <t>The Proxy-ARP/ND Proxy ARP/ND function can be structured in six sub-functions or
        procedures:</t>

        <t><list style="numbers">
            <t>Learning sub-function</t>

            <t>Reply sub-function</t>

            <t>Unicast-forward sub-function</t>

            <t>Maintenance sub-function</t>

            <t>Flood
        <ol spacing="normal" type="1"><li>Learning sub-function</li>
          <li>Reply sub-function</li>
          <li>Unicast-forward sub-function</li>
          <li>Maintenance sub-function</li>
          <li>Flood handling sub-function</t>

            <t>Duplicate sub-function</li>
          <li>Duplicate IP detection sub-function</t>
          </list></t> sub-function</li>
        </ol>
        <t>A Proxy-ARP/ND Proxy ARP/ND implementation MUST <bcp14>MUST</bcp14> at least support
        the Learning, Reply, Maintenance, and Duplicate duplicate IP detection
        sub-functions. The following sections describe each individual
        sub-function.</t>
      </section>
      <section anchor="sect-4.1" title="Learning Sub-Function"> numbered="true" toc="default">
        <name>Learning Sub-function</name>
        <t>A Proxy-ARP/ND Proxy ARP/ND implementation in an EVPN BD MUST <bcp14>MUST</bcp14>
        support dynamic and EVPN-learned entries, entries and SHOULD <bcp14>SHOULD</bcp14>
        support static entries.</t>
        <t>Static entries are provisioned from the management plane. A static
        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
        <bcp14>MUST</bcp14> be advertised in EVPN with an ARP/ND Extended
        Community where the Immutable ARP/ND Binding Flag (I) is set to 1, as
        per <xref
        target="RFC9047"/>. target="RFC9047" format="default"/>. When the I flag Flag in the
        ARP/ND Extended Community is 1, the advertising PE indicates that the
        IP address must not be associated to a MAC, MAC other than the one included
        in the EVPN MAC/IP Advertisement route. The advertisement of I=1 I = 1 in
        the ARP/ND Extended Community is compatible with any value of the
        Sticky bit (S) or
        Sequence Number sequence number in the <xref target="RFC7432"/> target="RFC7432"
        format="default"/> MAC Mobility Extended Community. Note that the
        I bit in the ARP/ND Extended Community refers to the immutable
        configured association between the IP and the MAC address in the
        IP-&gt;MAC binding, whereas the S bit in the MAC Mobility Extended
        Community refers to the fact that the advertised MAC address is not
        subject to the <xref target="RFC7432"/> target="RFC7432" format="default"/> mobility
        procedures.</t>

        <t>An entry may associate a configured static IP to a list of
        potential MACs, i.e. i.e., IP1-&gt;(MAC1,MAC2..MACN). Until a frame
        (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
        CE, the PE will check that the source MAC, E.g., e.g., MAC1, is included in
        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
        Advertisement route.</t>
        <t>The PE MUST <bcp14>MUST</bcp14> create EVPN-learned entries from the received valid
        EVPN MAC/IP Advertisement routes containing a MAC and IP address.</t>
        <t>Dynamic entries are learned in different ways depending on whether
        the entry contains an IPv4 or IPv6 address:</t>

        <t><list style="letters">
            <t>Proxy-ARP

	<dl newline="true">

	  <dt>Proxy ARP dynamic entries: <list style="empty">
                <t>The
	  </dt>
	  <dd>The PE MUST <bcp14>MUST</bcp14> 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 sender MAC and Sender sender IP of the
	  snooped ARP packet to the Proxy-ARP Proxy ARP table. Note that a MAC or an IP
	  address with value 0 SHOULD NOT <bcp14>SHOULD NOT</bcp14> be learned.</t>
              </list></t>

            <t>Proxy-ND learned.
	  </dd>

	  <dt>Proxy ND dynamic entries:<list style="empty"> entries:
	  </dt>
	  <dd>
	    <t>The PE MUST <bcp14>MUST</bcp14> snoop the NA messages (Ethertype
	    0x86dd, ICMPv6 type 136) received from the CEs attached to the BD
	    and learn dynamic entries from the Target Address and TLLA
	    information.  NA messages received from remote EVPN PEs are not
	    snooped. A PE implementing Proxy-ND Proxy ND as in this document MUST NOT
	    <bcp14>MUST NOT</bcp14> create dynamic IP-&gt;MAC entries from NS messages, since
	    messages because they don't contain the R Flag required by the Proxy-ND
	    Proxy ND reply function.  See <xref target="sect-4.1.1"/> 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 Proxy ND function of the PE, PE and affects how
	    dynamic Proxy-ND 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 SHOULD <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>
              </list></t>
          </list></t> lookup.
	    </t>
	  </dd>

</dl>

        <t>The following procedure associated to the Learning sub-function is
        RECOMMENDED:</t>

        <t><list style="symbols">
            <t>When
        <bcp14>RECOMMENDED</bcp14>:</t>
        <ul spacing="normal">
          <li>When a new Proxy-ARP/ND Proxy ARP/ND EVPN or static active entry is learned
            (or provisioned), the PE SHOULD <bcp14>SHOULD</bcp14> send a GARP or unsolicited-NA
            message to all the connected access CEs. The PE SHOULD <bcp14>SHOULD</bcp14> send a GARP
            or unsolicited-NA message for dynamic entries only if the ARP/NA
            message that previously created the entry on the PE was NOT
            flooded to all the local connected CEs before. This
            GARP/unsolicited-NA message makes sure the CE ARP/ND caches are
            updated even if the ARP/NS/NA messages from CEs connected to
            remote PEs are not flooded in the EVPN network.</t>
          </list></t> network.</li>
        </ul>

        <t>Note that if a Static static entry is provisioned with the same IP as an
        existing EVPN-learned or Dynamic dynamic entry, the Static static entry takes
        precedence.</t>
        <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
        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
        remote PEs and dynamic entries gradually re-learned relearned again.</t>

	<section anchor="sect-4.1.1" title="Proxy-ND numbered="true" toc="default">
          <name>Proxy ND and the NA Flags"> Flags</name>
          <t><xref target="RFC4861"/> target="RFC4861" format="default"/> describes the use of the R Flag in IPv6
          address resolution:</t>

          <t><list style="symbols">
              <t>Nodes
          <ul spacing="normal">
            <li>Nodes capable of routing IPv6 packets must reply to NS
            messages with NA messages where the R Flag is set (R
              Flag=1).</t>

              <t>Hosts Flag = 1).</li>
            <li>Hosts that are not able to route IPv6 packets must indicate
              that inability by replying with NA messages that contain R
              Flag=0.</t>
            </list></t>
              Flag = 0.</li>
          </ul>
          <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
          <xref target="RFC4861"/>:</t>

          <t><list style="symbols">
              <t>Hosts target="RFC4861" format="default"/>:</t>
          <ul spacing="normal">
            <li>Hosts build a Default Router List based on the received RAs
              and NAs with R Flag=1. Flag = 1. Each cache entry has an IsRouter flag,
              which must be set for received RAs and is set based on the R
              flag
              Flag in the received NAs. A host can choose one or more Default
              Routers when sending packets off-link.</t>

              <t>In off-link.</li>
            <li>In those cases where the IsRouter flag changes from TRUE to
            FALSE as a result of a an NA update, the node must remove that
            router from the Default Router List and update the Destination
            Cache entries for all destinations using that neighbor as a
            router, as specified in <xref target="RFC4861"/> section 7.3.3. target="RFC4861" sectionFormat="of"
            section="7.3.3" format="default"/>. This is needed to detect when
            a node that is used as a router stops forwarding packets due to
            being configured as a host.</t>
            </list></t> host.</li>
          </ul>
          <t>The R Flag and O Flag Flags for a Proxy-ARP/ND Proxy ARP/ND entry will be learned in
          the following ways:</t>

          <t><list style="symbols">
              <t>The
          <ul spacing="normal">
            <li>The R Flag information SHOULD <bcp14>SHOULD</bcp14> be added to the Static
            static entries by the management interface. The O Flag information MAY
            <bcp14>MAY</bcp14> also be added by the management interface. If
            the R and O Flags are not configured, the default value is 1.</t>

              <t>Dynamic 1.</li>
            <li>Dynamic entries SHOULD <bcp14>SHOULD</bcp14> learn the R Flag and MAY
            <bcp14>MAY</bcp14> learn the O Flag from the snooped NA messages
            used to learn the IP-&gt;MAC
              itself.</t>

              <t>EVPN-learned itself.</li>
            <li>EVPN-learned entries SHOULD <bcp14>SHOULD</bcp14> learn the R Flag
            and MAY <bcp14>MAY</bcp14> learn the O Flag from the ARP/ND Extended
            Community <xref
              target="RFC9047"/> target="RFC9047" format="default"/> received from
            EVPN along with the RT2 used to learn the IP-&gt;MAC itself. If no
            ARP/ND Extended Community is received, the PE will add a
            configured R Flag/O Flag / O Flag to the entry. These configured R and O
            Flags MAY <bcp14>MAY</bcp14> be an administrative choice with a
            default value of 1. The configuration of this administrative
            choice provides a backwards compatible backwards-compatible option with EVPN PEs that
            follow <xref target="RFC7432"/> target="RFC7432" format="default"/> but do not
            support this specification.</t>
            </list></t> specification.</li>
          </ul>
          <t>Note that, typically, IP-&gt;MAC entries with O=0 O = 0 will not be
          learned, and therefore
          learned; therefore, the Proxy-ND Proxy ND function will reply to NS
          messages with NA messages that contain O=1. O = 1. However, this document
          allows the configuration of the "anycast" capability in the BD where
          the Proxy-ND Proxy ND function is enabled. If "anycast" is enabled in the BD
          and an NA message with O=0 O = 0 is received, the associated IP-&gt;MAC
          entry will be learned with O=0. O = 0. If this "anycast" capability is
          enabled in the BD, Duplicate duplicate IP Detection detection must be disabled so that
          the PE is able to learn the same IP mapped to different MACs in the
          same Proxy-ND Proxy ND table. If the "anycast" capability is disabled, NA
          messages with O Flag = 0 will not create a Proxy-ND Proxy ND entry (although
          they will be forwarded normally), hence normally); hence, no EVPN advertisement with
          ARP/ND Extended Community will be generated.</t>
        </section>
      </section>
      <section anchor="sect-4.2" title="Reply Sub-Function"> numbered="true" toc="default">
        <name>Reply Sub-function</name>
        <t>This sub-function will reply to address resolution
        requests/solicitations upon successful lookup in the Proxy-ARP/ND Proxy ARP/ND
        table for a given IP address. The following considerations should be
        taken into account, assuming that the ARP Request/NS Request / NS lookup hits a
        Proxy-ARP/ND
        Proxy ARP/ND entry IP1-&gt;MAC1:</t>

        <t><list style="letters">
        <ol spacing="normal" type="a"><li>
            <t>When replying to ARP Request Requests or NS messages:<list
                style="symbols">
                <t>the messages:</t>
            <ul spacing="normal">
              <li>The PE SHOULD <bcp14>SHOULD</bcp14> use the Proxy-ARP/ND Proxy ARP/ND entry MAC
              address MAC1 as MAC SA. This is RECOMMENDED <bcp14>RECOMMENDED</bcp14> so
              that the resolved MAC can be learned in the MAC forwarding
              database of potential layer-2 Layer 2 switches sitting between the PE
              and the CE requesting the address resolution.</t>

                <t>for resolution.</li>
              <li>For an ARP reply, the PE MUST <bcp14>MUST</bcp14> use the Proxy-ARP
              Proxy ARP entry IP1 and MAC1 addresses in the Sender sender Protocol
              Address and Hardware Address fields, respectively.</t>

                <t>for respectively.</li>
              <li>For an NA message in response to an address resolution NS or
              DAD NS, the PE MUST <bcp14>MUST</bcp14> use IP1 as the IP SA and
              Target Address. M1 MUST <bcp14>MUST</bcp14> be used as the Target
              Link Local Address
                (TLLA).</t>
              </list></t>

            <t>A (TLLA).</li>
            </ul>
          </li>
          <li>A PE SHOULD NOT <bcp14>SHOULD NOT</bcp14> reply to a request/solicitation received on the
            same attachment circuit over which the IP-&gt;MAC is learned. In
            this case case, the requester and the requested IP are assumed to be
            connected to the same layer-2 Layer 2 CE/access network linked to the PE's
            attachment circuit, and therefore circuit; therefore, the requested IP owner will
            receive the request directly.</t>

            <t>A directly.</li>
          <li>A PE SHOULD <bcp14>SHOULD</bcp14> reply to broadcast/multicast address resolution
            messages, that is, ARP-Request, i.e., ARP Requests, ARP probes, NS messages messages, as well as
            DAD NS messages. An ARP probe is an ARP request Request constructed with
            an all-zero sender IP address that may be used by hosts for IPv4
            Address Conflict Detection as specified in <xref
            target="RFC5227"/>. target="RFC5227" format="default"/>. A PE SHOULD NOT <bcp14>SHOULD NOT</bcp14> reply to unicast address
            resolution requests (for instance, NUD NS messages).</t> messages).</li>
          <li>
            <t>When replying to an NS, a PE SHOULD <bcp14>SHOULD</bcp14> set the Flags in the NA
            messages as follows:<list style="symbols">
                <t>The R-bit follows:</t>
            <ul spacing="normal">
              <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="sect-4.1.1"/>).</t>

                <t>The target="sect-4.1.1" format="default"/>).</li>
              <li>The S Flag will be set/unset as per <xref
                target="RFC4861"/>.</t>

                <t>The target="RFC4861" format="default"/>.</li>
              <li>The O Flag will be set in all the NA messages issued by the
                PE,
              PE except in the case in which the BD is configured with the
              "anycast" capability and the entry was previously learned with O=0.
              O = 0. If "anycast" is enabled and there are is more than one MAC for
              a given IP in the Proxy-ND Proxy ND table, the PE will reply to NS
              messages with as many NA responses as 'anycast' "anycast" entries there
              are in the Proxy-ND table.</t>
              </list></t>

            <t>For Proxy-ARP, Proxy ND table.</li>
            </ul>
          </li>
          <li>For Proxy ARP, a PE MUST <bcp14>MUST</bcp14> only reply to ARP-Request ARP Requests with the
            format specified in <xref target="RFC0826"/>.</t> target="RFC0826" format="default"/>.</li>
          <li>
            <t>For Proxy-ND, Proxy ND, a PE MUST <bcp14>MUST</bcp14> reply to NS messages
            with known options with the format and options specified in <xref target="RFC4861"/>,
            target="RFC4861" format="default"/> and MAY <bcp14>MAY</bcp14> reply,
            discard, forward forward, or unicast-forward NS messages containing other
            options. An administrative choice to control the behavior for
            received NS messages with unknown options ('reply',
            'discard', 'unicast-forward' ("reply", "discard",
            "unicast-forward", or 'forward') MAY "forward") <bcp14>MAY</bcp14> be
            supported. <list
                style="symbols">
                <t>The 'reply' </t>
            <ul spacing="normal">
              <li>The "reply" option implies that the PE ignores the unknown
                options and replies with NA messages, assuming a successful
                lookup on the Proxy-ND Proxy ND table. An unsuccessful lookup will
                result in a &lsquo;forward&rsquo; "forward" behavior (i.e., flood the NS
                message based on the MAC DA.</t>

                <t>If 'discard' DA).</li>
              <li>If "discard" is available, the operator should assess if
              flooding NS unknown options may be a security risk for the EVPN
              BD (and if so, enable 'discard'), or if, "discard") or, on the contrary, if not
              forwarding/flooding NS unknown options may disrupt
              connectivity. This option discards NS messages with unknown
                options,
              options irrespective of the result of the lookup on the
                Proxy-ND table.</t>

                <t>The 'unicast-forward'
              Proxy ND table.</li>
              <li>The "unicast-forward" option is described in <xref
                target="sect-4.3"/>.</t>

                <t>The 'forward' target="sect-4.3" format="default"/>.</li>
              <li>The "forward" option implies flooding the NS message based
                on the MAC DA. This option forwards NS messages with unknown
                options,
                options irrespective of the result of the lookup on the
                Proxy-ND
                Proxy ND table. The 'forward' "forward" option is RECOMMENDED <bcp14>RECOMMENDED</bcp14> by this
                document.</t>
              </list></t>
          </list></t>
                document.</li>
            </ul>
          </li>
        </ol>
      </section>
      <section anchor="sect-4.3" title="Unicast-forward Sub-Function"> numbered="true" toc="default">
        <name>Unicast-Forward Sub-function</name>
        <t>As discussed in <xref target="sect-4.2"/>, target="sect-4.2" format="default"/>, in some cases cases, the
        operator may want to 'unicast-forward' "unicast-forward" certain ARP-Request ARP Requests and NS
        messages as opposed to reply to them. The implementation of a
        'unicast-forward'
        "unicast-forward" function is RECOMMENDED. <bcp14>RECOMMENDED</bcp14>. This option can be enabled
        with one of the following parameters:</t>

        <t><list style="letters">
            <t>unicast-forward always</t>

            <t>unicast-forward unknown-options</t>
          </list></t>
        <ol spacing="normal" type="a"><li>unicast-forward always</li>
          <li>unicast-forward unknown-options</li>
        </ol>
        <t>If 'unicast-forward always' "unicast-forward always" is enabled, the PE will perform a
        Proxy-ARP/ND
        Proxy ARP/ND table lookup and and, in case of a hit, the PE will forward
        the packet to the owner of the MAC found in the Proxy-ARP/ND Proxy ARP/ND table.
        This is irrespective of the options carried in the ARP/ND packet. This
        option provides total transparency in the BD and yet reduces the
        amount of flooding significantly.</t>
        <t>If 'unicast-forward unknown-options' "unicast-forward unknown-options" is enabled, upon a successful
        Proxy-ARP/ND
        Proxy ARP/ND lookup, the PE will perform a 'unicast-forward' "unicast-forward" action
        only if the ARP-Request ARP Requests or NS messages carry unknown options, as
        explained in <xref target="sect-4.2"/>. target="sect-4.2" format="default"/>. The 'unicast-forward
        unknown-options' "unicast-forward
        unknown-options" configuration allows the support of new applications
        using ARP/ND in the BD while still reducing the flooding.</t>

        <t>Irrespective of the enabled option, if there is no successful
        Proxy-ARP/ND
        Proxy ARP/ND lookup, the unknown ARP-Request/NS ARP Request / NS message will be flooded in the
        context of the BD, as per <xref target="sect-4.5"/>.</t> target="sect-4.5" format="default"/>.</t>
      </section>
      <section anchor="sect-4.4" title="Maintenance Sub-Function"> numbered="true" toc="default">
        <name>Maintenance Sub-function</name>
        <t>The Proxy-ARP/ND Proxy ARP/ND tables SHOULD <bcp14>SHOULD</bcp14> follow a number of maintenance
        procedures so that the dynamic IP-&gt;MAC entries are kept 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
        RECOMMENDED:</t>

        <t><list style="letters">
            <t>Age-time <vspace blankLines="1"/>A
        <bcp14>RECOMMENDED</bcp14>:</t>

	<dl newline="true">

	  <dt>Age-time:
	  </dt>
	  <dd>A dynamic Proxy-ARP/ND Proxy ARP/ND entry
            MUST <bcp14>MUST</bcp14> 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
	  option, and its value should be carefully chosen depending on the
	  specific use case: case; in IXP networks (where the CE routers are fairly static)
	  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 required).
	  </dd>

	  <dt>Send-refresh option:
	  </dt>
	  <dd>

            <t>The PE MAY <bcp14>MAY</bcp14> send periodic refresh messages
            (ARP/ND "probes") to the owners of the dynamic Proxy-ARP/ND Proxy ARP/ND
            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
            RECOMMENDED
            <bcp14>RECOMMENDED</bcp14> to be a third of the age-time or a half
            of the age-time in scaled networks. <vspace blankLines="1"/>An </t>
            <t>An ARP refresh issued by the PE will be an ARP-Request ARP Request message
            with the
            Sender's sender's IP = 0 sent from the PE's MAC SA. If the PE has
            an IP address in the subnet, for instance instance, on an Integrated Routing
            and Bridging (IRB) interface, then it MAY <bcp14>MAY</bcp14> use it as
            a source for the ARP request Request (instead of Sender's sender's IP = 0). An ND
            refresh will be a an NS message issued from the PE's MAC SA and a
            Link Local Address associated to the PE's MAC. <vspace blankLines="1"/>The </t>
            <t>The refresh request messages SHOULD <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 SHOULD <bcp14>SHOULD</bcp14> only send the message to
            the attachment circuit associated to the MAC in the IP-&gt;MAC
            entry.</t>
          </list></t>

	  </dd>

	</dl>
<t>The age-time and send-refresh options are used in EVPN networks to avoid
unnecessary EVPN RT2 withdrawals: withdrawals; if refresh messages are sent before the
corresponding BD Bridge-Table and Proxy-ARP/ND 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 Proxy-ARP/ND) 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" title="Flood numbered="true" toc="default">
        <name>Flood (to Remote PEs) Handling"> Handling</name>
        <t>The Proxy-ARP/ND Proxy ARP/ND function implicitly helps reducing reduce the flooding of
        ARP Request 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
        unknown unicast flooding) to remote PEs can be suppressed completely
        in an EVPN network.</t>
        <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
        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
        local PE, a given Proxy-ARP/ND Proxy ARP/ND table will only contain static and
        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
        completely.</t>
        <t>The flooding may also be suppressed completely in IXP networks with
        dynamic Proxy-ARP/ND Proxy ARP/ND entries assuming that all the CEs are directly
        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
        two assumptions is are not true and any of the PEs may not learn all the
        local Proxy-ARP/ND Proxy ARP/ND entries, flooding of the ARP/NS/NA messages from
        the local PE to the remote PEs SHOULD NOT <bcp14>SHOULD NOT</bcp14> be suppressed, or the
        address resolution process for some CEs will not be completed.</t>
        <t>In networks where fast mobility is expected (DC use case), it is
        NOT RECOMMENDED
        <bcp14>NOT RECOMMENDED</bcp14> to suppress the flooding of unknown ARP-Requests/NS ARP Requests / NS messages or
        GARPs/unsolicited-NAs. Unknown ARP-Requests/NS ARP Requests / NS messages refer to those
        ARP-Request/NS
        ARP Requests / NS messages for which the Proxy-ARP/ND Proxy ARP/ND lookups for the
        requested IPs do not succeed.</t>
        <t>In order to give the operator the choice to suppress/allow the
        flooding to remote PEs, a PE MAY <bcp14>MAY</bcp14> support administrative options to
        individually suppress/allow the flooding of:</t>

        <t><list style="symbols">
            <t>Unknown ARP-Request
        <ul spacing="normal">
          <li>Unknown ARP Requests and NS messages.</t>

            <t>GARP messages.</li>
          <li>GARP and unsolicited-NA messages.</t>
          </list></t> messages.</li>
        </ul>
        <t>The operator will use these options based on the expected behavior
        on the CEs.</t>
      </section>
      <section anchor="sect-4.6" title="Duplicate numbered="true" toc="default">
        <name>Duplicate IP Detection"> Detection</name>
        <t>The Proxy-ARP/ND Proxy ARP/ND function MUST <bcp14>MUST</bcp14> support duplicate IP
        detection as per this section so that ARP/ND-spoofing attacks or
        duplicate IPs due to human errors can be detected. For IPv6 addresses,
        CEs will continue to carry out the DAD procedures as per <xref target="RFC4862"/>.
        target="RFC4862" format="default"/>. The solution described in this
        section is an additional security mechanism carried out by the PEs
        that guarantees IPv6 address moves between PEs are legitimate and not
        the result of an attack. <xref
        target="RFC6957"/> target="RFC6957" format="default"/>
        describes a solution for the IPv6 Duplicate Address Detection Proxy, Proxy;
        however, it is defined for point-to-multipoint topologies with a
        split-horizon forwarding, where the
        &lsquo;CEs&rsquo; "CEs" have no direct communication
        within the same L2 link
        and therefore link; therefore, it is not suitable for EVPN
        Broadcast Domains. In addition, the solution described in this section
        includes the use of the AS-MAC for additional security.</t>
        <t>ARP/ND spoofing is a technique whereby an attacker sends "fake"
        ARP/ND messages onto a broadcast domain. Generally Broadcast Domain. Generally, the aim is to
        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
        attacker instead.</t>
        <t>The distributed nature of EVPN and Proxy-ARP/ND Proxy ARP/ND allows the easy
        detection of duplicated IPs in the network, network in a similar way to the
        MAC duplication detection function supported by <xref
        target="RFC7432"/> target="RFC7432" format="default"/> for MAC addresses.</t>
        <t>Duplicate IP detection monitors "IP-moves" in the Proxy-ARP/ND Proxy ARP/ND
        table in the following way:<!----><list style="letters">
            <t>When way:
        </t>
        <ol spacing="normal" type="a"><li>When an existing active IP1-&gt;MAC1
        entry is modified, a PE starts an M-second timer (default value of M=180),
        M = 180), and if it detects N IP moves before the timer expires (default
        value of
            N=5), N = g5), it concludes that a duplicate IP situation has
        occurred. An IP move is considered when, for instance, IP1-&gt;MAC1 is
        replaced by IP1-&gt;MAC2 in the Proxy-ARP/ND Proxy ARP/ND table. Static IP-&gt;MAC
        entries, that is, i.e., locally provisioned or EVPN-learned entries with
            I=1 I = 1
        in the ARP/ND Extended Community, are not subject to this
        procedure. Static entries MUST NOT <bcp14>MUST NOT</bcp14> be overridden by
        dynamic
            Proxy-ARP/ND entries.</t> Proxy ARP/ND entries.</li>
          <li>
            <t>In order to detect the duplicate IP faster, the PE SHOULD
            <bcp14>SHOULD</bcp14> send a Confirm message to the former owner
            of the IP. A Confirm message is a unicast ARP-Request/NS ARP Request / NS message
            sent by the PE to the MAC addresses that previously owned the IP,
            when the MAC changes in the Proxy-ARP/ND Proxy ARP/ND table. The Confirm
            message uses a sender's IP 0.0.0.0 in case of ARP (if the PE has
            an IP address in the subnet subnet, then it MAY <bcp14>MAY</bcp14> use it)
            and an IPv6 Link Local Address in case of NS.  If the PE does not
            receive an answer within a given time, the new entry will be
            confirmed and activated. The default RECOMMENDED <bcp14>RECOMMENDED</bcp14>
            time to receive the confirmation is 30 seconds. In case of
            spoofing, for instance, if IP1-&gt;MAC1 moves to IP1-&gt;MAC2, the
            PE may send a unicast ARP-Request/NS ARP Request / NS message for IP1 with MAC DA= DA
            = MAC1 and MAC SA= SA = PE's MAC. This will force the legitimate owner
            to respond if the move to MAC2 was spoofed, spoofed and make the PE issue
            another Confirm message, this time to MAC DA= DA = MAC2.

	    If both, the legitimate owner and spoofer keep replying to the
	    Confirm message,
            the message. The PE will would then detect the duplicate IP within the
	    M-second
            timer:<list style="symbols">
                <t>If 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
                issued Confirm message would trigger a response from the
                spoofer.</t>

                <t>If
                spoofer.</li>
              <li>If it were the other way around, that is, IP1-&gt;MAC1 was
                previously owned by a valid CE, the Confirm message would
                trigger a response from the CE.</t>
              </list><list style="empty">
                <t hangText="">Either CE.</li>
            </ul>
            <ul empty="true" spacing="normal">
              <li>Either way, if this process continues, then
                duplicate detection will kick in.</t>
              </list></t> in.</li>
            </ul>
          </li>
          <li>
            <t>Upon detecting a duplicate IP situation:<list style="numbers">
                <t>The situation:</t>
            <ol spacing="normal" type="1"><li>The entry in duplicate detected
            state cannot be updated with new dynamic or EVPN-learned entries
            for the same IP. The operator MAY <bcp14>MAY</bcp14> override the
            entry, though, with a static
                IP-&gt;MAC.</t>

                <t>The IP-&gt;MAC.</li>
              <li>The PE SHOULD <bcp14>SHOULD</bcp14> alert the operator and stop responding to
                ARP/NS for the duplicate IP until a corrective action is
                taken.</t>

                <t>Optionally
                taken.</li>
              <li>Optionally, the PE MAY <bcp14>MAY</bcp14> associate an
              "anti-spoofing-mac" (AS-MAC) to the duplicate IP in the Proxy-ARP/ND
              Proxy ARP/ND table. The PE will send a GARP/unsolicited-NA
              message with IP1-&gt;AS-MAC to the local CEs as well as an RT2
              (with IP1-&gt;AS-MAC) to the remote PEs. This will update the
              ARP/ND caches on all the CEs in the BD, and hence BD; hence, all the CEs in
              the BD will use the AS-MAC as MAC DA when sending traffic to
              IP1. This procedure prevents the spoofer from attracting any
              traffic for IP1. Since the AS-MAC is a managed MAC address known
              by all the PEs in the BD, all the PEs MAY <bcp14>MAY</bcp14> apply
              filters to drop and/or log any frame with MAC DA= DA = AS-MAC. The
              advertisement of the AS-MAC as a
                "black-hole MAC" "drop-MAC" (by using an
              indication in the RT2) that can be used directly in the BD to
              drop frames is for further
                study.</t>
              </list></t>

            <t>The study.</li>
            </ol>
          </li>
          <li>The duplicate IP situation will be cleared when a corrective
            action is taken by the operator, or alternatively operator or, alternatively, after a
            HOLD-DOWN timer (default value of 540 seconds).</t>
          </list></t> seconds).</li>

	  </ol>
        <t>The values of M, N N, and HOLD-DOWN timer SHOULD <bcp14>SHOULD</bcp14> be a configurable
        administrative option to allow for the required flexibility in
        different scenarios.</t>
        <t>For Proxy-ND, Proxy ND, the Duplicate duplicate IP Detection detection described in this section
        SHOULD
        <bcp14>SHOULD</bcp14> only monitor IP moves for IP-&gt;MACs learned from NA messages
        with O Flag=1. Flag = 1. NA messages with O Flag=0 Flag = 0 would not override the ND
        cache entries for an existing IP, and therefore IP; therefore, the procedure in this
        section would not detect duplicate IPs. This Duplicate duplicate IP Detection detection
        for IPv6 SHOULD <bcp14>SHOULD</bcp14> be disabled when the IPv6 "anycast" capability is
        activated in a given BD.</t>
      </section>
    </section>

    <section anchor="sect-5" title="Solution Benefits"> numbered="true" toc="default">
      <name>Solution Benefits</name>
      <t>The solution described in this document provides the following
      benefits:<list style="letters">
          <t>The solution may suppress
      benefits:</t>
      <ol spacing="normal" type="a">
	<li>May completely suppress
      the flooding of the ARP/ND messages in the EVPN network, assuming that
      all the CE IP-&gt;MAC addresses local to the PEs are known or
      provisioned on the PEs from a management system. Note that in this case,
      the unknown unicast flooded traffic can also be suppressed, since all
      the expected unicast traffic will be destined to known MAC addresses in
      the PE
          BDs.</t>

          <t>The solution BDs.</li>
        <li>Significantly reduces significantly the flooding of the ARP/ND
          messages in the EVPN network, assuming that some or all the CE
          IP-&gt;MAC addresses are learned on the data plane by snooping
          ARP/ND messages issued by the CEs.</t>

          <t>The solution provides CEs.</li>
        <li>Provides a way to refresh periodically the CE
          IP-&gt;MAC entries learned through the data plane, plane so that the
          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
          EVPN control plane overhead in a network with active CEs that do not
          send packets frequently.</t>

          <t>Provides frequently.</li>
        <li>Provides a mechanism to detect duplicate IP addresses and avoid
          ARP/ND-spoof attacks or the effects of duplicate addresses due to
          human errors.</t>
        </list></t> errors.</li>
      </ol>
    </section>
    <section anchor="sect-6" title="Deployment Scenarios"> numbered="true" toc="default">
      <name>Deployment Scenarios</name>
      <t>Four deployment scenarios with different levels of ARP/ND control are
      available to operators using this solution, solution depending on their
      requirements to manage ARP/ND: all dynamic learning, all dynamic
      learning with Proxy-ARP/ND, Proxy ARP/ND, hybrid dynamic learning and static
      provisioning with Proxy-ARP/ND, Proxy ARP/ND, and all static provisioning with
      Proxy-ARP/ND.</t>
      Proxy ARP/ND.</t>
      <section anchor="sect-6.1" title="All numbered="true" toc="default">
        <name>All Dynamic Learning"> Learning</name>
        <t>In this scenario for minimum security and mitigation, EVPN is
        deployed in the BD with the Proxy-ARP/ND Proxy ARP/ND function shutdown. PEs do not
        intercept ARP/ND requests and flood all requests issued by the CEs, CEs as
        a conventional layer-2 Layer 2 network among those CEs would do. suffice. While no
        ARP/ND mitigation is used in this scenario, the operator can still
        take advantage of EVPN features such as control plane learning and
        all-active multihoming in the peering network.</t>
        <t>Although this option does not require any of the procedures
        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
        concerned. The options described in Sections <xref target="sect-6.2"/>, target="sect-6.2" format="counter"/>, <xref
        target="sect-6.3"/> target="sect-6.3" format="counter"/>, and <xref target="sect-6.4"/> target="sect-6.4" format="counter"/> are only possible in
        EVPN networks in combination with their Proxy-ARP/ND Proxy ARP/ND capabilities.</t>
      </section>
      <section anchor="sect-6.2" title="Dynamic numbered="true" toc="default">
        <name>Dynamic Learning with Proxy-ARP/ND"> Proxy ARP/ND</name>
        <t>This scenario minimizes flooding while enabling dynamic learning of
        IP-&gt;MAC entries. The Proxy-ARP/ND Proxy ARP/ND function is enabled in the BDs of
        the EVPN PEs, PEs so that the PEs snoop ARP/ND messages issued by the CEs
        and respond to CE ARP-requests/NS ARP Requests / NS messages.</t>
        <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
        in EVPN, and traffic to unknown entries is discarded at the ingress
        PE.</t>
        <t>This scenario makes use of the Learning, Reply Reply, and Maintenance
        sub-functions, with an optional use of the Unicast-forward and
        Duplicate
        duplicate IP detection sub-functions. The Flood handling sub-function
        uses default flooding for unknown ARP-Request/NS ARP Requests / NS messages.</t>
      </section>
      <section anchor="sect-6.3"
               title="Hybrid numbered="true" toc="default">
        <name>Hybrid Dynamic Learning and Static Provisioning with Proxy-ARP/ND"> Proxy ARP/ND</name>
        <t>Some IXPs and other operators want to protect particular hosts on
        the BD while allowing dynamic learning of CE addresses. For example,
        an operator may want to configure static IP-&gt;MAC entries for
        management and infrastructure hosts that provide critical services. In
        this scenario, static entries are provisioned from the management
        plane for protected IP-&gt;MAC addresses, and dynamic learning with
        Proxy-ARP/ND
        Proxy ARP/ND is enabled as described in <xref target="sect-6.2"/> target="sect-6.2" format="default"/> on
        the BD.</t>
        <t>This scenario makes use of the same sub-functions as in <xref
        target="sect-6.2"/>,
        target="sect-6.2" format="default"/> but adding with static entries added by
        the Learning sub-function.</t>
      </section>
      <section anchor="sect-6.4"
               title="All numbered="true" toc="default">
        <name>All Static Provisioning with Proxy-ARP/ND"> Proxy ARP/ND</name>
        <t>For a solution that maximizes security and eliminates flooding and
        unknown unicast in the peering network, all IP-&gt;MAC entries are
        provisioned from the management plane. The Proxy-ARP/ND Proxy ARP/ND function is
        enabled in the BDs of the EVPN PEs, PEs so that the PEs intercept and
        respond to CE requests.
	Dynamic learning and ARP/ND snooping is
        disabled so that ARP-Requests ARP Requests and NS messages to unknown IPs are discarded at
        the ingress PE. This scenario provides an operator the most control
        over IP-&gt;MAC entries and allows an operator to manage all entries
        from a management system.</t>
        <t>In this scenario, the Learning sub-function is limited to static
        entries, the Maintenance sub-function will not require any procedures
        due to the static entries, and the Flood handling sub-function will
        completely suppress Unknown ARP-Requests/NS unknown ARP Requests / NS messages as well as GARP
        and unsolicited-NA messages.</t>
      </section>
      <section anchor="sect-6.5"
               title="Example numbered="true" toc="default">
        <name>Example of Deployment in Internet Exchange Points"> Points</name>
        <t>Nowadays, almost all IXPs install some security rules in order to
        protect the peering network (BD). These rules are often called port
        security. Port security summarizes different operational steps that
        limit the access to the IXP-LAN and the customer router, router and controls
        the kind of traffic that the routers are allowed to exchange (e.g.,
        Ethernet, IPv4, and IPv6). Due to this, the deployment scenario as
        described in <xref target="sect-6.4"/> target="sect-6.4" format="default"/>, "All Static
        Provisioning with
        Proxy-ARP/ND" Proxy ARP/ND", is the predominant scenario for
        IXPs.</t>
        <t>In addition to the "All Static Provisioning" behavior, in IXP
        networks it is recommended to configure the Reply Sub-Function sub-function to
        'discard' ARP-Requests/NS
        "discard" ARP Requests / NS messages with unrecognized options.</t>
        <t>At IXPs, customers usually follow a certain operational life-cycle. life cycle.
        For each step of the operational life-cycle life cycle, specific operational
        procedures are executed.</t>
        <t>The following describes the operational procedures that are needed
        to guarantee port security throughout the life-cycle life cycle of a customer
        with focus on EVPN features:</t>

        <t><list style="numbers">
        <ol spacing="normal" type="1"><li>
            <t>A new customer is connected the first time to the IXP:<vspace
            blankLines="1"/>Before IXP:</t>
            <t>Before the connection between the customer router
            and the IXP-LAN is activated, the MAC of the router is
            allow-listed
            allowlisted on the IXP's switch port. All other MAC addresses are
            blocked. Pre-defined IPv4 and IPv6 addresses of the IXP peering
            network space are configured at the customer router. 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
            support Proxy-ARP/ND. <vspace blankLines="1"/> In Proxy ARP/ND. </t>
            <t>In case a customer uses multiple ports aggregated to a single
            logical port (LAG) (LAG), some vendors randomly select the MAC address of
            the LAG from the different MAC addresses assigned to the ports. In
            this case case, the static entry will be used and associated to a list of
            allowed MACs.</t>
          </li>
          <li>
            <t>Replacement of customer router:<vspace blankLines="1"/>If router:</t>

	    <t>If a customer router is about to be replaced, the new MAC
	    address(es) must be installed in the management system besides 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<vspace blankLines="1"/>If router:</t>
            <t>If a
            customer router is decommissioned, the router is disconnected from
            the IXP PE. Right after that, the MAC address(es) of the router
            and IP-&gt;MAC bindings can be removed from the management
            system.</t>
          </list></t>
          </li>
        </ol>
      </section>
      <section anchor="sect-6.6" title="Example numbered="true" toc="default">
        <name>Example of Deployment in Data Centers"> Centers</name>
        <t>DCs normally have different requirements than IXPs in terms of
        Proxy-
        Proxy ARP/ND. Some differences are listed below:<list style="letters">
            <t>The below:</t>
        <ol spacing="normal" type="a"><li>The required mobility in virtualized
        DCs makes the "Dynamic Learning" or "Hybrid Dynamic and Static
        Provisioning" models more appropriate than the "All Static
        Provisioning" model.</t>

            <t>IPv6 'anycast' model.</li>
          <li>IPv6 "anycast" may be required in DCs, while it is typically not
          a requirement in IXP networks. Therefore Therefore, if the DC needs IPv6
          anycast addresses, the "anycast" capability will be explicitly
          enabled in the Proxy-ND function, Proxy ND function and hence the Proxy-ND Proxy ND sub-functions
          modified accordingly. For instance, if IPv6 'anycast' "anycast" is enabled in
          the Proxy-ND Proxy ND function, the Duplicate duplicate IP Detection detection procedure in <xref target="sect-4.6"/>
          target="sect-4.6" format="default"/> must be disabled.</t>

            <t>DCs disabled.</li>
          <li>DCs may require special options on ARP/ND as opposed to the
            address resolution function, which is the only one typically
            required in IXPs. Based on that, the Reply Sub-function sub-function may be
            modified to forward or discard unknown options.</t>
          </list></t> options.</li>
        </ol>
      </section>
    </section>

    <section anchor="sect-7" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The security considerations of <xref target="RFC7432"/> target="RFC7432" format="default"/> and <xref
      target="RFC9047"/> target="RFC9047" format="default"/> apply to this document too. Note that EVPN does not
      inherently provide cryptographic protection (including confidentiality
      protection).</t>
      <t>The procedures in this document reduce the amount of ARP/ND message
      flooding, which in itself provides a protection to "slow path" software
      processors of routers and Tenant Systems in large BDs. The ARP/ND
      requests that are replied to by the Proxy-ARP/ND Proxy ARP/ND function (hence not
      flooded) are normally targeted to existing hosts in the BD. ARP/ND
      requests targeted to absent hosts are still normally flooded; however,
      the suppression of Unknown ARP-Requests unknown ARP Requests and NS messages described in
      <xref target="sect-4.5"/> target="sect-4.5" format="default"/> can provide an additional
      level of security against ARP-Requests/NS ARP Requests / NS messages issued to
      non-existing hosts.</t>
      <t>While the unicast-forward and/or flood suppression sub-functions
      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 ARP/ND resolution that the CE needs.</t>
      <t>The solution also provides protection against Denial Of Service Denial-of-Service (DoS)
      attacks that use ARP/ND-spoofing ARP/ND spoofing as a first step. The Duplicate duplicate IP
      Detection
      detection and the use of an AS-MAC as explained in <xref
      target="sect-4.6"/>
      target="sect-4.6" format="default"/> protects the BD against ARP/ND
      spoofing.</t>
      <t>The Proxy-ARP/ND 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 same table, table unless the "anycast" capability is enabled (and only in
      case of Proxy-ND). Proxy ND). When "anycast" is enabled in the Proxy-ND Proxy ND function,
      the number of allowed entries for the same IP address MUST
      <bcp14>MUST</bcp14> be limited by the operator to prevent DoS attacks
      that attempt to fill the Proxy-ND Proxy ND table with a significant number of
      entries for the same IP.</t>

      <t>The
      <t>This document provides some examples and guidelines that can be used
      by IXPs in their EVPN BDs. When EVPN and its associated Proxy-ARP/ND Proxy ARP/ND
      function are used in IXP networks, they provide ARP/ND security and
      mitigation. IXPs must still employ additional security mechanisms that
      protect the peering network as per the established BCPs such as the ones
      described in <xref target="Euro-IX-BCP"/>. target="EURO-IX-BCP" format="default"/>. For example,
      IXPs should disable all unneeded control protocols, protocols and block unwanted
      protocols from CEs so that only IPv4, ARP ARP, and IPv6 Ethertypes are
      permitted on the peering network. In addition, port security features
      and ACLs can provide an additional level of security.</t>
      <t>Finally, it is worth noting that the Proxy-ARP/ND Proxy ARP/ND solution in this
      document will not work if there is a mechanism securing ARP/ND exchanges
      among CEs, CEs because the PE is not able to secure the "proxied" ND
      messages.</t>
    </section>
    <section anchor="sect-8" title="IANA Considerations">
      <t>No numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document has no IANA considerations.</t> actions.</t>
    </section>

  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7432.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0826.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5227.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9047.xml"/>
      </references>
      <references>
        <name>Informative References</name>

        <reference anchor="EURO-IX-BCP" target="https://www.euro-ix.net/en/forixps/set-ixp/ixp-bcops">
          <front>
            <title>European Internet Exchange Association</title>
            <author fullname="Euro-IX"/>
            <date/>
          </front>
        </reference>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6820.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6957.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4862.xml"/>
      </references>
    </references>

    <section anchor="sect-10" title="Acknowledgments"> numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>The authors want to thank Ranganathan Boovaraghavan, Sriram
      Venkateswaran, Manish Krishnan, Seshagiri Venugopal, Tony Przygienda,
      Robert Raszuk and Iftekhar Hussain <contact fullname="Ranganathan
      Boovaraghavan"/>, <contact fullname="Sriram Venkateswaran"/>, <contact
      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 Oliver Knapp <contact fullname="Oliver Knapp"/> as well,
      well for his detailed review.</t>
    </section>
    <section anchor="sect-11" title="Contributors"> numbered="false" toc="default">
      <name>Contributors</name>
      <t>In addition to the authors listed on the front page, the following
      co-authors
      coauthors have also contributed to this document:</t>

      <figure>
        <artwork><![CDATA[
Wim Henderickx
Nokia

Daniel Melzer
DE-CIX

 <author fullname="Wim Henderickx" initials="W" surname="Henderickx">
      <organization>Nokia</organization>
    </author>

     <author fullname="Daniel Melzer" initials="D" surname="Melzer">
      <organization>DE-CIX Management GmbH

Erik Nordmark
Zededa
]]></artwork>
      </figure>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      &RFC7432;

      &RFC4861;

      &RFC0826;

      &RFC5227;

      &RFC2119;

      &RFC8174;

      &RFC9047;
    </references>

    <references title="Informative References">
      <reference anchor="Euro-IX-BCP">
        <front>
          <title>European Internet Exchange Association Best Practises -
          https://www.euro-ix.net/en/forixps/set-ixp/ixp-bcops/</title> GmbH</organization>
    </author>

 <author fullname="Euro-IX"/>

          <date/>
        </front>
      </reference>

      &RFC6820;

      &RFC6957;

      &RFC4862;
    </references> fullname="Erik Nordmark" initials="E" surname="Nordmark">
      <organization>Zededa</organization>
    </author>

    </section>

  </back>
</rfc>