<?xml version="1.0" encoding="US-ASCII"?> encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC4861 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml">
<!ENTITY RFC7432 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7432.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 I-D.ietf-bess-evpn-irb-extended-mobility SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-bess-evpn-irb-extended-mobility.xml">
<!ENTITY I-D.rbickhart-evpn-ip-mac-proxy-adv SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.rbickhart-evpn-ip-mac-proxy-adv.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"?> "rfc2629-xhtml.ent">

<rfc category="std" xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-bess-evpn-na-flags-09" number="9047" ipr="trust200902" submissionType="IETF">
  <!--Generated by id2xml 1.5.0 on 2020-07-14T16:15:56Z -->

  <?rfc strict="yes"?>

  <?rfc compact="yes"?>

  <?rfc subcompact="no"?>

  <?rfc symrefs="yes"?>

  <?rfc sortrefs="no"?>

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

  <?rfc toc="yes"?> submissionType="IETF" category="std" consensus="true" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3">

  <front>
    <title abbrev="EVPN Neighbor Advertisement ARP/ND Flags">Propagation of ARP/ND Flags in EVPN</title> an Ethernet Virtual Private Network (EVPN)</title>
    <seriesInfo name="RFC" value="9047"/>
    <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="Wen Lin" initials="W." surname="Lin">
      <organization abbrev="Juniper">Juniper Networks</organization>
      <address>
        <email>wlin@juniper.net</email>
      </address>
    </author>
    <date day="1" month="December" year="2020"/> month="June" year="2021"/>
    <workgroup>BESS Workgroup</workgroup>

<keyword>proxy-ARP</keyword>
<keyword>proxy-ND</keyword>
<keyword>proxy-ARP/ND</keyword>
<keyword>ARP/ND extended community</keyword>

    <abstract>
      <t>This document defines an Extended Community that is advertised along
      with an EVPN MAC/IP Ethernet Virtual Private Network (EVPN) Media Access Control (MAC) / IP Advertisement route and carries information relevant
      to the ARP/ND resolution, Address Resolution Protocol (ARP) / Neighbor Discovery (ND) resolution so that an EVPN PE Provider Edge (PE) implementing a proxy-ARP/ND function in broadcast domains (BDs) or an ARP/ND (on IRB interfaces) function on Integrated
Routing and Bridging (IRB) interfaces can reply to ARP Requests or
      Neighbor Solicitations Solicitation (NS) messages with the correct information.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="sect-1" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>An Ethernet Virtual Private Network (EVPN) EVPN MAC/IP Advertisement route
      can optionally carry IPv4 or IPv6 addresses associated with a MAC
      address. Remote Provider Edge (PE) PE routers can use this information to
      populate their Address Resolution Protocol (ARP) ARP or Neighbor Discovery
      (ND) ND tables on Integrated Routing and Bridging (IRB) IRB interfaces or their
      proxy-ARP/ND tables in Broadcast Domains (BD). BDs. PEs can then reply
      locally (act as an ARP/ND proxy, as per <xref target="RFC7432"/>) target="RFC7432" format="default"/>) to
      IPv4 ARP requests Requests and IPv6 Neighbor Solicitation  messages and
      reduce/suppress
      reduce or suppress the flooding produced by the Address Resolution address resolution
      procedure. However, the information conveyed in the EVPN MAC/IP
      Advertisement route may not be enough for the remote PE to reply to
      local ARP or ND requests. For example, if a PE learns an IPv6-&gt;MAC IPv6 address and MAC address combination ND
      entry via EVPN, EVPN (denoted by IPv6-&gt;MAC), the PE would not know if that particular IPv6-&gt;MAC
      pair belongs to a router or a host, and host or if that address is an anycast
      address, as this information is not carried in the EVPN MAC/IP
      Advertisement routes.</t>
      <t>This document defines an Extended Community that is advertised along
      with an EVPN MAC/IP Advertisement route and carries information relevant
      to the ARP/ND resolution, resolution so that an EVPN PE implementing a proxy-ARP/ND
      function can reply to ARP Requests or Neighbor Solicitations with the
      correct information. In particular, the Flags flags defined in <xref
      target="RFC4861"/> target="RFC4861" format="default"/> can now be conveyed along with a MAC/IP Advertisement
      route,
      route so that an egress EVPN PE can issue Neighbor Advertisement (NA)
      messages with the correct Flag flag information.</t>
      <t>The Flags flags are carried in the EVPN Address Resolution Protocol (ARP)
      and Neighbor Discovery (ND) (ARP/ND) Extended Community, as described in the
      following sections.</t>
      <section anchor="sect-1.1" title="Terminology numbered="true" toc="default">
        <name>Terminology and Conventions">
        <t>The Conventions</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<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
        "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP
        14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t>

        <t>EVPN: Ethernet here.
        </t>
