wdiff draft-thubert-6man-ipv6-over-wireless-04.txt draft-thubert-6man-ipv6-over-wireless-05.txt

6MAN P. Thubert, Ed.
Internet-Draft Cisco Systems
Intended status: Informational September 26, 2019
Expires: Standards Track 31 March 29, 2020
Expires: 2 October 2020

IPv6 Neighbor Discovery on Wireless Networks
draft-thubert-6man-ipv6-over-wireless-04
draft-thubert-6man-ipv6-over-wireless-05

Abstract

This document describes how the original IPv6 Neighbor Discovery and
Wireless ND (WiND) can be applied on various abstractions of wireless
media.

Status of This Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on March 29, 2 October 2020.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4
3. IPv6 ND, Wireless ND and ND-Proxies . . . . . . . . . . . . . 4
4. IP Models . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.
4.1. Physical Broadcast Domain . . . . . . . . . . . . . . . . 6
3.2. MAC-Layer
4.2. Link-Layer Broadcast Emulations . . . . . . . . . . . . . 7
3.3.
4.3. Mapping the IPv6 Link link Abstraction . . . . . . . . . . . . 8
3.4.
4.4. Mapping the IPv6 Subnet subnet Abstraction . . . . . . . . . . . 9
4.
5. Wireless ND . . . . . . . . Neighbor Discovery . . . . . . . . . . . . . . . . . 10
4.1.
5.1. Introduction to WiND . . . Wireless ND . . . . . . . . . . . . . . . 10
4.2. Links
5.2. links and Link-Local Addresses . . . . . . . . . . . . . 11
4.3. Subnets
5.3. subnets and Global Addresses . . . . . . . . . . . . . . 12
5. 11
6. WiND Applicability . . . . . . . . . . . . . . . . . . . . . 12
5.1.
6.1. Case of LPWANs . . . . . . . . . . . . . . . . . . . . . 13
5.2.
6.2. Case of Infrastructure BSS and ESS . . . . . . . . . . . 13
5.3.
6.3. Case of Mesh Under Technologies . . . . . . . . . . . . . 14
5.4. 15
6.4. Case of DMC DMB radios . . . . . . . . . . . . . . . . . . . 15
5.4.1.
6.4.1. Using IPv6 ND only . . . . . . . . . . . . . . . . . 15
5.4.2.
6.4.2. Using Wireless ND . . . . . . . . . . . . . . . . . . 15
6.
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7.
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8.
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
9.
10. Normative References . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative
11. Informative References . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21

1. Introduction

IEEE STD. 802.1 [IEEEstd8021] Ethernet Bridging provides an efficient
and reliable broadcast service for wired networks; applications and
protocols have been built that heavily depend on that feature for
their core operation.

Unfortunately, Low-Power Lossy Networks (LLNs) and local wireless networks Wireless Local
Area Networks (WLANs) generally do not provide benefit from the same reliable
and cheap broadcast capabilities of as Ethernet Bridging in an economical fashion. 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
multicast and
broadcast transmissions often exhibit disappointing behaviours when
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
Service Set (ESS) act as Ethernet Bridges [IEEEstd8021], with [IEEEstd8021] between the
property
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 ensures connectivity to the node (STA) and
protects the wireless medium against broadcast-intensive Transparent
Bridging reactive Lookups. lookups. In other words, the association process is used to register registers
the MAC Link-Layer (MAC) Address of the STA to the AP. The AP subsequently proxies maintains
the
bridging operation full list of associated addresses and does not need to forward over the
radio the broadcast Lookups
over lookups for destinations that are not there.

In the case of Ethernet LANs as well as 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 Link-Layer multicast operation. That Link-Layer
multicast operation would need to handle a possibly very large number
of groups and it was easier to simply broadcast all the radio. Network-Layer
multicast packets.

Like Transparent Bridging, the IPv6 [RFC8200] Neighbor Discovery
[RFC4861] [RFC4862] Protocol (IPv6 ND) is a reactive protocol, reactive, based on on-
demand multicast transmissions to locate an on-link correspondent and
ensure the uniqueness of an IPv6 address. The mechanism On wireless, the packets
are broadcasted, meaning that they are both expensive and unreliable.

On paper, a Wi-Fi station must keep its radio turned on to listen to
the periodic series of broadcast frames, which for
Duplicate Address Detection (DAD) [RFC4862] the most part will
be dropped when they reach Network-Layer. In order to avoid this
waste of energy and increase its battery life, a typical battery-
operated device such as an IoT sensor or a smartphone will blindly
ignore a ratio of the broadcasts, making IPv6 ND operations even less
reliable.

It results that an IPv6 ND multicast message is processed by many of
the wireless nodes over the whole subnet (e.g., the ESS fabric)
though there are very few nodes subscribed to the multicast group,
and at most one intended target. Yet, the packet may be missed by
the intended target.

Though IPv6 ND was the state of the art when designed for an Ethernet
wire at the
efficient broadcast operation end of Ethernet Bridging. Since broadcast
can the twentieth century, it must be unreliable reevaluated for
the new technologies, such as wireless and overlays, that evolved
since then. This document discusses the applicability of IPv6 ND
over wireless media, DAD often fails links, as compared with routing-based alternatives such
as prefix-per node and multi-link subnets (MLSN), and with Wireless
ND (WiND), that is similar to discover
duplications [I-D.yourtchenko-6man-dad-issues]. In practice, IPv6
addresses very rarely conflict because of the entropy of Wi-Fi association and reduces the 64-bit
Interface IDs, not because address duplications are detected
need for Network-Layer multicast.

