< draft-thubert-6man-ipv6-over-wireless-04.txt		draft-thubert-6man-ipv6-over-wireless-05.txt >
	6MAN P. Thubert, Ed.		6MAN P. Thubert, Ed.
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Intended status: Informational September 26, 2019		Intended status: Standards Track 31 March 2020
	Expires: March 29, 2020		Expires: 2 October 2020
	IPv6 Neighbor Discovery on Wireless Networks		IPv6 Neighbor Discovery on Wireless Networks
	draft-thubert-6man-ipv6-over-wireless-04		draft-thubert-6man-ipv6-over-wireless-05
	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 March 29, 2020.		This Internet-Draft will expire on 2 October 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 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		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Simplified BSD License text
	include Simplified BSD License text as described in Section 4.e of		as described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		provided without warranty as described in the Simplified BSD License.
	described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. IP Models . . . . . . . . . . . . . . . . . . . . . . . . . . 6		3. IPv6 ND, Wireless ND and ND-Proxies . . . . . . . . . . . . . 4
	3.1. Physical Broadcast Domain . . . . . . . . . . . . . . . . 6		4. IP Models . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.2. MAC-Layer Broadcast Emulations . . . . . . . . . . . . . 7		4.1. Physical Broadcast Domain . . . . . . . . . . . . . . . . 6
	3.3. Mapping the IPv6 Link Abstraction . . . . . . . . . . . . 8		4.2. Link-Layer Broadcast Emulations . . . . . . . . . . . . . 7
	3.4. Mapping the IPv6 Subnet Abstraction . . . . . . . . . . . 9		4.3. Mapping the IPv6 link Abstraction . . . . . . . . . . . . 8
	4. Wireless ND . . . . . . . . . . . . . . . . . . . . . . . . . 10		4.4. Mapping the IPv6 subnet Abstraction . . . . . . . . . . . 9
	4.1. Introduction to WiND . . . . . . . . . . . . . . . . . . 10		5. Wireless Neighbor Discovery . . . . . . . . . . . . . . . . . 10
	4.2. Links and Link-Local Addresses . . . . . . . . . . . . . 11		5.1. Introduction to Wireless ND . . . . . . . . . . . . . . . 10
	4.3. Subnets and Global Addresses . . . . . . . . . . . . . . 12		5.2. links and Link-Local Addresses . . . . . . . . . . . . . 11
	5. WiND Applicability . . . . . . . . . . . . . . . . . . . . . 12		5.3. subnets and Global Addresses . . . . . . . . . . . . . . 11
	5.1. Case of LPWANs . . . . . . . . . . . . . . . . . . . . . 13		6. WiND Applicability . . . . . . . . . . . . . . . . . . . . . 12
	5.2. Case of Infrastructure BSS and ESS . . . . . . . . . . . 13		6.1. Case of LPWANs . . . . . . . . . . . . . . . . . . . . . 13
	5.3. Case of Mesh Under Technologies . . . . . . . . . . . . . 14		6.2. Case of Infrastructure BSS and ESS . . . . . . . . . . . 13
	5.4. Case of DMC radios . . . . . . . . . . . . . . . . . . . 15		6.3. Case of Mesh Under Technologies . . . . . . . . . . . . . 15
	5.4.1. Using IPv6 ND only . . . . . . . . . . . . . . . . . 15		6.4. Case of DMB radios . . . . . . . . . . . . . . . . . . . 15
	5.4.2. Using Wireless ND . . . . . . . . . . . . . . . . . . 15		6.4.1. Using IPv6 ND only . . . . . . . . . . . . . . . . . 15
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		6.4.2. Using Wireless ND . . . . . . . . . . . . . . . . . . 15
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 18		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18		8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
	9.1. Normative References . . . . . . . . . . . . . . . . . . 18		10. Normative References . . . . . . . . . . . . . . . . . . . . 18
	9.2. Informative References . . . . . . . . . . . . . . . . . 19		11. Informative References . . . . . . . . . . . . . . . . . . . 19
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
	1. Introduction		1. Introduction
	IEEE STD. 802.1 [IEEEstd8021] Ethernet Bridging provides an efficient		IEEE STD. 802.1 [IEEEstd8021] Ethernet Bridging provides an efficient
	and reliable broadcast service for wired networks; applications and		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. Unfortunately, Low-Power Lossy Networks (LLNs)		their core operation.
	and local wireless networks generally do not provide the broadcast
	capabilities of Ethernet Bridging in an economical fashion.		Unfortunately, Low-Power Lossy Networks (LLNs) and Wireless Local
			Area Networks (WLANs) generally do not benefit from the same reliable
			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		As a result, protocols designed for bridged networks that rely on
	multicast and broadcast often exhibit disappointing behaviours when		broadcast transmissions often exhibit disappointing behaviours when
	employed unmodified on a local wireless medium (see		employed unmodified on a local wireless medium (see
	[I-D.ietf-mboned-ieee802-mcast-problems]).		[MCAST-PROBLEMS]).
	Wi-Fi [IEEEstd80211] Access Points (APs) deployed in an Extended		Wi-Fi [IEEEstd80211] Access Points (APs) deployed in an Extended
	Service Set (ESS) act as Ethernet Bridges [IEEEstd8021], with the		Service Set (ESS) act as Ethernet Bridges [IEEEstd8021] between the
	property that the bridging state is established at the time of		wireless stations (STA) and the wired backbone. As opposed to the
	association. This ensures connectivity to the node (STA) and		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		protects the wireless medium against broadcast-intensive Transparent
	Bridging reactive Lookups.		Bridging lookups. In other words, the association process registers
			the Link-Layer (MAC) Address of the STA to the AP. The AP maintains
	In other words, the association process is used to register the MAC		the full list of associated addresses and does not forward over the
	Address of the STA to the AP. The AP subsequently proxies the		radio the broadcast lookups for destinations that are not there.
	bridging operation and does not need to forward the broadcast Lookups
	over the radio.
	Like Transparent Bridging, IPv6 [RFC8200] Neighbor Discovery
	[RFC4861] [RFC4862] Protocol (IPv6 ND) is a reactive protocol, based
	on multicast transmissions to locate an on-link correspondent and
	ensure the uniqueness of an IPv6 address. The mechanism for
	Duplicate Address Detection (DAD) [RFC4862] was designed for the
	efficient broadcast operation of Ethernet Bridging. Since broadcast
	can be unreliable over wireless media, DAD often fails to discover
	duplications [I-D.yourtchenko-6man-dad-issues]. In practice, IPv6
	addresses very rarely conflict because of the entropy of the 64-bit
	Interface IDs, not because address duplications are detected and
	resolved.
	The IPv6 ND Neighbor Solicitation (NS) [RFC4861] message is used for		In the case of Ethernet LANs as well as most WLANs and Low-Power
	DAD and Address Resolution (AR) when a node moves, or wakes up and		Personal Area Networks (LoWPANs), the Network-Layer multicast
	reconnects to the wireless network. The NS message is targeted to a		operation is typically implemented as a Link-Layer broadcast for the
	Solicited-Node Multicast Address (SNMA) [RFC4291] and should in		lack of an adapted Link-Layer multicast operation. That Link-Layer
	theory only reach a very small group of nodes. It must be noted that		multicast operation would need to handle a possibly very large number
	in the the case of Ethernet LANs as well as most WLANs and LPWANs,		of groups and it was easier to simply broadcast all the Network-Layer
	the Layer-3 multicast operation becomes a MAC_Layer broadcast for the		multicast packets.
	lack of a Layer-2 multicast operation that could handle a possibly
	very large number of groups in order to make the unicast efficient.
	It results that IPv6 ND messages are processed by most of the
	wireless nodes over the subnet (e.g., the ESS fabric) regardless of
	how few of the nodes are subscribed to the SNMA.
	IPv6 ND address Lookups and DADs over a large fabric can generate		Like Transparent Bridging, the IPv6 [RFC8200] Neighbor Discovery
	hnudreds of broadcasts per second. If the broadcasts were blindly		[RFC4861] [RFC4862] Protocol (IPv6 ND) is reactive, based on on-
	copied over Wi-Fi and/or over a LowPower Lossy Network (LLN), the ND-		demand multicast transmissions to locate an on-link correspondent and
	related multicast could consume enough bandwidth to cause a		ensure the uniqueness of an IPv6 address. On wireless, the packets
	substantial degradation to the unicast traffic service		are broadcasted, meaning that they are both expensive and unreliable.
	[I-D.vyncke-6man-mcast-not-efficient]. To protect their bandwidth,
	some networks throttle ND-related broadcasts, which reduces the
	capability of the protocol to perform as expected.
	Conversely, a Wi-Fi station must keep its radio turned on to listen		On paper, a Wi-Fi station must keep its radio turned on to listen to
	to the periodic series of broadcast frames, which for the most part		the periodic series of broadcast frames, which for the most part will
	will be dropped when they reach Layer-3. 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 IPv6 ND operations even less
	reliable.		reliable.
	These problems can be alleviated by reducing the IPv6 ND broadcasts		It results that an IPv6 ND multicast message is processed by many of
	over wireless access links. This has been done by splitting the		the wireless nodes over the whole subnet (e.g., the ESS fabric)
	broadcast domains and by routing between subnets, at the extreme by		though there are very few nodes subscribed to the multicast group,
	assigning a /64 prefix to each wireless node (see [RFC8273]).		and at most one intended target. Yet, the packet may be missed by
			the intended target.
	Another way is to proxy at the boundary of the wired and wireless
	domains the Layer-3 protocols that rely on MAC Layer broadcast
	operations. For instance, IEEE 802.11 [IEEEstd80211] situates proxy-
	ARP (IPv4) and proxy-ND (IPv6) functions at the Access Points (APs).
	But proxying ND requires a perfect knowledge of the peer IPv6
	addresses for which proxying is provided. In a generic fashion,
	radio connectivity changes with movements and variations in the
	environment, which makes forming and maintaining that knowledge a
	hard problem in the general case.
	Discovering peer addresses by snooping the IPV6 ND protocol as
	proposed for SAVI [I-D.bi-savi-wlan] was found to be unreliable. An
	IPv6 address may not be discovered immediately due to a packet loss,
	or if a "silent" node is not currently using one of its addresses,
	e.g., a node that waits in wake-on-lan state. A change of state,
	e.g. due to a movement, may be missed or misordered, leading to
	unreliable connectivity and an incomplete knowledge of the set of
	peers.
	Wireless ND (WiND) introduces a new approach to IPv6 ND that is
	designed to apply to the WLANs and WPANs types of networks. 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 MAC-
	level domains are not congruent, which is common in those types of
	networks unless a specific MAC-Level emulation is provided. WiND
	applies routing inside the Subnets, which enables MultiLink Subnets.
	Hosts register their addresses to their serving routers with
	[RFC8505]. With the registration, routers have a complete knowledge
	of the hosts they serve and in return, hosts obtain routing services
	for their registered addresses. The registration is abstract to the
	routing protocol, and it can be protected to prevent impersonation
	attacks with [I-D.ietf-6lo-ap-nd].
	The routing service can be a simple reflexion in a Hub-and-Spoke		Though IPv6 ND was the state of the art when designed for an Ethernet
	Subnet that emulates an IEEE Std 802.11 Infrastructure BSS at Layer		wire at the end of the twentieth century, it must be reevaluated for
	3. It can also be a full-fledge routing protocol, in particular RPL		the new technologies, such as wireless and overlays, that evolved
	[RFC6550] that was designed to adapt to various LLNs such as WLAN and		since then. This document discusses the applicability of IPv6 ND
	WPAN radio meshes with the concept of Objective Function. Finally,		over wireless links, as compared with routing-based alternatives such
	the routing service can also be ND proxy that emulates an IEEE Std		as prefix-per node and multi-link subnets (MLSN), and with Wireless
	802.11 Infrastructure ESS at Layer 3. WiND specifies the IPv6		ND (WiND), that is similar to the Wi-Fi association and reduces the
	Backbone Router for that purpose in [I-D.ietf-6lo-backbone-router].		need for Network-Layer multicast.
	More details on WiND can be found in Section 4.1.
	2. Acronyms		2. Acronyms
	This document uses the following abbreviations:		This document uses the following abbreviations:
	6BBR: 6LoWPAN Backbone Router		6BBR: 6LoWPAN Backbone Router
	6LBR: 6LoWPAN Border 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
	DAD: Duplicate Address Detection		DAD: Duplicate Address Detection
	DAR: Duplicate Address Request		DAR: Duplicate Address Request
			EDAC: Extended Duplicate Address Confirmation
	EDAC: Extended Duplicate Address Confirmation		EDAR: Extended Duplicate Address Request
			MLSN: Multi-link subnet
	EDAR: Extended Duplicate Address Request
	MLSN: Multi-Link Subnet
	LLN: Low-Power and Lossy Network		LLN: Low-Power and Lossy Network
			LoWPAN: Low-Power Wireless Personal Area Network
			NA: Neighbor Advertisement
			NBMA: Non-Broadcast Multi-Access
			NCE: Neighbor Cache Entry
			ND: Neighbor Discovery
			NDP: Neighbor Discovery Protocol
			NS: Neighbor Solicitation
			RPL: IPv6 Routing Protocol for LLNs
			RA: Router Advertisement
			RS: Router Solicitation
			VLAN: Virtual Local Area Network
			WiND: Wireless Neighbor Discovery
			WLAN: Wireless Local Area Network
			WPAN: Wireless Personal Area Network
	NA: Neighbor Advertisement		3. IPv6 ND, Wireless ND and ND-Proxies
	NBMA: Non-Broadcast Multi-Access		The IPv6 ND Neighbor Solicitation (NS) [RFC4861] message is used as a
			multicast IP packet for Address Resolution (AR) and Duplicate Address
			Setection (DAD) [RFC4862]. In those cases, the NS message is sent at
			the Network Layer to a Solicited-Node Multicast Address (SNMA)
			[RFC4291] and should in theory only reach a very small group of
			nodes. Those messages are generated individually for each address,
			and may occur when a node joins the network, moves, or wakes up and
			reconnects to the network.
	NCE: Neighbor Cache Entry		DAD was designed for the efficient broadcast operation of Ethernet.
			Experiments show that DAD often fails to discover the duplication of
			IPv6 addresses in large wireless access networks [DAD-ISSUES]. In
			practice, IPv6 addresses very rarely conflict, not because the
			address duplications are detected and resolved by the DAD operation,
			but thanks to the entropy of the 64-bit Interface IDs (IIDs) that
			makes a collision quasi-impossible for randomized IIDs.
	ND: Neighbor Discovery		IPv6 ND Address Lookups and DADs over a very large fabric can
			generate hundreds of broadcasts per second. If the broadcasts were
			blindly copied over Wi-Fi, the ND-related multicast traffic could
			consume enough bandwidth to cause a substantial degradation to the
			unicast service [MCAST-EFFICIENCY]. To protect their bandwidth, some
			networks throttle ND-related broadcasts, which reduces the capability
			for the ND protocol to operate as expected.
	NDP: Neighbor Discovery Protocol		This problem can be alleviated by reducing the size of the broadcast
			domain that encompasses wireless access links. This has been done in
			the art of IP subnetting by partitioning the subnets and by routing
			between them, at the extreme by assigning a /64 prefix to each
			wireless node (see [RFC8273]).
	NS: Neighbor Solicitation		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
			protocols that rely on Link-Layer broadcast operations. For
			instance, IEEE 802.11 [IEEEstd80211] recommends to deploy proxy-ARP
			(IPv4) and proxy-ND (IPv6) functions at the Access Points (APs). But
			proxying ND requires the full list of the IPv6 addresses for which
			proxying is provided. Forming and maintaining that knowledge a hard
			problem in the general case of radio connectivity, which keeps
			changing with movements and other variations in the environment.
	RPL: IPv6 Routing Protocol for LLNs		[SAVI] suggests to discover the addresses by snooping the IPV6 ND
			protocol, but that can also be unreliable. An IPv6 address may not
			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
			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
			misordered, leading to unreliable connectivity and an incomplete list
			of IPv6 addresses to be proxied for.
	RA: Router Advertisement		Wireless ND (WiND) introduces a new approach to IPv6 ND that is
			designed to apply to the WLANs and LoWPANs types of networks. 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 those types of
			networks unless a specific Link-Layer emulation is provided.
	RS: Router Solicitation		WiND applies routing inside the subnets, which enables Multilink
			subnets. Hosts register their addresses to their serving routers
			with [RFC8505]. With the registration, routers have a complete
			knowledge of the hosts they serve and in return, hosts obtain routing
			services for their registered addresses. The registration is
			abstract to the routing protocol, and it can be protected to prevent
			impersonation attacks with [ADDR-PROTECT].
	WiND: Wireless Neighbor Discovery		The routing service can be a simple reflexion in a Hub-and-Spoke
	WLAN: Wireless Local Area Network		subnet that emulates an IEEE Std. 802.11 Infrastructure BSS at the
			Network Layer. It can also be a full-fledge routing protocol, in
			particular RPL [RFC6550] that was designed to adapt to various LLNs
			such as WLAN and WPAN radio meshes with the concept of Objective
			Function. Finally, the routing service can also be ND proxy that
			emulates an IEEE Std. 802.11 Infrastructure ESS at the Network Layer,
			as specified in the IPv6 Backbone Router [BB-ROUTER].
	WPAN: Wireless Personal Area Network		More details on WiND can be found in Section 5.1.
	3. IP Models		4. IP Models
	3.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 datagram 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 radio transmission. This
	set can comprise a single peer on a serial cable used as point-to-		set can comprise a single peer on a serial cable used as point-to-
	point (P2P) link. It may also comprise multiple peer nodes on a		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 legacy
	Ethernet shared wire.		Ethernet yellow wire for which IPv6 ND was initially designed.
	On WLAN and WPAN radios, the physical broadcast domain is defined by		On WLAN and LoWPAN radios, the physical broadcast domain is defined
	a particular transmitter, as the set of nodes that can receive what		by a particular transmitter, as the set of nodes that can receive
	this transmitter is sending. Literally every datagram defines its		what this transmitter is sending. Literally every datagram defines
	own broadcast domain since the chances of reception of a given		its own broadcast domain since the chances of reception of a given
	datagram are statistical. In average and in stable conditions, the		datagram are statistical. In average and in stable conditions, the
	broadcast domain of a particular node can be still be seen as mostly		broadcast domain of a particular node can be still be seen as mostly
	constant and can be used to define a closure of nodes on which an		constant and can be used to define a closure of nodes on which an
	upper-layer abstraction can be built.		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 2 nodes if their
	physical broadcast domains overlap.		physical broadcast domains overlap. On WLAN and LoWPAN radios, MC
			property is usually reflexive, meaning that if B can receive a
			datagram from A, then A can receive a datagram 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
			that the connectivity becomes mostly uni-directional, e.g., A to B
			but practically not B to A.
	On WLAN and WPAN radios, this property is usually reflexive, meaning		It takes a particular effort to place a set of devices in a fashion
	that if B can receive a datagram from A, then A can receive a		that all their physical broadcast domains fully overlap, and that
	datagram from B. But there can be asymmetries due to power levels,		situation can not be assumed in the general case. In other words,
	interferers near one of the receivers, or differences in the quality		the property of radio connectivity is generally not transitive,
	of the hardware (e.g., crystals, PAs and antennas) that may affect		meaning that A in range with B and B in range with C does not
	the balance to the point that the connectivity becomes mostly uni-		necessarily imply that A is in range with C.
	directional, e.g., A to B but practically not B to A. It takes a
	particular effort to place a set of devices in a fashion that all
	their physical broadcast domains fully overlap, and it can not be
	assumed in the general case. In other words, the property of radio
	connectivity is generally not transitive, meaning that A may be in
	range with B and B may be in range with C does not necessarily imply
	that A is in range with C.
	We define Direct MAC-Layer Broadcast (DMC) a transmission mode where		4.2. Link-Layer Broadcast Emulations
	the broadcast domain that is usable at the MAC layer is directly the
	physical broadcast domain. IEEE 802.15.4 [IEEE802154] and IEEE
	802.11 OCB [IEEEstd80211] (for Out of the Context of a BSS) are
	examples of DMC radios. This contrasts with a number of MAC-layer
	Broadcast Emulation schemes that are described in the next section.
	3.2. MAC-Layer Broadcast Emulations		We call Direct MAC Broadcast (DMB) the transmission mode where the
			broadcast domain that is usable at the MAC layer is directly the
			physical broadcast domain. IEEE Std. 802.15.4 [IEEE802154] and IEEE
			Std. 802.11 OCB [IEEEstd80211] (for Out of the Context of a BSS) are
			examples of DMB radios. This contrasts with a number of Link-Layer
			Broadcast Emulation (LLBE) schemes that are described in this
			section.
	While a physical broadcast domain is constrained to a single shared		While a physical broadcast domain is constrained to a single shared
	wire, Ethernet Bridging emulates the broadcast properties of that		wire, Ethernet Bridging emulates the broadcast properties of that
	wire over a whole physical mesh of Ethernet links. For the upper		wire over a whole physical mesh of Ethernet links. For the upper
	layer, the qualities of the shared wire are essentially conserved,		layer, the qualities of the shared wire are essentially conserved,
	with a reliable and cheap broadcast operation over a closure of nodes		with a reliable and cheap broadcast operation over a closure of nodes
	defined by their connectivity to the emulated wire.		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 mapping server. 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.
	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 closure of nodes as defined by the broadcast domain of a
	central Access Point (AP). The AP relays both unicast and broadcast		central AP. The AP relays both unicast and broadcast packets and
	packets and ensures a reflexive and transitive emulation of the		ensures a reflexive and transitive emulation of the shared wire
	shared wire between the associated nodes, with the capability to		between the associated nodes, with the capability to signal link-up/
	signal link-up/link-down to the upper layer. Within an		link-down to the upper layer. Within an Infrastructure BSS, the
	Infrastructure BSS, the physical broadcast domain of the AP serves as		physical broadcast domain of the AP serves as emulated broadcast
	emulated broadcast domain for all the nodes that are associated to		domain for all the nodes that are associated to the AP. Broadcast
	the AP. Broadcast packets are relayed by the AP and are not		packets are relayed by the AP and are not acknowledged. To increase
	acknowledged. To ensure that all nodes in the BSS receive the		the chances that all nodes in the BSS receive the broadcast
	broadcast transmission, AP transmits at the slowest PHY speed. This		transmission, AP transmits at the slowest PHY speed. This translates
	translates into maximum co-channel interferences for others and		into maximum co-channel interferences for others and the longest
	longest occupancy of the medium, for a duration that can be 100 times		occupancy of the medium, for a duration that can be a hundred times
	that of a unicast. For that reason, upper layer protocols should		that of the unicast transmission of a frame of the same size. For
	tend to avoid the use of broadcast when operating over Wi-Fi.		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),		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 Spanning tree Protocol.		typically running Transparent Bridging and the Spanning tree
	In the original model of learning bridges, the state in the		Protocol. In the original model of learning bridges, the forwarding
	Transparent Bridge is set by observing the source MAC address of the		state is set by observing the source MAC address of the frames. When
	frames. When a state is missing for a destination MAC address, the		a state is missing for a destination MAC address, the frame is
	frame is broadcasted with the expectation that the response will		broadcasted with the expectation that the response will populate the
	populate the state. This is a reactive operation, meaning that the		state on the reverse path. This is a reactive operation, meaning
	state is populated reactively to a need for forwarding. It is also		that the state is populated reactively to the need for to reach a
	possible in the original model to send a gratuitous frame to		destination. It is also possible in the original model to broadcast
	advertise self throughout the bridged network, and that is also a		a gratuitous frame to advertise self throughout the bridged network,
	broadcast.		and that is also a broadcast.
	In contrast, the process of the Wi-Fi association prepares a bridging		The process of the Wi-Fi association prepares a bridging state
	state proactively at the AP, which avoids the need for a reactive		proactively at the AP, which avoids the need for a reactive broadcast
	broadcast lookup over the wireless access. 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. With WiND, IPv6 ND		towards the AP for the MAC address of the STA. WiND emulates that
	evolves towards similar proactive methods at Layer-3 for its		proactive method at the Network-Layer for the operations of AR, DAD
	operation of address discovery (AD) and duplicate address detection		and IPv6 ND proxy.
	(DAD).
	In some cases of WLAN and WPAN radios, a mesh-under technology (e.g.,		In some instances of WLANs and LoWPANs, a Mesh-Under technology
	a IEEE 802.11s or IEEE 802.15.10) provides meshing services that are		(e.g., a IEEE Std. 802.11s or IEEE Std. 802.15.10) provides meshing
	similar to bridging, and the broadcast domain is well defined by the		services that are similar to bridging, and the broadcast domain is
	membership of the mesh. Mesh-Under emulates a broadcast domain by		well-defined by the membership of the mesh. Mesh-Under emulates a
	flooding the broadcast packets at Layer-2. When operating on a		broadcast domain by flooding the broadcast packets at the Link-Layer.
	single frequency, this operation is known to interfere with itself,		When operating on a single frequency, this operation is known to
	forcing deployment to introduce delays that dampen the collisions.		interfere with itself, and requires inter-frame gaps to dampen the
	All in all, the mechanism is slow, inefficient and expensive.		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 MAC-layer communication can be established between 2		There again, a Link-Layer communication can be established between 2
	nodes if their MAC-layer broadcast domains overlap. In the absence		nodes if their Link-Layer broadcast domains overlap. In the absence
	of a MAC-layer emulation such as a mesh-under or an Infrastructure		of a Link-Layer emulation such as a Mesh-Under or an Infrastructure
	BSS, the MAC-layer broadcast domain is congruent with that of the		BSS, the Link-Layer broadcast domain is congruent with that of the
	PHY-layer and inherits its properties for reflexivity and		PHY-layer and inherits its properties for reflexivity and
	transitivity. IEEE 802.11 OCB, which operates Out of the Context of		transitivity. The IEEE Std. 802.11 OCB, which operates without a
	a BSS (DMC radios) is an example of a network that does not have a		BSS, is an example of a network that does not have a Link-Layer
	MAC-Layer broadcast domain emulation, which means that it will		broadcast domain emulation, which means that it will exhibit mostly
	exhibit mostly reflexive and mostly non-transitive transmission		reflexive and mostly non-transitive transmission properties.
	properties.
	3.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 Neighbor Discovery (ND) [RFC4861][RFC4862] Duplicate		Link. The IPv6 ND [RFC4861] DAD [RFC4862] process uses a multicast
	Adress Detection (DAD) process leverages a multicast transmission to		transmission to detect a duplicate address, which requires that the
	ensure that an IPv6 address is unique as long as the owner of the		owner of the address is connected to the Link-Layer broadcast domain
	address is connected to the broadcast domain. It must be noted that		of the sender.
	in all the cases in this specification, the Layer-3 multicast
	operation is always a MAC_Layer broadcast for the lack of a Layer-2
	multicast operation that could handle a possibly very large number of
	groups in order to make the unicast efficient. This means that for
	every multicast packet regardless of the destination group, all nodes
	will receive the packet and process it all the way to Layer-3.
	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
	by provising a MAC-Layer broadcast domain that emulates a physical		with a Link-Layer broadcast domain that emulates a physical broadcast
	broadcast domain over the mesh of wires. But the difference shows on		domain over the mesh of wires. But the difference shows on legacy
	legacy Non-Broadcast Multi-Access (NBMA) such as ATM and Frame-Relay,		Non-Broadcast Multi-Access (NBMA) networks such as ATM and Frame-
	on shared links and on newer types of NBMA networks such as radio and		Relay, on shared links and on newer types of NBMA networks such as
	composite radio-wires networks. It also shows when private VLANs or		radio and composite radio-wires networks. It also shows when private
	Layer-2 cryptography restrict the capability to read a frame to a		VLANs or Link-Layer cryptography restrict the capability to read 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 MAC-Layer broadcast domain.		physical broadcast domain to the emulated Link-Layer broadcast
	Relying on Multicast for the ND operation remains feasible but		domain. Relying on Multicast for the ND operation remains feasible
	becomes detrimental to unicast traffic, energy-inefficient and		but becomes highly detrimental to the unicast traffic, and more
	unreliable, and its use is discouraged.		energy-inefficient and unreliable as the network grows.
	On DMC 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 on 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. The nodes may need to form new
	LLAs to talk to one another and the scope where LLA uniqueness can be		Link-Local Addresses (LLAs) to talk to one another and the scope on
	dynamically checked is that pair of nodes. As long as there's no		which the uniqueness of an LLA must be checked is that pair of nodes.
	conflict a node may use the same LLA with multiple peers but it has		As long as there's no conflict, a node may use the same LLA with
	to revalidate DAD with every new peer node. In practice, each pair		multiple peers but it has to perform DAD with each new peer node. In
	of nodes defines a temporary P2P link, which can be modeled as a sub-		practice, each pair of nodes defines a temporary P2P link, which can
	interface of the radio interface.		be modeled as a sub-interface of the radio interface.
	3.4. Mapping the IPv6 Subnet Abstraction		4.4. Mapping the IPv6 subnet Abstraction
	IPv6 also defines a concept of Subnet for Glocal and Unique Local		IPv6 also defines the concept of a subnet for Glocal and Unique Local
	Addresses. Addresses in a same Subnet share a same prefix and by		Addresses. All the addresses in a subnet share the same prefix, and
	extension, a node belongs to a Subnet if it has an interface with an		by extension, a node belongs to a subnet if it has with an address in
	address on that Subnet. A Subnet prefix is Globally Unique so it is		that subnet. A subnet prefix is Globally Unique so it is sufficient
	sufficient to validate that an address that is formed from a Subnet		to validate that an address that is formed from a subnet prefix is
	prefix is unique within that Subnet to guarantee that it is globally		unique within that subnet to guarantee that it is globally unique.
	unique. IPv6 aggregation relies on the property that a packet from
	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
	destination MAC address and deliver the packet, or route the packet
	to the destination within the Subnet. If the Subnet is known as
	onlink, then any node may also resolve the destination MAC address
	and deliver the packet, but if the Subnet is not onlink, then a host
	that does not have an NCE for the destination will need to pass the
	packet to a router.
	On IEEE Std. 802.3, a Subnet is often congruent with an IP Link		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 subnet, and that this router will be able to either resolve the
			destination Link-Layer address and deliver the packet, or route the
			packet to the destination within the subnet. If the subnet is known
			as on-link, then any node may also resolve the destination Link-Layer
			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
	because both are determined by the physical attachment to an Ethernet		because both are determined by the physical attachment to an Ethernet
	shared wire or an IEEE Std. 802.1 bridged broadcast domain. In that		shared wire or an IEEE Std. 802.1 bridged broadcast domain. In that
	case, the connectivity over the Link is transitive, the Subnet can		case, the connectivity over the link is transitive, the subnet can
	appear as onlink, and any node can resolve a destination MAC address		appear as on-link, and any node can resolve a destination MAC address
	of any other node directly using IPv6 Neighbor Discovery.		of any other node directly using IPv6 Neighbor Discovery.
	But an IP Link and an IP Subnet are not always congruent. In a		But an IP link and an IP subnet are not always congruent. In the
	shared Link situation, a Subnet may encompass only a subset of the		case of a Shared Link, individual subnets may each encompass only a
	nodes connected to the Link. In Route-Over Multi-Link Subnets (MLSN)		subset of the nodes connected to the link. In Route-Over Multi-link
	[RFC4903], routers federate the Links between nodes that belong to		subnets (MLSN) [RFC4903], routers federate the links between nodes
	the Subnet, the Subnet is not onlink and it extends beyond any of the		that belong to the subnet, the subnet is not on-link and it extends
	federated Links.		beyond any of the federated links.
	The DAD and lookup procedures in IPv6 ND expects that a node in a		5. Wireless Neighbor Discovery
	Subnet is reachable within the broadcast domain of any other node in
	the Subnet when that other node attempts to form an address that
	would be a duplicate or attempts to resolve the MAC address of this
	node. This is why ND is only applicable for P2P and transit links,
	and requires extensions for other topologies.
	4. Wireless ND		5.1. Introduction to Wireless ND
	4.1. Introduction to WiND		The DAD and AR procedures in IPv6 ND expect that a node in a subnet
			is reachable within the broadcast domain of any other node in the
			subnet when that other node attempts to form an address that would be
			a duplicate or attempts to resolve the MAC address of this node.
			This is why ND is only applicable for P2P and transit links, and
			requires extensions for other topologies.
	Wireless Neighbor Discovery (WiND)		WiND [RFC6775][RFC8505][BB-ROUTER][ADDR-PROTECT] defines a new
	[RFC6775][RFC8505][I-D.ietf-6lo-backbone-router][I-D.ietf-6lo-ap-nd]		operation for Neighbor Discovery that is based on 2 major paradigm
	defines a new ND operation that is based on 2 major paradigm changes,		changes, proactive address registration by hosts to their attachment
	proactive address registration by hosts to their attachment routers		routers and routing to host routes (/128) within the subnet. This
	and routing to host routes (/128) within the subnet. This allows		allows WiND to avoid the expectations of transit links and subnet-
	WiND to avoid the classical ND expectations of transit links and		wide broadcast domains.
	Subnet-wide broadcast domains.
			WiND is agnostic to the method used for Address Assignment, e.g.,
			Stateless Address Autoconfiguration (SLAAC) [RFC4862] or DHCPv6
			[RFC8415]. It does not change the IPv6 addressing [RFC4291] or the
			current practices of assigning prefixes, typically a /64, to a
			subnet. But the DAD operation is performed as a unicast exchange
			with a central registrar, using new ND Extended Duplicate Address
			messages (EDAR and EDAC) [RFC6775][RFC8505]. This operation
			modernizes ND for application in overlays with Map Resolvers and
			enables unicast lookups [UNICAST-AR] for addresses registered to the
			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)
	defiend 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 NS(Lookup) found		host routes in the routers and avoids the reactive Address Resolution
	in IPv6 ND. This is a direct benefit for wireless Links since it		in IPv6 ND and the associated Link-Layer broadcasts transmissions.
	avoids the MAC level broadcasts that are associated to NS(Lookup).
	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 ub-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 for RIFT [I-D.ietf-rift-rift], RPL [RFC6550] with		referenced as the registrtaion interface to "RIFT: Routing in Fat
	[I-D.thubert-roll-unaware-leaves] and IPv6 ND proxy		Trees" [I-D.ietf-rift-rift] and "RPL: IPv6 Routing Protocol for
	[I-D.ietf-6lo-backbone-router].		Low-Power and Lossy Networks" [RFC6550] with [RPL-UNAWARE-LEAVES].
	WiND does not change IPv6 addressing [RFC4291] or the current
	practices of assigning prefixes to subnets. It is still typical to
	assign a /64 to a subnet and to use interface IDs of 64 bits.
	Duplicate Address detection within the Subnet is performed with a
	central registrar, using new ND Extended Duplicate Address messages
	(EDAR and EDAC) [RFC8505]. This operation modernizes ND for
	application in overlays with Map Resolvers and enables unicast
	lookups [I-D.thubert-6lo-unicast-lookup] for addresses registered to
	the resolver.
	WiND also enables to extend a legacy /64 on Ethernet with ND proxy
	over the wireless. This way nodes can form any address the want and
	move freely from an L3-AP (that is really a backbone router in
	bridging mode, more in [I-D.ietf-6lo-backbone-router]) to another,
	without renumbering. Backbone Routers federate multiple LLNs over a
	Backbone Link to form a MultiLink Subnet (MLSN). Backbone Routers
	placed along the LLN edge of the Backbone handle IPv6 Neighbor
	Discovery, and forward packets on behalf of registered nodes.
	An LLN node (6LN) registers all its IPv6 Addresses using an NS(EARO)		WiND also enables to span a subnet over an MLSN that federates edge
	as specified in [RFC8505] to the 6BBR. The 6BBR is also a Border		wireless links with a high-speed, typically Ethernet, backbone. This
	Router that performs IPv6 Neighbor Discovery (IPv6 ND) operations on		way, nodes can form any address they want and move freely from a
	its Backbone interface on behalf of the 6LNs that have registered		wireless edge link to another, without renumbering. Backbone Routers
	addresses on its LLN interfaces without the need of a broadcast over		(6BBRs) placed along the wireless edge of the Backbone handle IPv6
	the wireless medium.		Neighbor Discovery and forward packets over the backbone on behalf of
			the registered nodes on the wireless edge. For instance, a 6BBR in
			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
			reachability for Global Unicast and Link-LOcal Addresses within the
			federated MLSN.
	WiND is also compatible with DHCPv6 and other forms of address		5.2. links and Link-Local Addresses
	assignment in which case it can still be used for DAD.
	4.2. Links and Link-Local Addresses		For Link-Local Addresses, DAD is typically performed between
			communicating pairs of nodes and an NCE can be populated with a
			single unicast exchange. In the case of a bridging proxies, though,
			the Link-Local traffic is bridged over the backbone and the DAD must
			proxied there as well.
	For Link-Local Addresses, DAD is performed between communicating		For instance, in the case of Bluetooth Low Energy (BLE)
	pairs of nodes. It is carried out as part of a registration process		[RFC7668][IEEEstd802151], the uniqueness of Link-Local Addresses
	that is based on a NS/NA exchange that transports an EARO. During		needs only to be verified between the pair of communicating nodes,
	that process, the DAD is validated and a Neighbor Cache Entry (NCE)		the central router and the peripheral host. In that example, 2
	is populated with a single unicast exchange.		peripheral hosts connected to the same central router can not have
			the same Link-Local Address because the addresses would collision at
			the central router which could not talk to both over the same
			interface. The DAD operation from WiND is appropriate for that use
			case, but the one from ND is not, because the peripheral hosts are
			not on the same broadcast domain.
	For instance, in the case of a Bluetooth Low Energy (BLE)		On the other hand, the uniqueness of Global and Unique-Local
	[RFC7668][IEEEstd802151] Hub-and Spoke configuration, Uniqueness of		Addresses is validated at the subnet Level, using a logical registrar
	Link local Addresses need only to be verified between the pairs of		that is global to the subnet.
	communicating nodes, a central router and a peripheral host. In that
	example, 2 peripheral hosts connected to the same central router can
	not have the same Link Local Address because the Binding Cache
	Entries (BCEs) would collide at the central router which could not
	talk to both over the same interface. The WiND operation is
	appropriate for that DAD operation, but the one from ND is not,
	because peripheral hosts are not on the same broadcast domain. On
	the other hand, Global and ULA DAD is validated at the Subnet Level,
	using a registrar hosted by the central router.
	4.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 IPv6 ND 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 6LR, the Hub advertises the prefix as not-onlink to the
	spokes in RA messages Prefix Information Options (PIO). Acting as		Acting as routers, the Hub advertises the prefix as not-on-link to
	6LNs, the Spokes autoconfigure addresses from that prefix and		the spokes in RA messages Prefix Information Options (PIO). Acting
			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
	6LBR, 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. Acting as 6LR, the Hub also maintains an NCE for the		sleeping. The Hub also maintains an NCE for the registered addresses
	registered addresses and can deliver a packet to any of them for		and can deliver a packet to any of them during their respective
	their respective lifetimes. It can be observed that this design		lifetimes. It can be observed that this design builds a form of
	builds a form of Layer-3 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 6LBR is deployed to serve the whole mesh.		subnet. A single logical registrar is deployed to serve the whole
			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 [I-D.thubert-roll-unaware-leaves]. In a degraded mode,		specified in [RPL-UNAWARE-LEAVES]. In a degraded mode, all the Hubs
	all the Hubs are connected to a same high speed backbone such as an		are connected to a same high speed backbone such as an Ethernet
	Ethernet bridging domain where IPv6 ND is operated. In that case, it		bridging domain where IPv6 ND is operated. In that case, it is
	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		subnet, operating IPv6 ND proxy operations [BB-ROUTER] at the Hubs,
	[I-D.ietf-6lo-backbone-router] at the Hubs, acting as 6BBRs. It can		acting as 6BBRs. It can be observed that this latter design builds a
	be observed that this latter design builds a form of Layer-3		form of Network-Layer Infrastructure ESS.
	Infrastructure ESS.
	5. WiND Applicability		6. WiND Applicability
	WiND allows P2P, P2MP hub-and spoke, MAC-level broadcast domain		WiND applies equally to P2P links, P2MP Hub-and-Spoke, Link-Layer
	emulation such as mesh-under and Wi-Fi BSS, and Route-Over meshes.		Broadcast Domain Emulation such as Mesh-Under and Wi-Fi BSS, and
			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		This is discussed in more details in the introduction of [BB-ROUTER].
	the introduction of [I-D.ietf-6lo-backbone-router]).
	There are also numerous 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 P2P and not congruent:		where links and subnets are not congruent:
	o IEEE std 802.11 infrastructure BSS enables one subnet per AP, and		* The IEEE Std. 802.11 infrastructure BSS enables one subnet per AP,
	emulates a broadcast domain at L2. Infra ESS extends that and		and emulates a broadcast domain at the Link-Layer. The
	recommends to use an IPv6 ND proxy [IEEEstd80211] to coexist with		Infrastructure ESS extends that model over a backbone and
	Ethernet connected nodes. WiND incorporates an ND proxy to serve		recommends the use of an IPv6 ND proxy [IEEEstd80211] to
	that need and that was missing so far.		interoperate with Ethernet-connected nodes. WiND incorporates an
			ND proxy to serve that need, which was missing so far.
	o BlueTooth is Hub-and-Spoke at the MAC layer. It would make little		* BlueTooth is Hub-and-Spoke at the Link-Layer. It would make
	sense to configure a different subnet between the central and each		little sense to configure a different subnet between the central
	individual peripheral node (e.g., sensor). Rather, [RFC7668]		and each individual peripheral node (e.g., sensor). Rather,
	allocates a prefix to the central node acting as router (6LR), and		[RFC7668] allocates a prefix to the central node acting as router,
	each peripheral host (acting as a host (6LR) 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.
	o 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
	a [IEEEstd802154] Time-Slotted Channel-Hopping mesh, and		an IEEE Std. 802.15.4 Time-Slotted Channel-Hopping (TSCH)
	generalizes it for multiple other applications. Each node in a		[IEEEstd802154] mesh, and generalizes it for multiple other
	Smartgrid network may have tens to a hundred others nodes in		applications.
	range. A key problem for the routing protocol is which other
	node(s) should this node peer with, because most of the possible
	peers do not provide added routing value. When both energy and
	bandwidth are constrained,talking to them is a bad idea and most
	of the possible P2P links are not even used. Peerings that are
	actually used come and go with the dynamics of radio signal
	propagation. It results that allocating prefixes to all the
	possible P2P Links and maintain as many addresses in all nodes is
	not even considered.
	5.1. Case of LPWANs		Each node in a Smartgrid network may have tens to a hundred others
			nodes in range. A key problem for the routing protocol is which
			other node(s) should this node peer with, because most of the
			possible peers do not provide added routing value. When both
			energy and bandwidth are constrained, talking to them is a waste
			of resources and most of the possible P2P links are not even used.
			Peerings that are actually used come and go with the dynamics of
			radio signal propagation. It results that allocating prefixes to
			all the possible P2P links and maintain as many addresses in all
			nodes is not even considered.
	LPWANs are by nature so constrained that the addresses and Subnets		6.1. Case of LPWANs
			LPWANs are by nature so constrained that the addresses and subnets
	are fully pre-configured and operate as P2P or Hub-and-Spoke. This		are fully pre-configured and operate as P2P or Hub-and-Spoke. This
	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.
	5.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. Even if the knowledge of IPv6		asynchronously to the association.
	addresses used by a STA can be obtained by snooping protocols such as
	IPv6 ND and DHCPv6, or by observing data traffic sourced at the STA,
	such methods provide only an imperfect knowledge of the state of the
	STA at the AP. This may result in a loss of connectivity for some
	IPv6 addresses, in particular for addresses rarely used and in a
	situation of mobility. This may also result in undesirable remanent
	state in the AP when a STA ceases to use an IPv6 address. It results
	that snooping protocols is not a recommended technique and that it
	should only be used as last resort.
	The recommended alternate is to use the IPv6 Registration method		Snooping protocols such as IPv6 ND and DHCPv6 and observing data
	speficied in p. By that method, the AP exposes its capability to		traffic sourced at the STA provides an imperfect knowledge of the
	proxy ND to the STA in Router Advertisement messages. In turn, the		state of the STA at the AP. Missing a state or a transition may
	STA may request proxy ND services from the AP for one or more IPv6		result in the loss of connectivity for some of the addresses, in
	addresses, using an Address Registration Option. The Registration		particular for an address that is rarely used, belongs to a sleeping
	state has a lifetime that limits unwanted state remanence in the		node, or one in a situation of mobility. This may also result in
	network. The registration is optionally secured using		undesirable remanent state in the AP when the STA ceases to use an
	[I-D.ietf-6lo-ap-nd] to prevent address theft and impersonation. The		IPv6 address while remaining associated. It results that snooping
	registration carries a sequence number, which enables a fast mobility		protocols is not a recommended technique and that it should only be
	without a loss of connectivity.		used as last resort, when the WiND registration is not available to
			populate the state.
			The recommended alternative method is to use the WiND Registration
			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
			request proxy ND services from the AP for all of its IPv6 addresses,
			using the Extended Address Registration Option, which provides the
			following elements:
			* The registration state has a lifetime that limits unwanted state
			remanence in the network.
			* The registration is optionally secured using [ADDR-PROTECT] to
			prevent address theft and impersonation.
			* The registration carries a sequence number, which enables to
			figure the order of events in a fast mobility scenario without
			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. The proxy ND specification		following the mobility of the STA.
	associated to the address registration is
	[I-D.ietf-6lo-backbone-router]. With that specification, the AP		The WiND proxy ND specification that associated to the Address
			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 proxy replies to NS lookups		also possible. As a bridging proxy, the backbone router either
	with the MAC address of the STA, and then bridges packets to the STA		replies to NS lookups with the MAC address of the STA, or preferably
	normally; as a routing proxy, it replies with its own MAC address and		forwards the lookups to the STA as Link-Layer unicast frames to let
	then routes to the STA at the IP layer. The routing proxy reduces		the STA answer. For the data plane, the backbone router acts as a
	the need to expose the MAC address of the STA on the wired side, for		normal AP and bridges the packets to the STA as usual. As a routing
	a better stability and scalability of the bridged fabric.		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
			need to expose the MAC address of the STA on the wired side, for a
			better stability and scalability of the bridged fabric.
	5.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 reflexive
	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 an Access Point		to that of a BSS, with the root of the mesh operating as an Access
	does in a BSS/ESS. While it is still possible to operate IPv6 ND,		Point does in a BSS/ESS.
	the inefficiencies of the flooding operation make the IPv6 ND
	operations even less desirable than in a BSS, and the use of WiND is
	highly recommended.
	5.4. Case of DMC radios		While it is still possible to operate IPv6 ND, the inefficiencies of
			the flooding operation make the IPv6 ND operations even less
			desirable than in a BSS, and the use of WiND is highly recommended.
	IPv6 over DMC radios uses P2P Links that can be formed and maintained		6.4. Case of DMB radios
	when a pair of DMC radios transmitters are in range from one another.
	5.4.1. Using IPv6 ND only		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.
	DMC radios do not provide MAC level broadcast emulation. An example		6.4.1. Using IPv6 ND only
			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 IPv6 ND over those links with Link-Local addresses.
	DAD must be performed for all addresses on all P2P IP Links.		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 IPv6 ND.
	The model can be stretched beyond the scope of IPv6 ND if an external		If an external mechanism avoids duplicate addresses and if the
	mechanism avoids duplicate addresses and if the deployment ensures		deployment ensures the connectivity between peers, a non-transit Hub-
	the connectivity between peers. This can be achieved for instance in		and-Spoke deployment is also possible where the Hub is the only
	a Hub-and-Spoke deployment if the Hub is the only router in the		router in the subnet and the Prefix is advertised as not on-link.
	Subnet and the Prefix is advertised as not onlink.
	5.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 IPv6 ND, WiND is the recommended
	approach since it uses more unicast communications which are more		approach since it uses unicast communications which are more reliable
	reliable and less impacting for other users of the medium.		and less impacting for other users of the medium.
	Router and Hosts respectively send a compressed RA/NA with a SLLAO at		The routers send RAs with a SLLAO at a regular period. The period
	a regular period. The period can be indicated in a RA as in an RA-		can be indicated in the RA-Interval Option [RFC6275]. If available,
	Interval Option [RFC6275]. If available, the message can be		the message can be transported in a compressed form in a beacon,
	transported in a compressed form in a beacon, e.g., in OCB Basic		e.g., in OCB Basic Safety Messages (BSM) that are nominally sent
	Safety Messages (BSM) that are nominally sent every 100ms. An active		every 100ms.
	beaconing mode is possible whereby the Host sends broadcast RS
	messages to which a router can answer with a unicast RA.		An active beaconing mode is possible whereby the Host sends broadcast
			RS messages to which a router can answer with a unicast RA.
	A router that has Internet connectivity and is willing to serve as an		A router that has Internet connectivity and is willing to serve as an
	Internet Access may advertise itself as a default router [RFC4191] in		Internet Access may advertise itself as a default router [RFC4191] in
	its RA. The NA/RA is sent over an Unspecified Link where it does not		its RA messages. The RA is sent over an unspecified link where it
	conflict to anyone, so DAD is not necessary at that stage.		does not conflict to anyone, so DAD is not necessary at that stage.
	The receiver instantiates a Link where the sender's address is not a		The host instantiates a link where the router's address is not a
	duplicate. To achieve this, it forms an LLA that does not conflict		duplicate. To achieve this, it forms an LLA that does not conflict
	with that of the sender and registers to the sender using [RFC8505].		with that of the router and registers to the router using [RFC8505].
			If the router sent an RA(PIO), the host can also autoconfigure an
	If the sender sent an RA(PIO) the receiver can also autoconfigure an
	address from the advertised prefix and register it.		address from the advertised prefix and register it.
	6LoWPAN Node 6LR		(host) (router)
	(RPL leaf) (router)
	| |		| |
	| LLN link |		| DMB link |
	| |		| |
	| IPv6 ND RS |		| IPv6 ND RS |
	|-------------->|		|-------------->|
	|-----------> |		|-----------> |
	|------------------>		|------------------>
	| IPv6 ND RA |		| IPv6 ND RA |
	|<--------------|		|<--------------|
	| |		| |
	| NS(EARO) |		| NS(EARO) |
	|-------------->|		|-------------->|
	| |		| |
	| NA(EARO) |		| NA(EARO) |
	|<--------------|		|<--------------|
	| |		| |
	Figure 1: Initial Registration Flow		Figure 1: Initial Registration Flow
	The lifetime in the registration should start with a small value		The lifetime in the registration should start with a small value
	(X=RMin, TBD), and exponentially grow with each reregistration to a		(X=RMin, TBD), and exponentially grow with each re-registration to a
	mlarger value (X=Rmax, TBD). The IP Link is considered down when		larger value (X=Rmax, TBD). The IP link is considered down when
	(X=NbBeacons, TDB) expected messages are not received in a row. It		(X=NbBeacons, TDB) expected messages are not received in a row. It
	must be noted that the Link flapping does not affect the state of the		must be noted that the link flapping does not affect the state of the
	registration and when a Link comes back up, the active -lifetime not		registration and when a link comes back up, the active registrations
	elapsed- registrations are still usable. Packets should be held or		(i.e., registrations for which lifetime is not elapsed) are still
	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 described above. More details on the operation of WiND and		MLSNs as illustrated in Figure 2. More details on the operation of
	RPL over the MLSN can be found in section 3.1, 3.2, 4.1 and 4.2.2 of		WiND and RPL over the MLSN can be found in section 3.1, 3.2, 4.1 and
	[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 | IPv6 ND
	| LLN link |Route-Over mesh|Ethernet/serial| Backbone		| LLN link |Route-Over mesh|Ethernet/serial| Backbone
	| | | |		| | | |
	| IPv6 ND RS | | |		| IPv6 ND RS | | |
	|-------------->| | |		|-------------->| | |
	|-----------> | | |		|-----------> | | |
	skipping to change at page 17, line 36 ¶		skipping to change at page 17, line 36 ¶
	| | | | (EARO)		| | | | (EARO)
	| | | |		| | | |
	| | | NA(EARO) |<timeout>		| | | NA(EARO) |<timeout>
	| | |<--------------|		| | |<--------------|
	| | Extended DAC | |		| | Extended DAC | |
	| |<--------------| |		| |<--------------| |
	| NA(EARO) | | |		| NA(EARO) | | |
	|<--------------| | |		|<--------------| | |
	| | | |		| | | |
	Figure 2: Initial Registration Flow over Multi-Link Subnet		Figure 2: Initial Registration Flow over Multi-link subnet
	An example Hub-and-Spoke is an OCB Road-Side Unit (RSU) that owns a		An example Hub-and-Spoke is an OCB Road-Side Unit (RSU) that owns a
	prefix, provides Internet connectivity using that prefix to On-Board		prefix, provides Internet connectivity using that prefix to On-Board
	Units (OBUs) within its physical broadcast domain. An example of		Units (OBUs) within its physical broadcast domain. An example of
	Route-Over MLSN is a collection of cars in a parking lot operating		Route-Over MLSN is a collection of cars in a parking lot operating
	RPL to extend the connectivity provided by the RSU beyond its		RPL to extend the connectivity provided by the RSU beyond its
	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.
	6. IANA Considerations		7. IANA Considerations
	This specification does not require IANA action.		This specification does not require IANA action.
	7. Security Considerations		8. Security Considerations
	This specification refers to the security sections of IPv6 ND and		This specification refers to the security sections of IPv6 ND and
	WiND, respectively.		WiND, respectively.
	8. 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.
	9. References		10. Normative References
	9.1. Normative References
	[I-D.ietf-6lo-ap-nd]
	Thubert, P., Sarikaya, B., Sethi, M., and R. Struik,
	"Address Protected Neighbor Discovery for Low-power and
	Lossy Networks", draft-ietf-6lo-ap-nd-12 (work in
	progress), April 2019.
	[I-D.ietf-6lo-backbone-router]
	Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6
	Backbone Router", draft-ietf-6lo-backbone-router-13 (work
	in progress), September 2019.
	[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.		[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
	Thubert, "Network Mobility (NEMO) Basic Support Protocol",		Thubert, "Network Mobility (NEMO) Basic Support Protocol",
	RFC 3963, DOI 10.17487/RFC3963, January 2005,		RFC 3963, DOI 10.17487/RFC3963, January 2005,
	<https://www.rfc-editor.org/info/rfc3963>.		<https://www.rfc-editor.org/info/rfc3963>.
	[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and		[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
	More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,		More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
	November 2005, <https://www.rfc-editor.org/info/rfc4191>.		November 2005, <https://www.rfc-editor.org/info/rfc4191>.
	skipping to change at page 19, line 16 ¶		skipping to change at page 18, line 51 ¶
	(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>.
	9.2. Informative References		[ADDR-PROTECT]
			Thubert, P., Sarikaya, B., Sethi, M., and R. Struik,
			"Address Protected Neighbor Discovery for Low-power and
			Lossy Networks", Work in Progress, Internet-Draft, draft-
			ietf-6lo-ap-nd-20, 9 March 2020,
			<https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-20>.
	[I-D.bi-savi-wlan]		[BB-ROUTER]
	Bi, J., Wu, J., Wang, Y., and T. Lin, "A SAVI Solution for		Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6
	WLAN", draft-bi-savi-wlan-17 (work in progress), May 2019.		Backbone Router", Work in Progress, Internet-Draft, draft-
			ietf-6lo-backbone-router-20, 23 March 2020,
			<https://tools.ietf.org/html/draft-ietf-6lo-backbone-
			router-20>.
	[I-D.ietf-6tisch-architecture]		11. Informative References
	Thubert, P., "An Architecture for IPv6 over the TSCH mode
	of IEEE 802.15.4", draft-ietf-6tisch-architecture-26 (work
	in progress), August 2019.
	[I-D.ietf-mboned-ieee802-mcast-problems]		[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
	Perkins, C., McBride, M., Stanley, D., Kumari, W., and J.		Architecture", RFC 4291, DOI 10.17487/RFC4291, February
	Zuniga, "Multicast Considerations over IEEE 802 Wireless		2006, <https://www.rfc-editor.org/info/rfc4291>.
	Media", draft-ietf-mboned-ieee802-mcast-problems-08 (work
	in progress), August 2019.		[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903,
			DOI 10.17487/RFC4903, June 2007,
			<https://www.rfc-editor.org/info/rfc4903>.
			[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
			Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
			JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
			Low-Power and Lossy Networks", RFC 6550,
			DOI 10.17487/RFC6550, March 2012,
			<https://www.rfc-editor.org/info/rfc6550>.
			[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
			Bormann, "Neighbor Discovery Optimization for IPv6 over
			Low-Power Wireless Personal Area Networks (6LoWPANs)",
			RFC 6775, DOI 10.17487/RFC6775, November 2012,
			<https://www.rfc-editor.org/info/rfc6775>.
			[RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
			Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low
			Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015,
			<https://www.rfc-editor.org/info/rfc7668>.
			[RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix
			per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017,
			<https://www.rfc-editor.org/info/rfc8273>.
			[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
			Richardson, M., Jiang, S., Lemon, T., and T. Winters,
			"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
			RFC 8415, DOI 10.17487/RFC8415, November 2018,
			<https://www.rfc-editor.org/info/rfc8415>.
	[I-D.ietf-rift-rift]		[I-D.ietf-rift-rift]
	Przygienda, T., Sharma, A., Thubert, P., and D. Afanasiev,		Przygienda, T., Sharma, A., Thubert, P., Rijsman, B., and
	"RIFT: Routing in Fat Trees", draft-ietf-rift-rift-08		D. Afanasiev, "RIFT: Routing in Fat Trees", Work in
	(work in progress), September 2019.		Progress, Internet-Draft, draft-ietf-rift-rift-11, 10
			March 2020,
			<https://tools.ietf.org/html/draft-ietf-rift-rift-11>.
	[I-D.thubert-6lo-unicast-lookup]		[RPL-UNAWARE-LEAVES]
	Thubert, P. and E. Levy-Abegnoli, "IPv6 Neighbor Discovery		Thubert, P. and M. Richardson, "Routing for RPL Leaves",
	Unicast Lookup", draft-thubert-6lo-unicast-lookup-00 (work		Work in Progress, Internet-Draft, draft-ietf-roll-unaware-
	in progress), January 2019.		leaves-13, 17 March 2020, <https://tools.ietf.org/html/
			draft-ietf-roll-unaware-leaves-13>.
	[I-D.thubert-roll-unaware-leaves]		[DAD-ISSUES]
	Thubert, P., "Routing for RPL Leaves", draft-thubert-roll-		Yourtchenko, A. and E. Nordmark, "A survey of issues
	unaware-leaves-07 (work in progress), April 2019.		related to IPv6 Duplicate Address Detection", Work in
			Progress, Internet-Draft, draft-yourtchenko-6man-dad-
			issues-01, 3 March 2015, <https://tools.ietf.org/html/
			draft-yourtchenko-6man-dad-issues-01>.
	[I-D.vyncke-6man-mcast-not-efficient]		[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", draft-vyncke-6man-mcast-not-		Efficient At Datalink Layer", Work in Progress, Internet-
	efficient-01 (work in progress), February 2014.		Draft, draft-vyncke-6man-mcast-not-efficient-01, 14
			February 2014, <https://tools.ietf.org/html/draft-vyncke-
			6man-mcast-not-efficient-01>.
	[I-D.yourtchenko-6man-dad-issues]		[I-D.ietf-6tisch-architecture]
	Yourtchenko, A. and E. Nordmark, "A survey of issues		Thubert, P., "An Architecture for IPv6 over the TSCH mode
	related to IPv6 Duplicate Address Detection", draft-		of IEEE 802.15.4", Work in Progress, Internet-Draft,
	yourtchenko-6man-dad-issues-01 (work in progress), March		draft-ietf-6tisch-architecture-28, 29 October 2019,
	2015.		<https://tools.ietf.org/html/draft-ietf-6tisch-
			architecture-28>.
			[MCAST-PROBLEMS]
			Perkins, C., McBride, M., Stanley, D., Kumari, W., and J.
			Zuniga, "Multicast Considerations over IEEE 802 Wireless
			Media", Work in Progress, Internet-Draft, draft-ietf-
			mboned-ieee802-mcast-problems-11, 11 December 2019,
			<https://tools.ietf.org/html/draft-ietf-mboned-ieee802-
			mcast-problems-11>.
			[SAVI] Bi, J., Wu, J., Wang, Y., and T. Lin, "A SAVI Solution for
			WLAN", Work in Progress, Internet-Draft, draft-bi-savi-
			wlan-18, 17 November 2019,
			<https://tools.ietf.org/html/draft-bi-savi-wlan-18>.
			[UNICAST-AR]
			Thubert, P. and E. Levy-Abegnoli, "IPv6 Neighbor Discovery
			Unicast Lookup", Work in Progress, Internet-Draft, draft-
			thubert-6lo-unicast-lookup-00, 25 January 2019,
			<https://tools.ietf.org/html/draft-thubert-6lo-unicast-
			lookup-00>.
	[IEEE802154]		[IEEE802154]
	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".
	[IEEEstd8021]
	IEEE standard for Information Technology, "IEEE Standard
	for Information technology -- Telecommunications and
	information exchange between systems Local and
	metropolitan area networks Part 1: Bridging and
	Architecture".
	[IEEEstd80211]		[IEEEstd80211]
	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
	skipping to change at page 20, line 46 ¶		skipping to change at page 21, line 42 ¶
	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)".
	[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing		[IEEEstd8021]
	Architecture", RFC 4291, DOI 10.17487/RFC4291, February		IEEE standard for Information Technology, "IEEE Standard
	2006, <https://www.rfc-editor.org/info/rfc4291>.		for Information technology -- Telecommunications and
			information exchange between systems Local and
	[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903,		metropolitan area networks Part 1: Bridging and
	DOI 10.17487/RFC4903, June 2007,		Architecture".
	<https://www.rfc-editor.org/info/rfc4903>.
	[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
	Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
	JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
	Low-Power and Lossy Networks", RFC 6550,
	DOI 10.17487/RFC6550, March 2012,
	<https://www.rfc-editor.org/info/rfc6550>.
	[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
	Bormann, "Neighbor Discovery Optimization for IPv6 over
	Low-Power Wireless Personal Area Networks (6LoWPANs)",
	RFC 6775, DOI 10.17487/RFC6775, November 2012,
	<https://www.rfc-editor.org/info/rfc6775>.
	[RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
	Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low
	Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015,
	<https://www.rfc-editor.org/info/rfc7668>.
	[RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix
	per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017,
	<https://www.rfc-editor.org/info/rfc8273>.
	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
	MOUGINS - Sophia Antipolis 06254		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. 142 change blocks.
	586 lines changed or deleted		623 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/