<dl newline="false" indent="8">
        <dt>EVPN:</dt><dd>Ethernet Virtual Private Networks, as in <xref
        target="RFC7432"/>.</t>

        <t>BD: Broadcast target="RFC7432" format="default"/></dd>
        <dt>BD:</dt><dd>Broadcast Domain, also described in <xref
        target="RFC7432"/>.</t>

        <t>ARP: Address target="RFC7432" format="default"/></dd>
        <dt>ARP:</dt><dd>Address Resolution Protocol.</t>

        <t>ND: Neighbor Protocol</dd>
        <dt>ND:</dt><dd>Neighbor Discovery protocol, specified in <xref
        target="RFC4861"/>.</t>

        <t>PE: target="RFC4861" format="default"/></dd>
        <dt>PE:</dt><dd> Provider Edge router.</t>

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

        <t>IRB: Integrated router</dd>
        <dt>IRB:</dt><dd>Integrated Routing and Bridging interface.</t>

        <t>Proxy-ARP/ND: interface</dd>
        <dt>Proxy-ARP/ND:</dt><dd> A function on the EVPN PEs by which received Address
        Resolution Protocol (ARP)
        ARP Requests or Neighbor Solicitation (NS) NS
        messages are replied to locally by the PE, without the need to flood
        the requests to remote PEs in the BD. In order to reply to ARP
        Requests or NS messages, the PE does a lookup on an ARP/ND table, that which
        is a collection of IP-&gt;MAC entries learned by the PE.</t>

        <t>IP-&gt;MAC: an PE.</dd>
        <dt>IP-&gt;MAC:</dt><dd>An IP address and MAC address combination that
        represents a given host and is added to an Address Resolution Protocol ARP
        table or Neighbor Discovery ND table. This document uses IP-&gt;MAC
        generically for IPv4 and IPv6 addresses. When something is specific to
        IPv4, the document will use IPv4-&gt;MAC and IPv4-&gt;MAC; likewise, IPv6-&gt;MAC
        will be used when something is specific to IPv6 entries only.</t> only.</dd>