2. Acronyms

This document uses the following abbreviations:

6BBR: 6LoWPAN Backbone Router
6LN: 6LoWPAN Node
6LR: 6LoWPAN Router
ARO: Address Registration Option
DAC: Duplicate Address Confirmation
DAD: Duplicate Address Detection
DAR: Duplicate Address Request
EDAC: Extended Duplicate Address Confirmation
EDAR: Extended Duplicate Address Request
MLSN: Multi-link subnet
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

3. IPv6 ND, Wireless ND and
resolved. ND-Proxies

The IPv6 ND Neighbor Solicitation (NS) [RFC4861] message is used as a
multicast IP packet for
DAD and Address Resolution (AR) when a node moves, or wakes up and
reconnects to Duplicate Address
Setection (DAD) [RFC4862]. In those cases, the wireless network. The NS message is targeted 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. It must be noted that
in the Those messages are generated individually for each address,
and may occur when a node joins the case of Ethernet LANs as well as most WLANs network, moves, or wakes up and LPWANs,
reconnects to the Layer-3 multicast operation becomes a MAC_Layer broadcast network.

DAD was designed for the
lack of a Layer-2 multicast efficient broadcast operation that could handle a possibly
very large number of groups in order Ethernet.
Experiments show that DAD often fails to make discover the unicast efficient.
It results that duplication of
IPv6 ND messages addresses in large wireless access networks [DAD-ISSUES]. In
practice, IPv6 addresses very rarely conflict, not because the
address duplications are processed detected and resolved by most of the
wireless nodes over the subnet (e.g., DAD operation,
but thanks to the ESS fabric) regardless of
how few entropy of the nodes are subscribed to the SNMA. 64-bit Interface IDs (IIDs) that
makes a collision quasi-impossible for randomized IIDs.

IPv6 ND address Address Lookups and DADs over a very large fabric can
generate
hnudreds hundreds of broadcasts per second. If the broadcasts were
blindly copied over Wi-Fi and/or over a LowPower Lossy Network (LLN), Wi-Fi, the ND-
related ND-related multicast traffic could
consume enough bandwidth to cause a substantial degradation to the
unicast traffic service
[I-D.vyncke-6man-mcast-not-efficient]. [MCAST-EFFICIENCY]. To protect their bandwidth, some
networks throttle ND-related broadcasts, which reduces the capability of
for the ND protocol to perform operate as expected.

Conversely, 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 be dropped when they reach Layer-3. In order to avoid this
waste of energy and increase its battery life, a typical battery-
operated device such as an IoT sensor or a smartphone will blindly
ignore a ratio of the broadcasts, making IPv6 ND operations even less
reliable.

These problems

This problem can be alleviated by reducing the IPv6 ND broadcasts
over size of the broadcast
domain that encompasses wireless access links. This has been done in
the art of IP subnetting by splitting partitioning the
broadcast domains subnets and by routing
between subnets, them, at the extreme by assigning a /64 prefix to each
wireless node (see [RFC8273]).

Another way to split the broadcast domain within a subnet is to proxy
at the boundary of the wired and wireless domains the Layer-3 Network-Layer
protocols that rely on MAC Layer Link-Layer broadcast operations. For
instance, IEEE 802.11 [IEEEstd80211] situates proxy-
ARP recommends to deploy proxy-ARP
(IPv4) and proxy-ND (IPv6) functions at the Access Points (APs). But
proxying ND requires a perfect knowledge the full list 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 Forming and maintaining that knowledge a hard
problem in the general case.

Discovering peer 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 protocol as
proposed for SAVI [I-D.bi-savi-wlan] was found to
protocol, but that can also be unreliable. An IPv6 address may not
be discovered immediately due to a packet loss,
or if 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 node printer that waits in wake-on-lan
state. A change of state, anchor, e.g. due to a movement, may be missed or
misordered, leading to unreliable connectivity and an incomplete knowledge of the set list
of
peers. IPv6 addresses to be proxied for.

Wireless ND (WiND) introduces a new approach to IPv6 ND that is
designed to apply to the WLANs and WPANs 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 subnet and MAC-
level Link-
Layer domains are not congruent, which is common in those types of
networks unless a specific MAC-Level Link-Layer emulation is provided.

WiND applies routing inside the Subnets, subnets, which enables MultiLink Subnets. 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]. [ADDR-PROTECT].

The routing service can be a simple reflexion in a Hub-and-Spoke
Subnet
subnet that emulates an IEEE Std Std. 802.11 Infrastructure BSS at Layer
3. 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 Std. 802.11 Infrastructure ESS at Layer 3. WiND specifies the Network Layer,
as specified in the IPv6 Backbone Router for that purpose in [I-D.ietf-6lo-backbone-router]. [BB-ROUTER].

More details on WiND can be found in Section 4.1.

2. Acronyms

This document uses the following abbreviations:

6BBR: 6LoWPAN Backbone Router

6LBR: 6LoWPAN Border Router

6LN: 6LoWPAN Node

6LR: 6LoWPAN Router

ARO: Address Registration Option

