< draft-thubert-6man-ipv6-over-wireless-05.txt		draft-thubert-6man-ipv6-over-wireless-06.txt >
	6MAN P. Thubert, Ed.		6MAN P. Thubert, Ed.
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Intended status: Standards Track 31 March 2020		Intended status: Standards Track 1 June 2020
	Expires: 2 October 2020		Expires: 3 December 2020
	IPv6 Neighbor Discovery on Wireless Networks		IPv6 Neighbor Discovery on Wireless Networks
	draft-thubert-6man-ipv6-over-wireless-05		draft-thubert-6man-ipv6-over-wireless-06
	Abstract		Abstract
	This document describes how the original IPv6 Neighbor Discovery and		This document describes how the original IPv6 Neighbor Discovery and
	Wireless ND (WiND) can be applied on various abstractions of wireless		Wireless ND (WiND) can be applied on various abstractions of wireless
	media.		media.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 1, line 32 ¶		skipping to change at page 1, line 32 ¶
	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 2 October 2020.		This Internet-Draft will expire on 3 December 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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 Simplified BSD License text
	as described in Section 4.e of the Trust Legal Provisions and are		as 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 Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. IPv6 ND, Wireless ND and ND-Proxies . . . . . . . . . . . . . 4		3. ND-Classic, Wireless ND and ND-Proxies . . . . . . . . . . . 4
	4. IP Models . . . . . . . . . . . . . . . . . . . . . . . . . . 6		4. IP Models . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4.1. Physical Broadcast Domain . . . . . . . . . . . . . . . . 6		4.1. Physical Broadcast Domain . . . . . . . . . . . . . . . . 6
	4.2. Link-Layer Broadcast Emulations . . . . . . . . . . . . . 7		4.2. Link Layer Broadcast Emulations . . . . . . . . . . . . . 7
	4.3. Mapping the IPv6 link Abstraction . . . . . . . . . . . . 8		4.3. Mapping the IPv6 link Abstraction . . . . . . . . . . . . 9
	4.4. Mapping the IPv6 subnet Abstraction . . . . . . . . . . . 9		4.4. Mapping the IPv6 subnet Abstraction . . . . . . . . . . . 10
	5. Wireless Neighbor Discovery . . . . . . . . . . . . . . . . . 10		5. Wireless Neighbor Discovery . . . . . . . . . . . . . . . . . 10
	5.1. Introduction to Wireless ND . . . . . . . . . . . . . . . 10		5.1. Introduction to Wireless ND . . . . . . . . . . . . . . . 11
	5.2. links and Link-Local Addresses . . . . . . . . . . . . . 11		5.2. links and Link-Local Addresses . . . . . . . . . . . . . 12
	5.3. subnets and Global Addresses . . . . . . . . . . . . . . 11		5.3. subnets and Global Addresses . . . . . . . . . . . . . . 12
	6. WiND Applicability . . . . . . . . . . . . . . . . . . . . . 12		6. WiND Applicability . . . . . . . . . . . . . . . . . . . . . 13
	6.1. Case of LPWANs . . . . . . . . . . . . . . . . . . . . . 13		6.1. Case of LPWANs . . . . . . . . . . . . . . . . . . . . . 14
	6.2. Case of Infrastructure BSS and ESS . . . . . . . . . . . 13		6.2. Case of Infrastructure BSS and ESS . . . . . . . . . . . 14
	6.3. Case of Mesh Under Technologies . . . . . . . . . . . . . 15		6.3. Case of Mesh Under Technologies . . . . . . . . . . . . . 15
	6.4. Case of DMB radios . . . . . . . . . . . . . . . . . . . 15		6.4. Case of DMB radios . . . . . . . . . . . . . . . . . . . 16
	6.4.1. Using IPv6 ND only . . . . . . . . . . . . . . . . . 15		6.4.1. Using ND-Classic only . . . . . . . . . . . . . . . . 16
	6.4.2. Using Wireless ND . . . . . . . . . . . . . . . . . . 15		6.4.2. Using Wireless ND . . . . . . . . . . . . . . . . . . 16
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 18		8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
	10. Normative References . . . . . . . . . . . . . . . . . . . . 18		10. Normative References . . . . . . . . . . . . . . . . . . . . 19
	11. Informative References . . . . . . . . . . . . . . . . . . . 19		11. Informative References . . . . . . . . . . . . . . . . . . . 20
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23
	1. Introduction		1. Introduction
	IEEE STD. 802.1 [IEEEstd8021] Ethernet Bridging provides an efficient		[IEEE Std. 802.1] Ethernet Bridging provides an efficient and
	and reliable broadcast service for wired networks; applications and		reliable broadcast service for wired networks; applications and
	protocols have been built that heavily depend on that feature for		protocols have been built that heavily depend on that feature for
	their core operation.		their core operation. Unfortunately, Low-Power Lossy Networks (LLNs)
			and Wireless Local Area Networks (WLANs) generally do not benefit
	Unfortunately, Low-Power Lossy Networks (LLNs) and Wireless Local		from the same reliable and cheap broadcast capabilities as Ethernet
	Area Networks (WLANs) generally do not benefit from the same reliable		links.
	and cheap broadcast capabilities as Ethernet links. As opposed to
	unicast transmissions, the broadcast transmissions over wireless
	links are not subject to automatic retries (ARQ) and can be very
	unreliable. Reducing the speed at the PHY layer for broadcast
	transmissions can increase the reliability, at the expense of a
	higher relative cost of broadcast on the overall available bandwidth.
	As a result, protocols designed for bridged networks that rely on
	broadcast transmissions often exhibit disappointing behaviours when
	employed unmodified on a local wireless medium (see
	[MCAST-PROBLEMS]).
	Wi-Fi [IEEEstd80211] Access Points (APs) deployed in an Extended
	Service Set (ESS) act as Ethernet Bridges [IEEEstd8021] between the
	wireless stations (STA) and the wired backbone. As opposed to the
	classical Transparent (aka Learning) Bridge operation that installs
	the forwarding state reactively to traffic, the bridging state in the
	AP is established proactively, at the time of association. This
	protects the wireless medium against broadcast-intensive Transparent
	Bridging lookups. In other words, the association process registers
	the Link-Layer (MAC) Address of the STA to the AP. The AP maintains
	the full list of associated addresses and does not forward over the
	radio the broadcast lookups for destinations that are not there.
	In the case of Ethernet LANs as well as most WLANs and Low-Power		As opposed to unicast transmissions, the broadcast transmissions over
	Personal Area Networks (LoWPANs), the Network-Layer multicast		wireless links are not subject to automatic retries (ARQ) and can be
	operation is typically implemented as a Link-Layer broadcast for the		very unreliable. Reducing the speed at the physical (PHY) layer for
	lack of an adapted Link-Layer multicast operation. That Link-Layer		broadcast transmissions can increase the reliability, at the expense
	multicast operation would need to handle a possibly very large number		of a higher relative cost of broadcast on the overall available
	of groups and it was easier to simply broadcast all the Network-Layer		bandwidth. As a result, protocols designed for bridged networks that
	multicast packets.		rely on broadcast transmissions often exhibit disappointing
			behaviours when employed unmodified on a local wireless medium (see
			[MCAST PROBLEMS]).
	Like Transparent Bridging, the IPv6 [RFC8200] Neighbor Discovery		Like Transparent Bridging, the IPv6 [RFC8200] Neighbor Discovery
	[RFC4861] [RFC4862] Protocol (IPv6 ND) is reactive, based on on-		[RFC4861] [RFC4862] Protocol (ND-Classic) is reactive, and relies on
	demand multicast transmissions to locate an on-link correspondent and		on-demand Network Layer multicast to locate an on-link correspondent
	ensure the uniqueness of an IPv6 address. On wireless, the packets		(Address Resolution, AR) and ensure the uniqueness of an IPv6 address
	are broadcasted, meaning that they are both expensive and unreliable.		(Duplicate Address Detection, DAD). On Ethernet LANs and most WLANs
			and Low-Power Personal Area Networks (LoWPANs), the Network Layer
			multicast operation is typically implemented as a Link Layer
			broadcast for the lack of an adapted and scalable Link Layer
			multicast operation.
			It results that on wireless, an ND-Classic multicast message is
			typically broadcasted. So even though there are very few nodes
			subscribed to the Network Layer multicast group, and there is at most
			one intended Target, the broadcast is received by many wireless nodes
			over the whole subnet (e.g., the ESS fabric). And yet, the broadcast
			transmission being unreliable, the intended Target may effectively
			have missed the packet.
	On paper, a Wi-Fi station must keep its radio turned on to listen to		On paper, a Wi-Fi station must keep its radio turned on to listen to
	the periodic series of broadcast frames, which for the most part will		the periodic series of broadcast frames, which for the most part will
	be dropped when they reach Network-Layer. In order to avoid this		be dropped when they reach Network Layer. In order to avoid this
	waste of energy and increase its battery life, a typical battery-		waste of energy and increase its battery life, a typical battery-
	operated device such as an IoT sensor or a smartphone will blindly		operated device such as an IoT sensor or a smartphone will blindly
	ignore a ratio of the broadcasts, making IPv6 ND operations even less		ignore a ratio of the broadcasts, making ND-Classic operations even
	reliable.		less reliable.
	It results that an IPv6 ND multicast message is processed by many of		Wi-Fi [IEEE Std. 802.11] Access Points (APs) deployed in an Extended
	the wireless nodes over the whole subnet (e.g., the ESS fabric)		Service Set (ESS) act as [IEEE Std. 802.1] bridges between the
	though there are very few nodes subscribed to the multicast group,		wireless stations (STA) and the wired backbone. As opposed to the
	and at most one intended target. Yet, the packet may be missed by		classical Transparent (aka Learning) Bridge operation that installs
	the intended target.		the forwarding state reactively to traffic, the bridging state in the
			AP is established proactively, at the time of association. This
			protects the wireless medium against broadcast-intensive Transparent
			Bridging lookups. The association process registers the Link Layer
			(MAC) Address (LLA) of the STA to the AP proactively, i.e., before it
			is needed. The AP maintains the list of the associated addresses and
			blocks the lookups for destinations that are not registered. This
			solves the broadcast issue for the Link Layer lookups, but the
			Network Layer problem remains.
	Though IPv6 ND was the state of the art when designed for an Ethernet		Though ND-Classic was the state of the art when designed for an
	wire at the end of the twentieth century, it must be reevaluated for		Ethernet wire at the end of the twentieth century, it must be
	the new technologies, such as wireless and overlays, that evolved		reevaluated for the new technologies, such as wireless and overlays,
	since then. This document discusses the applicability of IPv6 ND		that evolved since then. This document discusses the applicability
	over wireless links, as compared with routing-based alternatives such		of ND-Classic over wireless links, as compared with routing-based
	as prefix-per node and multi-link subnets (MLSN), and with Wireless		alternatives such as prefix-per node and multi-link subnets (MLSN),
	ND (WiND), that is similar to the Wi-Fi association and reduces the		and with Wireless ND (WiND), that is similar to the Wi-Fi association
	need for Network-Layer multicast.		and reduces the need for Network Layer multicast.
	2. Acronyms		2. Acronyms
	This document uses the following abbreviations:		This document uses the following abbreviations:
	6BBR: 6LoWPAN Backbone Router		6BBR: 6LoWPAN Backbone Router
	6LN: 6LoWPAN Node		6LN: 6LoWPAN Node
	6LR: 6LoWPAN Router		6LR: 6LoWPAN Router
	ARO: Address Registration Option		ARO: Address Registration Option
	DAC: Duplicate Address Confirmation		DAC: Duplicate Address Confirmation
	skipping to change at page 4, line 35 ¶		skipping to change at page 4, line 35 ¶
	NDP: Neighbor Discovery Protocol		NDP: Neighbor Discovery Protocol
	NS: Neighbor Solicitation		NS: Neighbor Solicitation
	RPL: IPv6 Routing Protocol for LLNs		RPL: IPv6 Routing Protocol for LLNs
	RA: Router Advertisement		RA: Router Advertisement
	RS: Router Solicitation		RS: Router Solicitation
	VLAN: Virtual Local Area Network		VLAN: Virtual Local Area Network
	WiND: Wireless Neighbor Discovery		WiND: Wireless Neighbor Discovery
	WLAN: Wireless Local Area Network		WLAN: Wireless Local Area Network
	WPAN: Wireless Personal Area Network		WPAN: Wireless Personal Area Network
	3. IPv6 ND, Wireless ND and ND-Proxies		3. ND-Classic, Wireless ND and ND-Proxies
	The IPv6 ND Neighbor Solicitation (NS) [RFC4861] message is used as a		The ND-Classic Neighbor Solicitation (NS) [RFC4861] message is used
	multicast IP packet for Address Resolution (AR) and Duplicate Address		as a multicast IP packet for Address Resolution (AR) and Duplicate
	Setection (DAD) [RFC4862]. In those cases, the NS message is sent at		Address Setection (DAD) [RFC4862]. In those cases, the NS message is
	the Network Layer to a Solicited-Node Multicast Address (SNMA)		sent at the Network Layer to a Solicited-Node Multicast Address
	[RFC4291] and should in theory only reach a very small group of		(SNMA) [RFC4291] and should in theory only reach a very small group
	nodes. Those messages are generated individually for each address,		of nodes. Those messages are generated individually for each
	and may occur when a node joins the network, moves, or wakes up and		address, and may occur when a node joins the network, moves, or wakes
	reconnects to the network.		up and reconnects to the network.
	DAD was designed for the efficient broadcast operation of Ethernet.		DAD was designed for the efficient broadcast operation of Ethernet.
	Experiments show that DAD often fails to discover the duplication of		Experiments show that DAD often fails to discover the duplication of
	IPv6 addresses in large wireless access networks [DAD-ISSUES]. In		IPv6 addresses in large wireless access networks [DAD ISSUES]. In
	practice, IPv6 addresses very rarely conflict, not because the		practice, IPv6 addresses very rarely conflict, not because the
	address duplications are detected and resolved by the DAD operation,		address duplications are detected and resolved by the DAD operation,
	but thanks to the entropy of the 64-bit Interface IDs (IIDs) that		but thanks to the entropy of the 64-bit Interface IDs (IIDs) that
	makes a collision quasi-impossible for randomized IIDs.		makes a collision quasi-impossible for randomized IIDs.
	IPv6 ND Address Lookups and DADs over a very large fabric can		ND-Classic Address Lookups and DADs over a very large fabric can
	generate hundreds of broadcasts per second. If the broadcasts were		generate hundreds of broadcasts per second. If the broadcasts were
	blindly copied over Wi-Fi, the ND-related multicast traffic could		blindly copied over Wi-Fi, the ND-related multicast traffic could
	consume enough bandwidth to cause a substantial degradation to the		consume enough bandwidth to cause a substantial degradation to the
	unicast service [MCAST-EFFICIENCY]. To protect their bandwidth, some		unicast service [MCAST EFFICIENCY]. To protect their bandwidth, some
	networks throttle ND-related broadcasts, which reduces the capability		networks throttle ND-related broadcasts, which reduces the capability
	for the ND protocol to operate as expected.		for the ND protocol to operate as expected.
	This problem can be alleviated by reducing the size of the broadcast		This problem can be alleviated by reducing the size of the broadcast
	domain that encompasses wireless access links. This has been done in		domain that encompasses wireless access links. This has been done in
	the art of IP subnetting by partitioning the subnets and by routing		the art of IP subnetting by partitioning the subnets and by routing
	between them, at the extreme by assigning a /64 prefix to each		between them, at the extreme by assigning a /64 prefix to each
	wireless node (see [RFC8273]).		wireless node (see [RFC8273]).
	Another way to split the broadcast domain within a subnet is to proxy		Another way to split the broadcast domain within a subnet is to proxy
	at the boundary of the wired and wireless domains the Network-Layer		at the boundary of the wired and wireless domains the Network Layer
	protocols that rely on Link-Layer broadcast operations. For		protocols that rely on Link Layer broadcast operations. For
	instance, IEEE 802.11 [IEEEstd80211] recommends to deploy proxy-ARP		instance, [IEEE Std. 802.11] recommends to deploy proxies for the
	(IPv4) and proxy-ND (IPv6) functions at the Access Points (APs). But		IPv4 Address Resolution Protocl (ARP)) and IPv6 Neighbor Discosvery
	proxying ND requires the full list of the IPv6 addresses for which		functions at the Access Points (APs). But proxying ND requires the
	proxying is provided. Forming and maintaining that knowledge a hard		full list of the IPv6 addresses for which proxying is provided.
	problem in the general case of radio connectivity, which keeps		Forming and maintaining that knowledge a hard problem in the general
	changing with movements and other variations in the environment.		case of radio connectivity, which keeps changing with movements and
			other variations in the environment.
	[SAVI] suggests to discover the addresses by snooping the IPV6 ND		[SAVI] suggests to discover the addresses by snooping the ND-Classic
	protocol, but that can also be unreliable. An IPv6 address may not		protocol, but that can also be unreliable. An IPv6 address may not
	be discovered immediately due to a packet loss. It may never be		be discovered immediately due to a packet loss. It may never be
	discovered in the case of a "silent" node that is not currently using		discovered in the case of a "silent" node that is not currently using
	one of its addresses, e.g., a printer that waits in wake-on-lan		one of its addresses, e.g., a printer that waits in wake-on-lan
	state. A change of anchor, e.g. due to a movement, may be missed or		state. A change of anchor, e.g. due to a movement, may be missed or
	misordered, leading to unreliable connectivity and an incomplete list		misordered, leading to unreliable connectivity and an incomplete list
	of IPv6 addresses to be proxied for.		of IPv6 addresses to be proxied for.
	Wireless ND (WiND) introduces a new approach to IPv6 ND that is		Wireless ND (WiND) introduces a new approach to IPv6 Neighbor
	designed to apply to the WLANs and LoWPANs types of networks. On the		Discovery that is designed to apply to the WLANs and LoWPANs types of
	one hand, WiND avoids the use of broadcast operation for DAD and AR,		networks, as well as other Non-Broadcast Multi-Access (NBMA) networks
	and on the other hand, WiND supports use cases where subnet and Link-		such as Data-Center overlays. WiND applies routing inside the
	Layer domains are not congruent, which is common in those types of		subnets, which enables to form potentially large MLSNs without
	networks unless a specific Link-Layer emulation is provided.		creating a large broadcast domain at the Link Layer.
	WiND applies routing inside the subnets, which enables Multilink		In a fashion similar to a Wi-Fi Association, IPv6 Hosts register
	subnets. Hosts register their addresses to their serving routers		their addresses to their serving router(s), using [RFC8505]. With
	with [RFC8505]. With the registration, routers have a complete		the registration, the routers have a complete knowledge of the hosts
	knowledge of the hosts they serve and in return, hosts obtain routing		they serve and in return, hosts obtain routing services for their
	services for their registered addresses. The registration is		registered addresses. The registration is abstract to the routing
	abstract to the routing protocol, and it can be protected to prevent		service, and it can be protected to prevent impersonation attacks
	impersonation attacks with [ADDR-PROTECT].		with [ADDR PROTECT].
	The routing service can be a simple reflexion in a Hub-and-Spoke		The routing service can be a simple reflexion in a Hub-and-Spoke
	subnet that emulates an IEEE Std. 802.11 Infrastructure BSS at the		subnet that emulates an IEEE Std. 802.11 Infrastructure BSS at the
	Network Layer. It can also be a full-fledge routing protocol, in		Network Layer. It can also be a full-fledge routing protocol, in
	particular RPL [RFC6550] that was designed to adapt to various LLNs		particular RPL [RFC6550], which is designed to adapt to various LLNs
	such as WLAN and WPAN radio meshes with the concept of Objective		such as WLAN and WPAN radio meshes. Finally, the routing service can
	Function. Finally, the routing service can also be ND proxy that		also be an ND proxy that emulates an IEEE Std. 802.11 Infrastructure
	emulates an IEEE Std. 802.11 Infrastructure ESS at the Network Layer,		ESS at the Network Layer, as specified in the IPv6 Backbone Router
	as specified in the IPv6 Backbone Router [BB-ROUTER].		[BB ROUTER].
	More details on WiND can be found in Section 5.1.		On the one hand, WiND avoids the use of broadcast operation for DAD
			and AR, and on the other hand, WiND supports use cases where subnet
			and Link Layer domains are not congruent, which is common in wireless
			networks unless a specific Link Layer emulation is provided. More
			details on WiND can be found in Section 5.1.
	4. IP Models		4. IP Models
	4.1. Physical Broadcast Domain		4.1. Physical Broadcast Domain
	At the physical (PHY) Layer, a broadcast domain is the set of nodes		At the physical (PHY) Layer, a broadcast domain is the set of nodes
	that may receive a datagram that one sends over an interface, in		that may receive a transmission that one sends over an interface, in
	other words the set of nodes in range of radio transmission. This		other words the set of nodes in range of the radio transmission.
	set can comprise a single peer on a serial cable used as point-to-		This set can comprise a single peer on a serial cable used as point-
	point (P2P) link. It may also comprise multiple peer nodes on a		to-point (P2P) link. It may also comprise multiple peer nodes on a
	broadcast radio or a shared physical resource such as the legacy		broadcast radio or a shared physical resource such as the Ethernet
	Ethernet yellow wire for which IPv6 ND was initially designed.		wires and hubs for which ND-Classic was initially designed.
	On WLAN and LoWPAN radios, the physical broadcast domain is defined		On WLAN and LoWPAN radios, the physical broadcast domain is defined
	by a particular transmitter, as the set of nodes that can receive		relative to a particular transmitter, as the set of nodes that can
	what this transmitter is sending. Literally every datagram defines		receive what this transmitter is sending. Literally every frame
	its own broadcast domain since the chances of reception of a given		defines its own broadcast domain since the chances of reception of a
	datagram are statistical. In average and in stable conditions, the		given frame are statistical. In average and in stable conditions,
	broadcast domain of a particular node can be still be seen as mostly		the broadcast domain of a particular node can be still be seen as
	constant and can be used to define a closure of nodes on which an		mostly constant and can be used to define a closure of nodes on which
	upper-layer abstraction can be built.		an upper Layer abstraction can be built.
	A PHY-layer communication can be established between 2 nodes if their		A PHY Layer communication can be established between two nodes if the
	physical broadcast domains overlap. On WLAN and LoWPAN radios, MC		physical broadcast domains of their unicast transmissions overlap.
	property is usually reflexive, meaning that if B can receive a		On WLAN and LoWPAN radios, that relation is usually not reflexive,
	datagram from A, then A can receive a datagram from B. But there can		since nodes disable the reception when they transmit; still they may
	be asymmetries due to power levels, interferers near one of the		retain a copy of the transmitted frame, so it can be seen as
	receivers, or differences in the quality of the hardware (e.g.,		reflexive at the MAC Layer. It is often symmetric, meaning that if B
			can receive a frame from A, then A can receive a frame from B. But
			there can be asymmetries due to power levels, interferers near one of
			the receivers, or differences in the quality of the hardware (e.g.,
	crystals, PAs and antennas) that may affect the balance to the point		crystals, PAs and antennas) that may affect the balance to the point
	that the connectivity becomes mostly uni-directional, e.g., A to B		that the connectivity becomes mostly uni-directional, e.g., A to B
	but practically not B to A.		but practically not B to A.
	It takes a particular effort to place a set of devices in a fashion		It takes a particular effort to place a set of devices in a fashion
	that all their physical broadcast domains fully overlap, and that		that all their physical broadcast domains fully overlap, and that
	situation can not be assumed in the general case. In other words,		specific situation can not be assumed in the general case. In other
	the property of radio connectivity is generally not transitive,		words, the relation of radio connectivity is generally not
	meaning that A in range with B and B in range with C does not		transitive, meaning that A in range with B and B in range with C does
	necessarily imply that A is in range with C.		not necessarily imply that A is in range with C.
	4.2. Link-Layer Broadcast Emulations		4.2. Link Layer Broadcast Emulations
	We call Direct MAC Broadcast (DMB) the transmission mode where the		We call Direct MAC Broadcast (DMB) the transmission mode where the
	broadcast domain that is usable at the MAC layer is directly the		broadcast domain that is usable at the MAC layer is directly the
	physical broadcast domain. IEEE Std. 802.15.4 [IEEE802154] and IEEE		physical broadcast domain. [IEEE Std. 802.15.4] and [IEEE Std.
	Std. 802.11 OCB [IEEEstd80211] (for Out of the Context of a BSS) are		802.11] OCB (for Out of the Context of a BSS) are examples of DMB
	examples of DMB radios. This contrasts with a number of Link-Layer		radios. DMB networks provide mostly symmetric and non-transitive
	Broadcast Emulation (LLBE) schemes that are described in this		transmission. This contrasts with a number of Link Layer Broadcast
	section.		Emulation (LLBE) schemes that are described in this section.
	While a physical broadcast domain is constrained to a single shared		In the case of Ethernet, while a physical broadcast domain is
	wire, Ethernet Bridging emulates the broadcast properties of that		constrained to a single shared wire, the [IEEE Std. 802.1] bridging
	wire over a whole physical mesh of Ethernet links. For the upper		function emulates the broadcast properties of that wire over a whole
	layer, the qualities of the shared wire are essentially conserved,		physical mesh of Ethernet links. For the upper layer, the qualities
	with a reliable and cheap broadcast operation over a closure of nodes		of the shared wire are essentially conserved, with a reliable and
	defined by their connectivity to the emulated wire.		cheap broadcast operation over a transitive closure of nodes defined
			by their connectivity to the emulated wire.
	In large switched fabrics, overlay techniques enable a limited		In large switched fabrics, overlay techniques enable a limited
	connectivity between nodes that are known to a Map Resolver. The		connectivity between nodes that are known to a Map Resolver. The
	emulated broadcast domain is configured to the system, e.g., with a		emulated broadcast domain is configured to the system, e.g., with a
	VXLAN network identifier (VNID). Broadcast operations on the overlay		VXLAN network identifier (VNID). Broadcast operations on the overlay
	can be emulated but can become very expensive, and it makes sense to		can be emulated but can become very expensive, and it makes sense to
	proactively install the relevant state in the mapping server as		proactively install the relevant state in the mapping server as
	opposed to rely on reactive broadcast lookups.		opposed to rely on reactive broadcast lookups to do so.
	An IEEE Std. 802.11 Infrastructure Basic Service Set (BSS) also		An [IEEE Std. 802.11] Infrastructure Basic Service Set (BSS) also
	provides a closure of nodes as defined by the broadcast domain of a		provides a transitive closure of nodes as defined by the broadcast
	central AP. The AP relays both unicast and broadcast packets and		domain of a central AP. The AP relays both unicast and broadcast
	ensures a reflexive and transitive emulation of the shared wire		packets and provides the symmetric and transitive emulation of a
	between the associated nodes, with the capability to signal link-up/		shared wire between the associated nodes, with the capability to
	link-down to the upper layer. Within an Infrastructure BSS, the		signal link-up/link-down to the upper layer. Within a BSS, the
	physical broadcast domain of the AP serves as emulated broadcast		physical broadcast domain of the AP serves as emulated broadcast
	domain for all the nodes that are associated to the AP. Broadcast		domain for all the nodes that are associated to the AP. Broadcast
	packets are relayed by the AP and are not acknowledged. To increase		packets are relayed by the AP and are not acknowledged. To increase
	the chances that all nodes in the BSS receive the broadcast		the chances that all nodes in the BSS receive the broadcast
	transmission, AP transmits at the slowest PHY speed. This translates		transmission, AP transmits at the slowest PHY speed. This translates
	into maximum co-channel interferences for others and the longest		into maximum co-channel interferences for others and the longest
	occupancy of the medium, for a duration that can be a hundred times		occupancy of the medium, for a duration that can be a hundred times
	that of the unicast transmission of a frame of the same size. For		that of the unicast transmission of a frame of the same size.
	that reason, upper layer protocols should tend to avoid the use of
	broadcast when operating over Wi-Fi.
	In an IEEE Std. 802.11 Infrastructure Extended Service Set (ESS),		For that reason, upper layer protocols should tend to avoid the use
			of broadcast when operating over Wi-Fi. To cope with this problems,
			APs may implement strategies such as turn a broadcast into a series
			of unicast transmissions, or drop the message altogether, which may
			impact the upper layer protocols. For instance, some APs may not
			copy Router Solicitation (RS) messages under the assumption that
			there is no router across the wireless interface. This assumption
			may be correct at some point of time and may become incorrect in the
			future. Another strategy used in Wi-Fi APS is to proxy protocols
			that heavily rely on broadcast, such as the Address Resolution in ARP
			and ND-Classic, and either respond on behalf or preferably forward
			the broadcast frame as a unicast to the intended Target.
			In an [IEEE Std. 802.11] Infrastructure Extended Service Set (ESS),
	infrastructure BSSes are interconnected by a bridged network,		infrastructure BSSes are interconnected by a bridged network,
	typically running Transparent Bridging and the Spanning tree		typically running Transparent Bridging and the Spanning tree Protocol
	Protocol. In the original model of learning bridges, the forwarding		or a more advanced Layer 2 Routing (L2R) scheme. In the original
	state is set by observing the source MAC address of the frames. When		model of learning bridges, the forwarding state is set by observing
	a state is missing for a destination MAC address, the frame is		the source MAC address of the frames. When a state is missing for a
	broadcasted with the expectation that the response will populate the		destination MAC address, the frame is broadcasted with the
	state on the reverse path. This is a reactive operation, meaning		expectation that the response will populate the state on the reverse
	that the state is populated reactively to the need for to reach a		path. This is a reactive operation, meaning that the state is
	destination. It is also possible in the original model to broadcast		populated reactively to the need to reach a destination. It is also
	a gratuitous frame to advertise self throughout the bridged network,		possible in the original model to broadcast a gratuitous frame to
	and that is also a broadcast.		advertise self throughout the bridged network, and that is also a
			broadcast.
	The process of the Wi-Fi association prepares a bridging state		The process of the Wi-Fi association prepares a bridging state
	proactively at the AP, which avoids the need for a reactive broadcast		proactively at the AP, which avoids the need for a reactive broadcast
	lookup over the wireless access. In an ESS, the AP may also generate		lookup over the wireless access. In an ESS, the AP may also generate
	a gratuitous broadcast sourced at the MAC address of the STA to		a gratuitous broadcast sourced at the MAC address of the STA to
	prepare or update the state in the learning bridges so they point		prepare or update the state in the learning bridges so they point
	towards the AP for the MAC address of the STA. WiND emulates that		towards the AP for the MAC address of the STA. WiND emulates that
	proactive method at the Network-Layer for the operations of AR, DAD		proactive method at the Network Layer for the operations of AR, DAD
	and IPv6 ND proxy.		and ND proxy.
	In some instances of WLANs and LoWPANs, a Mesh-Under technology		In some instances of WLANs and LoWPANs, a Mesh-Under technology
	(e.g., a IEEE Std. 802.11s or IEEE Std. 802.15.10) provides meshing		(e.g., a IEEE Std. 802.11s or IEEE Std. 802.15.10) provides meshing
	services that are similar to bridging, and the broadcast domain is		services that are similar to bridging, and the broadcast domain is
	well-defined by the membership of the mesh. Mesh-Under emulates a		well-defined by the membership of the mesh. Mesh-Under emulates a
	broadcast domain by flooding the broadcast packets at the Link-Layer.		broadcast domain by flooding the broadcast packets at the Link Layer.
	When operating on a single frequency, this operation is known to		When operating on a single frequency, this operation is known to
	interfere with itself, and requires inter-frame gaps to dampen the		interfere with itself, and requires inter-frame gaps to dampen the
	collisions, which reduces further the amount of available bandwidth.		collisions, which reduces further the amount of available bandwidth.
	Going down the list of cases above, the cost of a broadcast		Going down the list of cases above, the cost of a broadcast
	transmissions becomes increasingly expensive, and there is a push to		transmissions becomes increasingly expensive, and there is a push to
	rethink the upper-layer protocols so as to reduce the depency on		rethink the upper Layer protocols so as to reduce the depency on
	broadcast operations.		broadcast operations.
	There again, a Link-Layer communication can be established between 2
	nodes if their Link-Layer broadcast domains overlap. In the absence
	of a Link-Layer emulation such as a Mesh-Under or an Infrastructure
	BSS, the Link-Layer broadcast domain is congruent with that of the
	PHY-layer and inherits its properties for reflexivity and
	transitivity. The IEEE Std. 802.11 OCB, which operates without a
	BSS, is an example of a network that does not have a Link-Layer
	broadcast domain emulation, which means that it will exhibit mostly
	reflexive and mostly non-transitive transmission properties.
	4.3. Mapping the IPv6 link Abstraction		4.3. Mapping the IPv6 link Abstraction
	IPv6 defines a concept of Link, link Scope and Link-Local Addresses		IPv6 defines a concept of Link, link Scope and Link-Local Addresses
	(LLA), an LLA being unique and usable only within the Scope of a		(LLA), an LLA being unique and usable only within the Scope of a
	Link. The IPv6 ND [RFC4861] DAD [RFC4862] process uses a multicast		Link. The ND-Classic [RFC4861] DAD [RFC4862] process uses a
	transmission to detect a duplicate address, which requires that the		multicast transmission to detect a duplicate address, which requires
	owner of the address is connected to the Link-Layer broadcast domain		that the owner of the address is connected to the Link Layer
	of the sender.		broadcast domain of the sender.
	On wired media, the link is often confused with the physical		On wired media, the link is often confused with the physical
	broadcast domain because both are determined by the serial cable or		broadcast domain because both are determined by the serial cable or
	the Ethernet shared wire. Ethernet Bridging reinforces that illusion		the Ethernet shared wire. Ethernet Bridging reinforces that illusion
	with a Link-Layer broadcast domain that emulates a physical broadcast		with a Link Layer broadcast domain that emulates a physical broadcast
	domain over the mesh of wires. But the difference shows on legacy		domain over the mesh of wires. But the difference shows on legacy
	Non-Broadcast Multi-Access (NBMA) networks such as ATM and Frame-		Non-Broadcast Multi-Access (NBMA) networks such as ATM and Frame-
	Relay, on shared links and on newer types of NBMA networks such as		Relay, on shared links and on newer types of NBMA networks such as
	radio and composite radio-wires networks. It also shows when private		radio and composite radio-wires networks. It also shows when private
	VLANs or Link-Layer cryptography restrict the capability to read a		VLANs or Link Layer cryptography restrict the capability to read a
	frame to a subset of the connected nodes.		frame to a subset of the connected nodes.
	In Mesh-Under and Infrastructure BSS, the IP link extends beyond the		In Mesh-Under and Infrastructure BSS, the IP link extends beyond the
	physical broadcast domain to the emulated Link-Layer broadcast		physical broadcast domain to the emulated Link Layer broadcast
	domain. Relying on Multicast for the ND operation remains feasible		domain. Relying on Multicast for the ND operation remains feasible
	but becomes highly detrimental to the unicast traffic, and more		but becomes highly detrimental to the unicast traffic, and becomes
	energy-inefficient and unreliable as the network grows.		less and less energy-efficient and reliable as the network grows.
	On DMB radios, IP links between peers come and go as the individual		On DMB radios, IP links between peers come and go as the individual
	physical broadcast domains of the transmitters meet and overlap. The		physical broadcast domains of the transmitters meet and overlap. The
	DAD operation cannot provide once and for all guarantees on the		DAD operation cannot provide once and for all guarantees over the
	broadcast domain defined by one radio transmitter if that transmitter		broadcast domain defined by one radio transmitter if that transmitter
	keeps meeting new peers on the go. The nodes may need to form new		keeps meeting new peers on the go.
	Link-Local Addresses (LLAs) to talk to one another and the scope on
	which the uniqueness of an LLA must be checked is that pair of nodes.		The scope on which the uniqueness of an LLA must be checked is each
	As long as there's no conflict, a node may use the same LLA with		new pair of nodes for the duration of their conversation. As long as
	multiple peers but it has to perform DAD with each new peer node. In		there's no conflict, a node may use the same LLA with multiple peers
			but it has to perform DAD again with each new peer. A node may need
			to form a new LLA to talk to a new peer, and multiple LLAs may be
			present in the same radio interface to talk to different peers. In
	practice, each pair of nodes defines a temporary P2P link, which can		practice, each pair of nodes defines a temporary P2P link, which can
	be modeled as a sub-interface of the radio interface.		be modeled as a sub-interface of the radio interface.
	4.4. Mapping the IPv6 subnet Abstraction		4.4. Mapping the IPv6 subnet Abstraction
	IPv6 also defines the concept of a subnet for Glocal and Unique Local		IPv6 also defines the concept of a subnet for Global and Unique Local
	Addresses. All the addresses in a subnet share the same prefix, and		Addresses (GLA and ULA). All the addresses in a subnet share the
	by extension, a node belongs to a subnet if it has with an address in		same prefix, and by extension, a node belongs to a subnet if it has
	that subnet. A subnet prefix is Globally Unique so it is sufficient		with an address in that subnet.
	to validate that an address that is formed from a subnet prefix is
	unique within that subnet to guarantee that it is globally unique.		Unless intently replicated in different locations for very specific
			purposes, a subnet prefix is unique within a routing system; for
			ULAs, the routing system is typically a limited domain, whereas for
			GLAs, it is the whole Internet.
			For that reason, it is sufficient to validate that an address that is
			formed from a subnet prefix is unique within the scope of that subnet
			to guarantee that it is globally unique within the whole routing
			system. Note that a subnet may become partitioned due to the loss of
			a wired or wireless link, so even that operation is not necessarily
			obvious, more in [DAD APPROACHES].
	The IPv6 aggregation model relies on the property that a packet from		The IPv6 aggregation model relies on the property that a packet from
	the outside of a subnet can be routed to any router that belongs to		the outside of a subnet can be routed to any router that belongs to
	the subnet, and that this router will be able to either resolve the		the subnet, and that this router will be able to either resolve the
	destination Link-Layer address and deliver the packet, or route the		destination Link Layer address and deliver the packet, or, in the
	packet to the destination within the subnet. If the subnet is known		case of an MLSN, route the packet to the destination within the
	as on-link, then any node may also resolve the destination Link-Layer		subnet.
	address and deliver the packet, but if the subnet is not on-link,
	then a host in the subnet that does not have a Neighbor Cache Entry
	(NCE) for the destination will also need to pass the packet to a
	router.
	On IEEE Std. 802.3, a subnet is often congruent with an IP link		If the subnet is known as on-link, then any node may also resolve the
	because both are determined by the physical attachment to an Ethernet		destination Link Layer address and deliver the packet, but if the
	shared wire or an IEEE Std. 802.1 bridged broadcast domain. In that		subnet is not on-link, then a host in the subnet that does not have a
	case, the connectivity over the link is transitive, the subnet can		Neighbor Cache Entry (NCE) for the destination will also need to pass
	appear as on-link, and any node can resolve a destination MAC address		the packet to a router, more in [RFC5942].
	of any other node directly using IPv6 Neighbor Discovery.
			On Ethernet, an IP subnet is often congruent with an IP link because
			both are determined by the physical attachment to a shared wire or an
			IEEE Std. 802.1 bridged domain. In that case, the connectivity over
			the link is both symmetric and transitive, the subnet can appear as
			on-link, and any node can resolve a destination MAC address of any
			other node directly using ND-Classic.
	But an IP link and an IP subnet are not always congruent. In the		But an IP link and an IP subnet are not always congruent. In the
	case of a Shared Link, individual subnets may each encompass only a		case of a Shared Link, individual subnets may each encompass only a
	subset of the nodes connected to the link. In Route-Over Multi-link		subset of the nodes connected to the link. Conversely, in Route-Over
	subnets (MLSN) [RFC4903], routers federate the links between nodes		Multi-link subnets (MLSN) [RFC4903], routers federate the links
	that belong to the subnet, the subnet is not on-link and it extends		between nodes that belong to the subnet, the subnet is not on-link
	beyond any of the federated links.		and it extends beyond any of the federated links.
	5. Wireless Neighbor Discovery		5. Wireless Neighbor Discovery
	5.1. Introduction to Wireless ND		5.1. Introduction to Wireless ND
	The DAD and AR procedures in IPv6 ND expect that a node in a subnet		The DAD and AR procedures in ND-Classic expect that a node in a
	is reachable within the broadcast domain of any other node in the		subnet is reachable within the broadcast domain of any other node in
	subnet when that other node attempts to form an address that would be		the subnet when that other node attempts to form an address that
	a duplicate or attempts to resolve the MAC address of this node.		would be a duplicate or attempts to resolve the MAC address of this
	This is why ND is only applicable for P2P and transit links, and		node. This is why ND is applicable for P2P and transit links, but
	requires extensions for other topologies.		requires extensions for more complex topologies.
	WiND [RFC6775][RFC8505][BB-ROUTER][ADDR-PROTECT] defines a new		WiND [RFC6775][RFC8505][BB ROUTER][ADDR PROTECT] defines a new
	operation for Neighbor Discovery that is based on 2 major paradigm		operation for ND that is based on 2 major paradigm changes, proactive
	changes, proactive address registration by hosts to their attachment		address registration by hosts to their attachment routers and routing
	routers and routing to host routes (/128) within the subnet. This		to host routes (/128) within the subnet. This allows WiND to avoid
	allows WiND to avoid the expectations of transit links and subnet-		the expectations of transit links and subnet-wide broadcast domains.
	wide broadcast domains.
	WiND is agnostic to the method used for Address Assignment, e.g.,		WiND is agnostic to the method used for Address Assignment, e.g.,
	Stateless Address Autoconfiguration (SLAAC) [RFC4862] or DHCPv6		Stateless Address Autoconfiguration (SLAAC) [RFC4862] or DHCPv6
	[RFC8415]. It does not change the IPv6 addressing [RFC4291] or the		[RFC8415]. It does not change the IPv6 addressing [RFC4291] or the
	current practices of assigning prefixes, typically a /64, to a		current practices of assigning prefixes, typically a /64, to a
	subnet. But the DAD operation is performed as a unicast exchange		subnet. But the DAD operation is performed as a unicast exchange
	with a central registrar, using new ND Extended Duplicate Address		with a central registrar, using new ND Extended Duplicate Address
	messages (EDAR and EDAC) [RFC6775][RFC8505]. This operation		messages (EDAR and EDAC) [RFC6775][RFC8505]. This modernizes ND for
	modernizes ND for application in overlays with Map Resolvers and		application in overlays with Map Resolvers and enables unicast
	enables unicast lookups [UNICAST-AR] for addresses registered to the		lookups [UNICAST AR] for addresses registered to the resolver.
	resolver.
	The proactive address registration is performed with a new option in		The proactive address registration is performed with a new option in
	NS/NA messages, the Extended Address Registration Option (EARO)		NS/NA messages, the Extended Address Registration Option (EARO)
	defined in [RFC8505]. This method allows to prepare and maintain the		defined in [RFC8505]. This method allows to prepare and maintain the
	host routes in the routers and avoids the reactive Address Resolution		host routes in the routers and avoids the reactive Address Resolution
	in IPv6 ND and the associated Link-Layer broadcasts transmissions.		in ND-Classic and the associated Link Layer broadcasts transmissions.
	The EARO provides information to the router that is independent to		The EARO provides information to the router that is independent to
	the routing protocol and routing can take multiple forms, from a		the routing protocol and routing can take multiple forms, from a
	traditional IGP to a collapsed Hub-and-Spoke model where only one		traditional IGP to a collapsed Hub-and-Spoke model where only one
	router owns and advertises the prefix. [RFC8505] is already		router owns and advertises the prefix. [RFC8505] is already
	referenced as the registrtaion interface to "RIFT: Routing in Fat		referenced as the registrtaion interface to "RIFT: Routing in Fat
	Trees" [I-D.ietf-rift-rift] and "RPL: IPv6 Routing Protocol for		Trees" [I-D.ietf-rift-rift] and "RPL: IPv6 Routing Protocol for
	Low-Power and Lossy Networks" [RFC6550] with [RPL-UNAWARE-LEAVES].		Low-Power and Lossy Networks" [RFC6550] with [RPL UNAWARE LEAVES].
	WiND also enables to span a subnet over an MLSN that federates edge		WiND also enables to span a subnet over an MLSN that federates edge
	wireless links with a high-speed, typically Ethernet, backbone. This		wireless links with a high-speed, typically Ethernet, backbone. This
	way, nodes can form any address they want and move freely from a		way, nodes can form any address they want and move freely from a
	wireless edge link to another, without renumbering. Backbone Routers		wireless edge link to another, without renumbering. Backbone Routers
	(6BBRs) placed along the wireless edge of the Backbone handle IPv6		(6BBRs) placed along the wireless edge of the Backbone handle IPv6
	Neighbor Discovery and forward packets over the backbone on behalf of		Neighbor Discovery and forward packets over the backbone on behalf of
	the registered nodes on the wireless edge. For instance, a 6BBR in		the registered nodes on the wireless edge.
	bridging proxy mode (more in [BB-ROUTER]) can operate as a Layer-3 AP
	to serve wireless IPv6 hosts that are Wi-Fi STAs and maintain the		For instance, a 6BBR in bridging proxy mode (more in [BB ROUTER]) can
	reachability for Global Unicast and Link-LOcal Addresses within the		operate as a Layer-3 AP to serve wireless IPv6 hosts that are Wi-Fi
	federated MLSN.		STAs and maintain the reachability for Global Unicast and Link-LOcal
			Addresses within the federated MLSN.
	5.2. links and Link-Local Addresses		5.2. links and Link-Local Addresses
	For Link-Local Addresses, DAD is typically performed between		For Link-Local Addresses, DAD is typically performed between
	communicating pairs of nodes and an NCE can be populated with a		communicating pairs of nodes and an NCE can be populated with a
	single unicast exchange. In the case of a bridging proxies, though,		single unicast exchange. In the case of a bridging proxies, though,
	the Link-Local traffic is bridged over the backbone and the DAD must		the Link-Local traffic is bridged over the backbone and the DAD must
	proxied there as well.		proxied there as well.
	For instance, in the case of Bluetooth Low Energy (BLE)		For instance, in the case of Bluetooth Low Energy (BLE)
	skipping to change at page 11, line 50 ¶		skipping to change at page 12, line 35 ¶
	interface. The DAD operation from WiND is appropriate for that use		interface. The DAD operation from WiND is appropriate for that use
	case, but the one from ND is not, because the peripheral hosts are		case, but the one from ND is not, because the peripheral hosts are
	not on the same broadcast domain.		not on the same broadcast domain.
	On the other hand, the uniqueness of Global and Unique-Local		On the other hand, the uniqueness of Global and Unique-Local
	Addresses is validated at the subnet Level, using a logical registrar		Addresses is validated at the subnet Level, using a logical registrar
	that is global to the subnet.		that is global to the subnet.
	5.3. subnets and Global Addresses		5.3. subnets and Global Addresses
	WiND extends IPv6 ND for Hub-and-Spoke (e.g., BLE) and Route-Over		WiND extends ND-Classic for Hub-and-Spoke (e.g., BLE) and Route-Over
	(e.g., RPL) Multi-link subnets (MLSNs).		(e.g., RPL) Multi-link subnets (MLSNs).
	In the Hub-and-Spoke case, each Hub-Spoke pair is a distinct IP Link,		In the Hub-and-Spoke case, each Hub-Spoke pair is a distinct IP Link,
	and a subnet can be mapped on a collection of links that are		and a subnet can be mapped on a collection of links that are
	connected to the Hub. The subnet prefix is associated to the Hub.		connected to the Hub. The subnet prefix is associated to the Hub.
	Acting as routers, the Hub advertises the prefix as not-on-link to		Acting as routers, the Hub advertises the prefix as not-on-link to
	the spokes in RA messages Prefix Information Options (PIO). Acting		the spokes in RA messages Prefix Information Options (PIO). Acting
	as hosts, the Spokes autoconfigure addresses from that prefix and		as hosts, the Spokes autoconfigure addresses from that prefix and
	register them to the Hub with a corresponding lifetime. Acting as a		register them to the Hub with a corresponding lifetime. Acting as a
	registrar, the Hub maintains a binding table of all the registered IP		registrar, the Hub maintains a binding table of all the registered IP
	addresses and rejects duplicate registrations, thus ensuring a DAD		addresses and rejects duplicate registrations, thus ensuring a DAD
	protection for a registered address even if the registering node is		protection for a registered address even if the registering node is
	sleeping. The Hub also maintains an NCE for the registered addresses		sleeping. The Hub also maintains an NCE for the registered addresses
	and can deliver a packet to any of them during their respective		and can deliver a packet to any of them during their respective
	lifetimes. It can be observed that this design builds a form of		lifetimes. It can be observed that this design builds a form of
	Network-Layer Infrastructure BSS.		Network Layer Infrastructure BSS.
	A Route-Over MLSN is considered as a collection of Hub-and-Spoke		A Route-Over MLSN is considered as a collection of Hub-and-Spoke
	where the Hubs form a connected dominating set of the member nodes of		where the Hubs form a connected dominating set of the member nodes of
	the subnet, and IPv6 routing takes place between the Hubs within the		the subnet, and IPv6 routing takes place between the Hubs within the
	subnet. A single logical registrar is deployed to serve the whole		subnet. A single logical registrar is deployed to serve the whole
	mesh.		mesh.
	The registration in [RFC8505] is abstract to the routing protocol and		The registration in [RFC8505] is abstract to the routing protocol and
	provides enough information to feed a routing protocol such as RPL as		provides enough information to feed a routing protocol such as RPL as
	specified in [RPL-UNAWARE-LEAVES]. In a degraded mode, all the Hubs		specified in [RPL UNAWARE LEAVES]. In a degraded mode, all the Hubs
	are connected to a same high speed backbone such as an Ethernet		are connected to a same high speed backbone such as an Ethernet
	bridging domain where IPv6 ND is operated. In that case, it is		bridging domain where ND-Classic is operated. In that case, it is
	possible to federate the Hub, Spoke and Backbone nodes as a single		possible to federate the Hub, Spoke and Backbone nodes as a single
	subnet, operating IPv6 ND proxy operations [BB-ROUTER] at the Hubs,		subnet, operating ND proxy operations [BB ROUTER] at the Hubs, acting
	acting as 6BBRs. It can be observed that this latter design builds a		as 6BBRs. It can be observed that this latter design builds a form
	form of Network-Layer Infrastructure ESS.		of Network Layer Infrastructure ESS.
	6. WiND Applicability		6. WiND Applicability
	WiND applies equally to P2P links, P2MP Hub-and-Spoke, Link-Layer		WiND applies equally to P2P links, P2MP Hub-and-Spoke, Link Layer
	Broadcast Domain Emulation such as Mesh-Under and Wi-Fi BSS, and		Broadcast Domain Emulation such as Mesh-Under and Wi-Fi BSS, and
	Route-Over meshes.		Route-Over meshes.
	There is an intersection where link and subnet are congruent and		There is an intersection where link and subnet are congruent and
	where both ND and WiND could apply. These includes P2P, the MAC		where both ND and WiND could apply. These includes P2P, the MAC
	emulation of a PHY broadcast domain, and the particular case of		emulation of a PHY broadcast domain, and the particular case of
	always on, fully overlapping physical radio broadcast domain. But		always on, fully overlapping physical radio broadcast domain. But
	even in those cases where both are possible, WiND is preferable vs.		even in those cases where both are possible, WiND is preferable vs.
	ND because it reduces the need of broadcast.		ND because it reduces the need of broadcast.
	This is discussed in more details in the introduction of [BB-ROUTER].		This is discussed in more details in the introduction of [BB ROUTER].
	There are also a number of practical use cases in the wireless world		There are also a number of practical use cases in the wireless world
	where links and subnets are not congruent:		where links and subnets are not congruent:
	* The IEEE Std. 802.11 infrastructure BSS enables one subnet per AP,		* The IEEE Std. 802.11 infrastructure BSS enables one subnet per AP,
	and emulates a broadcast domain at the Link-Layer. The		and emulates a broadcast domain at the Link Layer. The
	Infrastructure ESS extends that model over a backbone and		Infrastructure ESS extends that model over a backbone and
	recommends the use of an IPv6 ND proxy [IEEEstd80211] to		recommends the use of an ND proxy [IEEE Std. 802.11] to
	interoperate with Ethernet-connected nodes. WiND incorporates an		interoperate with Ethernet-connected nodes. WiND incorporates an
	ND proxy to serve that need, which was missing so far.		ND proxy to serve that need, which was missing so far.
	* BlueTooth is Hub-and-Spoke at the Link-Layer. It would make		* BlueTooth is Hub-and-Spoke at the Link Layer. It would make
	little sense to configure a different subnet between the central		little sense to configure a different subnet between the central
	and each individual peripheral node (e.g., sensor). Rather,		and each individual peripheral node (e.g., sensor). Rather,
	[RFC7668] allocates a prefix to the central node acting as router,		[RFC7668] allocates a prefix to the central node acting as router,
	and each peripheral host (acting as a host) forms one or more		and each peripheral host (acting as a host) forms one or more
	address(es) from that same prefix and registers it.		address(es) from that same prefix and registers it.
	* A typical Smartgrid networks puts together Route-Over MLSNs that		* A typical Smartgrid networks puts together Route-Over MLSNs that
	comprise thousands of IPv6 nodes. The 6TiSCH architecture		comprise thousands of IPv6 nodes. The 6TiSCH architecture
	[I-D.ietf-6tisch-architecture] presents the Route-Over model over		[I-D.ietf-6tisch-architecture] presents the Route-Over model over
	an IEEE Std. 802.15.4 Time-Slotted Channel-Hopping (TSCH)		an IEEE Std. 802.15.4 Time-Slotted Channel-Hopping (TSCH)
	skipping to change at page 14, line 5 ¶		skipping to change at page 14, line 37 ¶
	saves the steps of neighbor Discovery and enables a very efficient		saves the steps of neighbor Discovery and enables a very efficient
	stateful compression of the IPv6 header.		stateful compression of the IPv6 header.
	6.2. Case of Infrastructure BSS and ESS		6.2. Case of Infrastructure BSS and ESS
	In contrast to IPv4, IPv6 enables a node to form multiple addresses,		In contrast to IPv4, IPv6 enables a node to form multiple addresses,
	some of them temporary to elusive, and with a particular attention		some of them temporary to elusive, and with a particular attention
	paid to privacy. Addresses may be formed and deprecated		paid to privacy. Addresses may be formed and deprecated
	asynchronously to the association.		asynchronously to the association.
	Snooping protocols such as IPv6 ND and DHCPv6 and observing data		Snooping protocols such as ND-Classic and DHCPv6 and observing data
	traffic sourced at the STA provides an imperfect knowledge of the		traffic sourced at the STA provides an imperfect knowledge of the
	state of the STA at the AP. Missing a state or a transition may		state of the STA at the AP. Missing a state or a transition may
	result in the loss of connectivity for some of the addresses, in		result in the loss of connectivity for some of the addresses, in
	particular for an address that is rarely used, belongs to a sleeping		particular for an address that is rarely used, belongs to a sleeping
	node, or one in a situation of mobility. This may also result in		node, or one in a situation of mobility. This may also result in
	undesirable remanent state in the AP when the STA ceases to use an		undesirable remanent state in the AP when the STA ceases to use an
	IPv6 address while remaining associated. It results that snooping		IPv6 address while remaining associated. It results that snooping
	protocols is not a recommended technique and that it should only be		protocols is not a recommended technique and that it should only be
	used as last resort, when the WiND registration is not available to		used as last resort, when the WiND registration is not available to
	populate the state.		populate the state.
	skipping to change at page 14, line 27 ¶		skipping to change at page 15, line 15 ¶
	The recommended alternative method is to use the WiND Registration		The recommended alternative method is to use the WiND Registration
	for IPv6 Addresses. This way, the AP exposes its capability to proxy		for IPv6 Addresses. This way, the AP exposes its capability to proxy
	ND to the STA in Router Advertisement messages. In turn, the STA may		ND to the STA in Router Advertisement messages. In turn, the STA may
	request proxy ND services from the AP for all of its IPv6 addresses,		request proxy ND services from the AP for all of its IPv6 addresses,
	using the Extended Address Registration Option, which provides the		using the Extended Address Registration Option, which provides the
	following elements:		following elements:
	* The registration state has a lifetime that limits unwanted state		* The registration state has a lifetime that limits unwanted state
	remanence in the network.		remanence in the network.
	* The registration is optionally secured using [ADDR-PROTECT] to		* The registration is optionally secured using [ADDR PROTECT] to
	prevent address theft and impersonation.		prevent address theft and impersonation.
	* The registration carries a sequence number, which enables to		* The registration carries a sequence number, which enables to
	figure the order of events in a fast mobility scenario without		figure the order of events in a fast mobility scenario without
	loss of connectivity.		loss of connectivity.
	The ESS mode requires a proxy ND operation at the AP. The proxy ND		The ESS mode requires a proxy ND operation at the AP. The proxy ND
	operation must cover Duplicate Address Detection, Neighbor		operation must cover Duplicate Address Detection, Neighbor
	Unreachability Detection, Address Resolution and Address Mobility to		Unreachability Detection, Address Resolution and Address Mobility to
	transfer a role of ND proxy to the AP where a STA is associated		transfer a role of ND proxy to the AP where a STA is associated
	following the mobility of the STA.		following the mobility of the STA.
	The WiND proxy ND specification that associated to the Address		The WiND proxy ND specification that associated to the Address
	Registration is [BB-ROUTER]. With that specification, the AP		Registration is [BB ROUTER]. With that specification, the AP
	participates to the protocol as a Backbone Router, typically		participates to the protocol as a Backbone Router, typically
	operating as a bridging proxy though the routing proxy operation is		operating as a bridging proxy though the routing proxy operation is
	also possible. As a bridging proxy, the backbone router either		also possible. As a bridging proxy, the backbone router either
	replies to NS lookups with the MAC address of the STA, or preferably		replies to NS lookups with the MAC address of the STA, or preferably
	forwards the lookups to the STA as Link-Layer unicast frames to let		forwards the lookups to the STA as Link Layer unicast frames to let
	the STA answer. For the data plane, the backbone router acts as a		the STA answer. For the data plane, the backbone router acts as a
	normal AP and bridges the packets to the STA as usual. As a routing		normal AP and bridges the packets to the STA as usual. As a routing
	proxy, the backbone router replies with its own MAC address and then		proxy, the backbone router replies with its own MAC address and then
	routes to the STA at the IP layer. The routing proxy reduces the		routes to the STA at the IP layer. The routing proxy reduces the
	need to expose the MAC address of the STA on the wired side, for a		need to expose the MAC address of the STA on the wired side, for a
	better stability and scalability of the bridged fabric.		better stability and scalability of the bridged fabric.
	6.3. Case of Mesh Under Technologies		6.3. Case of Mesh Under Technologies
	The Mesh-Under provides a broadcast domain emulation with reflexive		The Mesh-Under provides a broadcast domain emulation with symmetric
	and Transitive properties and defines a transit link for IPv6		and Transitive properties and defines a transit link for IPv6
	operations. It results that the model for IPv6 operation is similar		operations. It results that the model for IPv6 operation is similar
	to that of a BSS, with the root of the mesh operating as an Access		to that of a BSS, with the root of the mesh operating as an Access
	Point does in a BSS/ESS.		Point does in a BSS/ESS.
	While it is still possible to operate IPv6 ND, the inefficiencies of		While it is still possible to operate ND-Classic, the inefficiencies
	the flooding operation make the IPv6 ND operations even less		of the flooding operation make the associated operations even less
	desirable than in a BSS, and the use of WiND is highly recommended.		desirable than in a BSS, and the use of WiND is highly recommended.
	6.4. Case of DMB radios		6.4. Case of DMB radios
	IPv6 over DMB radios uses P2P links that can be formed and maintained		IPv6 over DMB radios uses P2P links that can be formed and maintained
	when a pair of DMB radios transmitters are in range from one another.		when a pair of DMB radios transmitters are in range from one another.
	6.4.1. Using IPv6 ND only		6.4.1. Using ND-Classic only
	DMB radios do not provide MAC level broadcast emulation. An example		DMB radios do not provide MAC level broadcast emulation. An example
	of that is IEEE Std. 802.11 OCB which uses IEEE Std. 802.11 MAC/PHYs		of that is IEEE Std. 802.11 OCB which uses IEEE Std. 802.11 MAC/PHYs
	but does not provide the BSS functions.		but does not provide the BSS functions.
	It is possible to form P2P IP links between each individual pairs of		It is possible to form P2P IP links between each individual pairs of
	nodes and operate IPv6 ND over those links with Link-Local addresses.		nodes and operate ND-Classic over those links with Link-Local
	DAD must be performed for all addresses on all P2P IP links.		addresses. DAD must be performed for all addresses on all P2P IP
			links.
	If special deployment care is taken so that the physical broadcast		If special deployment care is taken so that the physical broadcast
	domains of a collection of the nodes fully overlap, then it is also		domains of a collection of the nodes fully overlap, then it is also
	possible to build an IP subnet within that collection of nodes and		possible to build an IP subnet within that collection of nodes and
	operate IPv6 ND.		operate ND-Classic.
	If an external mechanism avoids duplicate addresses and if the		If an external mechanism avoids duplicate addresses and if the
	deployment ensures the connectivity between peers, a non-transit Hub-		deployment ensures the connectivity between peers, a non-transit Hub-
	and-Spoke deployment is also possible where the Hub is the only		and-Spoke deployment is also possible where the Hub is the only
	router in the subnet and the Prefix is advertised as not on-link.		router in the subnet and the Prefix is advertised as not on-link.
	6.4.2. Using Wireless ND		6.4.2. Using Wireless ND
	Though this can be achieved with IPv6 ND, WiND is the recommended		Though this can be achieved with ND-Classic, WiND is the recommended
	approach since it uses unicast communications which are more reliable		approach since it uses unicast communications which are more reliable
	and less impacting for other users of the medium.		and less impacting for other users of the medium.
	The routers send RAs with a SLLAO at a regular period. The period		The routers send RAs with a SLLAO at a regular period. The period
	can be indicated in the RA-Interval Option [RFC6275]. If available,		can be indicated in the RA-Interval Option [RFC6275]. If available,
	the message can be transported in a compressed form in a beacon,		the message can be transported in a compressed form in a beacon,
	e.g., in OCB Basic Safety Messages (BSM) that are nominally sent		e.g., in OCB Basic Safety Messages (BSM) that are nominally sent
	every 100ms.		every 100ms.
	An active beaconing mode is possible whereby the Host sends broadcast		An active beaconing mode is possible whereby the Host sends broadcast
	skipping to change at page 17, line 8 ¶		skipping to change at page 18, line 8 ¶
	usable. Packets should be held or destroyed when the link is down.		usable. Packets should be held or destroyed when the link is down.
	P2P links may be federated in Hub-and-Spoke and then in Route-Over		P2P links may be federated in Hub-and-Spoke and then in Route-Over
	MLSNs as illustrated in Figure 2. More details on the operation of		MLSNs as illustrated in Figure 2. More details on the operation of
	WiND and RPL over the MLSN can be found in section 3.1, 3.2, 4.1 and		WiND and RPL over the MLSN can be found in section 3.1, 3.2, 4.1 and
	4.2.2 of [I-D.ietf-6tisch-architecture].		4.2.2 of [I-D.ietf-6tisch-architecture].
	6LoWPAN Node 6LR 6LBR 6BBR		6LoWPAN Node 6LR 6LBR 6BBR
	(RPL leaf) (router) (root)		(RPL leaf) (router) (root)
	| | | |		| | | |
	| 6LoWPAN ND |6LoWPAN ND+RPL | 6LoWPAN ND | IPv6 ND		| 6LoWPAN ND |6LoWPAN ND+RPL | 6LoWPAN ND | ND-Classic
	| LLN link |Route-Over mesh|Ethernet/serial| Backbone		| LLN link |Route-Over mesh|Ethernet/serial| Backbone
	| | | |		| | | |
	| IPv6 ND RS | | |		| IPv6 ND RS | | |
	|-------------->| | |		|-------------->| | |
	|-----------> | | |		|-----------> | | |
	|------------------> | |		|------------------> | |
	| IPv6 ND RA | | |		| IPv6 ND RA | | |
	|<--------------| | |		|<--------------| | |
	| | <once> | |		| | <once> | |
	| NS(EARO) | | |		| NS(EARO) | | |
	skipping to change at page 18, line 7 ¶		skipping to change at page 19, line 7 ¶
	physical broadcast domain. Cars may then operate NEMO [RFC3963] for		physical broadcast domain. Cars may then operate NEMO [RFC3963] for
	their own prefix using their address derived from the prefix of the		their own prefix using their address derived from the prefix of the
	RSU as CareOf Address.		RSU as CareOf Address.
	7. IANA Considerations		7. IANA Considerations
	This specification does not require IANA action.		This specification does not require IANA action.
	8. Security Considerations		8. Security Considerations
	This specification refers to the security sections of IPv6 ND and		This specification refers to the security sections of ND-Classic and
	WiND, respectively.		WiND, respectively.
	9. Acknowledgments		9. Acknowledgments
	Many thanks to the participants of the 6lo WG where a lot of the work		Many thanks to the participants of the 6lo WG where a lot of the work
	discussed here happened. Also ROLL, 6TiSCH, and 6LoWPAN.		discussed here happened. Also ROLL, 6TiSCH, and 6LoWPAN.
	10. Normative References		10. Normative References
	[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.		[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
	skipping to change at page 18, line 36 ¶		skipping to change at page 19, line 36 ¶
	[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>.
	[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless		[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
	Address Autoconfiguration", RFC 4862,		Address Autoconfiguration", RFC 4862,
	DOI 10.17487/RFC4862, September 2007,		DOI 10.17487/RFC4862, September 2007,
	<https://www.rfc-editor.org/info/rfc4862>.		<https://www.rfc-editor.org/info/rfc4862>.
			[RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet
			Model: The Relationship between Links and Subnet
			Prefixes", RFC 5942, DOI 10.17487/RFC5942, July 2010,
			<https://www.rfc-editor.org/info/rfc5942>.
	[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility		[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
	Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July		Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
	2011, <https://www.rfc-editor.org/info/rfc6275>.		2011, <https://www.rfc-editor.org/info/rfc6275>.
	[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", STD 86, RFC 8200,		(IPv6) Specification", STD 86, RFC 8200,
	DOI 10.17487/RFC8200, July 2017,		DOI 10.17487/RFC8200, July 2017,
	<https://www.rfc-editor.org/info/rfc8200>.		<https://www.rfc-editor.org/info/rfc8200>.
	[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.		[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
	Perkins, "Registration Extensions for IPv6 over Low-Power		Perkins, "Registration Extensions for IPv6 over Low-Power
	Wireless Personal Area Network (6LoWPAN) Neighbor		Wireless Personal Area Network (6LoWPAN) Neighbor
	Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,		Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
	<https://www.rfc-editor.org/info/rfc8505>.		<https://www.rfc-editor.org/info/rfc8505>.
	[ADDR-PROTECT]		[ADDR PROTECT]
	Thubert, P., Sarikaya, B., Sethi, M., and R. Struik,		Thubert, P., 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", Work in Progress, Internet-Draft, draft-		Lossy Networks", Work in Progress, Internet-Draft, draft-
	ietf-6lo-ap-nd-20, 9 March 2020,		ietf-6lo-ap-nd-23, 30 April 2020,
	<https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-20>.		<https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-23>.
	[BB-ROUTER]		[BB ROUTER]
	Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6		Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6
	Backbone Router", Work in Progress, Internet-Draft, draft-		Backbone Router", Work in Progress, Internet-Draft, draft-
	ietf-6lo-backbone-router-20, 23 March 2020,		ietf-6lo-backbone-router-20, 23 March 2020,
	<https://tools.ietf.org/html/draft-ietf-6lo-backbone-		<https://tools.ietf.org/html/draft-ietf-6lo-backbone-
	router-20>.		router-20>.
	11. Informative References		11. Informative References
	[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing		[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
	Architecture", RFC 4291, DOI 10.17487/RFC4291, February		Architecture", RFC 4291, DOI 10.17487/RFC4291, February
	skipping to change at page 20, line 10 ¶		skipping to change at page 21, line 18 ¶
	[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,		[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
	Richardson, M., Jiang, S., Lemon, T., and T. Winters,		Richardson, M., Jiang, S., Lemon, T., and T. Winters,
	"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",		"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
	RFC 8415, DOI 10.17487/RFC8415, November 2018,		RFC 8415, DOI 10.17487/RFC8415, November 2018,
	<https://www.rfc-editor.org/info/rfc8415>.		<https://www.rfc-editor.org/info/rfc8415>.
	[I-D.ietf-rift-rift]		[I-D.ietf-rift-rift]
	Przygienda, T., Sharma, A., Thubert, P., Rijsman, B., and		Przygienda, T., Sharma, A., Thubert, P., Rijsman, B., and
	D. Afanasiev, "RIFT: Routing in Fat Trees", Work in		D. Afanasiev, "RIFT: Routing in Fat Trees", Work in
	Progress, Internet-Draft, draft-ietf-rift-rift-11, 10		Progress, Internet-Draft, draft-ietf-rift-rift-12, 26 May
	March 2020,		2020,
	<https://tools.ietf.org/html/draft-ietf-rift-rift-11>.		<https://tools.ietf.org/html/draft-ietf-rift-rift-12>.
	[RPL-UNAWARE-LEAVES]		[RPL UNAWARE LEAVES]
	Thubert, P. and M. Richardson, "Routing for RPL Leaves",		Thubert, P. and M. Richardson, "Routing for RPL Leaves",
	Work in Progress, Internet-Draft, draft-ietf-roll-unaware-		Work in Progress, Internet-Draft, draft-ietf-roll-unaware-
	leaves-13, 17 March 2020, <https://tools.ietf.org/html/		leaves-15, 15 April 2020, <https://tools.ietf.org/html/
	draft-ietf-roll-unaware-leaves-13>.		draft-ietf-roll-unaware-leaves-15>.
	[DAD-ISSUES]		[DAD ISSUES]
	Yourtchenko, A. and E. Nordmark, "A survey of issues		Yourtchenko, A. and E. Nordmark, "A survey of issues
	related to IPv6 Duplicate Address Detection", Work in		related to IPv6 Duplicate Address Detection", Work in
	Progress, Internet-Draft, draft-yourtchenko-6man-dad-		Progress, Internet-Draft, draft-yourtchenko-6man-dad-
	issues-01, 3 March 2015, <https://tools.ietf.org/html/		issues-01, 3 March 2015, <https://tools.ietf.org/html/
	draft-yourtchenko-6man-dad-issues-01>.		draft-yourtchenko-6man-dad-issues-01>.
	[MCAST-EFFICIENCY]		[MCAST EFFICIENCY]
	Vyncke, E., Thubert, P., Levy-Abegnoli, E., and A.		Vyncke, E., Thubert, P., Levy-Abegnoli, E., and A.
	Yourtchenko, "Why Network-Layer Multicast is Not Always		Yourtchenko, "Why Network-Layer Multicast is Not Always
	Efficient At Datalink Layer", Work in Progress, Internet-		Efficient At Datalink Layer", Work in Progress, Internet-
	Draft, draft-vyncke-6man-mcast-not-efficient-01, 14		Draft, draft-vyncke-6man-mcast-not-efficient-01, 14
	February 2014, <https://tools.ietf.org/html/draft-vyncke-		February 2014, <https://tools.ietf.org/html/draft-vyncke-
	6man-mcast-not-efficient-01>.		6man-mcast-not-efficient-01>.
	[I-D.ietf-6tisch-architecture]		[I-D.ietf-6tisch-architecture]
	Thubert, P., "An Architecture for IPv6 over the TSCH mode		Thubert, P., "An Architecture for IPv6 over the TSCH mode
	of IEEE 802.15.4", Work in Progress, Internet-Draft,		of IEEE 802.15.4", Work in Progress, Internet-Draft,
	draft-ietf-6tisch-architecture-28, 29 October 2019,		draft-ietf-6tisch-architecture-28, 29 October 2019,
	<https://tools.ietf.org/html/draft-ietf-6tisch-		<https://tools.ietf.org/html/draft-ietf-6tisch-
	architecture-28>.		architecture-28>.
	[MCAST-PROBLEMS]		[MCAST PROBLEMS]
	Perkins, C., McBride, M., Stanley, D., Kumari, W., and J.		Perkins, C., McBride, M., Stanley, D., Kumari, W., and J.
	Zuniga, "Multicast Considerations over IEEE 802 Wireless		Zuniga, "Multicast Considerations over IEEE 802 Wireless
	Media", Work in Progress, Internet-Draft, draft-ietf-		Media", Work in Progress, Internet-Draft, draft-ietf-
	mboned-ieee802-mcast-problems-11, 11 December 2019,		mboned-ieee802-mcast-problems-11, 11 December 2019,
	<https://tools.ietf.org/html/draft-ietf-mboned-ieee802-		<https://tools.ietf.org/html/draft-ietf-mboned-ieee802-
	mcast-problems-11>.		mcast-problems-11>.
	[SAVI] Bi, J., Wu, J., Wang, Y., and T. Lin, "A SAVI Solution for		[SAVI] Bi, J., Wu, J., Wang, Y., and T. Lin, "A SAVI Solution for
	WLAN", Work in Progress, Internet-Draft, draft-bi-savi-		WLAN", Work in Progress, Internet-Draft, draft-bi-savi-
	wlan-18, 17 November 2019,		wlan-19, 14 May 2020,
	<https://tools.ietf.org/html/draft-bi-savi-wlan-18>.		<https://tools.ietf.org/html/draft-bi-savi-wlan-19>.
	[UNICAST-AR]		[UNICAST AR]
	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-00, 25 January 2019,
	<https://tools.ietf.org/html/draft-thubert-6lo-unicast-		<https://tools.ietf.org/html/draft-thubert-6lo-unicast-
	lookup-00>.		lookup-00>.
	[IEEE802154]		[DAD APPROACHES]
			Nordmark, E., "Possible approaches to make DAD more robust
			and/or efficient", Work in Progress, Internet-Draft,
			draft-nordmark-6man-dad-approaches-02, 19 October 2015,
			<https://tools.ietf.org/html/draft-nordmark-6man-dad-
			approaches-02>.
			[IEEE Std. 802.15.4]
	IEEE standard for Information Technology, "IEEE Std.		IEEE standard for Information Technology, "IEEE Std.
	802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)		802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)
	and Physical Layer (PHY) Specifications for Low-Rate		and Physical Layer (PHY) Specifications for Low-Rate
	Wireless Personal Area Networks".		Wireless Personal Area Networks".
	[IEEEstd80211]		[IEEE Std. 802.11]
	IEEE standard for Information Technology, "IEEE Standard		IEEE standard for Information Technology, "IEEE Standard
	for Information technology -- Telecommunications and		for Information technology -- Telecommunications and
	information exchange between systems Local and		information exchange between systems Local and
	metropolitan area networks-- Specific requirements Part		metropolitan area networks-- Specific requirements Part
	11: Wireless LAN Medium Access Control (MAC) and Physical		11: Wireless LAN Medium Access Control (MAC) and Physical
	Layer (PHY) Specifications".		Layer (PHY) Specifications".
	[IEEEstd802151]		[IEEEstd802151]
	IEEE standard for Information Technology, "IEEE Standard		IEEE standard for Information Technology, "IEEE Standard
	for Information Technology - Telecommunications and		for Information Technology - Telecommunications and
	skipping to change at page 21, line 42 ¶		skipping to change at page 23, line 10 ¶
	Metropolitan Area Networks - Specific Requirements. - Part		Metropolitan Area Networks - Specific Requirements. - Part
	15.1: Wireless Medium Access Control (MAC) and Physical		15.1: Wireless Medium Access Control (MAC) and Physical
	Layer (PHY) Specifications for Wireless Personal Area		Layer (PHY) Specifications for Wireless Personal Area
	Networks (WPANs)".		Networks (WPANs)".
	[IEEEstd802154]		[IEEEstd802154]
	IEEE standard for Information Technology, "IEEE Standard		IEEE standard for Information Technology, "IEEE Standard
	for Local and metropolitan area networks -- Part 15.4:		for Local and metropolitan area networks -- Part 15.4:
	Low-Rate Wireless Personal Area Networks (LR-WPANs)".		Low-Rate Wireless Personal Area Networks (LR-WPANs)".
	[IEEEstd8021]		[IEEE Std. 802.1]
	IEEE standard for Information Technology, "IEEE Standard		IEEE standard for Information Technology, "IEEE Standard
	for Information technology -- Telecommunications and		for Information technology -- Telecommunications and
	information exchange between systems Local and		information exchange between systems Local and
	metropolitan area networks Part 1: Bridging and		metropolitan area networks Part 1: Bridging and
	Architecture".		Architecture".
	Author's Address		Author's Address
	Pascal Thubert (editor)		Pascal Thubert (editor)
	Cisco Systems, Inc		Cisco Systems, Inc
	Building D		Building D
	45 Allee des Ormes - BP1200		45 Allee des Ormes - BP1200
	06254 Mougins - Sophia Antipolis		06254 Mougins - Sophia Antipolis
	France		France
	Phone: +33 497 23 26 34		Phone: +33 497 23 26 34
	Email: pthubert@cisco.com		Email: pthubert@cisco.com
End of changes. 98 change blocks.
	296 lines changed or deleted		333 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/