</dl>
        <t>Familiarity with the terminology in <xref target="RFC7432"/> target="RFC4861" format="default"/> and <xref target="RFC4861"/> target="RFC7432" format="default"/> is expected.</t>
      </section>
    </section>
    <section anchor="sect-2" title="The numbered="true" toc="default">
      <name>The EVPN ARP/ND Extended Community"> Community</name>
      <t>This document defines a transitive EVPN Extended Community (Type
      field value of 0x06) with a Sub-Type of 0x08, as allocated by IANA. It
      is advertised along with EVPN MAC/IP Advertisement routes that carry an
      IPv4 or IPv6 address.</t>

      <figure>
        <artwork><![CDATA[
      <artwork name="" type="" align="left" alt=""><![CDATA[
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Type=0x06     | Sub-Type=0x08 |Flags (1 octet)| Reserved=0    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                       Reserved=0                              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Flags field:

  0 1 2 3 4 5 6 7
 +-+-+-+-+-+-+-+-+
 |       |I| |O|R|
 +-+-+-+-+-+-+-+-+
]]></artwork>
      </figure>
      <t>The following Flags flags are defined in the Flags field, the third octet of
      the Extended Community:</t>

      <t>R - Router Flag
<dl newline="false" indent="5">
      <dt>R:</dt><dd><t>Router flag (corresponds to Bit 23 of the Extended Community)</t>
      <t>Bit 7 of the Flags field is defined as the "Router Flag". flag". When set,
      the R Flag flag indicates that the IPv6-&gt;MAC pair advertised in the MAC/IP
      Advertisement route route, along with the Extended Community Community, belongs to an IPv6
      router. If the R Flag flag is zero, the IPv6-&gt;MAC pair belongs to a host.
      The receiving PE implementing the ND function will use this information
      in Neighbor Advertisement messages for the associated IPv6 address. This
      Flag
      flag has no meaning for ARP IPv4-&gt;MAC entries and MUST <bcp14>MUST</bcp14> be ignored
      when the Extended Community is received with an EVPN MAC/IP
      Advertisement route for an IPv4-&gt;MAC pair.</t>

      <t>O - Override Flag pair.</t></dd>
      <dt>O:</dt><dd><t>Override flag (corresponds to Bit 22 of the Extended
      Community)</t>

      <t>Bit
      Community)</t><t>

      Bit 6 of the Flags field is defined as the "Override Flag". flag". An egress
      PE will normally advertise IPv6-&gt;MAC pairs with the O Flag flag set, and
      only when IPv6 "anycast" is enabled in the BD or interface, interface will the PE will
      send an IPv6-&gt;MAC pair with the O Flag flag = 0. The ingress PE will
      install the ND entry with the received O Flag flag and will always use this O
      Flag
      flag value when replying to a Neighbor Solicitation for the IPv6
      address. Similarly to the Router Flag, the Override Flag flag has no meaning
      for ARP IPv4-&gt;MAC entries and MUST <bcp14>MUST</bcp14> be ignored when the Extended
      Community is received with an EVPN MAC/IP Advertisement route for an
      IPv4-&gt;MAC pair.</t>

      <t>I - Immutable pair.</t></dd>
      <dt>I:</dt><dd><t>Immutable ARP/ND Binding Flag flag (corresponds to Bit 20 of the
      Extended Community)</t>
      <t>Bit 4 of the Flags field is defined as the "Immutable ARP/ND Binding
      Flag".
      flag". When set, the egress PE indicates that the IP-&gt;MAC pair that was sent
      in an EVPN MAC/IP Advertisement route (along with the Extended
      Community) is a configured ARP/ND entry. In this case, the IP address in
      the EVPN MAC/IP Advertisement route can only be bound together with the
      MAC address specified in the same route, and not with any other MAC
      addresses received in a different route without the I Flag set.</t> flag set.</t></dd></dl>
      <t>Bits 0-3 and 5 are not assigned by this document. They MUST <bcp14>MUST</bcp14> be set to
      zero,
      zero and ignored on receipt.</t>
      <t>The reserved fields are set to 0 and ignored by the receiver.</t>
    </section>
    <section anchor="sect-3" title="Use numbered="true" toc="default">
      <name>Use of the EVPN ARP/ND Extended Community"> Community</name>
      <t>This section describes the relevant procedures when advertising and
      processing the EVPN ARP/ND Extended Community. In all the procedures
      below
      below, a "PE" must be interpreted as a "PE which that supports the ND/ARP
      proxy function proxy-ARP/ND (introduced by <xref target="RFC7432"/>) target="RFC7432" format="default"/>) and implements
      the propagation of the ARP/ND Flags flags that this document specifies".</t>
      <section anchor="sect-3.1"
               title="Transmission numbered="true" toc="default">
        <name>Transmission of the EVPN ARP/ND Extended Community"> Community</name>
        <t>When an IP-&gt;MAC entry is not learned via EVPN, a PE may learn
        IP-&gt;MAC pairs in the management plane (this will create static
        entries in the ARP/ND or proxy-ARP/ND table) or by snooping ARP or
        Neighbor Advertisement (NA)
        NA messages coming from the CE (this will
        create dynamic entries). Those static and dynamic IP-&gt;MAC entries
        will be advertised in EVPN MAC/IP Advertisement routes that use the
        EVPN ARP/ND Extended Community as follows:</t>

        <t><list style="symbols">
            <t>Advertised
        <ul spacing="normal">
          <li>Advertised MAC/IP Advertisement routes for IPv6-&gt;MAC entries
            MUST
            <bcp14>MUST</bcp14> include one (and only one) ARP/ND Extended Community with the
            R and O Flag flag values associated with the entry. Those Flag flag values
            are either dynamically learned (from NA messages) or configured in
            case of static entries.</t>

            <t>MAC/IP entries.</li>
          <li>MAC/IP Advertisement routes for IPv4-&gt;MAC entries MAY <bcp14>MAY</bcp14>
            include one ARP/ND Extended Community. If the EVPN ARP/ND Extended
            Community is advertised along with an EVPN IPv4/MAC Advertisement
            route, the R and O Flags SHOULD flags <bcp14>SHOULD</bcp14> be set to zero.</t>

            <t>If zero.</li>
          <li>If an IP-&gt;MAC pair is static (it has been configured) configured), the
            corresponding MAC/IP Advertisement route MUST <bcp14>MUST</bcp14> be sent along with
            an ARP/ND Extended Community with the I Flag set.</t>

            <t>This flag set.</li>
          <li>This Extended Community does not change the procedures
            described in <xref target="RFC7432"/>. Specifically target="RFC7432" format="default"/>. Specifically, the procedures
            for advertising the MAC Mobility Extended Community along with the
            MAC/IP Advertisement route are not changed.</t>
          </list></t> changed.</li>
        </ul>
      </section>
      <section anchor="sect-3.2"
               title="Reception numbered="true" toc="default">
        <name>Reception of the EVPN ARP/ND Extended Community"> Community</name>
        <t>In addition to the procedures specified in <xref target="RFC7432"/> target="RFC7432" format="default"/>,
        a PE receiving a MAC/IP Advertisement route will process the EVPN
        ARP/ND Extended Community as follows:</t>

        <t><list style="symbols">
            <t>Only
        <ul spacing="normal">
          <li>Only one EVPN ARP/ND Extended Community is expected to be
            received along with an EVPN MAC/IP Advertisement route. If more
            than one ARP/ND Extended Community is received, the PE MUST <bcp14>MUST</bcp14>
            consider only the first one on the list for processing purposes
            and MUST NOT <bcp14>MUST NOT</bcp14> propagate the rest of the ARP/ND Extended
            Communities.</t>

            <t>The
            Communities.</li>
          <li>The R, O O, and I Flags MUST flags <bcp14>MUST</bcp14> be ignored if they are advertised
            along with an EVPN MAC/IP Advertisement route that does not
            contain an IP (IPv4 or IPv6) address. Otherwise Otherwise, they are processed
            as follows.</t> follows.</li>
          <li>
            <t>R and O Flags processing:<list style="symbols">
                <t>If flag processing:</t>
            <ul spacing="normal">
              <li>If the EVPN MAC/IP Advertisement route contains an IPv6
                address and the EVPN ARP/ND Extended Community, the PE MUST <bcp14>MUST</bcp14>
                add the R and O Flag flag values to the ND entry in the ND or
                proxy-ND table, table and propagate the value of the R and O flags
                from the ARP/ND Extended Community to the Neighbor
                Advertisements when replying to a Solicitation solicitation for the IPv6
                address.</t>

                <t>If
                address.</li>
              <li>If no EVPN ARP/ND Extended Community is received along with
                the route, the PE will add the default R and O Flags flags to the
                entry. The default R Flag SHOULD flag <bcp14>SHOULD</bcp14> be an administrative choice.
                The default O Flag SHOULD flag <bcp14>SHOULD</bcp14> be 1.</t>

                <t>A 1.</li>
              <li>A PE MUST <bcp14>MUST</bcp14> ignore the received R and O Flags flags for an EVPN
                MAC/IP Advertisement route that contains an IPv4-&gt;MAC
                pair.</t>
              </list></t>
                pair.</li>
            </ul>
          </li>
          <li>
            <t>I Flag processing:<list style="symbols">
                <t>A flag processing:</t>
            <ul spacing="normal">
              <li>A PE receiving an EVPN MAC/IP Advertisement route
                containing an IP-&gt;MAC and the I Flag flag set SHOULD <bcp14>SHOULD</bcp14> install the
                IP-&gt;MAC entry in the ARP/ND or proxy-ARP/ND table as an
                "Immutable
                "immutable binding". This Immutable immutable binding entry will
                override an existing non-immutable binding for the same
                IP-&gt;MAC. The absence of the EVPN ARP/ND Extended Community
                in a MAC/IP Advertisement route indicates that the IP-&gt;MAC
                entry is not an "Immutable binding".</t>

                <t>Receiving "immutable binding".</li>

              <li>Receiving multiple EVPN MAC/IP Advertisement routes with
                I=1
                the I flag set to 1 for the same IP but a different MAC address is considered a
                misconfiguration or a transient error condition. If this
                happens in the network, a PE receiving multiple routes (with
                I=1
                the I flag set to 1 for the same IP and a different MAC address) SHOULD <bcp14>SHOULD</bcp14> update
                the IP-&gt;MAC entry with the latest received information.
                Note that if a configured IP1-&gt;MAC1 changes to point to a
                new MAC address, i.e., IP1-&gt;MAC2, the EVPN MAC/IP
                Advertisement route for IP1-&gt;MAC1 will be withdrawn before
                the EVPN MAC/IP Advertisement route for IP1-&gt;MAC2 is
                advertised.</t>

                <t>A
                advertised.</li>

              <li>A PE originating an EVPN MAC/IP Advertisement route for
                IP1-&gt;MAC1 with I=1 MAY the I flag set to 1 <bcp14>MAY</bcp14> also originate the route with the
                Static bit
                "Sticky/static flag" set (in the MAC Mobility Extended Community). In
                such a case, the IP1-&gt;MAC1 binding is not only immutable
                but it cannot move as well. Even so, if an update for the same
                IP1-&gt;MAC1
                immutable and static, static IP1-&gt;MAC1 is received from a
                different PE, one of the two routes will be selected. This
                case
                is analogous to the <xref target="RFC7432"/> case described in <xref target="RFC7432" sectionFormat="of" section="15.2"/> when
                two MAC/IP routes with the Static bit static flag set are received, and
                the PE likewise MUST <bcp14>MUST</bcp14> alert the operator of such a
                situation.</t>
              </list></t>
          </list>In
                situation.</li>
            </ul>
          </li>
        </ul>
        <t>In a situation where a host (with an IP-&gt;MAC that is
        configured as Immutable immutable binding in the attached PE) is allowed to move
        between PEs (that is, the associated MAC is non-static), PEs can
        receive multiple MAC/IP advertisement Advertisement routes for the same IP-&gt;MAC.
        In such situations, MAC mobility procedures as in <xref
        target="RFC7432"/> target="RFC7432" format="default"/> dictate the reachability of the MAC.</t>
        <t>As an example of the use of the I Flag, flag, consider PE1, PE2 PE2, and PE3
        are attached to the same BD. PE1 originates an EVPN MAC/IP
        Advertisement route for IP1-&gt;MAC1 with I=1; the I flag set to 1 later on, PE2 also
        originates an EVPN MAC/IP Advertisement route IP1-&gt;MAC1 with a
        higher sequence number and I=1. the I flag set to 1. Then all the EVPN PEs attached to the
        same BD SHOULD <bcp14>SHOULD</bcp14> retain their IP1-&gt;MAC1 ARP/ND binding but update
        MAC1's forwarding destination to PE2. If for For some reason, if PE3
        originates an EVPN MAC/IP Advertisement route for IP1-&gt;MAC2 with
        I=0
        the I flag set to 0 (even with a higher sequence number), then the EVPN PEs in the BD
        will not update their IP1-&gt;MAC1 ARP/ND bindings, bindings since IP1 is bound
        to MAC1 (MAC2 SHOULD <bcp14>SHOULD</bcp14> still be programmed in the layer-2 Layer 2 BDs). This is
        considered a misconfiguration in PE3.</t>

        <t>The use of
        <t>When the Flag I=1 assumes that I flag is set to 1, a given IP is assumed to be always bound to
        the same MAC address, and therefore address; therefore, the mobility procedures described
        in <xref target="I-D.ietf-bess-evpn-irb-extended-mobility"/> target="I-D.ietf-bess-evpn-irb-extended-mobility" format="default"/> for "Host
        IP move to a new MAC" will not apply.</t>
      </section>
    </section>
    <section anchor="sect-4" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The same security considerations described in <xref
      target="RFC7432"/> target="RFC7432" format="default"/> apply to this document. In general, it is worth
      noting that the use of Proxy ARP/ND proxy-ARP/ND in EVPN BDs may add some security
      risks. Attackers can make use of ARP/ND messages to create state in all
      the PEs attached to the same BD as the attacker and exhaust resources in
      those PEs. Therefore, additional security mechanisms may be needed. Some
      examples of such additional security mechanisms are e.g., limit limiting the
      number of Proxy ARP/ND proxy-ARP/ND entries per-BD/per-port, per BD and/or per port or monitor closely monitoring the
      rate at which hosts create dynamic Proxy-ARP/ND proxy-ARP/ND entries.</t>
      <t>In addition, this document adds pieces of information that impact on
      the way ARP/ND entries are installed in ARP/ND and/or proxy-ARP/ND
      tables, and therefore
      tables and, therefore, impacts the resolution protocols for IPv4 and IPv6
      addresses. For instance, if a given IPv6-&gt;MAC binding is configured
      with the wrong R or O Flags flags (intentionally or not) on a given PE, the
      rest of the PEs attached to the same BD will install the wrong
      information for the IPv6-&gt;MAC. This will cause all the PEs in the BD
      to reply to Neighbor Solicitations for the IPv6 with Neighbor
      Advertisement (NA)
      NA messages containing the wrong R and O Flags. flags. For
      example, as specified in <xref target="RFC4861"/>, target="RFC4861" format="default"/>, the receiver of a an NA
      message with O not set will not update its existing cache entry for the
      IP-&gt;MAC, hence
      IP-&gt;MAC; hence, the communication between the owner of the IP address
      and the receiver of the NA message with the wrong O flag will fail.
      Similarly, the receiver of a an NA message with the wrong R flag, flag may
      update its Default Router List by incorrectly adding or removing an entry,
      which could could, for example example, lead to sending traffic to a node that is not a
      router, causing the traffic to be dropped .</t> dropped.</t>

      <t>The I Flag, flag, or Immutable ARP/ND Binding Flag, introduces flag, is a useful
      security tool so that tool, allowing an operator makes sure to ensure a given IP address is
      always bound to the same MAC and that information is distributed to all
      the PEs attached to the same BD. ARP/ND spoofing attacks from hosts
      injecting attacks, in which a malicious host injects Gratuitous ARPs or unsolicited Neighbor Advertisement messages NAs
      for that IP address with a different MAC address address, will not succeed to be
      programmed in
      programming the ARP/ND and proxy-ARP/ND tables and therefore the spoofer will avoid
      attracting traffic to not receive the spoofer.</t> traffic.</t>
    </section>
    <section anchor="sect-5" title="IANA Considerations">
      <t>This document request that the Name of numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>IANA has changed the currently registered value name
      for Sub-Type Value 0x08 in the EVPN "EVPN Extended Community Sub-Types Sub-Types" registry
      (https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml#evpn)
      be changed to:</t>

      <texttable>
        <ttcol>Sub-Type</ttcol>

        <ttcol>Name</ttcol>

        <ttcol>Reference</ttcol>

        <c>0x08</c>

        <c>ARP/ND Extended Community</c>

        <c>[this document]</c>
      </texttable>

      <t>This document also requests
      <xref target="IANA-BGP-EXT-COMM" format="default"/>
      to the following:</t>
      <table align="center">
        <name>Updated Value in the "EVPN Extended Community Sub-Types" Registry</name>
        <thead>
          <tr>
            <th align="left">Sub-Type Value</th>
            <th align="left">Name</th>
            <th align="left">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">0x08</td>
            <td align="left">ARP/ND Extended Community</td>
            <td align="left">RFC 9047</td>
          </tr>
        </tbody>
      </table>
      <t>IANA has created the creation of a registry called "ARP/ND
      Extended Community Flags" registry, where the following initial allocations are have
      been made:</t>

      <texttable>
        <ttcol>Flag position</ttcol>

        <ttcol>Name</ttcol>

        <ttcol>Reference</ttcol>

        <c>0-3</c>

        <c>Unassigned</c>

        <c>-</c>

        <c>4</c>

        <c>Immutable
      <table align="center">
        <name>Initial Values of the "ARP/ND Extended Community Flags" Registry</name>
        <thead>
          <tr>
            <th align="left">Flag Position</th>
            <th align="left">Name</th>
            <th align="left">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">0-3</td>
            <td align="left">Unassigned</td>
            <td align="left"></td>
          </tr>
          <tr>
            <td align="left">4</td>
            <td align="left">Immutable ARP/ND Binding Flag (I)</c>

        <c>[this document]</c>

        <c>5</c>

        <c>Unassigned</c>

        <c>-</c>

        <c>6</c>

        <c>Override Flag (O)</c>

        <c>[this document]</c>

        <c>7</c>

        <c>Router Flag (R)</c>

        <c>[this document]</c>
      </texttable> (I)</td>
            <td align="left">RFC 9047</td>
          </tr>
          <tr>
            <td align="left">5</td>
            <td align="left">Unassigned</td>
            <td align="left"></td>
          </tr>
          <tr>
            <td align="left">6</td>
            <td align="left">Override Flag (O)</td>
            <td align="left">RFC 9047</td>
          </tr>
          <tr>
            <td align="left">7</td>
            <td align="left">Router Flag (R)</td>
            <td align="left">RFC 9047</td>
          </tr>
        </tbody>
      </table>

      <t>The registration procedure policy for this registry is Standards Action. Action <xref target="RFC8126" format="default"/>.
      This registry should be is located in the Border "Border Gateway Protocol (BGP)
      Extended Communities general Communities" registry
      (https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml).</t>
      <xref target="IANA-BGP-EXT-COMM" format="default"/>.</t>
      <t>Note that the Flag flag position 5 is left unassigned and not used in this
      specification since it was previously requested by <xref
      target="I-D.rbickhart-evpn-ip-mac-proxy-adv"/>.</t> target="I-D.rbickhart-evpn-ip-mac-proxy-adv" format="default"/>.</t>
    </section>
  </middle>
  <back>

<displayreference target="I-D.ietf-bess-evpn-irb-extended-mobility" to="EXTENDED-MOBILITY"/>
<displayreference target="I-D.rbickhart-evpn-ip-mac-proxy-adv" to="EVPN-IP-MAC-PROXY"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <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.7432.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"/>
      </references>
      <references>
        <name>Informative References</name>

<reference anchor='I-D.ietf-bess-evpn-irb-extended-mobility'>
<front>
<title>Extended Mobility Procedures for EVPN-IRB</title>

<author initials='N' surname='Malhotra' fullname='Neeraj Malhotra' role="editor">
    <organization />
</author>

<author initials='A' surname='Sajassi' fullname='Ali Sajassi'>
    <organization />
</author>

<author initials='A' surname='Pattekar' fullname='Aparna Pattekar'>
    <organization />
</author>

<author initials='A' surname='Lingala' fullname='Avinash Lingala'>
    <organization />
</author>

<author initials='J' surname='Rabadan' fullname='Jorge Rabadan'>
    <organization />
</author>

<author initials='J' surname='Drake' fullname='John Drake'>
    <organization />
</author>

<date month='March' day='15' year='2021' />

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-bess-evpn-irb-extended-mobility-05' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-bess-evpn-irb-extended-mobility-05.txt' />
</reference>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.rbickhart-evpn-ip-mac-proxy-adv.xml"/>

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

<reference anchor="IANA-BGP-EXT-COMM" target="https://www.iana.org/assignments/bgp-extended-communities">
  <front>
    <title>Border Gateway Protocol (BGP) Extended Communities</title>
    <author><organization>IANA</organization></author>
  </front>
</reference>

      </references>
    </references>
    <section anchor="sect-6" title="Acknowledgments"> numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>The authors would like to thank Ali Sajassi <contact fullname="Ali Sajassi"/> for his feedback.</t>
    </section>
  </middle>

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

      &RFC7432;

      &RFC2119;

      &RFC8174;
    </references>

    <references title="Informative References">
      &I-D.ietf-bess-evpn-irb-extended-mobility;

      <reference anchor="I-D.rbickhart-evpn-ip-mac-proxy-adv">
        <front>
          <title>Proxy IP-&gt;MAC Advertisement in EVPNs</title>

          <author fullname="R. Bickhart" initials="R" surname="Bickhart">
            <organization>Twitch</organization>
          </author>

          <date day="23" month="January" year="2020"/>
        </front>
      </reference>
    </references>

  </back>
</rfc>