DAC: Duplicate Address Confirmation

DAD: Duplicate Address Detection

DAR: Duplicate Address Request

EDAC: Extended Duplicate Address Confirmation

EDAR: Extended Duplicate Address Request

MLSN: Multi-Link Subnet

LLN: Low-Power and Lossy 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

WiND: Wireless Neighbor Discovery
WLAN: Wireless Local Area Network

WPAN: Wireless Personal Area Network

3. 5.1.

4. IP Models

3.1.

4.1. Physical Broadcast Domain

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
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-
point (P2P) link. It may also comprise multiple peer nodes on a
broadcast radio or a shared physical resource such as the legacy
Ethernet shared wire. yellow wire for which IPv6 ND was initially designed.

On WLAN and WPAN LoWPAN radios, the physical broadcast domain is defined
by a particular transmitter, as the set of nodes that can receive
what this transmitter is sending. Literally every datagram defines
its own broadcast domain since the chances of reception of a given
datagram are statistical. In average and in stable conditions, the
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
upper-layer abstraction can be built.

A PHY-layer communication can be established between 2 nodes if their
physical broadcast domains overlap. On WLAN and WPAN LoWPAN radios, this 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, uni-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 that
situation 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.

4.2. Link-Layer Broadcast Emulations

We define call Direct MAC-Layer MAC Broadcast (DMC) a (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 DMC DMB radios. This contrasts with a number of MAC-layer Link-Layer
Broadcast Emulation (LLBE) schemes that are described in the next this
section.

3.2. MAC-Layer Broadcast Emulations

While a physical broadcast domain is constrained to a single shared
wire, Ethernet Bridging emulates the broadcast properties of that
wire over a whole physical mesh of Ethernet links. For the upper
layer, the qualities of the shared wire are essentially conserved,
with a reliable and cheap broadcast operation over a closure of nodes
defined by their connectivity to the emulated wire.

In large switched fabrics, overlay techniques enable a limited
connectivity between nodes that are known to a mapping server. Map Resolver. The
emulated broadcast domain is configured to the system, e.g., with a
VXLAN network identifier (VNID). Broadcast operations on the overlay
can be emulated but can become very expensive, and it makes sense to
proactively install the relevant state in the mapping server as
opposed to rely on reactive broadcast lookups.

An IEEE Std Std. 802.11 Infrastructure Basic Service Set (BSS) also
provides a closure of nodes as defined by the broadcast domain of a
central Access Point (AP). AP. The AP relays both unicast and broadcast packets and
ensures a reflexive and transitive emulation of the shared wire
between the associated nodes, with the capability to signal link-up/link-down link-up/
link-down to the upper layer. Within an Infrastructure BSS, the
physical broadcast domain of the AP serves as emulated broadcast
domain for all the nodes that are associated to the AP. Broadcast
packets are relayed by the AP and are not acknowledged. To ensure increase
the chances that all nodes in the BSS receive the broadcast
transmission, AP transmits at the slowest PHY speed. This translates
into maximum co-channel interferences for others and the longest
occupancy of the medium, for a duration that can be 100 a hundred times
that of the unicast transmission of a unicast. frame of the same size. For
that reason, upper layer protocols should tend to avoid the use of
broadcast when operating over Wi-Fi.

In an IEEE Std Std. 802.11 Infrastructure Extended Service Set (ESS),
infrastructure BSSes are interconnected by a bridged network,
typically running Transparent Bridging and the Spanning tree
Protocol. In the original model of learning bridges, the forwarding
state in the
Transparent Bridge is set by observing the source MAC address of the frames. When
a state is missing for a destination MAC address, the frame is
broadcasted with the expectation that the response will populate the state.
state on the reverse path. This is a reactive operation, meaning
that the state is populated reactively to a the need for forwarding. to reach a
destination. It is also possible in the original model to send broadcast
a gratuitous frame to advertise self throughout the bridged network,
and that is also a broadcast.

In contrast, the

The process of the Wi-Fi association prepares a bridging state
proactively at the AP, which avoids the need for a reactive broadcast
lookup over the wireless access. The In an ESS, the AP may also generate
a gratuitous broadcast sourced at the MAC address of the STA to
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
evolves towards similar WiND emulates that
proactive methods method at Layer-3 the Network-Layer for its
operation the operations of address discovery (AD) AR, DAD
and duplicate address detection
(DAD). IPv6 ND proxy.

In some cases instances of WLAN WLANs and WPAN radios, LoWPANs, a mesh-under Mesh-Under technology
(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 well defined
well-defined by the membership of the mesh. Mesh-Under emulates a
broadcast domain by flooding the broadcast packets at Layer-2. the Link-Layer.
When operating on a single frequency, this operation is known to
interfere with itself,
forcing deployment and requires inter-frame gaps to introduce delays that dampen the collisions.
All in all,
collisions, which reduces further the mechanism is slow, inefficient and expensive. amount of available bandwidth.

Going down the list of cases above, the cost of a broadcast
transmissions becomes increasingly expensive, and there is a push to
rethink the upper-layer protocols so as to reduce the depency on
broadcast operations.

There again, a MAC-layer Link-Layer communication can be established between 2
nodes if their MAC-layer Link-Layer broadcast domains overlap. In the absence
of a MAC-layer Link-Layer emulation such as a mesh-under Mesh-Under or an Infrastructure
BSS, the MAC-layer 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 Out of the Context of without a BSS (DMC radios)
BSS, is an example of a network that does not have a
MAC-Layer Link-Layer
broadcast domain emulation, which means that it will exhibit mostly
reflexive and mostly non-transitive transmission properties.

3.3.

4.3. Mapping the IPv6 Link link Abstraction

IPv6 defines a concept of Link, Link link Scope and Link-Local Addresses
(LLA), an LLA being unique and usable only within the Scope of a
Link. The IPv6 Neighbor Discovery (ND) [RFC4861][RFC4862] Duplicate
Adress Detection (DAD) ND [RFC4861] DAD [RFC4862] process leverages uses a multicast
transmission to
ensure detect a duplicate address, which requires that an IPv6 address is unique as long as the
owner of the address is connected to the Link-Layer broadcast domain. It must be noted that
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 domain
of the destination group, all nodes
will receive the packet and process it all the way to Layer-3. sender.

On wired media, the Link link is often confused with the physical
broadcast domain because both are determined by the serial cable or
the Ethernet shared wire. Ethernet Bridging reinforces that illusion
by provising
with a MAC-Layer Link-Layer broadcast domain that emulates a physical broadcast
domain over the mesh of wires. But the difference shows on legacy
Non-Broadcast Multi-Access (NBMA) networks such as ATM and Frame-Relay, Frame-
Relay, on shared links and on newer types of NBMA networks such as
radio and composite radio-wires networks. It also shows when private
VLANs or
Layer-2 Link-Layer cryptography restrict the capability to read a
frame to a subset of the connected nodes.

In mesh-under Mesh-Under and Infrastructure BSS, the IP Link link extends beyond the
physical broadcast domain to the emulated MAC-Layer Link-Layer broadcast
domain. Relying on Multicast for the ND operation remains feasible
but becomes highly detrimental to the unicast traffic, energy-inefficient and
unreliable, more
energy-inefficient and its use is discouraged. unreliable as the network grows.

On DMC DMB radios, IP Links links between peers come and go as the individual
physical broadcast domains of the transmitters meet and overlap. The
DAD operation cannot provide once and for all guarantees on the
broadcast domain defined by one radio transmitter if that transmitter
keeps meeting new peers on the go. The nodes may need to form new
LLAs
Link-Local Addresses (LLAs) to talk to one another and the scope where LLA on
which the uniqueness can of an LLA must be
dynamically checked is that pair of nodes.
As long as there's no
conflict conflict, a node may use the same LLA with
multiple peers but it has to revalidate perform DAD with every each new peer node. In
practice, each pair of nodes defines a temporary P2P link, which can
be modeled as a sub-
interface sub-interface of the radio interface.

3.4.

4.4. Mapping the IPv6 Subnet subnet Abstraction

IPv6 also defines a the concept of Subnet a subnet for Glocal and Unique Local
Addresses. Addresses All the addresses in a same Subnet subnet share a the same prefix prefix, and
by extension, a node belongs to a Subnet subnet if it has an interface with an address on in
that Subnet. subnet. A Subnet subnet prefix is Globally Unique so it is sufficient
to validate that an address that is formed from a Subnet subnet prefix is
unique within that Subnet subnet to guarantee that it is globally unique.

The IPv6 aggregation model relies on the property that a packet from
the outside of a Subnet subnet can be routed to any router that belongs to
the Subnet, subnet, and that this router will be able to either resolve the
destination MAC Link-Layer address and deliver the packet, or route the
packet to the destination within the Subnet. subnet. If the Subnet subnet is known
as
onlink, on-link, then any node may also resolve the destination MAC Link-Layer
address and deliver the packet, but if the Subnet subnet is not onlink, on-link,
then a host in the subnet that does not have an NCE 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 subnet is often congruent with an IP Link link
because both are determined by the physical attachment to an Ethernet
shared wire or an IEEE Std. 802.1 bridged broadcast domain. In that
case, the connectivity over the Link link is transitive, the Subnet subnet can
appear as onlink, on-link, and any node can resolve a destination MAC address
of any other node directly using IPv6 Neighbor Discovery.

But an IP Link link and an IP Subnet subnet are not always congruent. In the
case of a
shared Link situation, a Subnet Shared Link, individual subnets may each encompass only a
subset of the nodes connected to the Link. link. In Route-Over Multi-Link Subnets Multi-link
subnets (MLSN) [RFC4903], routers federate the Links links between nodes
that belong to the Subnet, subnet, the Subnet subnet is not onlink on-link and it extends
beyond any of the federated Links. links.

5. Wireless Neighbor Discovery

5.1. Introduction to Wireless ND

The DAD and lookup AR procedures in IPv6 ND expects expect that a node in a
Subnet subnet
is reachable within the broadcast domain of any other node in the Subnet
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

4.1. Introduction to

WiND

Wireless Neighbor Discovery (WiND)
[RFC6775][RFC8505][I-D.ietf-6lo-backbone-router][I-D.ietf-6lo-ap-nd] [RFC6775][RFC8505][BB-ROUTER][ADDR-PROTECT] defines a new ND
operation for Neighbor Discovery that is based on 2 major paradigm
changes, proactive address registration by hosts to their attachment
routers and routing to host routes (/128) within the subnet. This
allows WiND to avoid the classical ND expectations of transit links and
Subnet-wide 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
NS/NA messages, the Extended Address Registration Option (EARO)
defiend
defined in [RFC8505]. This method allows to prepare and maintain the
host routes in the routers and avoids the reactive NS(Lookup) found Address Resolution
in IPv6 ND. This is a direct benefit for wireless Links since it
avoids ND and the MAC level broadcasts that are associated to NS(Lookup). Link-Layer broadcasts transmissions.

The EARO provides information to the router that is independent to
the routing protocol and routing can take multiple forms, from a
traditional IGP to a collapsed ub-and-Spoke Hub-and-Spoke model where only one
router owns and advertises the prefix. [RFC8505] is already
referenced for RIFT [I-D.ietf-rift-rift], RPL [RFC6550] with
[I-D.thubert-roll-unaware-leaves] and IPv6 ND proxy
[I-D.ietf-6lo-backbone-router].

WiND does not change IPv6 addressing [RFC4291] or as the current
practices of assigning prefixes to subnets. It is still typical to
assign a /64 to a subnet and to use registrtaion 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 to "RIFT: Routing in overlays with Map Resolvers Fat
Trees" [I-D.ietf-rift-rift] and enables unicast
lookups [I-D.thubert-6lo-unicast-lookup] "RPL: IPv6 Routing Protocol for addresses registered to
the resolver.
Low-Power and Lossy Networks" [RFC6550] with [RPL-UNAWARE-LEAVES].

WiND also enables to extend span a legacy /64 on Ethernet with ND proxy subnet over the wireless. an MLSN that federates edge
wireless links with a high-speed, typically Ethernet, backbone. This way
way, nodes can form any address the they 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])
wireless edge link to another, without renumbering. Backbone Routers federate multiple LLNs over a
Backbone Link to form a MultiLink Subnet (MLSN). Backbone Routers
(6BBRs) placed along the LLN wireless edge of the Backbone handle IPv6
Neighbor
Discovery, Discovery and forward packets on behalf of registered nodes.

