< draft-thubert-bess-secure-evpn-mac-signaling-01.txt		draft-thubert-bess-secure-evpn-mac-signaling-02.txt >
	BESS P. Thubert, Ed.		BESS P. Thubert, Ed.
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Intended status: Standards Track A. Przygienda		Intended status: Standards Track A. Przygienda
	Expires: 6 June 2022 Juniper Networks, Inc		Expires: 22 July 2022 Juniper Networks, Inc
	J. Tantsura		J. Tantsura
	Microsoft		Microsoft
	3 December 2021		18 January 2022
	Secure EVPN MAC Signaling		Secure EVPN MAC Signaling
	draft-thubert-bess-secure-evpn-mac-signaling-01		draft-thubert-bess-secure-evpn-mac-signaling-02
	Abstract		Abstract
	This specification adds attributes to EVPN to carry IPv6 address		This specification adds attributes to EVPN to carry IPv6 address
	metadata learned from RFC 8505 and RFC 8928 so as to maintain a		metadata learned from RFC 8505 and RFC 8928 so as to maintain a
	synchronized copy of the 6LoWPAN ND registrar at each EVPN router and		synchronized copy of the 6LoWPAN ND registrar at each EVPN router and
	perform locally a unicast IPv6 ND service for address lookup and		perform locally a unicast IPv6 ND service for address lookup and
	duplicate address detection.		duplicate address detection.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 6 June 2022.		This Internet-Draft will expire on 22 July 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2022 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Revised BSD License text as		extracted from this document must include Revised BSD License text as
	described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Revised BSD License.		provided without warranty as described in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4		2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
	2.2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 4		2.2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.3. References . . . . . . . . . . . . . . . . . . . . . . . 5		2.3. References . . . . . . . . . . . . . . . . . . . . . . . 5
	3. 6LoWPAN Neighbor Discovery . . . . . . . . . . . . . . . . . 6		3. 6LoWPAN Neighbor Discovery . . . . . . . . . . . . . . . . . 6
	3.1. RFC 6775 Address Registration . . . . . . . . . . . . . . 6		3.1. IPv6 Interface, Link, and Subnet . . . . . . . . . . . . 6
	3.2. RFC 8505 Extended Address Registration . . . . . . . . . 7		3.2. RFC 6775 Address Registration . . . . . . . . . . . . . . 10
	3.2.1. R Flag . . . . . . . . . . . . . . . . . . . . . . . 8		3.3. RFC 8505 Extended Address Registration . . . . . . . . . 10
	3.2.2. TID, "I" Field and Opaque Fields . . . . . . . . . . 8		3.3.1. R Flag . . . . . . . . . . . . . . . . . . . . . . . 11
	3.2.3. Status . . . . . . . . . . . . . . . . . . . . . . . 8		3.3.2. TID, "I" Field and Opaque Fields . . . . . . . . . . 11
	3.2.4. Route Ownership Verifier . . . . . . . . . . . . . . 9		3.3.3. Status . . . . . . . . . . . . . . . . . . . . . . . 12
	3.2.5. Anycast and Multicast Addresses . . . . . . . . . . . 9		3.3.4. Route Ownership Verifier . . . . . . . . . . . . . . 12
	3.3. RFC 8505 Extended DAR/DAC . . . . . . . . . . . . . . . . 10		3.3.5. Anycast and Multicast Addresses . . . . . . . . . . . 13
	3.4. RFC 7400 Capability Indication Option . . . . . . . . . . 11		3.4. RFC 8505 Extended DAR/DAC . . . . . . . . . . . . . . . . 13
	4. Extending 6LoWPAN ND . . . . . . . . . . . . . . . . . . . . 11		3.5. RFC 7400 Capability Indication Option . . . . . . . . . . 14
	4.1. Use of the R flag in NA . . . . . . . . . . . . . . . . . 11		4. Extending 6LoWPAN ND . . . . . . . . . . . . . . . . . . . . 15
	4.2. Distributing the 6LBR . . . . . . . . . . . . . . . . . . 12		4.1. Use of the R flag in NA . . . . . . . . . . . . . . . . . 15
	4.3. Unicast Address Lookup with the 6LBR . . . . . . . . . . 15		4.2. Distributing the 6LBR . . . . . . . . . . . . . . . . . . 15
	5. Requirements on the EVPN-Unaware Host . . . . . . . . . . . . 21		4.3. Unicast Address Lookup with the 6LBR . . . . . . . . . . 19
	5.1. Support of 6LoWPAN ND . . . . . . . . . . . . . . . . . . 21		5. Requirements on the EVPN-Unaware Host . . . . . . . . . . . . 25
	6. Enhancements to EVPN . . . . . . . . . . . . . . . . . . . . 22		5.1. Support of 6LoWPAN ND . . . . . . . . . . . . . . . . . . 25
	6.1. ARP/ND Extended Community . . . . . . . . . . . . . . . . 24		6. Enhancements to EVPN . . . . . . . . . . . . . . . . . . . . 26
	6.2. ROVR MAC Mobility Extended Community . . . . . . . . . . 26		6.1. ARP/ND Extended Community . . . . . . . . . . . . . . . . 28
	6.3. Extended ROVR MAC Procedures . . . . . . . . . . . . . . 27		6.2. ROVR MAC Mobility Extended Community . . . . . . . . . . 30
	7. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 27		6.3. Extended ROVR MAC Procedures . . . . . . . . . . . . . . 31
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 38		7. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 31
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38		8. Security Considerations . . . . . . . . . . . . . . . . . . . 42
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
	11. Normative References . . . . . . . . . . . . . . . . . . . . 38		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42
	12. Informative References . . . . . . . . . . . . . . . . . . . 40		11. Normative References . . . . . . . . . . . . . . . . . . . . 42
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41		12. Informative References . . . . . . . . . . . . . . . . . . . 44
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
	1. Introduction		1. Introduction
	"Registration Extensions for IPv6 over 6LoWPAN Neighbor Discovery"		"Registration Extensions for IPv6 over 6LoWPAN Neighbor Discovery"
	[RFC8505] (ND) provides a zeroconf routing-agnostic Host-to-Router		[RFC8505] (ND) provides a zeroconf routing-agnostic Host-to-Router
	Link-Local interface for Stateful Address Autoconfiguration.		Link-Local interface for Stateful Address Autoconfiguration.
	"Address-Protected Neighbor Discovery for Low-Power and Lossy		"Address-Protected Neighbor Discovery for Low-Power and Lossy
	Networks" [RFC8928] (AP-ND) adds a zeroconf anti-theft protection		Networks" [RFC8928] (AP-ND) adds a zeroconf anti-theft protection
	that protects the ownership of the autoconfigured address with		that protects the ownership of the autoconfigured address with
	autoconfigured proof of ownership called a Registration Ownership		autoconfigured proof of ownership called a Registration Ownership
	Verifier (ROVR).		Verifier (ROVR).
	[RFC8505] enables the host to claim an IPv6 address and obtain		[RFC8505] enables the host to claim an IPv6 address and obtain
	reachability services for that address. It is already used to inject		reachability services for that address. It is already used to inject
	host routes in RPL [RFC9010] and RIFT "Routing in Fat Trees" [RIFT],		host routes in RPL [RFC9010] and RIFT "Routing in Fat Trees" [RIFT],
	and to maintain a proxy-ND state in a backbone router [RFC8929]; this		and to maintain a proxy-ND state in a backbone router [RFC8929]; this
	specification extends its applicability to the case of Ethernet		specification extends its applicability to the case of Ethernet
	Virtual Private Network (eVPN).		Virtual Private Network (EVPN).
	[RFC8505] specifies a unicast address registration mechanism that		[RFC8505] specifies a unicast address registration mechanism that
	enables the host called a 6LowPAN Node (6LN) to install a ND binding		enables the host called a 6LowPAN Node (6LN) to install a ND binding
	state in the 6LowPAN Router (6LR) that can serve as Neighbor Cache		state in the 6LowPAN Router (6LR) that can serve as Neighbor Cache
	Entry (NCE), though it is not operated as a cache. The protocol		Entry (NCE), though it is not operated as a cache. The protocol
	provides the means to reject the registration in case of address		provides the means to reject the registration in case of address
	duplication. It also enables to discriminate mobility from		duplication. It also enables to discriminate mobility from
	multihoming. [RFC8928] adds the capability to verify the ownership		multihoming. [RFC8928] adds the capability to verify the ownership
	of the address and prevent an attacker from stealing and/or		of the address and prevent an attacker from stealing and/or
	impersonating an address.		impersonating an address.
	skipping to change at page 6, line 26 ¶		skipping to change at page 6, line 26 ¶
	In contrast to Stateless Address Autoconfiguration (SLAAC) [RFC4862]		In contrast to Stateless Address Autoconfiguration (SLAAC) [RFC4862]
	which relies on broadcast for duplicate address detection (DAD) and		which relies on broadcast for duplicate address detection (DAD) and
	address lookup, 6LoWPAN ND installs and maintains a state in the		address lookup, 6LoWPAN ND installs and maintains a state in the
	neighbors for the duration of their interaction. Though it is also		neighbors for the duration of their interaction. Though it is also
	called a Neighbor Cache Entry (BCE) in [RFC6775], and in contrast		called a Neighbor Cache Entry (BCE) in [RFC6775], and in contrast
	with the the BCE in SLAAC, that state is not a cache that can be		with the the BCE in SLAAC, that state is not a cache that can be
	casually flushed and rebuilt. It must be installed proactively and		casually flushed and rebuilt. It must be installed proactively and
	refreshed periodically to maintain the connectivity and enable		refreshed periodically to maintain the connectivity and enable
	unicast-only operations.		unicast-only operations.
	The typical abstraction for an IP Link with 6LoWPAN ND is point-to-		This section goes through the 6LoWPAN ND network abstractions and
	point (P2P) between a node and a router. An IP interface bundles		mechanisms that this specification leverages, as a non-normative
	multiple links between this node and peers in the same subnet, aka		reference to the reader. The relevant normative text is to be found
	point-to-multipoint (P2MP). The subnet is a not-on-link L3-connected		in [RFC6775], [RFC8505], and [RFC8928].
	collection of such nodes and links, which means that the any-to-any
	connectivity across the subnet is ensured through L3 routing as
	opposed to transitive (any-to-any) reachability from L2.
	This section goes through the 6LoWPAN ND mechanisms that this		3.1. IPv6 Interface, Link, and Subnet
	specification leverages, as a non-normative reference to the reader.
	The relevant normative text is to be found in [RFC6775], [RFC8505],
	and [RFC8928].
	3.1. RFC 6775 Address Registration		The typical abstraction for an IP Link with 6LoWPAN ND is a logical
			point-to-point (P2P) link between a node (a host or a router) and a
			router, regardless of the physical medium between the node and the
			router, which may or may not be shared with other nodes.
			A Subnet is deployed over a mesh of nodes connected with those
			logical P2P Links, where routers form a connected dominating set as
			represented in Figure 1; the resulting aggregate is called a
			multilink subnet (MLSN). An MLSN may be only partially meshed, and
			the underlaying network is not expected to provide a multicast or a
			broadcast service across the subnet.
			+------+ +------+
			| Host |----------+ +-----| Host |
			+------+ | | +------+
			| +--------+
			| +-------| Router |
			| | +--------+
			+--------+ | | +------+
			| Router | | +------ | Host |
			+--------+ | +------+
			| | +--------+
			| +---| Router |
			| +--------+
			+------+ | | +------+
			| Host |-----+ +-----| Host |
			+------+ +------+
			Figure 1: PPP Links in an NBMA Mesh
			Consequently, the subnet model is not-on-link, meaning that the any-
			to-any connectivity across the subnet is ensured through L3
			operations (routing or proxy) as opposed to transitive (any-to-any)
			reachability from L2. It also means that hosts do not lookup other
			nodes using IPv6 Neighbor Discovery but forward all their traffic via
			their connected routers. Which in turn means that only routers need
			to be discovered, which is done by sending Router Advertisement (RA)
			messages to all directly reachable nodes in the subnet, e.g., using a
			radio broadcast.
			As illustrated in Figure 2, an IP interface bundles multiple sub-
			interfaces to connect the IP links between this node and peers in the
			same subnet, which is known as a point-to-multipoint (P2MP)
			interface.
			+---------------------
			| P2MP Interface
			| --------------
			| MAC Address
			| IPv6 Link-Local address(es)
			| IPv6 global addresses
			|
			| +------------------------
			| | P2P sub-interface
			| | -----------------
			| | Peer MAC Address
			| | Peer IP addresses
			| +------------------------
			|
			| +------------------------
			| | P2P sub-interface
			| | -----------------
			| | Peer MAC Address
			| | Peer IP addresses
			| +------------------------
			|
			| +------------------------
			| | P2P sub-interface
			| | -----------------
			| | Peer MAC Address
			| | Peer IP addresses
			| +------------------------
			|
			| ....
			|
			+---------------
			Figure 2: P2MP Interface
			In the case of a 6LoWPAN radio, the IP Interface may be physical, and
			the P2P IP links are virtual based on discovered neighbor routers;
			the same model can apply when the node is connected via a switch to
			one or more routers.
			In the case of a multihomed NIC card in a datacenter, the NIC is
			connected to several Top-of-Rack (ToR) switches acting as leaves in
			the fabric, over as many Ethernet physical interfaces. If the NIC
			provides a L2 virtual switch, then the stack can apply the same model
			as above, modeling the virtual port to the virtual switch as a P2MP
			interface.
			On the other hand, if the NIC provides a virtual router, then
			Ethernet ports are L3 ports and the physical link to the leaf is
			modeled as P2P. To form the P2MP interface, the router bundles
			(aggregates) the physical interfaces as the sub-interfaces of a
			single logical P2MP Link, as shown in Figure 3.
			+---------------------
			| NIC Aggregate interface
			| -----------------------
			| virtual MAC Address
			| IPv6 global addresses
			|
			| +------------------------
			| | Ethernet Port 1
			| | -----------------
			| | Physical MAC Address
			| | IPv6 Link-Local address(es)
			| | Leaf MAC Address
			| | Leaf IP addresses
			| +------------------------
			|
			| +------------------------
			| | Ethernet Port 2
			| | -----------------
			| | Physical MAC Address
			| | IPv6 Link-Local address(es)
			| | Leaf MAC Address
			| | Leaf IP addresses
			| +------------------------
			|
			| ....
			|
			+---------------
			Figure 3: Logical P2MP Interface
			To conserve the same model, it makes sense to configure the same
			(virtual) MAC address on all the physical interfaces, and use it for
			the purpose of IPv6 ND. In that case, the same MAC address is
			exposed as Link-layer Address (LLA) to both leaves for the NIC IP
			addresses, and the IPv6 address still appears as unicast. Note that
			the Link-Local addresses used to register the global IPv6 addresses
			to the leaf may be different but that does not affect the exposed
			mapping.
			When that is not possible, then the same IP address is advertised
			with the physical MAC address of each port as the LLA over that port.
			In that case, the global IPv6 address appears as anycast, and SHOULD
			be advertised as such, more in Section 3.3.5.
			3.2. RFC 6775 Address Registration
	The classical "IPv6 Neighbor Discovery (IPv6 ND) Protocol" [RFC4861]		The classical "IPv6 Neighbor Discovery (IPv6 ND) Protocol" [RFC4861]
	[RFC4862] was defined for serial links and transit media such as		[RFC4862] was defined for serial links and transit media such as
	Ethernet. It is a reactive protocol that relies heavily on multicast		Ethernet. It is a reactive protocol that relies heavily on multicast
	operations for Address Discovery (aka Lookup) and Duplicate Address		operations for Address Discovery (aka Lookup) and Duplicate Address
	Detection (DAD).		Detection (DAD).
	"Neighbor Discovery Optimizations for 6LoWPAN networks" [RFC6775]		"Neighbor Discovery Optimizations for 6LoWPAN networks" [RFC6775]
	adapts IPv6 ND for operations over energy-constrained LLNs. The main		adapts IPv6 ND for operations over energy-constrained LLNs. The main
	functions of [RFC6775] are to proactively establish the Neighbor		functions of [RFC6775] are to proactively establish the Neighbor
	skipping to change at page 7, line 23 ¶		skipping to change at page 10, line 36 ¶
	[RFC6775] defines a new Address Registration Option (ARO) that is		[RFC6775] defines a new Address Registration Option (ARO) that is
	carried in the unicast Neighbor Solicitation (NS) and Neighbor		carried in the unicast Neighbor Solicitation (NS) and Neighbor
	Advertisement (NA) messages between the 6LoWPAN Node (6LN) and the		Advertisement (NA) messages between the 6LoWPAN Node (6LN) and the
	6LoWPAN router (6LR). It also defines the Duplicate Address Request		6LoWPAN router (6LR). It also defines the Duplicate Address Request
	(DAR) and Duplicate Address Confirmation (DAC) messages between the		(DAR) and Duplicate Address Confirmation (DAC) messages between the
	6LR and the 6LBR. In a Low-Power and Lossy Network (LLN), the 6LBR		6LR and the 6LBR. In a Low-Power and Lossy Network (LLN), the 6LBR
	is the central repository of all the Registered Addresses in its		is the central repository of all the Registered Addresses in its
	domain and the authoritative source of truth for uniqueness and		domain and the authoritative source of truth for uniqueness and
	ownership.		ownership.
	3.2. RFC 8505 Extended Address Registration		3.3. RFC 8505 Extended Address Registration
	"Registration Extensions for 6LoWPAN Neighbor Discovery" [RFC8505]		"Registration Extensions for 6LoWPAN Neighbor Discovery" [RFC8505]
	updates RFC 6775 into a generic Address Registration mechanism that		updates RFC 6775 into a generic Address Registration mechanism that
	can be used to access services such as routing and ND proxy. To that		can be used to access services such as routing and ND proxy. To that
	effect, [RFC8505] defines the Extended Address Registration Option		effect, [RFC8505] defines the Extended Address Registration Option
	(EARO), shown in Figure 1:		(EARO), shown in Figure 4:
	0 1 2 3		0 1 2 3
	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 | Length | Status | Opaque |		| Type | Length | Status | Opaque |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Rsvd | I |R|T| TID | Registration Lifetime |		| Rsvd | I |R|T| TID | Registration Lifetime |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	... Registration Ownership Verifier ...		... Registration Ownership Verifier ...
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: EARO Option Format		Figure 4: EARO Option Format
	3.2.1. R Flag		3.3.1. R Flag
	[RFC8505] introduces the R Flag in the EARO. The Registering Node		[RFC8505] introduces the R Flag in the EARO. The Registering Node
	sets the R Flag to indicate whether the 6LR should ensure		sets the R Flag to indicate whether the 6LR should ensure
	reachability for the Registered Address. If the R Flag is set to 0,		reachability for the Registered Address. If the R Flag is set to 0,
	then the Registering Node handles the reachability of the Registered		then the Registering Node handles the reachability of the Registered
	Address by other means. In an EVPN network, this means that either		Address by other means. In an EVPN network, this means that either
	it is a RAN that injects the route by itself or that it uses another		it is a RAN that injects the route by itself or that it uses another
	EVPN router for reachability services.		EVPN router for reachability services.
	This document specifies how the R Flag is used in the context of		This document specifies how the R Flag is used in the context of
	skipping to change at page 8, line 27 ¶		skipping to change at page 11, line 41 ¶
	[RFC8505] requires reachability services for an IPv6 address if and		[RFC8505] requires reachability services for an IPv6 address if and
	only if it sets the R Flag in the NS(EARO) used to register the		only if it sets the R Flag in the NS(EARO) used to register the
	address to a 6LR acting as an EVPN border router. Upon receiving the		address to a 6LR acting as an EVPN border router. Upon receiving the
	NS(EARO), the EVPN router generates a BGP advertisement for the		NS(EARO), the EVPN router generates a BGP advertisement for the
	Registered Address if and only if the R flag is set to 1.		Registered Address if and only if the R flag is set to 1.
	[RFC9010] specifies that the 'R' flags is set in the responded NA		[RFC9010] specifies that the 'R' flags is set in the responded NA
	messages if and only if the route was installed. This specification		messages if and only if the route was installed. This specification
	echoes that behavior.		echoes that behavior.
	3.2.2. TID, "I" Field and Opaque Fields		3.3.2. TID, "I" Field and Opaque Fields
	When the T Flag is set to 1, the EARO includes a sequence counter		When the T Flag is set to 1, the EARO includes a sequence counter
	called Transaction ID (TID), that is needed to format the MAC		called Transaction ID (TID), that is needed to format the MAC
	Mobility Extended Community. This is the reason why the support of		Mobility Extended Community. This is the reason why the support of
	[RFC8505] by the Host, as opposed to only [RFC6775], is a		[RFC8505] by the Host, as opposed to only [RFC6775], is a
	prerequisite for this specification); this requirement is fully		prerequisite for this specification); this requirement is fully
	explained in Section 5.1. The EARO also transports an Opaque field		explained in Section 5.1. The EARO also transports an Opaque field
	and an associated "I" field that describes what the Opaque field		and an associated "I" field that describes what the Opaque field
	transports and how to use it.		transports and how to use it.
	This document specifies the use of the "I" field and the Opaque field		This document specifies the use of the "I" field and the Opaque field
	by a Host.		by a Host.
	3.2.3. Status		3.3.3. Status
	The values of the EARO status are maintained by IANA in the Address		The values of the EARO status are maintained by IANA in the Address
	Registration Option Status Values subregistry [IANA-EARO-STATUS] of		Registration Option Status Values subregistry [IANA-EARO-STATUS] of
	the Internet Control Message Protocol version 6 (ICMPv6) Parameters		the Internet Control Message Protocol version 6 (ICMPv6) Parameters
	registry.		registry.
	[RFC6775] and [RFC8505] defined the original values whereas [RFC9010]		[RFC6775] and [RFC8505] defined the original values whereas [RFC9010]
	reduced range to 64 values and reformatted the octet field to enable		reduced range to 64 values and reformatted the octet field to enable
	to transport an external error, e.g., coming form a routing protocol.		to transport an external error, e.g., coming form a routing protocol.
	This specification uses the format expressed in [RFC9010]. The value		This specification uses the format expressed in [RFC9010]. The value
	of 0 denotes an unqualified success, 1 indicates an address		of 0 denotes an unqualified success, 1 indicates an address
	duplication, 3 a TID value that is outdated, and 4 is used in an		duplication, 3 a TID value that is outdated, and 4 is used in an
	asynchronous NA to indicate that 6LN should remove that address and		asynchronous NA to indicate that 6LN should remove that address and
	possibly form new ones.		possibly form new ones.
	3.2.4. Route Ownership Verifier		3.3.4. Route Ownership Verifier
	Section 5.3 of [RFC8505] introduces the Registration Ownership		Section 5.3 of [RFC8505] introduces the Registration Ownership
	Verifier (ROVR) field of variable length from 64 to 256 bits. The		Verifier (ROVR) field of variable length from 64 to 256 bits. The
	ROVR is a replacement of the EUI-64 in the ARO [RFC6775] that was		ROVR is a replacement of the EUI-64 in the ARO [RFC6775] that was
	used to identify uniquely an Address Registration with the Link-Layer		used to identify uniquely an Address Registration with the Link-Layer
	address of the owner but provided no protection against spoofing.		address of the owner but provided no protection against spoofing.
	"Address Protected Neighbor Discovery for Low-power and Lossy		"Address Protected Neighbor Discovery for Low-power and Lossy
	Networks" [RFC8928] leverages the ROVR field as a cryptographic proof		Networks" [RFC8928] leverages the ROVR field as a cryptographic proof
	of ownership to prevent a rogue third party from registering an		of ownership to prevent a rogue third party from registering an
	skipping to change at page 9, line 33 ¶		skipping to change at page 13, line 5 ¶
	to block traffic that is not sourced at an owned address.		to block traffic that is not sourced at an owned address.
	This specification does not address how the protection by [RFC8928]		This specification does not address how the protection by [RFC8928]
	could be extended for use in EVPN. On the other hand, it adds the		could be extended for use in EVPN. On the other hand, it adds the
	ROVR to the BGP advertisement to share the state with the other		ROVR to the BGP advertisement to share the state with the other
	routers via the Reflector (see Section 6.2), which means that the		routers via the Reflector (see Section 6.2), which means that the
	routers that are aware of the Host route are also aware of the ROVR		routers that are aware of the Host route are also aware of the ROVR
	associated to the Target Address, whether it is cryptographic and		associated to the Target Address, whether it is cryptographic and
	should be verified.		should be verified.
	3.2.5. Anycast and Multicast Addresses		3.3.5. Anycast and Multicast Addresses
	"IPv6 Neighbor Discovery Multicast Address Registration"		"IPv6 Neighbor Discovery Multicast Address Registration"
	[I-D.thubert-6lo-multicast-registration] updates [RFC8505] to enable		[I-D.thubert-6lo-multicast-registration] updates [RFC8505] to enable
	the address registration of IPv6 anycast and multicast addresses.		the address registration of IPv6 anycast and multicast addresses.
	From the host perspective, the registration is very similar to that		From the host perspective, the registration is very similar to that
	of unicast addresses, but for a flag in the EARO that signals that		of unicast addresses, but for a flag in the EARO that signals that
	the address is multicast or anycast.		the address is multicast or anycast.
	This procedure can be used as a replacement to "Multicast Listener		This procedure can be used as a replacement to "Multicast Listener
	Discovery Version 2 (MLDv2) for IPv6" [RFC3810] for source-		Discovery Version 2 (MLDv2) for IPv6" [RFC3810] for source-
	independant multicast operation. As for unicast, the method saves		independant multicast operation. As for unicast, the method saves
	the need for the host to listen to pollings from the router, and		the need for the host to listen to pollings from the router, and
	allows the host to sleep for periods of time.		allows the host to sleep for periods of time.
	3.3. RFC 8505 Extended DAR/DAC		3.4. RFC 8505 Extended DAR/DAC
	[RFC8505] updates the DAR/DAC messages to EDAR/EDAC messages to carry		[RFC8505] updates the DAR/DAC messages to EDAR/EDAC messages to carry
	the ROVR field. The EDAR/EDAC exchange takes place between the 6LR		the ROVR field. The EDAR/EDAC exchange takes place between the 6LR
	to which the node registers an address, and the abstract 6LBR that		to which the node registers an address, and the abstract 6LBR that
	stores the reference value for the ROVR and the TID associated to		stores the reference value for the ROVR and the TID associated to
	that address. It is triggered by an NS(EARO) message from a 6LN to		that address. It is triggered by an NS(EARO) message from a 6LN to
	the 6LR, to create, refresh, compare and delete the corresponding		the 6LR, to create, refresh, compare and delete the corresponding
	state in the 6LBR.		state in the 6LBR.
	In the status returned with the EDAC message, the 6LBR indicates if		In the status returned with the EDAC message, the 6LBR indicates if
	skipping to change at page 10, line 38 ¶		skipping to change at page 14, line 22 ¶
	| | EDAR |		| | EDAR |
	| |------------------>|		| |------------------>|
	| | |		| | |
	| | EDAC(status) |		| | EDAC(status) |
	| |<------------------|		| |<------------------|
	| | |		| | |
	| NA(EARO) | |		| NA(EARO) | |
	|<----------------| |		|<----------------| |
	| | |		| | |
	Figure 2: EDAR/EDAC flow		Figure 5: EDAR/EDAC flow
	The EDAR/EDAC exchange is protected by the retry mechanism specified		The EDAR/EDAC exchange is protected by the retry mechanism specified
	in Section 8.2.6 of [RFC6775], though in a data center, a duration		in Section 8.2.6 of [RFC6775], though in a data center, a duration
	significantly shorter than the default value of the Retransmission		significantly shorter than the default value of the Retransmission
	Timer [RFC4861] of 1 second may be sufficient to cover the round-trip		Timer [RFC4861] of 1 second may be sufficient to cover the round-trip
	delay between the 6R and the 6LBR.		delay between the 6R and the 6LBR.
	With this specification, the 6LBR is distributed across the leaves,		With this specification, the 6LBR is distributed across the leaves,
	and all the leaves where an address is currently registered maintain		and all the leaves where an address is currently registered maintain
	a full 6LBR state for the address, aka local state in the following		a full 6LBR state for the address, aka local state in the following
	text. The specification leverages the EDAR/EDAC exchange to ensure		text. The specification leverages the EDAR/EDAC exchange to ensure
	that a leaf (acting as a 6LR) that needs to create a 6LBR state for a		that a leaf (acting as a 6LR) that needs to create a 6LBR state for a
	new registration has the same value for the ROVR as any 6LBR already		new registration has the same value for the ROVR as any 6LBR already
	serving that address on another leaf. At the same time, the		serving that address on another leaf. At the same time, the
	specification avoids placing full ROVR information in BGP so 1) it is		specification avoids placing full ROVR information in BGP so 1) it is
	not observable by a potential attacker and 2) the new attributes		not observable by a potential attacker and 2) the new attributes
	remain reasonably small.		remain reasonably small.
	3.4. RFC 7400 Capability Indication Option		3.5. RFC 7400 Capability Indication Option
	"6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power		"6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power
	Wireless Personal Area Networks (6LoWPANs)" [RFC7400] defines the		Wireless Personal Area Networks (6LoWPANs)" [RFC7400] defines the
	6LoWPAN Capability Indication Option (6CIO) that enables a node to		6LoWPAN Capability Indication Option (6CIO) that enables a node to
	expose its capabilities in router Advertisement (RA) messages.		expose its capabilities in router Advertisement (RA) messages.
	[RFC8505] defines a number of bits in the 6CIO, in particular:		[RFC8505] defines a number of bits in the 6CIO, in particular:
	L: Node is a 6LR.		L: Node is a 6LR.
	E: Node is an IPv6 ND Registrar -- i.e., it supports registrations		E: Node is an IPv6 ND Registrar -- i.e., it supports registrations
	skipping to change at page 11, line 33 ¶		skipping to change at page 15, line 16 ¶
	also provides reachability services for the Registered Address.		also provides reachability services for the Registered Address.
	0 1 2 3		0 1 2 3
	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 | Length = 1 | Reserved |D|L|B|P|E|G|		| Type | Length = 1 | Reserved |D|L|B|P|E|G|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved |		| Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3: 6CIO flags		Figure 6: 6CIO flags
	A 6LR that provides reachability services for a Host in an EVPN		A 6LR that provides reachability services for a Host in an EVPN
	network as specified in this document includes a 6CIO in its RA		network as specified in this document includes a 6CIO in its RA
	messages and set the L, P and E flags to 1 as prescribed by		messages and set the L, P and E flags to 1 as prescribed by
	[RFC8505].		[RFC8505].
	4. Extending 6LoWPAN ND		4. Extending 6LoWPAN ND
	4.1. Use of the R flag in NA		4.1. Use of the R flag in NA
	skipping to change at page 12, line 16 ¶		skipping to change at page 15, line 47 ¶
	This specification enables to distribute the 6LBR at the edge of the		This specification enables to distribute the 6LBR at the edge of the
	EVPN network and collapse the 6LBR function with that of the EVPN		EVPN network and collapse the 6LBR function with that of the EVPN
	support. In that model, the EVPN to 6LBR interaction becomes an		support. In that model, the EVPN to 6LBR interaction becomes an
	internal interface, where each side informs the other in case of new		internal interface, where each side informs the other in case of new
	information concerning an IP to Link-Layer Address (LLA) mapping.		information concerning an IP to Link-Layer Address (LLA) mapping.
	Since this is an internal interface, this specification makes no		Since this is an internal interface, this specification makes no
	assumption on whether the 6LBR stores its own representation of the		assumption on whether the 6LBR stores its own representation of the
	full EVPN state, which means that the EVPN support informs the 6LBR		full EVPN state, which means that the EVPN support informs the 6LBR
	in case of any change on the EVPN side (this is called the push		in case of any change on the EVPN side (this is called the push
	model, see Figure 10), or if the 6LBR queries the EVPN support when		model, see Figure 13), or if the 6LBR queries the EVPN support when
	it does not have a mapping to satisfy a request (pull model, see		it does not have a mapping to satisfy a request (pull model, see
	Figure 9).		Figure 12).
	This specification leverages [RFC8929] that augments the abstract		This specification leverages [RFC8929] that augments the abstract
	data model of the 6LBR to store the LLA associated with the		data model of the 6LBR to store the LLA associated with the
	registered address. Based on that additional state, the 6LBR in a		registered address. Based on that additional state, the 6LBR in a
	leaf can communicate the mapping to the collocated EVPN function and		leaf can communicate the mapping to the collocated EVPN function and
	respond to unicast address mapping lookups from the server side.		respond to unicast address mapping lookups from the server side.
	In an environment where the server ranges from a classical host to a		In an environment where the server ranges from a classical host to a
	more complex platform that runs a collection of virtual hosts		more complex platform that runs a collection of virtual hosts
	interconnected by a virtual switch, but where the host-to-leaf		interconnected by a virtual switch, but where the host-to-leaf
	interface remains at layer 2, the 6LR and the 6LBR functions can be		interface remains at layer 2, the 6LR and the 6LBR functions can be
	collapsed in the leaf. The 6LR to 6LBR interaction also becomes an		collapsed in the leaf. The 6LR to 6LBR interaction also becomes an
	internal interface, and there is no need for EDAR/EDAC messages.		internal interface, and there is no need for EDAR/EDAC messages.
	In that case, the MAC address associated to the Registered Address is		In that case, the MAC address associated to the Registered Address is
	indicated in the Target Link-Layer Address Option (TLLAO) in the NS		indicated in the Target Link-Layer Address Option (TLLAO) in the NS
	message used for the registration, as shown in Figure 4. In the case		message used for the registration, as shown in Figure 7. In the case
	of a pull model, if the 6LBR does not have a local state for the		of a pull model, if the 6LBR does not have a local state for the
	mapping, it queries the EVPN support to obtain the EVPN state if any.		mapping, it queries the EVPN support to obtain the EVPN state if any.
	If a mapping is known then the 6LR/6LBR evaluates the registration		If a mapping is known then the 6LR/6LBR evaluates the registration
	for address duplication and other possible issues per [RFC8505].		for address duplication and other possible issues per [RFC8505].
	Else (this is for a new mapping), if the registration is accepted,		Else (this is for a new mapping), if the registration is accepted,
	then the 6LBR notifies the EVPN support to inject a route type 2 in		then the 6LBR notifies the EVPN support to inject a route type 2 in
	the fabric.		the fabric.
	Server Leaf		Server Leaf
	+--------------+ +-------------------+		+--------------+ +-------------------+
	skipping to change at page 13, line 32 ¶		skipping to change at page 17, line 32 ¶
	| |new mapping |		| |new mapping |
	| | indication |		| | indication |
	| |----------->|		| |----------->|
	| | Inject/maintain		| | Inject/maintain
	| store a mapping state | EVPN route type 2		| store a mapping state | EVPN route type 2
	| | ------------------>		| | ------------------>
	| NA(EARO) | | [via BGP signaling]		| NA(EARO) | | [via BGP signaling]
	|<-------------------| |		|<-------------------| |
	| | |		| | |
	Figure 4: Direct Registration		Figure 7: Direct Registration
	In another type of deployment, the 6LR may be a virtual router in the		In another type of deployment, the 6LR may be a virtual router in the
	server whereas the 6LBR runs in the leaf node. To address that case,		server whereas the 6LBR runs in the leaf node. To address that case,
	the EDAR/EDAC may be used to communicate as shown in figure 5 of		the EDAR/EDAC may be used to communicate as shown in figure 5 of
	[RFC8505]. This draft leverages the capability to insert IPv6 ND		[RFC8505]. This draft leverages the capability to insert IPv6 ND
	options in the EDAR and EDAC messages introduced in [RFC8929] to		options in the EDAR and EDAC messages introduced in [RFC8929] to
	place a TLLAO that carries the MAC address associated to the		place a TLLAO that carries the MAC address associated to the
	Registered address in the EDAR and EDAC messages as shown in		Registered address in the EDAR and EDAC messages as shown in
	Figure 5:		Figure 8:
	Server Leaf		Server Leaf
	+----------------+ +----------------+		+----------------+ +----------------+
	| | | |		| | | |
	6LN 6LR 6LBR EVPN		6LN 6LR 6LBR EVPN
	| | | |		| | | |
	| <vSwitch> | Ethernet | <call I/F> |		| <vSwitch> | Ethernet | <call I/F> |
	| | | |		| | | |
	| NS(EARO) | | |		| NS(EARO) | | |
	|----------->| | |		|----------->| | |
	skipping to change at page 14, line 36 ¶		skipping to change at page 18, line 36 ¶
	| | |----------->|		| | |----------->|
	| | | Inject/maintain		| | | Inject/maintain
	| | store a mapping state | EVPN route type 2		| | store a mapping state | EVPN route type 2
	| | | ------------------>		| | | ------------------>
	| | EDAC(TLLAO) | | [via BGP signaling]		| | EDAC(TLLAO) | | [via BGP signaling]
	| |<-------------| |		| |<-------------| |
	| NA(EARO) | | |		| NA(EARO) | | |
	|<-----------| | |		|<-----------| | |
	| | | |		| | | |
	Figure 5: leveraging EDAR		Figure 8: leveraging EDAR
	[RFC8505] updates the DAR/DAC messages into the Extended DAR/DAC to		[RFC8505] updates the DAR/DAC messages into the Extended DAR/DAC to
	carry the ROVR field. With this specification, the abstract 6LBR is		carry the ROVR field. With this specification, the abstract 6LBR is
	distributed in all the Leaf nodes and synchronized with EVPN. When a		distributed in all the Leaf nodes and synchronized with EVPN. When a
	server successfully registers an address to a leaf, the 6LR on that		server successfully registers an address to a leaf, the 6LR on that
	leaf becomes 6LBR for that address. It stores the full state for		leaf becomes 6LBR for that address. It stores the full state for
	that address including the ROVR and the TID. When the address		that address including the ROVR and the TID. When the address
	registration moves to another leaf, an EDAR/EDAC flow between the 6LR		registration moves to another leaf, an EDAR/EDAC flow between the 6LR
	in the new leaf and the 6LBR in the old leaf confirms that the ROVR		in the new leaf and the 6LBR in the old leaf confirms that the ROVR
	in the NS(EARO) received at the new leaf is correct, in which case		in the NS(EARO) received at the new leaf is correct, in which case
	skipping to change at page 15, line 23 ¶		skipping to change at page 19, line 23 ¶
	A classical IPv6 ND stack in the server that treats the subnet prefix		A classical IPv6 ND stack in the server that treats the subnet prefix
	as on-link (more in section 4.6.2. of [RFC4861]), will resolve an		as on-link (more in section 4.6.2. of [RFC4861]), will resolve an
	unknown LLA mapping with a multicast NS(lookup) message addressed to		unknown LLA mapping with a multicast NS(lookup) message addressed to
	the solicited node multicast address (SNMA) associated with the		the solicited node multicast address (SNMA) associated with the
	destination address being resolved. The RECOMMENDED operation in		destination address being resolved. The RECOMMENDED operation in
	that case is for the 6LBR that has a mapping state to forward the		that case is for the 6LBR that has a mapping state to forward the
	packet as a unicast MAC to the LLA that is stored for the IPv6		packet as a unicast MAC to the LLA that is stored for the IPv6
	address as expected by [RFC6085]. The actual owner of the address		address as expected by [RFC6085]. The actual owner of the address
	can then answer unicast with a NA message, setting the override (O)		can then answer unicast with a NA message, setting the override (O)
	bit to 1, as shown in Figure 6.		bit to 1, as shown in Figure 9.
	Local Local Remote		Local Local Remote
	Server Leaf Server		Server Leaf Server
	+----+ +--------+ +----+		+----+ +--------+ +----+
	| | | | | |		| | | | | |
	6LN 6LR/6LBR 6LN		6LN 6LR/6LBR 6LN
	| | |		| | |
	| Ethernet | |		| Ethernet | |
	| | [via EVPN ] |		| | [via EVPN ] |
	| multicast | [Data Tunnels] |		| multicast | [Data Tunnels] |
	skipping to change at page 15, line 46 ¶		skipping to change at page 19, line 46 ¶
	| | forward unicast |		| | forward unicast |
	| | NS(lookup) |		| | NS(lookup) |
	| |---------------------->|		| |---------------------->|
	| | |		| | |
	| | NA(O) |		| | NA(O) |
	| |<----------------------|		| |<----------------------|
	| NA(O) | |		| NA(O) | |
	|<----------------| |		|<----------------| |
	| | |		| | |
	Figure 6: Forwarding legacy NS (Lookup)		Figure 9: Forwarding legacy NS (Lookup)
	Section 3.1. of [RFC8929] adds the capability to insert IPv6 ND		Section 3.1. of [RFC8929] adds the capability to insert IPv6 ND
	options in the EDAR and EDAC messages. This enables the 6LBR to		options in the EDAR and EDAC messages. This enables the 6LBR to
	store the link-layer address associated with the Registered Address		store the link-layer address associated with the Registered Address
	and to serve as a mapping server. [UNICAST-LOOKUP] leverages that		and to serve as a mapping server. [UNICAST-LOOKUP] leverages that
	state to define a new unicast address lookup operation, extending the		state to define a new unicast address lookup operation, extending the
	EDAR and EDAC messages as the Address Mapping Request (AMR) and		EDAR and EDAC messages as the Address Mapping Request (AMR) and
	Confirmation (AMC) with a different Code Prefix [RFC8505].		Confirmation (AMC) with a different Code Prefix [RFC8505].
	In that model, the router advertises the subnet prefix as not on-link		In that model, the router advertises the subnet prefix as not on-link
	skipping to change at page 16, line 27 ¶		skipping to change at page 20, line 27 ¶
	from resolving the address mapping and passes the packets directly to		from resolving the address mapping and passes the packets directly to
	the router.		the router.
	In the case where the router is a virtual 6LR running in the server,		In the case where the router is a virtual 6LR running in the server,
	and the source and destination are in the same subnet served by EVPN,		and the source and destination are in the same subnet served by EVPN,
	the router then resolves the address mapping on behalf of the host.		the router then resolves the address mapping on behalf of the host.
	To that effect, the router sends a unicast AMR message to the 6LBR.		To that effect, the router sends a unicast AMR message to the 6LBR.
	The message contains the SLLAO of the router to which the 6LBR will		The message contains the SLLAO of the router to which the 6LBR will
	reply. If the binding is found, the 6LBR replies with an AMC message		reply. If the binding is found, the 6LBR replies with an AMC message
	that contains the TLLOA with the requested MAC address, as shown in		that contains the TLLOA with the requested MAC address, as shown in
	Figure 7.		Figure 10.
	Local Local Remote		Local Local Remote
	Server Leaf Server		Server Leaf Server
	+----------------+ +---------+ +----+		+----------------+ +---------+ +----+
	| | | | | |		| | | | | |
	6LN 6LR 6LBR/EVPN 6LN		6LN 6LR 6LBR/EVPN 6LN
	| | | |		| | | |
	| | | [via EVPN ] |		| | | [via EVPN ] |
	| <vSwitch> | Ethernet | [Data Tunnels] |		| <vSwitch> | Ethernet | [Data Tunnels] |
	| | | |		| | | |
	skipping to change at page 17, line 36 ¶		skipping to change at page 21, line 36 ¶
	| |<-------------| |		| |<-------------| |
	| | | |		| | | |
	| NCE in STALE state | |		| NCE in STALE state | |
	| | |		| | |
	| | Packet |		| | Packet |
	| |------------------------------->|		| |------------------------------->|
	| | |		| | |
	| NCE in DELAY state | |		| NCE in DELAY state | |
	| | | |		| | | |
	Figure 7: Unicast Lookup from the virtual Host		Figure 10: Unicast Lookup from the virtual Host
	If it is not found, [UNICAST-LOOKUP] provides the capability to		If it is not found, [UNICAST-LOOKUP] provides the capability to
	indicate immediately that the mapping is not known with a "not found"		indicate immediately that the mapping is not known with a "not found"
	status in the AMC, as opposed to waiting for an NS(lookup) and		status in the AMC, as opposed to waiting for an NS(lookup) and
	retries to time out per [RFC4861].		retries to time out per [RFC4861].
	In a fully stateful subnet where all nodes register all their		In a fully stateful subnet where all nodes register all their
	addresses with [RFC8505], this means that the looked up address is		addresses with [RFC8505], this means that the looked up address is
	not present in the network; in that case the packet is dropped and an		not present in the network; in that case the packet is dropped and an
	ICMP error type 1 "Destination Unreachable" code 3 "Address		ICMP error type 1 "Destination Unreachable" code 3 "Address
	unreachable" [RFC4443] is returned as shown in Figure 8.		unreachable" [RFC4443] is returned as shown in Figure 11.
	Local Local		Local Local
	Server Leaf		Server Leaf
	+----------------+ +---------+		+----------------+ +---------+
	| | | |		| | | |
	6LN 6LR 6LBR/EVPN		6LN 6LR 6LBR/EVPN
	| | |		| | |
	| | |		| | |
	| <vSwitch> | Ethernet |		| <vSwitch> | Ethernet |
	| | |		| | |
	skipping to change at page 18, line 35 ¶		skipping to change at page 22, line 35 ¶
	| | AMC(status= |		| | AMC(status= |
	| | "Not Found") |		| | "Not Found") |
	| |<-------------|		| |<-------------|
	|ICMPv6 Error| |		|ICMPv6 Error| |
	| "Address | |		| "Address | |
	|Unreachable"| |		|Unreachable"| |
	|<-----------| |		|<-----------| |
	| Drop Packet |		| Drop Packet |
	| | |		| | |
	Figure 8: Unicast Lookup failure		Figure 11: Unicast Lookup failure
	Note that the figures above make no assumption on the pull vs. push		Note that the figures above make no assumption on the pull vs. push
	model. In the case of pull model, the 6LBR queries the EVPN support		model. In the case of pull model, the 6LBR queries the EVPN support
	when it does not have the mapping information to satisfy a request.		when it does not have the mapping information to satisfy a request.
	Figure 9 illustrates a successful pull model lookup flow, when the		Figure 12 illustrates a successful pull model lookup flow, when the
	route type 2 for the mapping is already known on the EVPN side.		route type 2 for the mapping is already known on the EVPN side.
	Server Leaf		Server Leaf
	+----------------+ +----------------+		+----------------+ +----------------+
	| | | |		| | | |
	6LN 6LR 6LBR EVPN		6LN 6LR 6LBR EVPN
	| | | |		| | | |
	| <vSwitch> | Ethernet | <call I/F> |		| <vSwitch> | Ethernet | <call I/F> |
	| | | |		| | | |
	| | | |		| | | |
	skipping to change at page 19, line 39 ¶		skipping to change at page 23, line 39 ¶
	| | | |		| | | |
	| |AMC(A''s TLLA)| |		| |AMC(A''s TLLA)| |
	| |<-------------| |		| |<-------------| |
	| | | |		| | | |
	| | Packet for A' |		| | Packet for A' |
	| | [via EVPN ] |		| | [via EVPN ] |
	| | [Data Tunnels] |		| | [Data Tunnels] |
	| |----------------------------------->		| |----------------------------------->
	| | | |		| | | |
	Figure 9: Pull model		Figure 12: Pull model
	In the case of push model, the EVPN support synchronizes its state		In the case of push model, the EVPN support synchronizes its state
	upon a route type 2 with the 6LBR, and the 6LBR maintains an abstract		upon a route type 2 with the 6LBR, and the 6LBR maintains an abstract
	data structure for all information known to EVPN. This way, the 6LBR		data structure for all information known to EVPN. This way, the 6LBR
	already has the mapping information to satisfy any request for an		already has the mapping information to satisfy any request for an
	existing mapping and it can answer right away. Figure 10 illustrates		existing mapping and it can answer right away. Figure 13 illustrates
	a successful push model lookup flow, when the 6LBR is already in		a successful push model lookup flow, when the 6LBR is already in
	possession of the mapping.		possession of the mapping.
	Server Leaf		Server Leaf
	+----------------+ +----------------+		+----------------+ +----------------+
	| | | |		| | | |
	6LN 6LR 6LBR EVPN		6LN 6LR 6LBR EVPN
	| | | |		| | | |
	| <vSwitch> | Ethernet | <call I/F> |		| <vSwitch> | Ethernet | <call I/F> |
	| | | |		| | | |
	skipping to change at page 20, line 39 ¶		skipping to change at page 24, line 39 ¶
	| | | |		| | | |
	| |AMC(A's TLLA) | |		| |AMC(A's TLLA) | |
	| |<-------------| |		| |<-------------| |
	| | | |		| | | |
	| | Packet to A' |		| | Packet to A' |
	| | [via EVPN ] |		| | [via EVPN ] |
	| | [Data Tunnels] |		| | [Data Tunnels] |
	| |----------------------------------->		| |----------------------------------->
	| | | |		| | | |
	Figure 10: Push model		Figure 13: Push model
	In a mixed environment, a lookup failure (the mapping is not found		In a mixed environment, a lookup failure (the mapping is not found
	though the address is present in the network) may be caused by a		though the address is present in the network) may be caused by a
	legacy node that was node discovered (aka a silent node). In that		legacy node that was node discovered (aka a silent node). In that
	case, it is an administrative decision for the 6LR to broadcast an		case, it is an administrative decision for the 6LR to broadcast an
	NS(lookup) or to return an error as shown in Figure 8.		NS(lookup) or to return an error as shown in Figure 11.
	5. Requirements on the EVPN-Unaware Host		5. Requirements on the EVPN-Unaware Host
	This document describes how EVPN routing can be extended to reach a		This document describes how EVPN routing can be extended to reach a
	Host. This section specifies the minimal EVPN-independent		Host. This section specifies the minimal EVPN-independent
	functionality that the Host needs to implement to obtain routing		functionality that the Host needs to implement to obtain routing
	services for its addresses.		services for its addresses.
	5.1. Support of 6LoWPAN ND		5.1. Support of 6LoWPAN ND
	skipping to change at page 21, line 25 ¶		skipping to change at page 25, line 25 ¶
	a PIO in a RA with the L flag not set) should not attempt to resolve		a PIO in a RA with the L flag not set) should not attempt to resolve
	an address within that prefix using a multicast NS(lookup). Instead,		an address within that prefix using a multicast NS(lookup). Instead,
	it must pass its packets to a router, preferably one that advertises		it must pass its packets to a router, preferably one that advertises
	that prefix in a PIO; it must register the address that it uses as		that prefix in a PIO; it must register the address that it uses as
	source to that router to enable source address validation using		source to that router to enable source address validation using
	[RFC8505]. It is recommended that the Host also implements [RFC8928]		[RFC8505]. It is recommended that the Host also implements [RFC8928]
	to prove its ownership of its addresses.		to prove its ownership of its addresses.
	The Host is expected to request routing services from a router only		The Host is expected to request routing services from a router only
	if that router originates RA messages with a 6CIO that has the L, P,		if that router originates RA messages with a 6CIO that has the L, P,
	and E flags all set to 1 as discussed in Section 3.4, unless		and E flags all set to 1 as discussed in Section 3.5, unless
	configured to do so. To obtain routing services for one of its		configured to do so. To obtain routing services for one of its
	addresses, the host must register the address to a router that		addresses, the host must register the address to a router that
	advertises the prefix, setting the "R" and "T" flags in the EARO to 1		advertises the prefix, setting the "R" and "T" flags in the EARO to 1
	as discussed in Section 3.2.1 and Section 3.2.2, respectively.		as discussed in Section 3.3.1 and Section 3.3.2, respectively.
	This document echoes the behavior specified in [RFC9010] whereby,		This document echoes the behavior specified in [RFC9010] whereby,
	when the R Flag set to 1 in a NS(EARO) is not echoed in the NA(EARO),		when the R Flag set to 1 in a NS(EARO) is not echoed in the NA(EARO),
	the host must understand that the route injection failed, and if the		the host must understand that the route injection failed, and if the
	R flag is reset later in an asynchronous NA(EARO), the host must		R flag is reset later in an asynchronous NA(EARO), the host must
	understand that routing service has failed.		understand that routing service has failed.
	The host may attach to multiple 6LRs and is expected to prefer those		The host may attach to multiple 6LRs and is expected to prefer those
	that provide routing services. The abstract model for this is a P2MP		that provide routing services. The abstract model for this is a P2MP
	interface that wraps together as many P2P IP Links the host has		interface that wraps together as many P2P IP Links the host has
	skipping to change at page 22, line 7 ¶		skipping to change at page 26, line 7 ¶
	associated to sub-interface of the interface.		associated to sub-interface of the interface.
	The Host needs to register to all the 6LRs from which it desires		The Host needs to register to all the 6LRs from which it desires
	routing services. The multiple Address Registrations to several 6LRs		routing services. The multiple Address Registrations to several 6LRs
	should be performed in a rapid sequence, using the same EARO for the		should be performed in a rapid sequence, using the same EARO for the
	same Address. Gaps between the Address Registrations will invalidate		same Address. Gaps between the Address Registrations will invalidate
	some of the routes till the Address Registration finally shows on		some of the routes till the Address Registration finally shows on
	those routes. The routers recognize the same (ROVR, TID) as the		those routes. The routers recognize the same (ROVR, TID) as the
	signal of a multihomed address and maintain all the routes. In the		signal of a multihomed address and maintain all the routes. In the
	case of EVPN, the Ethernet Segment must also be the same. The flow		case of EVPN, the Ethernet Segment must also be the same. The flow
	for a successful multihomed registration is illustrated in Figure 14.		for a successful multihomed registration is illustrated in Figure 17.
	[RFC8505] introduces error Status values in the NA(EARO) which can be		[RFC8505] introduces error Status values in the NA(EARO) which can be
	received synchronously upon an NS(EARO) or asynchronously. The Host		received synchronously upon an NS(EARO) or asynchronously. The Host
	needs to support both cases and refrain from using the address when		needs to support both cases and refrain from using the address when
	the Status value indicates a rejection.		the Status value indicates a rejection.
	This specification can be used to register Anycast and Multicast IPv6		This specification can be used to register Anycast and Multicast IPv6
	addresses as discussed in Section 3.2.5 and replace MLDv2. To		addresses as discussed in Section 3.3.5 and replace MLDv2. To
	benefit from that capability, both the host and the 6LR MUST support		benefit from that capability, both the host and the 6LR MUST support
	the "A" and "M" flags that indicate Anycast and Multicast Addresses		the "A" and "M" flags that indicate Anycast and Multicast Addresses
	respectively. Those flags are defined in		respectively. Those flags are defined in
	[I-D.thubert-6lo-multicast-registration] for use in the EARO and in		[I-D.thubert-6lo-multicast-registration] for use in the EARO and in
	the EDAR and EDAC messages.		the EDAR and EDAC messages.
	6. Enhancements to EVPN		6. Enhancements to EVPN
	This section addresses the necessary changes to EVPN formats and		This section addresses the necessary changes to EVPN formats and
	behavior to support address registration security per [RFC8928] and		behavior to support address registration security per [RFC8928] and
	skipping to change at page 25, line 35 ¶		skipping to change at page 29, line 35 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved = 0 | ROVR Hash |		| Reserved = 0 | ROVR Hash |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Flags field:		Flags field:
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |I| |O|R| |M|U|M|X|V|H|		| |I| |O|R| |M|U|M|X|V|H|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 11: Updated ARP/ND Extended Community		Figure 14: Updated ARP/ND Extended Community
	Flags:		Flags:
	U: Unreachable, indicating that the IP address is not reachable via		U: Unreachable, indicating that the IP address is not reachable via
	that EVPN next hop, but is advertised for the purpose of		that EVPN next hop, but is advertised for the purpose of
	protecting the value of the ROVR until a first 6LBR that can reach		protecting the value of the ROVR until a first 6LBR that can reach
	the address becomes available.		the address becomes available.
	M: Multicast, indicating that the IP address duplication should be		M: Multicast, indicating that the IP address duplication should be
	ignored. When this bit is set, TID should be ignored in		ignored. When this bit is set, TID should be ignored in
	skipping to change at page 26, line 21 ¶		skipping to change at page 30, line 21 ¶
	ROVR Hash: Hash of ROVR used to generate the according ROVR MAC.		ROVR Hash: Hash of ROVR used to generate the according ROVR MAC.
	Hash is built by XOR'ing ROVR bytes in network order into the		Hash is built by XOR'ing ROVR bytes in network order into the
	least significant byte and rotating the two bytes result after		least significant byte and rotating the two bytes result after
	every byte by one bit to the left.		every byte by one bit to the left.
	6.2. ROVR MAC Mobility Extended Community		6.2. ROVR MAC Mobility Extended Community
	Extending MAC Mobility Extended Community to transport the TID allows		Extending MAC Mobility Extended Community to transport the TID allows
	to design a solution that, while backwards compatible, allows to		to design a solution that, while backwards compatible, allows to
	introduce ROVR MAC as "more trusted" entities. Figure 12 presents		introduce ROVR MAC as "more trusted" entities. Figure 15 presents
	the according extensions that will however necessitate some further		the according extensions that will however necessitate some further
	explanation.		explanation.
	To introduce a "precedence" of ROVR MACs over normal EVPN MACs ROVR		To introduce a "precedence" of ROVR MACs over normal EVPN MACs ROVR
	MACs are advertised to look like "sticky" MACs for non-ROVR nodes.		MACs are advertised to look like "sticky" MACs for non-ROVR nodes.
	As defined in the glossary, for simplicity reasons such nodes will be		As defined in the glossary, for simplicity reasons such nodes will be
	called non-ROVR nodes vs. ROVR nodes. The "sticky" bit will force		called non-ROVR nodes vs. ROVR nodes. The "sticky" bit will force
	non-ROVR nodes to disregard the sequence number and accept any IP/MAC		non-ROVR nodes to disregard the sequence number and accept any IP/MAC
	route provided.		route provided.
	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=0x00 | Flags = 0 |S| Reserved = 0 |		| Type=0x06 | Sub-Type=0x00 | Flags = 0 |S| Reserved = 0 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|T| Flags = 0 | TID | Reserved = 0 |		|T| Flags = 0 | TID | Reserved = 0 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 12: Modified MAC Mobility Extended Community		Figure 15: Modified MAC Mobility Extended Community
	This specification updates the Sequence Number field defined in		This specification updates the Sequence Number field defined in
	[RFC7432]. The field is split in 3 parts, one 8-bit flags field, the		[RFC7432]. The field is split in 3 parts, one 8-bit flags field, the
	TID, and a reserver 2-byte field. The unspecified flags and the		TID, and a reserver 2-byte field. The unspecified flags and the
	reserved fields MUST be set to 0 by the sender and ignored by the		reserved fields MUST be set to 0 by the sender and ignored by the
	receiver.		receiver.
	The "S" flag is defined in [RFC7432]. The following new fields are		The "S" flag is defined in [RFC7432]. The following new fields are
	defined:		defined:
	skipping to change at page 28, line 5 ¶		skipping to change at page 32, line 5 ¶
	local interface unless an implementation is somewhat clever and		local interface unless an implementation is somewhat clever and
	understands that the presence of the same ESI on all the routes		understands that the presence of the same ESI on all the routes
	indicates that this situation does not represent a sticky MAC being		indicates that this situation does not represent a sticky MAC being
	moved.		moved.
	7. Protocol Operations		7. Protocol Operations
	Following section illustrates several situations and resulting		Following section illustrates several situations and resulting
	signaling in EVPN from the point of view of a ROVR node.		signaling in EVPN from the point of view of a ROVR node.
	Figure 13 illustrates the registration flow of a new address		Figure 16 illustrates the registration flow of a new address
	protected by [RFC8928]. The ROVR in the EARO is a Crypto-ID that		protected by [RFC8928]. The ROVR in the EARO is a Crypto-ID that
	derives from a public address through hashing with some other terms.		derives from a public address through hashing with some other terms.
	The router challenges the host with a status of 5 (validation		The router challenges the host with a status of 5 (validation
	requested).		requested).
	The host performs the NS again, passing the parameters that enable to		The host performs the NS again, passing the parameters that enable to
	build the Crypto-ID in a Crypto-ID Parameters Option (CIPO), and		build the Crypto-ID in a Crypto-ID Parameters Option (CIPO), and
	signing that set of parameters together with a pair of Nonce values,		signing that set of parameters together with a pair of Nonce values,
	one from each side, in a resulting Neighbor Discovery Protocol		one from each side, in a resulting Neighbor Discovery Protocol
	Signature Option (NDPDO). The 6LR first verifies that the Crypto-ID		Signature Option (NDPDO). The 6LR first verifies that the Crypto-ID
	can be rebuilt based on the public key, then verifies that the		can be rebuilt based on the public key, then verifies that the
	signature in the NDPSO was effectively performed with the associated		signature in the NDPSO was effectively performed with the associated
	public key. When that is the case, the registration flow can		public key. When that is the case, the registration flow can
	continue, else the registration is rejected with a status of 10		continue, else the registration is rejected with a status of 10
	(Validation Failed) in the NA(EARO).		(Validation Failed) in the NA(EARO).
	With this specification, the 6LBR communicates internally with the		With this specification, the 6LBR communicates internally with the
	collocated eVPN router to inject the route in eVPN. Since the		collocated EVPN router to inject the route in EVPN. Since the
	[RFC8928] validation was performed, the V flag is set. Once this is		[RFC8928] validation was performed, the V flag is set. Once this is
	done, the local 6LBR installs a local state associated to the NCE and		done, the local 6LBR installs a local state associated to the NCE and
	becomes owner of the registration, whereas the remote leaves		becomes owner of the registration, whereas the remote leaves
	optionally install a remote state for the address with the indication		optionally install a remote state for the address with the indication
	of the 6LBR that owns the registration. The local 6LBR MUST be		of the 6LBR that owns the registration. The local 6LBR MUST be
	signalled as EVPN Next Hop for the route.		signalled as EVPN Next Hop for the route.
	Local Local Route Remote		Local Local Route Remote
	Server Leaf Reflector Leaf		Server Leaf Reflector Leaf
	+-------+ +---------+ +-------+ +---------+		+-------+ +---------+ +-------+ +---------+
	skipping to change at page 29, line 48 ¶		skipping to change at page 33, line 48 ¶
	| | | |		| | | |
	| NA(EARO( | | |		| NA(EARO( | | |
	| R set, | | |		| R set, | | |
	| status = 0)) | | |		| status = 0)) | | |
	|<---------------| | |		|<---------------| | |
	| | | ROVR MAC Route A'		| | | ROVR MAC Route A'
	| | |--------------->|		| | |--------------->|
	| | | install remote state		| | | install remote state
	| | | |		| | | |
	Figure 13: Host Registration		Figure 16: Host Registration
	Figure 14 presents the same flow but for a multihomed address; here		Figure 17 presents the same flow but for a multihomed address; here
	and in the following flows, the proof of ownership section is not		and in the following flows, the proof of ownership section is not
	shown, but its use is RECOMMENDED. The interesting piece is that		shown, but its use is RECOMMENDED. The interesting piece is that
	when the node registers to the second 6LBR, that second 6LBR find		when the node registers to the second 6LBR, that second 6LBR find
	that there is a first 6LBR that already own the registration. Using		that there is a first 6LBR that already own the registration. Using
	and EDAR / EDAC flow, the second 6LBR validates that the ROVR and TID		and EDAR / EDAC flow, the second 6LBR validates that the ROVR and TID
	are identical, in which case it accepts the registration and becomes		are identical, in which case it accepts the registration and becomes
	another 6LBR owner of the registration. The result is that the 2		another 6LBR owner of the registration. The result is that the 2
	6LBRs are synchronized and any of the 2 can now be used, e.g., if the		6LBRs are synchronized and any of the 2 can now be used, e.g., if the
	address is registered a third time.		address is registered a third time.
	skipping to change at page 31, line 4 ¶		skipping to change at page 35, line 4 ¶
	| | install local state |		| | install local state |
	| | | |		| | | |
	| | ROVR MAC Route A' |		| | ROVR MAC Route A' |
	| | |---------------->|		| | |---------------->|
	| |<-------------------------------|		| |<-------------------------------|
	| install remote state | |		| install remote state | |
	| | | |		| | | |
	| NA(EARO(status = 0)) | |		| NA(EARO(status = 0)) | |
	|<------------------------------| |		|<------------------------------| |
	| | | |		| | | |
	Figure 14: Multihoming		Figure 17: Multihoming
	The registration is associated with a lifetime, and it must be		The registration is associated with a lifetime, and it must be
	renewed with an incremented TID. The new TID is propagated in eVPN		renewed with an incremented TID. The new TID is propagated in EVPN
	as illustrated in Figure 15.		as illustrated in Figure 18.
	Local Local Route Remote		Local Local Route Remote
	Server Leaf Reflector Leaf		Server Leaf Reflector Leaf
	+-------+ +---------+ +-------+ +---------+		+-------+ +---------+ +-------+ +---------+
	| | | | | | | |		| | | | | | | |
	6LN 6LBR/EVPN BGP EVPN/6LBR		6LN 6LBR/EVPN BGP EVPN/6LBR
	| | | |		| | | |
	| Ethernet | [via BGP signaling] |		| Ethernet | [via BGP signaling] |
	| | | |		| | | |
	| | | |		| | | |
	skipping to change at page 31, line 32 ¶		skipping to change at page 35, line 32 ¶
	| renew lifetime locally | |		| renew lifetime locally | |
	| | | |		| | | |
	| | ROVR MAC Route A'(TID+1) |		| | ROVR MAC Route A'(TID+1) |
	| |---------------->| |		| |---------------->| |
	| NA(EARO | |--------------->|		| NA(EARO | |--------------->|
	| status = 0)) | | update remote state		| status = 0)) | | update remote state
	|<---------------| | |		|<---------------| | |
	| | | |		| | | |
	| | | |		| | | |
	Figure 15: Host Registration Renewal		Figure 18: Host Registration Renewal
	Figure 16 illustrates the case where a second host registers the same		Figure 19 illustrates the case where a second host registers the same
	address, creating a potential address duplication situation. in most		address, creating a potential address duplication situation. in most
	cases, the ROVR hash will be different, and the local 6LBR can reject		cases, the ROVR hash will be different, and the local 6LBR can reject
	the registration is a status of 1 (duplicate) right away.		the registration is a status of 1 (duplicate) right away.
	Local Local Route Remote		Local Local Route Remote
	Server Leaf Reflector Leaf		Server Leaf Reflector Leaf
	+-------+ +---------+ +-------+ +---------+		+-------+ +---------+ +-------+ +---------+
	| | | | | | | |		| | | | | | | |
	6LN 6LBR/EVPN BGP EVPN/6LBR		6LN 6LBR/EVPN BGP EVPN/6LBR
	| | | |		| | | |
	skipping to change at page 32, line 32 ¶		skipping to change at page 36, line 32 ¶
	| NS(EARO) | | |		| NS(EARO) | | |
	|--------------->| | |		|--------------->| | |
	| compute ROVR Hash F | |		| compute ROVR Hash F | |
	| | | |		| | | |
	| NA(EARO( | | |		| NA(EARO( | | |
	| status = 1)) | | |		| status = 1)) | | |
	|<---------------| | |		|<---------------| | |
	| | | |		| | | |
	| | | |		| | | |
	Figure 16: Duplicate Addresses		Figure 19: Duplicate Addresses
	Figure 17 illustrates the case of an address duplication situation		Figure 20 illustrates the case of an address duplication situation
	where by chance, the ROVR hashes are the same. In that case, the		where by chance, the ROVR hashes are the same. In that case, the
	local 6LR checks with the 6LBR that owns the registration using an		local 6LR checks with the 6LBR that owns the registration using an
	EDAR/EDAC message exchange. As opposed to the ROVR hash, the full		EDAR/EDAC message exchange. As opposed to the ROVR hash, the full
	ROVRs do not collide and the registration is also rejected.		ROVRs do not collide and the registration is also rejected.
	Local Local Route Remote		Local Local Route Remote
	Server Leaf Reflector Leaf		Server Leaf Reflector Leaf
	+-------+ +---------+ +-------+ +---------+		+-------+ +---------+ +-------+ +---------+
	| | | | | | | |		| | | | | | | |
	6LN 6LBR EVPN BGP EVPN/6LBR		6LN 6LBR EVPN BGP EVPN/6LBR
	skipping to change at page 33, line 39 ¶		skipping to change at page 37, line 39 ¶
	| |-------------------------------------->|		| |-------------------------------------->|
	| | |		| | |
	| | EDAC (status = 1) |		| | EDAC (status = 1) |
	| |<--------------------------------------|		| |<--------------------------------------|
	| | |		| | |
	| NA(EARO( | |		| NA(EARO( | |
	| status = 1))| |		| status = 1))| |
	|<-------------| |		|<-------------| |
	| | |		| | |
	Figure 17: Duplicate Addresses, ROVR Hash Collision		Figure 20: Duplicate Addresses, ROVR Hash Collision
	Figure 18 shows a rare case where the registration has already moved		Figure 21 shows a rare case where the registration has already moved
	elsewhere with an incremented TID when the local registration is		elsewhere with an incremented TID when the local registration is
	received after being delayed in the network. In that case, the		received after being delayed in the network. In that case, the
	registration is rejected with a status of 3 (moved).		registration is rejected with a status of 3 (moved).
	Local Local Route Remote		Local Local Route Remote
	Server Leaf Reflector Leaf		Server Leaf Reflector Leaf
	+-------+ +---------+ +-------+ +---------+		+-------+ +---------+ +-------+ +---------+
	| | | | | | | |		| | | | | | | |
	6LN 6LBR/EVPN BGP EVPN/6LBR		6LN 6LBR/EVPN BGP EVPN/6LBR
	| | | |		| | | |
	skipping to change at page 34, line 32 ¶		skipping to change at page 38, line 32 ¶
	| TID=Z-1)) | | |		| TID=Z-1)) | | |
	|--------------->| | |		|--------------->| | |
	| computes as | |		| computes as | |
	| ROVR Hash F | |		| ROVR Hash F | |
	| ESI X'', TID Z-1 | |		| ESI X'', TID Z-1 | |
	| NA(EARO) | | |		| NA(EARO) | | |
	| status = 3)) | | |		| status = 3)) | | |
	|<---------------| | |		|<---------------| | |
	| | | |		| | | |
	Figure 18: Address Already Moved		Figure 21: Address Already Moved
	Address move differs from multi-homing by the ESI being different as		Address move differs from multi-homing by the ESI being different as
	visualized by Figure 19. In case of different ESI BGP signalling		visualized by Figure 22. In case of different ESI BGP signalling
	happens immediately, in case of multi-homing we can reasonably expect		happens immediately, in case of multi-homing we can reasonably expect
	for the signalling to catch up on the other leg with a new, higher		for the signalling to catch up on the other leg with a new, higher
	TID. However, since ESI matches TID doesn't matter strictly speaking		TID. However, since ESI matches TID doesn't matter strictly speaking
	and the new remote state can be installed as is. However, if 6LN is		and the new remote state can be installed as is. However, if 6LN is
	not refreshing it registration we can expect elapsed lifetime to		not refreshing it registration we can expect elapsed lifetime to
	create scenario Figure 22 over time.		create scenario Figure 25 over time.
	Local Local Route Remote		Local Local Route Remote
	Server Leaf Reflector Leaf		Server Leaf Reflector Leaf
	+-------+ +---------+ +-------+ +---------+		+-------+ +---------+ +-------+ +---------+
	| | | | | | | |		| | | | | | | |
	6LN 6LBR/EVPN BGP EVPN/6LBR		6LN 6LBR/EVPN BGP EVPN/6LBR
	| | | |		| | | |
	| Ethernet | | |		| Ethernet | | |
	| | [via BGP signaling] |		| | [via BGP signaling] |
	| NS(EARO) | | |		| NS(EARO) | | |
	skipping to change at page 36, line 4 ¶		skipping to change at page 40, line 4 ¶
	| Create remote state | |		| Create remote state | |
	| | | |		| | | |
	| NA(EARO( | | |		| NA(EARO( | | |
	| status = 4)) | | |		| status = 4)) | | |
	|<---------------| | |		|<---------------| | |
	| | Withdraw ROVR MAC Route A' |		| | Withdraw ROVR MAC Route A' |
	| |---------------->| |		| |---------------->| |
	| | |--------------->|		| | |--------------->|
	| remove local state | |		| remove local state | |
	| | | |		| | | |
	Figure 19: Address Move		Figure 22: Address Move
	The host that registered the address may cancel the registration at		The host that registered the address may cancel the registration at
	any time, e.g., if the address is removed fmor its own interface.		any time, e.g., if the address is removed fmor its own interface.
	This is done by registering with a lifetime if 0 as shown in		This is done by registering with a lifetime if 0 as shown in
	Figure 20. The Leaf may respond with a status of 0 to indicate		Figure 23. The Leaf may respond with a status of 0 to indicate
	success, but a status of 4 (removed) is preferred for this situation.		success, but a status of 4 (removed) is preferred for this situation.
	Local Local Route Remote		Local Local Route Remote
	Server Leaf Reflector Leaf		Server Leaf Reflector Leaf
	+-------+ +---------+ +-------+ +---------+		+-------+ +---------+ +-------+ +---------+
	| | | | | | | |		| | | | | | | |
	6LN 6LBR/EVPN BGP EVPN/6LBR		6LN 6LBR/EVPN BGP EVPN/6LBR
	| | | |		| | | |
	| Ethernet | | |		| Ethernet | | |
	| | [via BGP signaling] |		| | [via BGP signaling] |
	skipping to change at page 36, line 35 ¶		skipping to change at page 40, line 35 ¶
	| | Withdraw ROVR MAC Route A' |		| | Withdraw ROVR MAC Route A' |
	| |---------------->| |		| |---------------->| |
	| | |--------------->|		| | |--------------->|
	| NA(EARO( | | |		| NA(EARO( | | |
	| status = 4)) | | |		| status = 4)) | | |
	|<---------------| | |		|<---------------| | |
	| | | |		| | | |
	| remove local state | |		| remove local state | |
	| | | |		| | | |
	Figure 20: Address Removal		Figure 23: Address Removal
	The host that registered the address may withdraw the route but		The host that registered the address may withdraw the route but
	maintain the NCE, e.g., in the case where it is multihomed but does		maintain the NCE, e.g., in the case where it is multihomed but does
	not want to use one interface for the traffic back as this time.		not want to use one interface for the traffic back as this time.
	This is done by registering with the R flag set to 0 as shown in		This is done by registering with the R flag set to 0 as shown in
	Figure 21.		Figure 24.
	Local Local Route Remote		Local Local Route Remote
	Server Leaf Reflector Leaf		Server Leaf Reflector Leaf
	+-------+ +---------+ +-------+ +---------+		+-------+ +---------+ +-------+ +---------+
	| | | | | | | |		| | | | | | | |
	6LN 6LBR/EVPN BGP EVPN/6LBR		6LN 6LBR/EVPN BGP EVPN/6LBR
	| | | |		| | | |
	| Ethernet | | |		| Ethernet | | |
	| | [via BGP signaling] |		| | [via BGP signaling] |
	| | | |		| | | |
	skipping to change at page 37, line 29 ¶		skipping to change at page 41, line 29 ¶
	| |---------------->| |		| |---------------->| |
	| | |--------------->|		| | |--------------->|
	| NA(EARO( | | |		| NA(EARO( | | |
	| R reset, | | |		| R reset, | | |
	| status = 0)) | | |		| status = 0)) | | |
	|<---------------| | |		|<---------------| | |
	| | | |		| | | |
	| retain only NCE | |		| retain only NCE | |
	| | | |		| | | |
	Figure 21: Route Type 2 Removal		Figure 24: Route Type 2 Removal
	When the lifetime elapses, the 6LBR requires the collocated eVPN		When the lifetime elapses, the 6LBR requires the collocated EVPN
	router to withdraw the route.		router to withdraw the route.
	Local Local Route Remote		Local Local Route Remote
	Server Leaf Reflector Leaf		Server Leaf Reflector Leaf
	+-------+ +---------+ +-------+ +---------+		+-------+ +---------+ +-------+ +---------+
	| | | | | | | |		| | | | | | | |
	6LN 6LBR/EVPN BGP EVPN/6LBR		6LN 6LBR/EVPN BGP EVPN/6LBR
	| | | |		| | | |
	| Ethernet | | |		| Ethernet | | |
	| | [via BGP signaling] |		| | [via BGP signaling] |
	skipping to change at page 38, line 26 ¶		skipping to change at page 42, line 26 ¶
	| | Withdraw ROVR MAC Route A' |		| | Withdraw ROVR MAC Route A' |
	| |---------------->| |		| |---------------->| |
	| | |--------------->|		| | |--------------->|
	| NA(EARO( | | |		| NA(EARO( | | |
	| status = 4)) | | |		| status = 4)) | | |
	|<---------------| | |		|<---------------| | |
	| | | |		| | | |
	| remove local state | |		| remove local state | |
	| | | |		| | | |
	Figure 22: Lifetime Elapse		Figure 25: Lifetime Elapse
	8. Security Considerations		8. Security Considerations
	TBD		TBD
	9. IANA Considerations		9. IANA Considerations
	10. Acknowledgments		10. Acknowledgments
	The authors wish to thank you for reading that far. We acknowledge		The authors wish to thank you for reading that far. We acknowledge
	skipping to change at page 41, line 5 ¶		skipping to change at page 45, line 5 ¶
	[RFC8929] Thubert, P., Ed., Perkins, C.E., and E. Levy-Abegnoli,		[RFC8929] Thubert, P., Ed., Perkins, C.E., and E. Levy-Abegnoli,
	"IPv6 Backbone Router", RFC 8929, DOI 10.17487/RFC8929,		"IPv6 Backbone Router", RFC 8929, DOI 10.17487/RFC8929,
	November 2020, <https://www.rfc-editor.org/info/rfc8929>.		November 2020, <https://www.rfc-editor.org/info/rfc8929>.
	[RFC9010] Thubert, P., Ed. and M. Richardson, "Routing for RPL		[RFC9010] Thubert, P., Ed. and M. Richardson, "Routing for RPL
	(Routing Protocol for Low-Power and Lossy Networks)		(Routing Protocol for Low-Power and Lossy Networks)
	Leaves", RFC 9010, DOI 10.17487/RFC9010, April 2021,		Leaves", RFC 9010, DOI 10.17487/RFC9010, April 2021,
	<https://www.rfc-editor.org/info/rfc9010>.		<https://www.rfc-editor.org/info/rfc9010>.
	[RIFT] Sharma, A., Thubert, P., Rijsman, B., and D. Afanasiev,		[RIFT] Sharma, A., Thubert, P., Rijsman, B., Afanasiev, D., and
	"RIFT: Routing in Fat Trees", Work in Progress, Internet-		A. Przygienda, "RIFT: Routing in Fat Trees", Work in
	Draft, draft-ietf-rift-rift-13, 12 July 2021,		Progress, Internet-Draft, draft-ietf-rift-rift-15, 3
	<https://datatracker.ietf.org/doc/html/draft-ietf-rift-		January 2022, <https://datatracker.ietf.org/doc/html/
	rift-13>.		draft-ietf-rift-rift-15>.
	[IANA-EARO-STATUS]		[IANA-EARO-STATUS]
	IANA, "Address Registration Option Status Values",		IANA, "Address Registration Option Status Values",
	<https://www.iana.org/assignments/icmpv6-parameters/		<https://www.iana.org/assignments/icmpv6-parameters/
	icmpv6-parameters.xhtml#address-registration>.		icmpv6-parameters.xhtml#address-registration>.
	Authors' Addresses		Authors' Addresses
	Pascal Thubert (editor)		Pascal Thubert (editor)
	Cisco Systems, Inc		Cisco Systems, Inc
End of changes. 69 change blocks.
	108 lines changed or deleted		244 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/