Diff: rfc9047xml2.original.xml

	rfc9047xml2.original.xml	rfc9047.xml

	<?xml version="1.0" encoding="US-ASCII"?>	<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
	<!ENTITY RFC4861 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.4861.xml">
	<!ENTITY RFC7432 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.7432.xml">
	<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.2119.xml">
	<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.8174.xml">
	<!ENTITY I-D.ietf-bess-evpn-irb-extended-mobility SYSTEM "https://xml2rfc.ietf.o
	rg/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/pu
	blic/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"?>
	<rfc category="std" docName="draft-ietf-bess-evpn-na-flags-09"
	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*+-"?>	<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">


	<?rfc toc="yes"?>	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-bess-evpn-na -flags-09" number="9047" ipr="trust200902" submissionType="IETF" category="std" consensus="true" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDept h="3" symRefs="true" sortRefs="true" version="3">

	<front>	<front>

	<title abbrev="EVPN Neighbor Advertisement Flags">Propagation of ARP/ND	<title abbrev="EVPN ARP/ND Flags">Propagation of ARP/ND Flags in an Ethernet
	Flags in EVPN</title>	Virtual Private Network (EVPN)</title>
		<seriesInfo name="RFC" value="9047"/>
	<author fullname="Jorge Rabadan" initials="J." role="editor"	<author fullname="Jorge Rabadan" initials="J." role="editor" surname="Rabada
	surname="Rabadan">	n">
	<organization>Nokia</organization>	<organization>Nokia</organization>


	<address>	<address>
	<postal>	<postal>
	<street>777 Middlefield Road</street>	<street>777 Middlefield Road</street>


	<city>Mountain View</city>	<city>Mountain View</city>


	<region>CA</region>	<region>CA</region>


	<code>94043</code>	<code>94043</code>

		<country>United States of America</country>
	<country>USA</country>
	</postal>	</postal>


	<email>jorge.rabadan@nokia.com</email>	<email>jorge.rabadan@nokia.com</email>
	</address>	</address>
	</author>	</author>


	<author fullname="Senthil Sathappan" initials="S." surname="Sathappan">	<author fullname="Senthil Sathappan" initials="S." surname="Sathappan">
	<organization>Nokia</organization>	<organization>Nokia</organization>


	<address>	<address>
	<postal>	<postal>
	<street>701 E. Middlefield Road</street>	<street>701 E. Middlefield Road</street>

		<city>Mountain View</city>
	<street>Mountain View, CA 94043 USA</street>	<region>CA</region>
		<code>94043</code>
		<country>United States of America</country>
	</postal>	</postal>


	<email>senthil.sathappan@nokia.com</email>	<email>senthil.sathappan@nokia.com</email>
	</address>	</address>
	</author>	</author>


	<author fullname="Kiran Nagaraj" initials="K." surname="Nagaraj">	<author fullname="Kiran Nagaraj" initials="K." surname="Nagaraj">
	<organization>Nokia</organization>	<organization>Nokia</organization>


	<address>	<address>
	<postal>	<postal>
	<street>701 E. Middlefield Road</street>	<street>701 E. Middlefield Road</street>

		<city>Mountain View</city>
	<street>Mountain View, CA 94043 USA</street>	<region>CA</region>
		<code>94043</code>
		<country>United States of America</country>
	</postal>	</postal>


	<email>kiran.nagaraj@nokia.com</email>	<email>kiran.nagaraj@nokia.com</email>
	</address>	</address>
	</author>	</author>


	<author fullname="Wen Lin" initials="W." surname="Lin">	<author fullname="Wen Lin" initials="W." surname="Lin">
	<organization abbrev="Juniper">Juniper Networks</organization>	<organization abbrev="Juniper">Juniper Networks</organization>


	<address>	<address>
	<email>wlin@juniper.net</email>	<email>wlin@juniper.net</email>
	</address>	</address>
	</author>	</author>

		<date month="June" year="2021"/>
	<date day="1" month="December" year="2020"/>

	<workgroup>BESS Workgroup</workgroup>	<workgroup>BESS Workgroup</workgroup>


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

	<abstract>	<abstract>
	<t>This document defines an Extended Community that is advertised along	<t>This document defines an Extended Community that is advertised along

	with an EVPN MAC/IP Advertisement route and carries information relevant	with an Ethernet Virtual Private Network (EVPN) Media Access Control (MAC)
	to the ARP/ND resolution, so that an EVPN PE implementing a proxy-ARP/ND	/ IP Advertisement route and carries information relevant
	or ARP/ND (on IRB interfaces) function can reply to ARP Requests or	to the Address Resolution Protocol (ARP) / Neighbor Discovery (ND) resolut
	Neighbor Solicitations with the correct information.</t>	ion so that an EVPN Provider Edge (PE) implementing a proxy-ARP/ND function in b
		roadcast domains (BDs) or an ARP/ND function on Integrated
		Routing and Bridging (IRB) interfaces can reply to ARP Requests or
		Neighbor Solicitation (NS) messages with the correct information.</t>
	</abstract>	</abstract>
	</front>	</front>


	<middle>	<middle>

	<section anchor="sect-1" title="Introduction">	<section anchor="sect-1" numbered="true" toc="default">
	<t>An Ethernet Virtual Private Network (EVPN) MAC/IP Advertisement route	<name>Introduction</name>
		<t>An EVPN MAC/IP Advertisement route
	can optionally carry IPv4 or IPv6 addresses associated with a MAC	can optionally carry IPv4 or IPv6 addresses associated with a MAC

	address. Remote Provider Edge (PE) routers can use this information to	address. Remote PE routers can use this information to
	populate their Address Resolution Protocol (ARP) or Neighbor Discovery	populate their ARP or ND tables on IRB interfaces or their
	(ND) tables on Integrated Routing and Bridging (IRB) interfaces or their	proxy-ARP/ND tables in BDs. PEs can then reply
	proxy-ARP/ND tables in Broadcast Domains (BD). PEs can then reply	locally (act as an ARP/ND proxy, as per <xref target="RFC7432" format="def
	locally (act as an ARP/ND proxy, as per <xref target="RFC7432"/>) to	ault"/>) to
	IPv4 ARP requests and IPv6 Neighbor Solicitation messages and	IPv4 ARP Requests and IPv6 Neighbor Solicitation messages and
	reduce/suppress the flooding produced by the Address Resolution	reduce or suppress the flooding produced by the address resolution
	procedure. However, the information conveyed in the EVPN MAC/IP	procedure. However, the information conveyed in the EVPN MAC/IP
	Advertisement route may not be enough for the remote PE to reply to	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->MAC ND	local ARP or ND requests. For example, if a PE learns an IPv6 address and
	entry via EVPN, the PE would not know if that particular IPv6->MAC	MAC address combination ND
	pair belongs to a router or a host, and if that address is an anycast	entry via EVPN (denoted by IPv6->MAC), the PE would not know if that pa
		rticular IPv6->MAC
		pair belongs to a router or a host or if that address is an anycast
	address, as this information is not carried in the EVPN MAC/IP	address, as this information is not carried in the EVPN MAC/IP
	Advertisement routes.</t>	Advertisement routes.</t>


	<t>This document defines an Extended Community that is advertised along	<t>This document defines an Extended Community that is advertised along
	with an EVPN MAC/IP Advertisement route and carries information relevant	with an EVPN MAC/IP Advertisement route and carries information relevant

	to the ARP/ND resolution, so that an EVPN PE implementing a proxy-ARP/ND	to the ARP/ND resolution so that an EVPN PE implementing a proxy-ARP/ND
	function can reply to ARP Requests or Neighbor Solicitations with the	function can reply to ARP Requests or Neighbor Solicitations with the

	correct information. In particular, the Flags defined in <xref	correct information. In particular, the flags defined in <xref target="RFC
	target="RFC4861"/> can now be conveyed along with a MAC/IP Advertisement	4861" format="default"/> can now be conveyed along with a MAC/IP Advertisement
	route, so that an egress EVPN PE can issue Neighbor Advertisement	route so that an egress EVPN PE can issue Neighbor Advertisement (NA)
	messages with the correct Flag information.</t>	messages with the correct flag information.</t>
		<t>The flags are carried in the EVPN Address Resolution Protocol
	<t>The Flags are carried in the EVPN Address Resolution Protocol (ARP)	and Neighbor Discovery (ARP/ND) Extended Community, as described in the
	and Neighbor Discovery (ND) Extended Community, as described in the
	following sections.</t>	following sections.</t>

		<section anchor="sect-1.1" numbered="true" toc="default">
	<section anchor="sect-1.1" title="Terminology and Conventions">	<name>Terminology and Conventions</name>
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",	<t>
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	"OPTIONAL" in this document are to be interpreted as described in BCP	IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
	when, they appear in all capitals, as shown here.</t>	RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	<t>EVPN: Ethernet Virtual Private Networks, as in <xref	be interpreted as
	target="RFC7432"/>.</t>	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
		when, and only when, they appear in all capitals, as shown here.
	<t>BD: Broadcast Domain, also described in <xref	</t>
	target="RFC7432"/>.</t>	<dl newline="false" indent="8">
		<dt>EVPN:</dt><dd>Ethernet Virtual Private Networks, as in <xref target=
	<t>ARP: Address Resolution Protocol.</t>	"RFC7432" format="default"/></dd>
		<dt>BD:</dt><dd>Broadcast Domain, also described in <xref target="RFC743
	<t>ND: Neighbor Discovery protocol, specified in <xref	2" format="default"/></dd>
	target="RFC4861"/>.</t>	<dt>ARP:</dt><dd>Address Resolution Protocol</dd>
		<dt>ND:</dt><dd>Neighbor Discovery protocol, specified in <xref target="
	<t>PE: Provider Edge router.</t>	RFC4861" format="default"/></dd>
		<dt>PE:</dt><dd> Provider Edge router</dd>
	<t>CE: Customer Edge router.</t>	<dt>CE:</dt><dd>Customer Edge router</dd>
		<dt>IRB:</dt><dd>Integrated Routing and Bridging interface</dd>
	<t>IRB: Integrated Routing and Bridging interface.</t>	<dt>Proxy-ARP/ND:</dt><dd> A function on the EVPN PEs by which received
		ARP Requests or NS
	<t>Proxy-ARP/ND: function on the EVPN PEs by which received Address
	Resolution Protocol (ARP) Requests or Neighbor Solicitation (NS)
	messages are replied to locally by the PE, without the need to flood	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	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	Requests or NS messages, the PE does a lookup on an ARP/ND table, which
	is a collection of IP->MAC entries learned by the PE.</t>	is a collection of IP->MAC entries learned by the PE.</dd>
		<dt>IP->MAC:</dt><dd>An IP address and MAC address combination that
	<t>IP->MAC: an IP address and MAC address combination that	represents a given host and is added to an ARP
	represents a given host and is added to an Address Resolution Protocol	table or ND table. This document uses IP->MAC
	table or Neighbor Discovery table. This document uses IP->MAC
	generically for IPv4 and IPv6 addresses. When something is specific to	generically for IPv4 and IPv6 addresses. When something is specific to

	IPv4, the document will use IPv4->MAC and likewise, IPv6->MAC	IPv4, the document will use IPv4->MAC; likewise, IPv6->MAC
	will be used when something is specific to IPv6 entries only.</t>	will be used when something is specific to IPv6 entries only.</dd>
		</dl>
	<t>Familiarity with the terminology in <xref target="RFC7432"/> and	<t>Familiarity with the terminology in <xref target="RFC4861" format="de
	<xref target="RFC4861"/> is expected.</t>	fault"/> and <xref target="RFC7432" format="default"/> is expected.</t>
	</section>	</section>
	</section>	</section>

		<section anchor="sect-2" numbered="true" toc="default">
	<section anchor="sect-2" title="The EVPN ARP/ND Extended Community">	<name>The EVPN ARP/ND Extended Community</name>
	<t>This document defines a transitive EVPN Extended Community (Type	<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	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	is advertised along with EVPN MAC/IP Advertisement routes that carry an
	IPv4 or IPv6 address.</t>	IPv4 or IPv6 address.</t>

		<artwork name="" type="" align="left" alt=""><![CDATA[
	<figure>
	<artwork><![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	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 \|	\| Type=0x06 \| Sub-Type=0x08 \|Flags (1 octet)\| Reserved=0 \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Reserved=0 \|	\| Reserved=0 \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	Flags field:	Flags field:

	0 1 2 3 4 5 6 7	0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+
	\| \|I\| \|O\|R\|	\| \|I\| \|O\|R\|
	+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+
	]]></artwork>	]]></artwork>

	</figure>	<t>The following flags are defined in the Flags field, the third octet of

	<t>The following Flags are defined in the Flags field, third octet of
	the Extended Community:</t>	the Extended Community:</t>

		<dl newline="false" indent="5">
	<t>R - Router Flag (corresponds to Bit 23 of the Extended Community)</t>	<dt>R:</dt><dd><t>Router flag (corresponds to Bit 23 of the Extended Commu
		nity)</t>
	<t>Bit 7 of the Flags field is defined as the "Router Flag". When set,	<t>Bit 7 of the Flags field is defined as the "Router flag". When set,
	the R Flag indicates that the IPv6->MAC pair advertised in the MAC/IP	the R flag indicates that the IPv6->MAC pair advertised in the MAC/IP
	Advertisement route along with the Extended Community belongs to an IPv6	Advertisement route, along with the Extended Community, belongs to an IPv6
	router. If the R Flag is zero, the IPv6->MAC pair belongs to a host.	router. If the R flag is zero, the IPv6->MAC pair belongs to a host.
	The receiving PE implementing the ND function will use this information	The receiving PE implementing the ND function will use this information
	in Neighbor Advertisement messages for the associated IPv6 address. This	in Neighbor Advertisement messages for the associated IPv6 address. This

	Flag has no meaning for ARP IPv4->MAC entries and MUST be ignored	flag has no meaning for ARP IPv4->MAC entries and <bcp14>MUST</bcp14> b e ignored
	when the Extended Community is received with an EVPN MAC/IP	when the Extended Community is received with an EVPN MAC/IP

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


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

	IPv4->MAC pair.</t>	IPv4->MAC pair.</t></dd>
		<dt>I:</dt><dd><t>Immutable ARP/ND Binding flag (corresponds to Bit 20 of
	<t>I - Immutable ARP/ND Binding Flag (corresponds to Bit 20 of the	the
	Extended Community)</t>	Extended Community)</t>


	<t>Bit 4 of the Flags field is defined as the "Immutable ARP/ND Binding	<t>Bit 4 of the Flags field is defined as the "Immutable ARP/ND Binding

	Flag". When set, the egress PE indicates that the IP->MAC pair sent	flag". When set, the egress PE indicates that the IP->MAC pair that was sent
	in an EVPN MAC/IP Advertisement route (along with the Extended	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	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	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	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>	addresses received in a different route without the I flag set.</t></dd></
		dl>
	<t>Bits 0-3 and 5 are not assigned by this document. They MUST be set to	<t>Bits 0-3 and 5 are not assigned by this document. They <bcp14>MUST</bcp
	zero, and ignored on receipt.</t>	14> be set to
		zero and ignored on receipt.</t>
	<t>The reserved fields are set to 0 and ignored by the receiver.</t>	<t>The reserved fields are set to 0 and ignored by the receiver.</t>
	</section>	</section>

		<section anchor="sect-3" numbered="true" toc="default">
	<section anchor="sect-3" title="Use of the EVPN ARP/ND Extended Community">	<name>Use of the EVPN ARP/ND Extended Community</name>
	<t>This section describes the relevant procedures when advertising and	<t>This section describes the relevant procedures when advertising and
	processing the EVPN ARP/ND Extended Community. In all the procedures	processing the EVPN ARP/ND Extended Community. In all the procedures

	below a "PE" must be interpreted as a "PE which supports the ND/ARP	below, a "PE" must be interpreted as a "PE that supports the proxy-ARP/ND
	proxy function (introduced by <xref target="RFC7432"/>) and implements	(introduced by <xref target="RFC7432" format="default"/>) and implements
	the propagation of the ARP/ND Flags that this document specifies".</t>	the propagation of the ARP/ND flags that this document specifies".</t>
		<section anchor="sect-3.1" numbered="true" toc="default">
	<section anchor="sect-3.1"	<name>Transmission of the EVPN ARP/ND Extended Community</name>
	title="Transmission of the EVPN ARP/ND Extended Community">
	<t>When an IP->MAC entry is not learned via EVPN, a PE may learn	<t>When an IP->MAC entry is not learned via EVPN, a PE may learn
	IP->MAC pairs in the management plane (this will create static	IP->MAC pairs in the management plane (this will create static
	entries in the ARP/ND or proxy-ARP/ND table) or by snooping ARP or	entries in the ARP/ND or proxy-ARP/ND table) or by snooping ARP or

	Neighbor Advertisement (NA) messages coming from the CE (this will	NA messages coming from the CE (this will
	create dynamic entries). Those static and dynamic IP->MAC entries	create dynamic entries). Those static and dynamic IP->MAC entries
	will be advertised in EVPN MAC/IP Advertisement routes that use the	will be advertised in EVPN MAC/IP Advertisement routes that use the
	EVPN ARP/ND Extended Community as follows:</t>	EVPN ARP/ND Extended Community as follows:</t>

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

	case of static entries.</t>	case of static entries.</li>
		<li>MAC/IP Advertisement routes for IPv4->MAC entries <bcp14>MAY</b
	<t>MAC/IP Advertisement routes for IPv4->MAC entries MAY	cp14>
	include one ARP/ND Extended Community. If the EVPN ARP/ND Extended	include one ARP/ND Extended Community. If the EVPN ARP/ND Extended
	Community is advertised along with an EVPN IPv4/MAC Advertisement	Community is advertised along with an EVPN IPv4/MAC Advertisement

	route, the R and O Flags SHOULD be set to zero.</t>	route, the R and O flags <bcp14>SHOULD</bcp14> be set to zero.</li>
		<li>If an IP->MAC pair is static (it has been configured), the
	<t>If an IP->MAC pair is static (it has been configured) the	corresponding MAC/IP Advertisement route <bcp14>MUST</bcp14> be sent
	corresponding MAC/IP Advertisement route MUST be sent along with	along with
	an ARP/ND Extended Community with the I Flag set.</t>	an ARP/ND Extended Community with the I flag set.</li>
		<li>This Extended Community does not change the procedures
	<t>This Extended Community does not change the procedures	described in <xref target="RFC7432" format="default"/>. Specifically
	described in <xref target="RFC7432"/>. Specifically the procedures	, the procedures
	for advertising the MAC Mobility Extended Community along with the	for advertising the MAC Mobility Extended Community along with the

	MAC/IP Advertisement route are not changed.</t>	MAC/IP Advertisement route are not changed.</li>
	</list></t>	</ul>
	</section>	</section>

		<section anchor="sect-3.2" numbered="true" toc="default">
	<section anchor="sect-3.2"	<name>Reception of the EVPN ARP/ND Extended Community</name>
	title="Reception of the EVPN ARP/ND Extended Community">	<t>In addition to the procedures specified in <xref target="RFC7432" for
	<t>In addition to the procedures specified in <xref target="RFC7432"/>	mat="default"/>,
	a PE receiving a MAC/IP Advertisement route will process the EVPN	a PE receiving a MAC/IP Advertisement route will process the EVPN
	ARP/ND Extended Community as follows:</t>	ARP/ND Extended Community as follows:</t>

		<ul spacing="normal">
	<t><list style="symbols">	<li>Only one EVPN ARP/ND Extended Community is expected to be
	<t>Only one EVPN ARP/ND Extended Community is expected to be
	received along with an EVPN MAC/IP Advertisement route. If more	received along with an EVPN MAC/IP Advertisement route. If more

	than one ARP/ND Extended Community is received, the PE MUST	than one ARP/ND Extended Community is received, the PE <bcp14>MUST</ bcp14>
	consider only the first one on the list for processing purposes	consider only the first one on the list for processing purposes

	and MUST NOT propagate the rest of the ARP/ND Extended	and <bcp14>MUST NOT</bcp14> propagate the rest of the ARP/ND Extende
	Communities.</t>	d
		Communities.</li>
	<t>The R, O and I Flags MUST be ignored if they are advertised	<li>The R, O, and I flags <bcp14>MUST</bcp14> be ignored if they are a
		dvertised
	along with an EVPN MAC/IP Advertisement route that does not	along with an EVPN MAC/IP Advertisement route that does not

	contain an IP (IPv4 or IPv6) address. Otherwise they are processed	contain an IP (IPv4 or IPv6) address. Otherwise, they are processed
	as follows.</t>	as follows.</li>
		<li>
	<t>R and O Flags processing:<list style="symbols">	<t>R and O flag processing:</t>
	<t>If the EVPN MAC/IP Advertisement route contains an IPv6	<ul spacing="normal">
	address and the EVPN ARP/ND Extended Community, the PE MUST	<li>If the EVPN MAC/IP Advertisement route contains an IPv6
	add the R and O Flag values to the ND entry in the ND or	address and the EVPN ARP/ND Extended Community, the PE <bcp14>MU
	proxy-ND table, and propagate the value of the R and O flags	ST</bcp14>
		add the R and O flag values to the ND entry in the ND or
		proxy-ND table and propagate the value of the R and O flags
	from the ARP/ND Extended Community to the Neighbor	from the ARP/ND Extended Community to the Neighbor

	Advertisements when replying to a Solicitation for the IPv6	Advertisements when replying to a solicitation for the IPv6
	address.</t>	address.</li>
		<li>If no EVPN ARP/ND Extended Community is received along with
	<t>If no EVPN ARP/ND Extended Community is received along with	the route, the PE will add the default R and O flags to the
	the route, the PE will add the default R and O Flags to the	entry. The default R flag <bcp14>SHOULD</bcp14> be an administra
	entry. The default R Flag SHOULD be an administrative choice.	tive choice.
	The default O Flag SHOULD be 1.</t>	The default O flag <bcp14>SHOULD</bcp14> be 1.</li>
		<li>A PE <bcp14>MUST</bcp14> ignore the received R and O flags for
	<t>A PE MUST ignore the received R and O Flags for an EVPN	an EVPN
	MAC/IP Advertisement route that contains an IPv4->MAC	MAC/IP Advertisement route that contains an IPv4->MAC

	pair.</t>	pair.</li>
	</list></t>	</ul>
		</li>
	<t>I Flag processing:<list style="symbols">	<li>
	<t>A PE receiving an EVPN MAC/IP Advertisement route	<t>I flag processing:</t>
	containing an IP->MAC and the I Flag set SHOULD install the	<ul spacing="normal">
		<li>A PE receiving an EVPN MAC/IP Advertisement route
		containing an IP->MAC and the I flag set <bcp14>SHOULD</bcp14
		> install the
	IP->MAC entry in the ARP/ND or proxy-ARP/ND table as an	IP->MAC entry in the ARP/ND or proxy-ARP/ND table as an

	"Immutable binding". This Immutable binding entry will	"immutable binding". This immutable binding entry will
	override an existing non-immutable binding for the same	override an existing non-immutable binding for the same
	IP->MAC. The absence of the EVPN ARP/ND Extended Community	IP->MAC. The absence of the EVPN ARP/ND Extended Community
	in a MAC/IP Advertisement route indicates that the IP->MAC	in a MAC/IP Advertisement route indicates that the IP->MAC

	entry is not an "Immutable binding".</t>	entry is not an "immutable binding".</li>


	<t>Receiving multiple EVPN MAC/IP Advertisement routes with	<li>Receiving multiple EVPN MAC/IP Advertisement routes with
	I=1 for the same IP but different MAC is considered a	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	misconfiguration or a transient error condition. If this
	happens in the network, a PE receiving multiple routes (with	happens in the network, a PE receiving multiple routes (with

	I=1 for the same IP and a different MAC address) SHOULD update	the I flag set to 1 for the same IP and a different MAC address) <bcp14>SHOULD</bcp14> update
	the IP->MAC entry with the latest received information.	the IP->MAC entry with the latest received information.
	Note that if a configured IP1->MAC1 changes to point to a	Note that if a configured IP1->MAC1 changes to point to a
	new MAC address, i.e., IP1->MAC2, the EVPN MAC/IP	new MAC address, i.e., IP1->MAC2, the EVPN MAC/IP
	Advertisement route for IP1->MAC1 will be withdrawn before	Advertisement route for IP1->MAC1 will be withdrawn before
	the EVPN MAC/IP Advertisement route for IP1->MAC2 is	the EVPN MAC/IP Advertisement route for IP1->MAC2 is

	advertised.</t>	advertised.</li>


	<t>A PE originating an EVPN MAC/IP Advertisement route for	<li>A PE originating an EVPN MAC/IP Advertisement route for
	IP1->MAC1 with I=1 MAY also originate the route with the	IP1->MAC1 with the I flag set to 1 <bcp14>MAY</bcp14> also or
	Static bit set (in the MAC Mobility Extended Community). In	iginate the route with the
		"Sticky/static flag" set (in the MAC Mobility Extended Community
		). In
	such a case, the IP1->MAC1 binding is not only immutable	such a case, the IP1->MAC1 binding is not only immutable
	but it cannot move as well. Even so, if an update for the same	but it cannot move as well. Even so, if an update for the same

	IP1->MAC1 immutable and static, is received from a	immutable and static IP1->MAC1 is received from a
	different PE, one of the two routes will be selected. This	different PE, one of the two routes will be selected. This

	case is analogous to the <xref target="RFC7432"/> case when	is analogous to the case described in <xref target="RFC7432" sec
	two MAC/IP routes with the Static bit set are received, and	tionFormat="of" section="15.2"/> when
	the PE likewise MUST alert the operator of such a	two MAC/IP routes with the static flag set are received, and
	situation.</t>	the PE likewise <bcp14>MUST</bcp14> alert the operator of such a
	</list></t>	situation.</li>
	</list>In a situation where a host (with an IP->MAC that is	</ul>
	configured as Immutable binding in the attached PE) is allowed to move	</li>
		</ul>
		<t>In a situation where a host (with an IP->MAC that is
		configured as immutable binding in the attached PE) is allowed to move
	between PEs (that is, the associated MAC is non-static), PEs can	between PEs (that is, the associated MAC is non-static), PEs can

	receive multiple MAC/IP advertisement routes for the same IP->MAC.	receive multiple MAC/IP Advertisement routes for the same IP->MAC.
	In such situations, MAC mobility procedures as in <xref	In such situations, MAC mobility procedures as in <xref target="RFC7432"
	target="RFC7432"/> dictate the reachability of the MAC.</t>	format="default"/> dictate the reachability of the MAC.</t>
		<t>As an example of the use of the I flag, consider PE1, PE2, and PE3 at
	<t>As an example of the use of the I Flag, consider PE1, PE2 and PE3	tached to the same BD. PE1 originates an EVPN MAC/IP
	are attached to the same BD. PE1 originates an EVPN MAC/IP	Advertisement route for IP1->MAC1 with the I flag set to 1 later on,
	Advertisement route for IP1->MAC1 with I=1; later on, PE2 also	PE2 also
	originates an EVPN MAC/IP Advertisement route IP1->MAC1 with a	originates an EVPN MAC/IP Advertisement route IP1->MAC1 with a

	higher sequence number and I=1. Then all the EVPN PEs attached to the	higher sequence number and the I flag set to 1. Then all the EVPN PEs at
	same BD SHOULD retain their IP1->MAC1 ARP/ND binding but update	tached to the
	MAC1's forwarding destination to PE2. If for some reason, PE3	same BD <bcp14>SHOULD</bcp14> retain their IP1->MAC1 ARP/ND binding b
		ut update
		MAC1's forwarding destination to PE2. For some reason, if PE3
	originates an EVPN MAC/IP Advertisement route for IP1->MAC2 with	originates an EVPN MAC/IP Advertisement route for IP1->MAC2 with

	I=0 (even with a higher sequence number), then the EVPN PEs in the BD	the I flag set to 0 (even with a higher sequence number), then the EVPN
	will not update their IP1->MAC1 ARP/ND bindings, since IP1 is bound	PEs in the BD
	to MAC1 (MAC2 SHOULD still be programmed in the layer-2 BDs). This is	will not update their IP1->MAC1 ARP/ND bindings since IP1 is bound
		to MAC1 (MAC2 <bcp14>SHOULD</bcp14> still be programmed in the Layer 2 B
		Ds). This is
	considered a misconfiguration in PE3.</t>	considered a misconfiguration in PE3.</t>

		<t>When the I flag is set to 1, a given IP is assumed to be always bound
	<t>The use of the Flag I=1 assumes that a given IP is always bound to	to
	the same MAC address, and therefore the mobility procedures described	the same MAC address; therefore, the mobility procedures described
	in <xref target="I-D.ietf-bess-evpn-irb-extended-mobility"/> for "Host	in <xref target="I-D.ietf-bess-evpn-irb-extended-mobility" format="defau
		lt"/> for "Host
	IP move to a new MAC" will not apply.</t>	IP move to a new MAC" will not apply.</t>
	</section>	</section>
	</section>	</section>

		<section anchor="sect-4" numbered="true" toc="default">
	<section anchor="sect-4" title="Security Considerations">	<name>Security Considerations</name>
	<t>The same security considerations described in <xref	<t>The same security considerations described in <xref target="RFC7432" fo
	target="RFC7432"/> apply to this document. In general, it is worth	rmat="default"/> apply to this document. In general, it is worth
	noting that the use of Proxy ARP/ND in EVPN BDs may add some security	noting that the use of proxy-ARP/ND in EVPN BDs may add some security
	risks. Attackers can make use of ARP/ND messages to create state in all	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	the PEs attached to the same BD as the attacker and exhaust resources in
	those PEs. Therefore, additional security mechanisms may be needed. Some	those PEs. Therefore, additional security mechanisms may be needed. Some

	examples of such additional security mechanisms are e.g., limit the	examples of such additional security mechanisms are limiting the
	number of Proxy ARP/ND entries per-BD/per-port, or monitor closely the	number of proxy-ARP/ND entries per BD and/or per port or closely monitorin
	rate at which hosts create dynamic Proxy-ARP/ND entries.</t>	g the
		rate at which hosts create dynamic proxy-ARP/ND entries.</t>
	<t>In addition, this document adds pieces of information that impact on	<t>In addition, this document adds pieces of information that impact
	the way ARP/ND entries are installed in ARP/ND and/or proxy-ARP/ND	the way ARP/ND entries are installed in ARP/ND and/or proxy-ARP/ND

	tables, and therefore the resolution protocols for IPv4 and IPv6	tables and, therefore, impacts the resolution protocols for IPv4 and IPv6
	addresses. For instance, if a given IPv6->MAC binding is configured	addresses. For instance, if a given IPv6->MAC binding is configured

	with the wrong R or O Flags (intentionally or not) on a given PE, the	with the wrong R or O flags (intentionally or not) on a given PE, the
	rest of the PEs attached to the same BD will install the wrong	rest of the PEs attached to the same BD will install the wrong
	information for the IPv6->MAC. This will cause all the PEs in the BD	information for the IPv6->MAC. This will cause all the PEs in the BD

	to reply to Neighbor Solicitations for the IPv6 with Neighbor	to reply to Neighbor Solicitations for the IPv6 with
	Advertisement (NA) messages containing the wrong R and O Flags. For	NA messages containing the wrong R and O flags. For
	example, as specified in <xref target="RFC4861"/>, the receiver of a NA	example, as specified in <xref target="RFC4861" format="default"/>, the re
		ceiver of an NA
	message with O not set will not update its existing cache entry for the	message with O not set will not update its existing cache entry for the

	IP->MAC, hence the communication between the owner of the IP address	IP->MAC; hence, the communication between the owner of the IP address
	and the receiver of the NA message with the wrong O flag will fail.	and the receiver of the NA message with the wrong O flag will fail.

	Similarly, the receiver of a NA message with the wrong R flag, may	Similarly, the receiver of an NA message with the wrong R flag may
	update its Default Router List incorrectly adding or removing an entry,	update its Default Router List by incorrectly adding or removing an entry,
	which could for example lead to sending traffic to a node that is not a	which could, for example, lead to sending traffic to a node that is not a
	router, causing the traffic to be dropped .</t>	router, causing the traffic to be dropped.</t>


	<t>The I Flag, or Immutable ARP/ND Binding Flag, introduces a useful	<t>The I flag, or Immutable ARP/ND Binding flag, is a useful
	security tool so that an operator makes sure a given IP address is	security tool, allowing an operator to ensure a given IP address is
	always bound to the same MAC and that information is distributed to all	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	the PEs attached to the same BD. ARP/ND spoofing attacks, in which a malic
	injecting Gratuitous ARPs or unsolicited Neighbor Advertisement messages	ious host injects Gratuitous ARPs or unsolicited NAs
	for that IP address with a different MAC address will not succeed to be	for that IP address with a different MAC address, will not succeed in
	programmed in ARP/ND and proxy-ARP/ND tables and therefore will avoid	programming the ARP/ND and proxy-ARP/ND tables and therefore the spoofer w
	attracting traffic to the spoofer.</t>	ill not receive the traffic.</t>
	</section>	</section>

		<section anchor="sect-5" numbered="true" toc="default">
		<name>IANA Considerations</name>
		<t>IANA has changed the name
		for Sub-Type Value 0x08 in the "EVPN Extended Community Sub-Types" registr
		y
		<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 "ARP/ND
		Extended Community Flags" registry, where the following initial allocation
		s have
		been made:</t>
		<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)</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>


	<section anchor="sect-5" title="IANA Considerations">	<t>The registration policy for this registry is Standards Action <xref tar
	<t>This document request that the Name of the currently registered value	get="RFC8126" format="default"/>.
	for Sub-Type 0x08 in the EVPN Extended Community Sub-Types registry	This registry is located in the "Border Gateway Protocol (BGP)
	(https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-co	Extended Communities" registry
	mmunities.xhtml#evpn)	<xref target="IANA-BGP-EXT-COMM" format="default"/>.</t>
	be changed to:</t>	<t>Note that the flag position 5 is left unassigned and not used in this
		specification since it was previously requested by <xref target="I-D.rbick
	<texttable>	hart-evpn-ip-mac-proxy-adv" format="default"/>.</t>
	<ttcol>Sub-Type</ttcol>	</section>
		</middle>
	<ttcol>Name</ttcol>	<back>

	<ttcol>Reference</ttcol>

	<c>0x08</c>

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

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

	<t>This document also requests the creation of a registry called "ARP/ND
	Extended Community Flags" where the following initial allocations are
	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 ARP/ND Binding Flag (I)</c>

	<c>[this document]</c>


	<c>5</c>	<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-P
		ROXY"/>


	<c>Unassigned</c>	<references>
		<name>References</name>
		<references>
		<name>Normative References</name>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.4861.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.7432.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.2119.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8174.xml"/>
		</references>
		<references>
		<name>Informative References</name>


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


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


	<c>Override Flag (O)</c>	<author initials='A' surname='Sajassi' fullname='Ali Sajassi'>
		<organization />
		</author>


	<c>[this document]</c>	<author initials='A' surname='Pattekar' fullname='Aparna Pattekar'>
		<organization />
		</author>


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


	<c>Router Flag (R)</c>	<author initials='J' surname='Rabadan' fullname='Jorge Rabadan'>
		<organization />
		</author>


	<c>[this document]</c>	<author initials='J' surname='Drake' fullname='John Drake'>
	</texttable>	<organization />
		</author>


	<t>The registration procedure for this registry is Standards Action.	<date month='March' day='15' year='2021' />
	This registry should be located in the Border Gateway Protocol (BGP)
	Extended Communities general registry
	(https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-co
	mmunities.xhtml).</t>


	<t>Note that the Flag position 5 is left unassigned and not used in this	</front>
	specification since it was previously requested by <xref
	target="I-D.rbickhart-evpn-ip-mac-proxy-adv"/>.</t>
	</section>


	<section anchor="sect-6" title="Acknowledgments">	<seriesInfo name='Internet-Draft' value='draft-ietf-bess-evpn-irb-extended-mobil
	<t>The authors would like to thank Ali Sajassi for his feedback.</t>	ity-05' />
	</section>	<format type='TXT'
	</middle>	target='http://www.ietf.org/internet-drafts/draft-ietf-bess-evpn-irb-ext
		ended-mobility-05.txt' />
		</reference>


	<back>	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
	<references title="Normative References">	.rbickhart-evpn-ip-mac-proxy-adv.xml"/>
	&RFC4861;


	&RFC7432;	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8126.xml"/>;


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


	&RFC8174;	</references>;
	</references>	</references>

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


	<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->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>	</back>
	</rfc>	</rfc>

End of changes. 99 change blocks.
	379 lines changed or deleted	402 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/