An LLN node (6LN) registers all its IPv6 Addresses using an NS(EARO)
as specified in [RFC8505] to over the 6BBR. The 6BBR is also a Border
Router that performs IPv6 Neighbor Discovery (IPv6 ND) operations on
its Backbone interface backbone on behalf of
the 6LNs that have registered
addresses nodes on its LLN interfaces without the need of a broadcast over the wireless medium.

WiND is also compatible with DHCPv6 and other forms of address
assignment edge. For instance, a 6BBR in which case it
bridging proxy mode (more in [BB-ROUTER]) can still be used operate as a Layer-3 AP
to serve wireless IPv6 hosts that are Wi-Fi STAs and maintain the
reachability for DAD.

4.2. Links Global Unicast and Link-LOcal Addresses within the
federated MLSN.

5.2. links and Link-Local Addresses

For Link-Local Addresses, DAD is typically performed between
communicating pairs of nodes. It is carried out as part of a registration process
that is based on a NS/NA exchange that transports an EARO. During
that process, the DAD is validated nodes and a Neighbor Cache Entry (NCE)
is 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 instance, in the case of a Bluetooth Low Energy (BLE)
[RFC7668][IEEEstd802151] Hub-and Spoke configuration, Uniqueness
[RFC7668][IEEEstd802151], the uniqueness of
Link local Link-Local Addresses need
needs only to be verified between the pairs pair of communicating nodes, a
the central router and a the peripheral host. In that example, 2
peripheral hosts connected to the same central router can not have
the same Link Local Link-Local Address because the Binding Cache
Entries (BCEs) addresses would collide collision at
the central router which could not talk to both over the same
interface. The WiND DAD operation from WiND is appropriate for that DAD operation, use
case, but the one from ND is not, because the peripheral hosts are
not on the same broadcast domain.

