< draft-thubert-bess-secure-evpn-mac-signaling-00.txt		draft-thubert-bess-secure-evpn-mac-signaling-01.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: 9 January 2022 Juniper Networks, Inc		Expires: 6 June 2022 Juniper Networks, Inc
	J. Tantsura		J. Tantsura
	Microsoft		Microsoft
	8 July 2021		3 December 2021
	Secure EVPN MAC Signaling		Secure EVPN MAC Signaling
	draft-thubert-bess-secure-evpn-mac-signaling-00		draft-thubert-bess-secure-evpn-mac-signaling-01
	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 9 January 2022.		This Internet-Draft will expire on 6 June 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 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 Simplified BSD License text		extracted from this document must include Revised BSD License text as
	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 Simplified 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. RFC 6775 Address Registration . . . . . . . . . . . . . . 6
	3.2. RFC 8505 Extended Address Registration . . . . . . . . . 7		3.2. RFC 8505 Extended Address Registration . . . . . . . . . 7
	3.2.1. R Flag . . . . . . . . . . . . . . . . . . . . . . . 8		3.2.1. R Flag . . . . . . . . . . . . . . . . . . . . . . . 8
	3.2.2. TID, "I" Field and Opaque Fields . . . . . . . . . . 8		3.2.2. TID, "I" Field and Opaque Fields . . . . . . . . . . 8
	3.2.3. Status . . . . . . . . . . . . . . . . . . . . . . . 8		3.2.3. Status . . . . . . . . . . . . . . . . . . . . . . . 8
	3.2.4. Route Ownership Verifier . . . . . . . . . . . . . . 9		3.2.4. Route Ownership Verifier . . . . . . . . . . . . . . 9
	3.3. RFC 8505 Extended DAR/DAC . . . . . . . . . . . . . . . . 9		3.2.5. Anycast and Multicast Addresses . . . . . . . . . . . 9
	3.4. RFC 7400 Capability Indication Option . . . . . . . . . . 10		3.3. RFC 8505 Extended DAR/DAC . . . . . . . . . . . . . . . . 10
			3.4. RFC 7400 Capability Indication Option . . . . . . . . . . 11
	4. Extending 6LoWPAN ND . . . . . . . . . . . . . . . . . . . . 11		4. Extending 6LoWPAN ND . . . . . . . . . . . . . . . . . . . . 11
	4.1. Use of the R flag in NA . . . . . . . . . . . . . . . . . 11		4.1. Use of the R flag in NA . . . . . . . . . . . . . . . . . 11
	4.2. Distributing the 6LBR . . . . . . . . . . . . . . . . . . 11		4.2. Distributing the 6LBR . . . . . . . . . . . . . . . . . . 12
	4.3. Unicast Address Lookup with the 6LBR . . . . . . . . . . 15		4.3. Unicast Address Lookup with the 6LBR . . . . . . . . . . 15
	5. Requirements on the EVPN-Unaware Host . . . . . . . . . . . . 21		5. Requirements on the EVPN-Unaware Host . . . . . . . . . . . . 21
	5.1. Support of 6LoWPAN ND . . . . . . . . . . . . . . . . . . 21		5.1. Support of 6LoWPAN ND . . . . . . . . . . . . . . . . . . 21
	6. Enhancements to EVPN . . . . . . . . . . . . . . . . . . . . 22		6. Enhancements to EVPN . . . . . . . . . . . . . . . . . . . . 22
	6.1. ROVR MAC Mobility Extended Community . . . . . . . . . . 24		6.1. ARP/ND Extended Community . . . . . . . . . . . . . . . . 24
	6.2. Extended ROVR MAC Procedures . . . . . . . . . . . . . . 25		6.2. ROVR MAC Mobility Extended Community . . . . . . . . . . 26
	7. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 26		6.3. Extended ROVR MAC Procedures . . . . . . . . . . . . . . 27
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 36		7. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 27
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37		8. Security Considerations . . . . . . . . . . . . . . . . . . . 38
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
	11. Normative References . . . . . . . . . . . . . . . . . . . . 37		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38
	12. Informative References . . . . . . . . . . . . . . . . . . . 38		11. Normative References . . . . . . . . . . . . . . . . . . . . 38
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39		12. Informative References . . . . . . . . . . . . . . . . . . . 40
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
	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
	skipping to change at page 9, line 28 ¶		skipping to change at page 9, line 28 ¶
	"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
	address that is already owned. The use of ROVR field enables the 6LR		address that is already owned. The use of ROVR field enables the 6LR
	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.1), 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
			"IPv6 Neighbor Discovery Multicast Address Registration"
			[I-D.thubert-6lo-multicast-registration] updates [RFC8505] to enable
			the address registration of IPv6 anycast and multicast addresses.
			From the host perspective, the registration is very similar to that
			of unicast addresses, but for a flag in the EARO that signals that
			the address is multicast or anycast.
			This procedure can be used as a replacement to "Multicast Listener
			Discovery Version 2 (MLDv2) for IPv6" [RFC3810] for source-
			independant multicast operation. As for unicast, the method saves
			the need for the host to listen to pollings from the router, and
			allows the host to sleep for periods of time.
	3.3. RFC 8505 Extended DAR/DAC		3.3. 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.
	skipping to change at page 22, line 7 ¶		skipping to change at page 22, 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 13.		for a successful multihomed registration is illustrated in Figure 14.
	[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
			addresses as discussed in Section 3.2.5 and replace MLDv2. To
			benefit from that capability, both the host and the 6LR MUST support
			the "A" and "M" flags that indicate Anycast and Multicast Addresses
			respectively. Those flags are defined in
			[I-D.thubert-6lo-multicast-registration] for use in the EARO and in
			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
	mobility per [RFC8505] while retaining interoperability with		mobility per [RFC8505] while retaining interoperability with
	traditional nodes. With 6LR injecting not only MACs via packet		traditional nodes. Basically the MAC Mobility Extended Community
	sources and TLLAO options but also ROVR into mobility extended		[RFC7432] and the ARP/ND Extended Community [RFC9047] are extended to
	community their semantics will be somewhat extended. Specifically		advertise the sequencing and ownership validation information
	following issues have to be addressed:		received in the EARO. With 6LR injecting not only MACs via packet
			sources and TLLAO options but also ROVR into MAC Mobility and ARP/ND
			Extended Community, their semantics will be somewhat extended.
			Specifically following issues have to be addressed:
	* The ROVR extends the semantics of the type-2 MAC advertisement via		* The ROVR extends the semantics of the type-2 MAC advertisement via
	changes in MAC Mobility Extended Community in the sense that the		changes in ARP/ND and MAC Mobility Extended Community in the sense
	MAC must be aligned with the ROVR and under normal circumstances		that the MAC must be aligned with the ROVR and under normal
	only the validity of ROVR guarantees that the type-2 MAC can be		circumstances only the validity of ROVR guarantees that the type-2
	allocated to the requester. A MAC validated by ROVR should take		MAC can be allocated to the requester. A MAC validated by ROVR
	precedence over MAC addresses allocated without using it given it		should take precedence over MAC addresses allocated without using
	presents a much more trustworthy topological information (it will		it given it presents a much more trustworthy topological
	be called ROVR MAC in further text). EVPN nodes not supporting		information (it will be called ROVR MAC in further text). EVPN
	extensions introduced by this document will need to be led to		nodes not supporting extensions introduced by this document will
	believe that a ROVR MAC is to be preferred over any advertisement		need to be led to believe that a ROVR MAC is to be preferred over
	they see as long a ROVR MAC route is present. Nevertheless,		any advertisement they see as long a ROVR MAC route is present.
	primary key of NRLI is still the IP/MAC/ESI combination as defined		Nevertheless, primary key of NRLI is still the (IP, MAC, Ethernet
	in [RFC7432], Section 7.2 and 7.7. This implies that the same MAC		Tag ID) tuple as defined in [RFC7432], Section 7.2 and 7.7. This
	(and consequently ROVR MAC) can be assigned multiple IP addresses		implies that the same MAC (and consequently ROVR MAC) can be
	and those represent independent NLRIs.		assigned multiple IP addresses and those represent independent
			NLRIs.
	* The TID field in the EARO is smaller than the mobility sequence		* The TID field in the EARO is smaller than the mobility sequence
	number in [RFC7432]. To allow a ROVR MAC mobility to "win" over		number in [RFC7432]. To allow a ROVR MAC mobility to "win" over
	legacy MACs in every circumstance, signaling must be introduced		legacy MACs in every circumstance, signaling must be introduced
	that enables to distinguish a TID-generated sequence number from a		that enables to distinguish a TID-generated sequence number from a
	legacy sequence number.		legacy sequence number.
	* [RFC8505] supports IP multihoming, but does not differentiate		* [RFC8505] supports IP multihoming, but does not differentiate
	multihoming from anycast, e.g., using the MAC address, to enable		multihoming from anycast, e.g., using the MAC address, to enable
	MAC address rotation. If an anycast IP address is registered with		MAC address rotation. If an anycast IP address is registered with
	a different ROVR it will be rejected as duplicate. If it is		a different ROVR it will be rejected as duplicate. If it is
	registered with a different TID, the older sequence will be		registered with a different TID, the older sequence will be
	withdrawn. So the basic expectation with [RFC8505] is that the		withdrawn. So the basic expectation with [RFC8505] is that the
	advertisement of an anycast address is coordinated, with the same		advertisement of an anycast address is coordinated, with the same
	keypair known to all parties, and the same value of the TID used		keypair known to all parties, and the same value of the TID used
	by all nodes (and possibly never increasing), in other words, with		by all nodes (and possibly never increasing), in other words, with
	no concept of mobility. This specification adds a flag in EVPN		no concept of mobility.
	that signals that the IP address is anycast and requires the local
	6LBR to ignore the duplication if the same IP address is		* [I-D.thubert-6lo-multicast-registration] adds new flags in the
	registered locally, and then to inject the NLRI with the A flag		EARO to signal that an address is anycast or multicast,
	set on mobility extended community as well.		respectively. This specification injects that information in the
			ARP/ND extended community using matching flags as follows:
			- This specification uses the "O" flag in the ARP/ND extended
			community to signal that the IP address is anycast, and
			requires the local 6LBR to ignore the duplication if the same
			IP address is registered locally, and then to inject the NLRI
			with the "O" flag set on the ARP/ND Extended Community as well.
			- This specification adds the new "M" flag in the ARP/ND extended
			community to signal that the IP address is multicast, and
			requires the local 6LBR to ignore the duplication if the same
			IP address is registered locally, and then to inject the NLRI
			with the "M" flag set on the ARP/ND Extended Community as well.
	* [RFC8928] needs the full ROVR to validate the address ownership,		* [RFC8928] needs the full ROVR to validate the address ownership,
	but the full ROVR can be too large to advertise through BGP. When		but the full ROVR can be too large to advertise through BGP. When
	an IP address is advertised through EVPN, it is REQUIRED that the		an IP address is advertised through EVPN, it is REQUIRED that the
	EVPN Next Hop represents the address of the 6LBR of the leaf where		EVPN Next Hop represents the address of the 6LBR of the leaf where
	the address was registered as well. This way, if the address is		the address was registered as well. This way, if the address is
	registered later on a second leaf, the 6LR in second leaf can		registered later on a second leaf, the 6LR in second leaf can
	leverage an out-of-band, i.e. via EVPN traffic carrying tunnels,		leverage an out-of-band, i.e. via EVPN traffic carrying tunnels,
	EDAR/EDAC exchange with that 6LBR to validate that the ROVR in the		EDAR/EDAC exchange with that 6LBR to validate that the ROVR in the
	registration is indeed the same. When that is the case, it can		registration is indeed the same. When that is the case, it can
	skipping to change at page 23, line 43 ¶		skipping to change at page 24, line 22 ¶
	that capability in EVPN, this specification adds a flag to signal		that capability in EVPN, this specification adds a flag to signal
	that the 6LBR that injects the address in EVPN does not provide		that the 6LBR that injects the address in EVPN does not provide
	reachability to the address. When that flag is set, the value of		reachability to the address. When that flag is set, the value of
	the TID is ignored in the mobility computation, the mapping to the		the TID is ignored in the mobility computation, the mapping to the
	MAC address is ignored, and the route to the IP address is not		MAC address is ignored, and the route to the IP address is not
	injected in the RIB on ROVR nodes. Non-ROVR nodes will consider		injected in the RIB on ROVR nodes. Non-ROVR nodes will consider
	the node a "honey-pot". Once the address is registered by a 6LN		the node a "honey-pot". Once the address is registered by a 6LN
	in the network and the according validation with the node		in the network and the according validation with the node
	advertising the U-bit version of the route performed, the owner		advertising the U-bit version of the route performed, the owner
	will inject the route without the U-bit. A node advertising the		will inject the route without the U-bit. A node advertising the
	NLRI with U-bit in its mobility extended community MUST withdraw		NLRI with U-bit in its ARP/ND Extended Community MUST withdraw the
	the U-bit route once it sees a validated NLRI without the U-bit		U-bit route once it sees a validated NLRI without the U-bit and it
	and it MAY reinject the route with the U-bit once all routes		MAY reinject the route with the U-bit once all routes without the
	without the U-bit are withdrawn to protect the address again.		U-bit are withdrawn to protect the address again.
	EVPN signaling is not used to carry ROVR since without challenge per		EVPN signaling is not used to carry ROVR since without challenge per
	[RFC8928] they do not represent any difference over using the IP/MAC		[RFC8928] they do not represent any difference over using the IP/MAC
	combination. Instead, the full ROVR is verified upon a movement or a		combination. Instead, the full ROVR is verified upon a movement or a
	multi-homed advertisement using an EDAR/EDAC exchange. Additionally,		multi-homed advertisement using an EDAR/EDAC exchange. Additionally,
	backwards compatibility could not be preserved given comparing routes		backwards compatibility could not be preserved given comparing routes
	based on ROVR would present a change in primary key of NLRIs which		based on ROVR would present a change in primary key of NLRIs which
	non-ROVR routers do not implement. An indication from a ROVR node		non-ROVR routers do not implement. An indication from a ROVR node
	that a MAC has been validated by proof of ownership is enough to		that a MAC has been validated by proof of ownership is enough to
	convey the necessary information. Only a small hash of the ROVR is		convey the necessary information. Only a small hash of the ROVR is
	carried to speed up the identification of an address duplication.		carried to speed up the identification of an address duplication.
	6.1. ROVR MAC Mobility Extended Community		6.1. ARP/ND Extended Community
	Extending MAC Mobility Extended Community allows to design a solution
	that, while backwards compatible, allows to introduce ROVR MAC as
	"more trusted" entities. Figure 11 presents the according extensions
	that will however necessitate some further explanation.
	To introduce a "precedence" of ROVR MACs over normal EVPN MACs ROVR		The ARP/ND Extended Community defined in [RFC9047] is a transitive
	MACs are advertised to look like "sticky" MACs for non-ROVR nodes.		EVPN Extended Community (Type field value of 0x06) with a Sub-Type of
	As defined in the glossary, for simplicity reasons such nodes will be		0x08. It is advertised along with EVPN MAC/IP Advertisement routes
	called non-ROVR nodes vs. ROVR nodes. The "sticky" bit will force		that carry an IPv4 or IPv6 address. Extending the ARP/ND Extended
	non-ROVR nodes to disregard the sequence number and accept any IP/MAC		Community to transport fields from the EARO is natural since the EARO
	route provided.		is an extension to IPv6 ND.
	ROVR nodes MUST set the "R" flag in Mobility Extended Community to		ROVR nodes MUST set the "H" flag in Mobility Extended Community to
	indicate that the advertisement is a ROVR MAC in case the host		indicate that the advertisement is a ROVR MAC in case the host
	followed the according procedures. ROVR MACs use (instead of		followed the according procedures. ROVR MACs use (instead of
	increasing the normal sequence number) the TID in the high bits of		increasing the normal sequence number) the TID in the high bits of
	the sequence number field to "override" any normal MAC advertisement		the sequence number field to "override" any normal MAC advertisement
	(further considerations will be provided in Section 6.2).		(further considerations will be provided in Section 6.3).
	ROVR nodes MUST set the "V" flag if the address assignment passed		ROVR nodes MUST set the "V" flag if the address assignment passed
	proof of ownership per [RFC8928]. Such "validated" ROVR MAC		proof of ownership per [RFC8928]. Such "validated" ROVR MAC
	addresses will be preferred by ROVR nodes over non validated ROVR		addresses will be preferred by ROVR nodes over non validated ROVR
	MACs.		MACs.
	In case a ROVR node configures the address as "sticky" (since the		In case a ROVR node configures the address as "sticky" (since the
	sticky bit semantics have been changed to the point a ROVR cannot		sticky bit semantics have been changed to the point a ROVR cannot
	tell whether address is really sticky unless advertised as such by		tell whether address is really sticky unless advertised as such by
	non-ROVR node) a new "X" flag called "super sticky" is introduced.		non-ROVR node) a new "X" flag called "super sticky" is introduced.
	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 |rsv|U|A|X|V|R|S| Reserved = 0 |		| Type=0x06 | Sub-Type=0x08 | Flags (2 octet) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| TID | Reserved = 0 | ROVR Hash |		| Reserved = 0 | ROVR Hash |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 11: Modified MAC Mobility Extended Community		Flags field:
			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|
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 11: 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.
	A: Anycast, 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
	comparison of EVPN advertisements, i.e. all ROVR MACs at same		comparison of EVPN advertisements, i.e. all ROVR MACs at same
	level of validation MUST be considered having same TID.		level of validation MUST be considered having same TID.
	S: Sticky as defined in [RFC7432].
	R: ROVR Capable indicates that the advertisement is originated after
	processing signaling from host meeting the requirements in
	Section 5. This indicates a ROVR MAC.
	V: ROVR Validated indicates that the MAC passed proof of ownership		V: ROVR Validated indicates that the MAC passed proof of ownership
	per [RFC8928]. Presence of this bit implies the "R" bit being set		per [RFC8928]. Presence of this bit implies the "R" bit being set
	irregardless of its value.		irregardless of its value.
	X: Super Sticky indicates that the ROVR MAC is sticky and should		X: Super Sticky indicates that the ROVR MAC is sticky and should
	follow procedures of sticky per [RFC7432].		follow procedures of sticky per [RFC7432].
	Sequence Number Field:		H: ROVR Capable indicates that the advertisement is originated after
			processing signaling from host meeting the requirements in
	TID: contains the ROVR MAC TID per [RFC8505]. This MUST NOT be		Section 5. This indicates a ROVR MAC.
	zero, i.e. a ROVR
	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. Extended ROVR MAC Procedures		6.2. ROVR MAC Mobility Extended Community
			Extending MAC Mobility Extended Community to transport the TID allows
			to design a solution that, while backwards compatible, allows to
			introduce ROVR MAC as "more trusted" entities. Figure 12 presents
			the according extensions that will however necessitate some further
			explanation.
			To introduce a "precedence" of ROVR MACs over normal EVPN MACs ROVR
			MACs are advertised to look like "sticky" MACs for non-ROVR nodes.
			As defined in the glossary, for simplicity reasons such nodes will be
			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
			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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Type=0x06 | Sub-Type=0x00 | Flags = 0 |S| Reserved = 0 |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			|T| Flags = 0 | TID | Reserved = 0 |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 12: Modified MAC Mobility Extended Community
			This specification updates the Sequence Number field defined in
			[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
			reserved fields MUST be set to 0 by the sender and ignored by the
			receiver.
			The "S" flag is defined in [RFC7432]. The following new fields are
			defined:
			T: 1-bit flag. MUST be set to 1 when this specification is used.
			This ensures that the TID always wins vs. the sequence counter
			defined in [RFC7432]
			TID: contains the ROVR MAC TID per [RFC8505]. This MUST NOT be
			zero, i.e. a ROVR
			6.3. Extended ROVR MAC Procedures
	In case a non-ROVR node advertises a sticky MAC by setting the "S"		In case a non-ROVR node advertises a sticky MAC by setting the "S"
	bit and a ROVR node sees an ROVR address registration for the same		bit and a ROVR node sees an ROVR address registration for the same
	MAC it MUST follow procedures per [RFC7432].		MAC it MUST follow procedures per [RFC7432].
	In case a non-ROVR node advertises a sequence number larger than the		In case a non-ROVR node advertises a sequence number larger than the
	one generated by TID on a ROVR node, the ROVR node SHOULD advertise a		one generated by TID on a ROVR node, the ROVR node SHOULD advertise a
	Sequence Number consisting of all bits being set to force a "roll-		Sequence Number consisting of all bits being set to force a "roll-
	over" on all nodes and then fall back to advertising the TID		over" on all nodes and then fall back to advertising the TID
	generated sequence number again. In case a non-ROVR node persists in		generated sequence number again. In case a non-ROVR node persists in
	skipping to change at page 26, line 32 ¶		skipping to change at page 28, 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 12 illustrates the registration flow of a new address		Figure 13 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
	skipping to change at page 28, line 4 ¶		skipping to change at page 29, line 47 ¶
	| route injected | |		| route injected | |
	| | | |		| | | |
	| 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 12: Host Registration
	Figure 13 presents the same flow but for a multihomed address; here		Figure 13: Host Registration
			Figure 14 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 29, line 45 ¶		skipping to change at page 31, 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 13: 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 14.		as illustrated in Figure 15.
	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 30, line 27 ¶		skipping to change at page 31, 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 14: Host Registration Renewal		Figure 15: Host Registration Renewal
	Figure 15 illustrates the case where a second host registers the same		Figure 16 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 31, line 32 ¶		skipping to change at page 32, line 32 ¶
	| NS(EARO) | | |		| NS(EARO) | | |
	|--------------->| | |		|--------------->| | |
	| compute ROVR Hash F | |		| compute ROVR Hash F | |
	| | | |		| | | |
	| NA(EARO( | | |		| NA(EARO( | | |
	| status = 1)) | | |		| status = 1)) | | |
	|<---------------| | |		|<---------------| | |
	| | | |		| | | |
	| | | |		| | | |
	Figure 15: Duplicate Addresses		Figure 16: Duplicate Addresses
	Figure 16 illustrates the case of an address duplication situation		Figure 17 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 32, line 39 ¶		skipping to change at page 33, line 39 ¶
	| |-------------------------------------->|		| |-------------------------------------->|
	| | |		| | |
	| | EDAC (status = 1) |		| | EDAC (status = 1) |
	| |<--------------------------------------|		| |<--------------------------------------|
	| | |		| | |
	| NA(EARO( | |		| NA(EARO( | |
	| status = 1))| |		| status = 1))| |
	|<-------------| |		|<-------------| |
	| | |		| | |
	Figure 16: Duplicate Addresses, ROVR Hash Collision		Figure 17: Duplicate Addresses, ROVR Hash Collision
	Figure 17 shows a rare case where the registration has already moved		Figure 18 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 33, line 32 ¶		skipping to change at page 34, 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 17: Address Already Moved		Figure 18: 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 18. In case of different ESI BGP signalling		visualized by Figure 19. 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 21 over time.		create scenario Figure 22 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 35, line 4 ¶		skipping to change at page 36, 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 18: Address Move		Figure 19: 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 19. The Leaf may respond with a status of 0 to indicate		Figure 20. 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 35, line 35 ¶		skipping to change at page 36, 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 19: Address Removal		Figure 20: 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 20.		Figure 21.
	| NS(EARO, | | |		Local Local Route Remote
	| R reset) | | |		Server Leaf Reflector Leaf
	|--------------->| | |		+-------+ +---------+ +-------+ +---------+
	| | | |		| | | | | | | |
	| | Withdraw ROVR MAC Route A' |		6LN 6LBR/EVPN BGP EVPN/6LBR
	| |---------------->| |		| | | |
	| | |--------------->|		| Ethernet | | |
	| NA(EARO( | | |		| | [via BGP signaling] |
	| R reset, | | |		| | | |
	| status = 0)) | | |		| NS(EARO, | | |
	|<---------------| | |		| R reset) | | |
	| | | |		|--------------->| | |
	| retain only NCE | |		| | | |
	| | | |		| | Withdraw ROVR MAC Route A' |
			| |---------------->| |
			| | |--------------->|
			| NA(EARO( | | |
			| R reset, | | |
			| status = 0)) | | |
			|<---------------| | |
			| | | |
			| retain only NCE | |
			| | | |
	Figure 20: Route Type 2 Removal		Figure 21: 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] |
	| | | |		| | | |
	| lifetime Expired | |		| lifetime Expired | |
	| | | |		| | | |
	| | 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 21: Lifetime Elapse		Figure 22: 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 37, line 21 ¶		skipping to change at page 38, line 48 ¶
	Abegnoli, Lukas Krattiger, Jerome Tollet, and Ali Sajassi, for their		Abegnoli, Lukas Krattiger, Jerome Tollet, and Ali Sajassi, for their
	help and support.		help and support.
	11. Normative References		11. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
			[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
			Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
			DOI 10.17487/RFC3810, June 2004,
			<https://www.rfc-editor.org/info/rfc3810>.
	[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet		[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
	Control Message Protocol (ICMPv6) for the Internet		Control Message Protocol (ICMPv6) for the Internet
	Protocol Version 6 (IPv6) Specification", STD 89,		Protocol Version 6 (IPv6) Specification", STD 89,
	RFC 4443, DOI 10.17487/RFC4443, March 2006,		RFC 4443, DOI 10.17487/RFC4443, March 2006,
	<https://www.rfc-editor.org/info/rfc4443>.		<https://www.rfc-editor.org/info/rfc4443>.
	[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,		[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
	"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,		"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
	DOI 10.17487/RFC4861, September 2007,		DOI 10.17487/RFC4861, September 2007,
	<https://www.rfc-editor.org/info/rfc4861>.		<https://www.rfc-editor.org/info/rfc4861>.
	skipping to change at page 38, line 31 ¶		skipping to change at page 40, line 16 ¶
	Uttaro, J., and W. Henderickx, "A Network Virtualization		Uttaro, J., and W. Henderickx, "A Network Virtualization
	Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365,		Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365,
	DOI 10.17487/RFC8365, March 2018,		DOI 10.17487/RFC8365, March 2018,
	<https://www.rfc-editor.org/info/rfc8365>.		<https://www.rfc-editor.org/info/rfc8365>.
	[RFC8928] Thubert, P., Ed., Sarikaya, B., Sethi, M., and R. Struik,		[RFC8928] Thubert, P., Ed., Sarikaya, B., Sethi, M., and R. Struik,
	"Address-Protected Neighbor Discovery for Low-Power and		"Address-Protected Neighbor Discovery for Low-Power and
	Lossy Networks", RFC 8928, DOI 10.17487/RFC8928, November		Lossy Networks", RFC 8928, DOI 10.17487/RFC8928, November
	2020, <https://www.rfc-editor.org/info/rfc8928>.		2020, <https://www.rfc-editor.org/info/rfc8928>.
			[RFC9047] Rabadan, J., Ed., Sathappan, S., Nagaraj, K., and W. Lin,
			"Propagation of ARP/ND Flags in an Ethernet Virtual
			Private Network (EVPN)", RFC 9047, DOI 10.17487/RFC9047,
			June 2021, <https://www.rfc-editor.org/info/rfc9047>.
	[UNICAST-LOOKUP]		[UNICAST-LOOKUP]
	Thubert, P. and E. Levy-Abegnoli, "IPv6 Neighbor Discovery		Thubert, P. and E. Levy-Abegnoli, "IPv6 Neighbor Discovery
	Unicast Lookup", Work in Progress, Internet-Draft, draft-		Unicast Lookup", Work in Progress, Internet-Draft, draft-
	thubert-6lo-unicast-lookup-00, 25 January 2019,		thubert-6lo-unicast-lookup-02, 8 November 2021,
	<https://datatracker.ietf.org/doc/html/draft-thubert-6lo-		<https://datatracker.ietf.org/doc/html/draft-thubert-6lo-
	unicast-lookup-00>.		unicast-lookup-02>.
			[I-D.thubert-6lo-multicast-registration]
			Thubert, P., "IPv6 Neighbor Discovery Multicast Address
			Registration", Work in Progress, Internet-Draft, draft-
			thubert-6lo-multicast-registration-02, 8 October 2021,
			<https://datatracker.ietf.org/doc/html/draft-thubert-6lo-
			multicast-registration-02>.
	12. Informative References		12. Informative References
	[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,		[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
	Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,		Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
	JP., and R. Alexander, "RPL: IPv6 Routing Protocol for		JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
	Low-Power and Lossy Networks", RFC 6550,		Low-Power and Lossy Networks", RFC 6550,
	DOI 10.17487/RFC6550, March 2012,		DOI 10.17487/RFC6550, March 2012,
	<https://www.rfc-editor.org/info/rfc6550>.		<https://www.rfc-editor.org/info/rfc6550>.
	[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] Przygienda, T., Sharma, A., Thubert, P., Rijsman, B., and		[RIFT] Sharma, A., Thubert, P., Rijsman, B., and D. Afanasiev,
	D. Afanasiev, "RIFT: Routing in Fat Trees", Work in		"RIFT: Routing in Fat Trees", Work in Progress, Internet-
	Progress, Internet-Draft, draft-ietf-rift-rift-12, 26 May		Draft, draft-ietf-rift-rift-13, 12 July 2021,
	2020, <https://datatracker.ietf.org/doc/html/draft-ietf-		<https://datatracker.ietf.org/doc/html/draft-ietf-rift-
	rift-rift-12>.		rift-13>.
	[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. 53 change blocks.
	124 lines changed or deleted		226 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/