On the other hand, the uniqueness of Global and ULA DAD Unique-Local
Addresses is validated at the Subnet subnet Level, using a logical registrar hosted by
that is global to the central router.

4.3. Subnets subnet.

5.3. subnets and Global Addresses

WiND extends IPv6 ND for Hub-and-Spoke (e.g., BLE) and Route-Over
(e.g., RPL) Multi-Link Subnets Multi-link subnets (MLSNs).

In the Hub-and-Spoke case, each Hub-Spoke pair is a distinct IP Link,
and a Subnet subnet can be mapped on a collection of Links links that are
connected to the Hub. The Subnet subnet prefix is associated to the Hub.

Acting as 6LR, routers, the Hub advertises the prefix as not-onlink not-on-link to
the spokes in RA messages Prefix Information Options (PIO). Acting
as
6LNs, hosts, the Spokes autoconfigure addresses from that prefix and
register them to the Hub with a corresponding lifetime. Acting as a
6LBR,
registrar, the Hub maintains a binding table of all the registered IP
addresses and rejects duplicate registrations, thus ensuring a DAD
protection for a registered address even if the registering node is
sleeping. Acting as 6LR, the The Hub also maintains an NCE for the registered addresses
and can deliver a packet to any of them for during their respective
lifetimes. It can be observed that this design builds a form of Layer-3
Network-Layer Infrastructure BSS.

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
the Subnet, subnet, and IPv6 routing takes place between the Hubs within the
Subnet.
subnet. A single logical 6LBR registrar is deployed to serve the whole
mesh.

The registration in [RFC8505] is abstract to the routing protocol and
provides enough information to feed a routing protocol such as RPL as
specified in [I-D.thubert-roll-unaware-leaves]. [RPL-UNAWARE-LEAVES]. In a degraded mode, all the Hubs
are connected to a same high speed backbone such as an Ethernet
bridging domain where IPv6 ND is operated. In that case, it is
possible to federate the Hub, Spoke and Backbone nodes as a single
Subnet,
subnet, operating IPv6 ND proxy operations
[I-D.ietf-6lo-backbone-router] [BB-ROUTER] at the Hubs,
acting as 6BBRs. It can be observed that this latter design builds a
form of Layer-3 Network-Layer Infrastructure ESS.

6. WiND Applicability

WiND allows P2P, applies equally to P2P links, P2MP hub-and spoke, MAC-level broadcast domain
emulation Hub-and-Spoke, Link-Layer
Broadcast Domain Emulation such as mesh-under Mesh-Under and Wi-Fi BSS, and
Route-Over meshes.

There is an intersection where Link link and Subnet subnet are congruent and
where both ND and WiND could apply. These includes P2P, the MAC
emulation of a PHY broadcast domain, and the particular case of
always on, fully overlapping physical radio broadcast domain. But
even in those cases where both are possible, WiND is preferable vs.
ND because it reduces the need of broadcast ( this broadcast.

This is discussed in more details in the introduction of [I-D.ietf-6lo-backbone-router]). [BB-ROUTER].

There are also numerous a number of practical use cases in the wireless world
where Links links and Subnets subnets are not P2P and not congruent:

* The IEEE std Std. 802.11 infrastructure BSS enables one subnet per AP,
and emulates a broadcast domain at L2. Infra the Link-Layer. The
Infrastructure ESS extends that model over a backbone and
recommends to the use of an IPv6 ND proxy [IEEEstd80211] to coexist
interoperate with
Ethernet connected Ethernet-connected nodes. WiND incorporates an
ND proxy to serve that need and that need, which was missing so far.

* BlueTooth is Hub-and-Spoke at the MAC layer. Link-Layer. It would make
little sense to configure a different subnet between the central
and each individual peripheral node (e.g., sensor). Rather,
[RFC7668] allocates a prefix to the central node acting as router (6LR), router,
and each peripheral host (acting as a host (6LR) host) forms one or more
address(es) from that same prefix and registers it.

* A typical Smartgrid networks puts together Route-Over MLSNs that
comprise thousands of IPv6 nodes. The 6TiSCH architecture
[I-D.ietf-6tisch-architecture] presents the Route-Over model over
a [IEEEstd802154]
an IEEE Std. 802.15.4 Time-Slotted Channel-Hopping (TSCH)
[IEEEstd802154] mesh, and generalizes it for multiple other
applications.

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 constrained, talking to them is a bad idea 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 links and maintain as many addresses in all
nodes is not even considered.

5.1.

6.1. Case of LPWANs

LPWANs are by nature so constrained that the addresses and Subnets subnets
are fully pre-configured and operate as P2P or Hub-and-Spoke. This
saves the steps of neighbor Discovery and enables a very efficient
stateful compression of the IPv6 header.

5.2.

6.2. Case of Infrastructure BSS and ESS

In contrast to IPv4, IPv6 enables a node to form multiple addresses,
some of them temporary to elusive, and with a particular attention
paid to privacy. Addresses may be formed and deprecated
asynchronously to the association. Even if the knowledge of IPv6
addresses used by a STA can be obtained by snooping

Snooping protocols such as IPv6 ND and DHCPv6, or by DHCPv6 and observing data
traffic sourced at the STA,
such methods provide only STA provides an imperfect knowledge of the
state of the STA at the AP. This Missing a state or a transition may
result in a the loss of connectivity for some
IPv6 of the addresses, in
particular for addresses an address that is rarely used and used, belongs to a sleeping
node, or one in a situation of mobility. This may also result in
undesirable remanent state in the AP when a the STA ceases to use an
IPv6 address. address while remaining associated. It results that snooping
protocols is not a recommended technique and that it should only be
used as last resort. resort, when the WiND registration is not available to
populate the state.

The recommended alternate alternative method is to use the IPv6 WiND Registration method
speficied in p. By that method,
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 one or more all of its IPv6 addresses,
using an the Extended Address Registration Option. Option, which provides the
following elements:

* The Registration registration state has a lifetime that limits unwanted state
remanence in the network.

* The registration is optionally secured using
[I-D.ietf-6lo-ap-nd] [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 a
loss of connectivity.

The ESS mode requires a proxy ND operation at the AP. The proxy ND
operation must cover Duplicate Address Detection, Neighbor
Unreachability Detection, Address Resolution and Address Mobility to
transfer a role of ND proxy to the AP where a STA is associated
following the mobility of the STA.

The WiND proxy ND specification that associated to the address registration Address
Registration is
[I-D.ietf-6lo-backbone-router]. [BB-ROUTER]. With that specification, the AP
participates to the protocol as a Backbone Router, typically
operating as a bridging proxy though the routing proxy operation is
also possible. As a bridging proxy, the proxy backbone router either
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
the STA answer. For the data plane, the backbone router acts as a
normal AP and then bridges the packets to the STA
normally; as usual. As a routing
proxy, it 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.

6.3. Case of Mesh Under Technologies

The Mesh-Under provides a broadcast domain emulation with reflexive
and Transitive properties and defines a transit Link link for IPv6
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
Point does in a BSS/ESS.

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.

5.4.

6.4. Case of DMC DMB radios

IPv6 over DMC DMB radios uses P2P Links links that can be formed and maintained
when a pair of DMC DMB radios transmitters are in range from one another.

5.4.1.

6.4.1. Using IPv6 ND only

DMC

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
but does not provide the BSS functions.

It is possible to form P2P IP Links links between each individual pairs of
nodes and operate IPv6 ND over those Links links with Link Local Link-Local addresses.
DAD must be performed for all addresses on all P2P IP Links. links.

If special deployment care is taken so that the physical broadcast
domains of a collection of the nodes fully overlap, then it is also
possible to build an IP Subnet subnet within that collection of nodes and
operate IPv6 ND.

The model can be stretched beyond the scope of IPv6 ND if

If an external mechanism avoids duplicate addresses and if the
deployment ensures the connectivity between peers. This can be achieved for instance in peers, a Hub-and-Spoke non-transit Hub-
and-Spoke deployment if is also possible where the Hub is the only
router in the
Subnet subnet and the Prefix is advertised as not onlink.

5.4.2. on-link.

6.4.2. Using Wireless ND

Though this can be achieved with IPv6 ND, WiND is the recommended
approach since it uses more unicast communications which are more reliable
and less impacting for other users of the medium.

Router and Hosts respectively

The routers send a compressed RA/NA RAs with a SLLAO at a regular period. The period
can be indicated in a RA as in an RA-
Interval the RA-Interval Option [RFC6275]. If available,
the message can be transported in a compressed form in a beacon,
e.g., in OCB Basic Safety Messages (BSM) that are nominally sent
every 100ms.

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
Internet Access may advertise itself as a default router [RFC4191] in
its RA. RA messages. The NA/RA RA is sent over an Unspecified Link unspecified link where it
does not conflict to anyone, so DAD is not necessary at that stage.

The receiver host instantiates a Link link where the sender's router's address is not a
duplicate. To achieve this, it forms an LLA that does not conflict
with that of the sender router and registers to the sender router using [RFC8505].
If the sender router sent an RA(PIO) RA(PIO), the receiver host can also autoconfigure an
address from the advertised prefix and register it.

6LoWPAN Node 6LR
(RPL leaf)

(host) (router)
| |
| LLN DMB link |
| |
| IPv6 ND RS |
|-------------->|
|-----------> |
|------------------>
| IPv6 ND RA |
|<--------------|
| |
| NS(EARO) |
|-------------->|
| |
| NA(EARO) |
|<--------------|
| |

Figure 1: Initial Registration Flow

The lifetime in the registration should start with a small value
(X=RMin, TBD), and exponentially grow with each reregistration re-registration to a
mlarger
larger value (X=Rmax, TBD). The IP Link link is considered down when
(X=NbBeacons, TDB) expected messages are not received in a row. It
must be noted that the Link link flapping does not affect the state of the
registration and when a Link link comes back up, the active -lifetime not
elapsed- registrations
(i.e., registrations for which lifetime is not elapsed) are still
usable. Packets should be held or destroyed when the Link link is down.

P2P Links links may be federated in Hub-and-Spoke and then in Route-Over
MLSNs as described above. 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
4.2.2 of [I-D.ietf-6tisch-architecture].

6LoWPAN Node 6LR 6LBR 6BBR
(RPL leaf) (router) (root)
| | | |
| 6LoWPAN ND |6LoWPAN ND+RPL | 6LoWPAN ND | IPv6 ND
| LLN link |Route-Over mesh|Ethernet/serial| Backbone
| | | |
| IPv6 ND RS | | |
|-------------->| | |
|-----------> | | |
|------------------> | |
| IPv6 ND RA | | |
|<--------------| | |
| | <once> | |
| NS(EARO) | | |
|-------------->| | |
| 6LoWPAN ND | Extended DAR | |
| |-------------->| |
| | | NS(EARO) |
| | |-------------->|
| | | | NS-DAD
| | | |------>
| | | | (EARO)
| | | |
| | | NA(EARO) |<timeout>
| | |<--------------|
| | Extended DAC | |
| |<--------------| |
| NA(EARO) | | |
|<--------------| | |
| | | |

Figure 2: Initial Registration Flow over Multi-Link Subnet Multi-link subnet

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
Units (OBUs) within its physical broadcast domain. An example of
Route-Over MLSN is a collection of cars in a parking lot operating
RPL to extend the connectivity provided by the RSU beyond its
physical broadcast domain. Cars may then operate NEMO [RFC3963] for
their own prefix using their address derived from the prefix of the
RSU as CareOf Address.

7. IANA Considerations

This specification does not require IANA action.

8. Security Considerations

This specification refers to the security sections of IPv6 ND and
WiND, respectively.

9. Acknowledgments

Many thanks to the participants of the 6lo WG where a lot of the work
discussed here happened. Also ROLL, 6TiSCH, and 6LoWPAN.

9. References

9.1.

10. 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.
Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, DOI 10.17487/RFC3963, January 2005,
<https://www.rfc-editor.org/info/rfc3963>.

[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
November 2005, <https://www.rfc-editor.org/info/rfc4191>.

[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.

[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>.

[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
2011, <https://www.rfc-editor.org/info/rfc6275>.

[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.

[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
Perkins, "Registration Extensions for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Neighbor
Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
<https://www.rfc-editor.org/info/rfc8505>.

9.2. Informative References

[I-D.bi-savi-wlan]
Bi, J., Wu, J., Wang, Y.,

[ADDR-PROTECT]
Thubert, P., Sarikaya, B., Sethi, M., and T. Lin, "A SAVI Solution R. Struik,
"Address Protected Neighbor Discovery for
WLAN", draft-bi-savi-wlan-17 (work Low-power and
Lossy Networks", Work in progress), May 2019.

[I-D.ietf-6tisch-architecture] Progress, Internet-Draft, draft-
ietf-6lo-ap-nd-20, 9 March 2020,
<https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-20>.

[BB-ROUTER]
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] Perkins, C., McBride, M., Stanley, and E. Levy-Abegnoli, "IPv6
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>.

11. Informative References

[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.

[RFC4903] Thaler, D., Kumari, W., "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 J.
Zuniga, "Multicast Considerations 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 IEEE 802
Low-Power Wireless
Media", draft-ietf-mboned-ieee802-mcast-problems-08 (work
in progress), August 2019. 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]
Przygienda, T., Sharma, A., Thubert, P., Rijsman, B., and
D. Afanasiev, "RIFT: Routing in Fat Trees", draft-ietf-rift-rift-08
(work Work in progress), September 2019.

[I-D.thubert-6lo-unicast-lookup]
Progress, Internet-Draft, draft-ietf-rift-rift-11, 10
March 2020,
<https://tools.ietf.org/html/draft-ietf-rift-rift-11>.

[RPL-UNAWARE-LEAVES]
Thubert, P. and E. Levy-Abegnoli, "IPv6 Neighbor Discovery
Unicast Lookup", draft-thubert-6lo-unicast-lookup-00 (work
in progress), January 2019.

[I-D.thubert-roll-unaware-leaves]
Thubert, P., M. Richardson, "Routing for RPL Leaves", draft-thubert-roll-
unaware-leaves-07 (work in progress), April 2019.

[I-D.vyncke-6man-mcast-not-efficient]
Work in Progress, Internet-Draft, draft-ietf-roll-unaware-
leaves-13, 17 March 2020, <https://tools.ietf.org/html/
draft-ietf-roll-unaware-leaves-13>.

[DAD-ISSUES]
Yourtchenko, A. and E. Nordmark, "A survey of issues
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>.

[MCAST-EFFICIENCY]
Vyncke, E., Thubert, P., Levy-Abegnoli, E., and A.
Yourtchenko, "Why Network-Layer Multicast is Not Always
Efficient At Datalink Layer", draft-vyncke-6man-mcast-not-
efficient-01 (work Work in progress), Progress, Internet-
Draft, draft-vyncke-6man-mcast-not-efficient-01, 14
February 2014.

[I-D.yourtchenko-6man-dad-issues]
Yourtchenko, A. 2014, <https://tools.ietf.org/html/draft-vyncke-
6man-mcast-not-efficient-01>.

[I-D.ietf-6tisch-architecture]
Thubert, P., "An Architecture for IPv6 over the TSCH mode
of IEEE 802.15.4", Work in Progress, Internet-Draft,
draft-ietf-6tisch-architecture-28, 29 October 2019,
<https://tools.ietf.org/html/draft-ietf-6tisch-
architecture-28>.

[MCAST-PROBLEMS]
Perkins, C., McBride, M., Stanley, D., Kumari, W., and E. Nordmark, 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 survey of issues
related to IPv6 Duplicate Address Detection", draft-
yourtchenko-6man-dad-issues-01 (work SAVI Solution for
WLAN", Work in progress), March
2015. 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]
IEEE standard for Information Technology, "IEEE Std.
802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)
and Physical Layer (PHY) Specifications for Low-Rate
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]
IEEE standard for Information Technology, "IEEE Standard
for Information technology -- Telecommunications and
information exchange between systems Local and
metropolitan area networks-- Specific requirements Part
11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) Specifications".

[IEEEstd802151]
IEEE standard for Information Technology, "IEEE Standard
for Information Technology - Telecommunications and
Information Exchange Between Systems - Local and
Metropolitan Area Networks - Specific Requirements. - Part
15.1: Wireless Medium Access Control (MAC) and Physical
Layer (PHY) Specifications for Wireless Personal Area
Networks (WPANs)".

[IEEEstd802154]
IEEE standard for Information Technology, "IEEE Standard
for Local and metropolitan area networks -- Part 15.4:
Low-Rate Wireless Personal Area Networks (LR-WPANs)".

[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.

[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

[IEEEstd8021]
IEEE standard 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 Information Technology, "IEEE Standard
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., Information technology -- Telecommunications 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.
information exchange between systems Local 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>.
metropolitan area networks Part 1: Bridging and
Architecture".

Author's Address
Pascal Thubert (editor)
Cisco Systems, Inc
Building D
45 Allee des Ormes - BP1200
MOUGINS
06254 Mougins - Sophia Antipolis 06254
FRANCE
France

Phone: +33 497 23 26 34
Email: pthubert@cisco.com