< draft-thubert-6man-ipv6-over-wireless-08.txt   draft-thubert-6man-ipv6-over-wireless-09.txt >
6MAN P. Thubert, Ed. 6MAN P. Thubert, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Informational 24 November 2020 Intended status: Informational 17 May 2021
Expires: 28 May 2021 Expires: 18 November 2021
IPv6 Neighbor Discovery on Wireless Networks IPv6 Neighbor Discovery on Wireless Networks
draft-thubert-6man-ipv6-over-wireless-08 draft-thubert-6man-ipv6-over-wireless-09
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 28 May 2021. This Internet-Draft will expire on 18 November 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. ND-Classic, Wireless ND and ND-Proxies . . . . . . . . . . . 4 2.1. IP Links . . . . . . . . . . . . . . . . . . . . . . . . 4
4. IP Models . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. IP Subnets . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Physical Broadcast Domain . . . . . . . . . . . . . . . . 6 2.3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Link Layer Broadcast Emulations . . . . . . . . . . . . . 7 3. ND-Classic, Wireless ND and ND-Proxies . . . . . . . . . . . 6
4.3. Mapping the IPv6 link Abstraction . . . . . . . . . . . . 9 4. IP Models . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Mapping the IPv6 subnet Abstraction . . . . . . . . . . . 10 4.1. Physical Broadcast Domain . . . . . . . . . . . . . . . . 8
5. Wireless Neighbor Discovery . . . . . . . . . . . . . . . . . 11 4.2. link-layer Broadcast Emulations . . . . . . . . . . . . . 9
5.1. Introduction to Wireless ND . . . . . . . . . . . . . . . 11 4.3. Mapping the IPv6 link Abstraction . . . . . . . . . . . . 11
5.2. links and Link-Local Addresses . . . . . . . . . . . . . 12 4.4. Mapping the IPv6 subnet Abstraction . . . . . . . . . . . 12
5.3. subnets and Global Addresses . . . . . . . . . . . . . . 12 5. Wireless Neighbor Discovery . . . . . . . . . . . . . . . . . 13
6. WiND Applicability . . . . . . . . . . . . . . . . . . . . . 13 5.1. Introduction to Wireless ND . . . . . . . . . . . . . . . 13
6.1. Case of LPWANs . . . . . . . . . . . . . . . . . . . . . 14 5.2. links and Link-Local Addresses . . . . . . . . . . . . . 14
6.2. Case of Infrastructure BSS and ESS . . . . . . . . . . . 14 5.3. subnets and Global Addresses . . . . . . . . . . . . . . 14
6.3. Case of Mesh Under Technologies . . . . . . . . . . . . . 15 6. WiND Applicability . . . . . . . . . . . . . . . . . . . . . 15
6.4. Case of DMB radios . . . . . . . . . . . . . . . . . . . 16 6.1. Case of LPWANs . . . . . . . . . . . . . . . . . . . . . 16
6.4.1. Using ND-Classic only . . . . . . . . . . . . . . . . 16 6.2. Case of Infrastructure BSS and ESS . . . . . . . . . . . 16
6.4.2. Using Wireless ND . . . . . . . . . . . . . . . . . . 16 6.3. Case of Mesh Under Technologies . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6.4. Case of DMB radios . . . . . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6.4.1. Using ND-Classic only . . . . . . . . . . . . . . . . 18
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 6.4.2. Using Wireless ND . . . . . . . . . . . . . . . . . . 18
10. Normative References . . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
11. Informative References . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
10. Normative References . . . . . . . . . . . . . . . . . . . . 21
11. Informative References . . . . . . . . . . . . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
[IEEE Std. 802.1] Ethernet Bridging provides an efficient and IEEE Std. 802.1 [IEEE Std. 802.1] Ethernet Bridging provides an
reliable broadcast service for wired networks; applications and efficient and reliable broadcast service for wired networks;
protocols have been built that heavily depend on that feature for applications and protocols have been built that heavily depend on
their core operation. Unfortunately, Low-Power Lossy Networks (LLNs) that feature for their core operation. Unfortunately, Low-Power
and Wireless Local Area Networks (WLANs) generally do not benefit Lossy Networks (LLNs) and Wireless Local Area Networks (WLANs)
from the same reliable and cheap broadcast capabilities as Ethernet generally do not benefit from the same reliable and cheap broadcast
links. capabilities as Ethernet links.
As opposed to unicast transmissions, the broadcast transmissions over As opposed to unicast transmissions, the broadcast transmissions over
wireless links are not subject to automatic retries (ARQ) and can be wireless links are not subject to automatic retries (ARQ) and can be
very unreliable. Reducing the speed at the physical (PHY) layer for very unreliable. Reducing the speed at the physical (PHY) layer for
broadcast transmissions can increase the reliability, at the expense broadcast transmissions can increase the reliability, at the expense
of a higher relative cost of broadcast on the overall available of a higher relative cost of broadcast on the overall available
bandwidth. As a result, protocols designed for bridged networks that bandwidth. As a result, protocols designed for bridged networks that
rely on broadcast transmissions often exhibit disappointing rely on broadcast transmissions often exhibit disappointing
behaviours when employed unmodified on a local wireless medium (see behaviours when employed unmodified on a local wireless medium (see
[MCAST PROBLEMS]). [MCAST PROBLEMS]).
Like Transparent Bridging, the IPv6 [RFC8200] Neighbor Discovery Like Transparent Bridging, the IPv6 [RFC8200] Neighbor Discovery
[RFC4861] [RFC4862] Protocol (ND-Classic) is reactive, and relies on [RFC4861] [RFC4862] Protocol (ND-Classic) is reactive, and relies on
on-demand Network Layer multicast to locate an on-link correspondent on-demand Network Layer multicast to locate an on-link correspondent
(Address Resolution, AR) and ensure the uniqueness of an IPv6 address (Address Resolution, AR) and ensure the uniqueness of an IPv6 address
(Duplicate Address Detection, DAD). On Ethernet LANs and most WLANs (Duplicate Address Detection, DAD). On Ethernet LANs and most WLANs
and Low-Power Personal Area Networks (LoWPANs), the Network Layer and Low-Power Personal Area Networks (LoWPANs), the Network Layer
multicast operation is typically implemented as a Link Layer multicast operation is typically implemented as a link-layer
broadcast for the lack of an adapted and scalable Link Layer broadcast for the lack of an adapted and scalable link-layer
multicast operation. multicast operation.
It results that on wireless, an ND-Classic multicast message is It results that on wireless, an ND-Classic multicast message is
typically broadcasted. So even though there are very few nodes typically broadcasted. So even though there are very few nodes
subscribed to the Network Layer multicast group, and there is at most subscribed to the Network Layer multicast group, and there is at most
one intended Target, the broadcast is received by many wireless nodes one intended Target, the broadcast is received by many wireless nodes
over the whole subnet (e.g., the ESS fabric). And yet, the broadcast over the whole subnet (e.g., the ESS fabric). And yet, the broadcast
transmission being unreliable, the intended Target may effectively transmission being unreliable, the intended Target may effectively
have missed the packet. have missed the packet.
skipping to change at page 3, line 38 skipping to change at page 4, line 12
ignore a ratio of the broadcasts, making ND-Classic operations even ignore a ratio of the broadcasts, making ND-Classic operations even
less reliable. less reliable.
Wi-Fi [IEEE Std. 802.11] Access Points (APs) deployed in an Extended Wi-Fi [IEEE Std. 802.11] Access Points (APs) deployed in an Extended
Service Set (ESS) act as [IEEE Std. 802.1] bridges between the Service Set (ESS) act as [IEEE Std. 802.1] bridges between the
wireless stations (STA) and the wired backbone. As opposed to the wireless stations (STA) and the wired backbone. As opposed to the
classical Transparent (aka Learning) Bridge operation that installs classical Transparent (aka Learning) Bridge operation that installs
the forwarding state reactively to traffic, the bridging state in the the forwarding state reactively to traffic, the bridging state in the
AP is established proactively, at the time of association. This 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 lookups. The association process registers the Link Layer Bridging lookups. The association process registers the link-layer
(MAC) Address (LLA) of the STA to the AP proactively, i.e., before it (MAC) Address (LLA) of the STA to the AP proactively, i.e., before it
is needed. The AP maintains the list of the associated addresses and is needed. The AP maintains the list of the associated addresses and
blocks the lookups for destinations that are not registered. This blocks the lookups for destinations that are not registered. This
solves the broadcast issue for the Link Layer lookups, but the solves the broadcast issue for the link-layer lookups, but the
Network Layer problem remains. Network Layer problem remains.
Though ND-Classic was the state of the art when designed for an Though ND-Classic was the state of the art when designed for an
Ethernet wire at the end of the twentieth century, it must be Ethernet wire at the end of the twentieth century, it must be
reevaluated for the new technologies, such as wireless and overlays, reevaluated for the new technologies, such as wireless and overlays,
that evolved since then. This document discusses the applicability that evolved since then. This document discusses the applicability
of ND-Classic over wireless links, as compared with routing-based of ND-Classic over wireless links, as compared with routing-based
alternatives such as prefix-per node and multi-link subnets (MLSN), alternatives such as prefix-per node and multi-link subnets (MLSN),
and with Wireless ND (WiND), that is similar to the Wi-Fi association and with Wireless ND (WiND), that is similar to the Wi-Fi association
and reduces the need for Network Layer multicast. and reduces the need for Network Layer multicast.
2. Acronyms 2. Terminology
2.1. IP Links
For a long time, the term link has been used to refer to the layer 2
communication medium that can be leveraged at layer 3 to instantiate
one IP hop. In this document we conserve that term but differentiate
it from an IP link, which is a layer 3 abstraction that represents
the layer 2 link but is not the layer 2 link, like the map is not the
country.
With IPv6, IP has moved to layer 3 abstractions for its operations,
e.g., with the use of link local address (LLA), and that of IP
multicast for link-scoped operations. At the same time, the concept
of an IP link emerged as an abstraction that represents how the IPv6
considers the layer 2 link:
* An IP link connects an IP node to one or more other IP nodes using
a lower layer network. The lower layer network may comprise
multiple lower layer links, e.g., in the case of a switched fabric
or a mesh-under LLN.
* an IP link defines the scope of an LLA, and defines the domain in
which the LLA must be unique
* an IP link provides a subset of the connectivity that is offered
by the lower layer; if the IP link is narrower than the layer 2
reachable domain, then layer 3 filters must restrict the link-
scoped communication to remain between peers on a same IP link,
and more than one IP link may be installed on the same physical
interface to connect to different peers.
* an IP link can be Point to Point (P2P), Point to Point (P2MP,
forming a partial mesh), NBMA (non-broadcast multi-access, fully
meshed), or transit (broadcast-capable and any-to-any).
It is a network design decision to use one IP link model or another
over a given lower layer network, e.g., to map a Frame Relay network
as a P2MP IP link, or as a collection of P2P IP links. As another
example, an Ethernet fabric may be bridged, in which case the nodes
that interconnect the layer 2 links are L2 switches, and the fabric
can be abstracted as a single transit IP link; or the fabric can be
routed, in which case the P2P IP links are congruent with the layer 2
links, and the nodes that interconnect the links are routers.
2.2. IP Subnets
IPv6 builds another abstraction, the subnet, over one shared or over
multiple IP links, forming a MLSN in the latter case. An MLSN is
formed over IP links (e.g., P2P or P2MP) that are interconnected by
routers that either inject hosts routes in an IGP, in which case the
topology can be anything, or perform ND proxy operations, in which
case the structure of links must be strictly hierarchical to avoid
loops.
[RFC8929] defines bridging and routing IPv6 ND proxies. Both forms
of ND proxies interconnect IP links and enable to isolate the layer 2
broadcast domains. But in the case of a bridging proxy, the layer 2
unicast communication can still exist between the layer 2 domains
that are coverered by the layer 3 links, whereas in the base of a
routing proxy, they are isolated and packets must be routed back and
forth. Bridging proxies are possible between compatible technologies
and translational bridges (e.g., Wi-Fi to Ethernet), whereas routing
proxies are required between non-bridgeable technologies and
desirable to avoid exposing the layer 2 addresses across, e.g., for
reasons of stability and scalability.
It is another network design decision to use one IP subnet model or
another over a given lower layer network. A switched fabric can host
one or more IP subnets, in which case the IP links can reach all and
beyond one subnet. On the other hand, a subnet can encompass a
collection of links; in that case, the scope of the link local
addresses, which is the IP Link, is narrower than that of the subnet.
The switched and routed fabric above could be the exact same network
of physical links and boxes, what changes is the way the networking
abstractions are mapped onto the system, and the implication of such
decision include the capability to reach another node at layer-2, and
the size of the broadcast domain and related broadcast storms.
2.3. Acronyms
This document uses the following abbreviations: This document uses the following abbreviations:
6BBR: 6LoWPAN Backbone Router 6BBR: 6LoWPAN Backbone Router
6LN: 6LoWPAN Node 6LN: 6LoWPAN Node
6LR: 6LoWPAN Router 6LR: 6LoWPAN Router
ARO: Address Registration Option ARO: Address Registration Option
DAC: Duplicate Address Confirmation DAC: Duplicate Address Confirmation
DAD: Duplicate Address Detection DAD: Duplicate Address Detection
DAR: Duplicate Address Request DAR: Duplicate Address Request
skipping to change at page 5, line 23 skipping to change at page 7, line 31
ND protocol to operate as expected. ND protocol to operate as expected.
This problem can be alleviated by reducing the size of the broadcast This problem can be alleviated by reducing the size of the broadcast
domain that encompasses wireless access links. This has been done in domain that encompasses wireless access links. This has been done in
the art of IP subnetting by partitioning the subnets and by routing the art of IP subnetting by partitioning the subnets and by routing
between them, at the extreme by assigning a /64 prefix to each between them, at the extreme by assigning a /64 prefix to each
wireless node (see [RFC8273]). wireless node (see [RFC8273]).
Another way to split the broadcast domain within a subnet is to proxy Another way to split the broadcast domain within a subnet is to proxy
at the boundary of the wired and wireless domains the Network Layer at the boundary of the wired and wireless domains the Network Layer
protocols that rely on Link Layer broadcast operations. [IEEE Std. protocols that rely on link-layer broadcast operations. [IEEE Std.
802.11] recommends to deploy proxies for the IPv4 Address Resolution 802.11] recommends to deploy proxies for the IPv4 Address Resolution
Protocol (ARP) and IPv6 ND at the APs. This requires the exhaustive Protocol (ARP) and IPv6 ND at the APs. This requires the exhaustive
list of the IP addresses for which proxying is provided. Forming and list of the IP addresses for which proxying is provided. Forming and
maintaining that knowledge a hard problem in the general case of maintaining that knowledge a hard problem in the general case of
radio connectivity, which keeps changing with movements and radio connectivity, which keeps changing with movements and
variations in the environment that alter the range of transmissions. variations in the environment that alter the range of transmissions.
[SAVI] suggests to discover the addresses by snooping the ND-Classic [SAVI] suggests to discover the addresses by snooping the ND-Classic
protocol, but that can also be unreliable. An IPv6 address may not protocol, but that can also be unreliable. An IPv6 address may not
be discovered immediately due to a packet loss. It may never be be discovered immediately due to a packet loss. It may never be
skipping to change at page 5, line 45 skipping to change at page 8, line 4
one of its addresses, e.g., a printer that waits in wake-on-lan one of its addresses, e.g., a printer that waits in wake-on-lan
state. A change of anchor, e.g. due to a movement, may be missed or state. A change of anchor, e.g. due to a movement, may be missed or
misordered, leading to unreliable connectivity and an incomplete list misordered, leading to unreliable connectivity and an incomplete list
of addresses. of addresses.
Wireless ND (WiND) introduces a new approach to IPv6 Neighbor Wireless ND (WiND) introduces a new approach to IPv6 Neighbor
Discovery that is designed to apply to the WLANs and LoWPANs types of Discovery that is designed to apply to the WLANs and LoWPANs types of
networks, as well as other Non-Broadcast Multi-Access (NBMA) networks networks, as well as other Non-Broadcast Multi-Access (NBMA) networks
such as Data-Center overlays. WiND applies routing inside the such as Data-Center overlays. WiND applies routing inside the
subnets, which enables to form potentially large MLSNs without subnets, which enables to form potentially large MLSNs without
creating a large broadcast domain at the Link Layer. In a fashion creating a large broadcast domain at the link-layer. In a fashion
similar to a Wi-Fi Association, IPv6 Hosts register their addresses similar to a Wi-Fi Association, IPv6 Hosts register their addresses
to their serving router(s), using [RFC8505]. With the registration, to their serving router(s), using [RFC8505]. With the registration,
the routers have a complete knowledge of the hosts they serve and in the routers have a complete knowledge of the hosts they serve and in
return, hosts obtain routing services for their registered addresses. return, hosts obtain routing services for their registered addresses.
The registration is abstract to the routing service, and it can be The registration is abstract to the routing service, and it can be
protected to prevent impersonation attacks with [RFC8928]. protected to prevent impersonation attacks with [RFC8928].
The routing service can be a simple reflexion in a Hub-and-Spoke The routing service can be a simple reflexion in a Hub-and-Spoke
subnet that emulates an IEEE Std. 802.11 Infrastructure BSS at the subnet that emulates an IEEE Std. 802.11 Infrastructure BSS at the
Network Layer. It can also be a full-fledge routing protocol, in Network Layer. It can also be a full-fledge routing protocol, in
particular RPL [RFC6550], which is designed to adapt to various LLNs particular RPL [RFC6550], which is designed to adapt to various LLNs
such as WLAN and WPAN radio meshes. Finally, the routing service can such as WLAN and WPAN radio meshes. Finally, the routing service can
also be an ND proxy that emulates an IEEE Std. 802.11 Infrastructure also be an ND proxy that emulates an IEEE Std. 802.11 Infrastructure
ESS at the Network Layer, as specified in the IPv6 Backbone Router ESS at the Network Layer, as specified in the IPv6 Backbone Router
[RFC8929]. [RFC8929].
On the one hand, WiND avoids the use of broadcast operation for DAD 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 AR, and on the other hand, WiND supports use cases where subnet
and Link Layer domains are not congruent, which is common in wireless and link-layer domains are not congruent, which is common in wireless
networks unless a specific Link Layer emulation is provided. More networks unless a specific link-layer emulation is provided. More
details on WiND can be found in Section 5.1. details on WiND can be found in Section 5.1.
4. IP Models 4. IP Models
4.1. Physical Broadcast Domain 4.1. Physical Broadcast Domain
At the physical (PHY) Layer, a broadcast domain is the set of nodes At the physical (PHY) Layer, a broadcast domain is the set of nodes
that may receive a transmission that one sends over an interface, in that may receive a transmission that one sends over an interface, in
other words the set of nodes in range of the radio transmission. other words the set of nodes in range of the radio transmission.
This set can comprise a single peer on a serial cable used as point- This set can comprise a single peer on a serial cable used as point-
skipping to change at page 7, line 12 skipping to change at page 9, line 20
that the connectivity becomes mostly uni-directional, e.g., A to B that the connectivity becomes mostly uni-directional, e.g., A to B
but practically not B to A. but practically not B to A.
It takes a particular effort to place a set of devices in a fashion It takes a particular effort to place a set of devices in a fashion
that all their physical broadcast domains fully overlap, and that that all their physical broadcast domains fully overlap, and that
specific situation can not be assumed in the general case. In other specific situation can not be assumed in the general case. In other
words, the relation of radio connectivity is generally not words, the relation of radio connectivity is generally not
transitive, meaning that A in range with B and B in range with C does transitive, meaning that A in range with B and B in range with C does
not necessarily imply that A is in range with C. not necessarily imply that A is in range with C.
4.2. Link Layer Broadcast Emulations 4.2. link-layer Broadcast Emulations
We call Direct MAC Broadcast (DMB) the transmission mode where the We call Direct MAC Broadcast (DMB) the transmission mode where the
broadcast domain that is usable at the MAC layer is directly the broadcast domain that is usable at the MAC layer is directly the
physical broadcast domain. [IEEE Std. 802.15.4] and [IEEE Std. physical broadcast domain. IEEE Std. 802.15.4 [IEEE Std. 802.15.4]
802.11] OCB (for Out of the Context of a BSS) are examples of DMB and IEEE Std. 802.11 [IEEE Std. 802.11] OCB (for Out of the Context
radios. DMB networks provide mostly symmetric and non-transitive of a BSS) are examples of DMB radios. DMB networks provide mostly
transmission. This contrasts with a number of Link Layer Broadcast symmetric and non-transitive transmission. This contrasts with a
Emulation (LLBE) schemes that are described in this section. number of link-layer Broadcast Emulation (LLBE) schemes that are
described in this section.
In the case of Ethernet, while a physical broadcast domain is In the case of Ethernet, while a physical broadcast domain is
constrained to a single shared wire, the [IEEE Std. 802.1] bridging constrained to a single shared wire, the IEEE Std. 802.1 [IEEE Std.
function emulates the broadcast properties of that wire over a whole 802.1] bridging function emulates the broadcast properties of that
physical mesh of Ethernet links. For the upper layer, the qualities wire over a whole physical mesh of Ethernet links. For the upper
of the shared wire are essentially conserved, with a reliable and layer, the qualities of the shared wire are essentially conserved,
cheap broadcast operation over a transitive closure of nodes defined with a reliable and cheap broadcast operation over a transitive
by their connectivity to the emulated wire. closure of nodes defined by their connectivity to the emulated wire.
In large switched fabrics, overlay techniques enable a limited In large switched fabrics, overlay techniques enable a limited
connectivity between nodes that are known to a Map Resolver. The connectivity between nodes that are known to a Map Resolver. The
emulated broadcast domain is configured to the system, e.g., with a emulated broadcast domain is configured to the system, e.g., with a
VXLAN network identifier (VNID). Broadcast operations on the overlay VXLAN network identifier (VNID). Broadcast operations on the overlay
can be emulated but can become very expensive, and it makes sense to can be emulated but can become very expensive, and it makes sense to
proactively install the relevant state in the mapping server as proactively install the relevant state in the mapping server as
opposed to rely on reactive broadcast lookups to do so. opposed to rely on reactive broadcast lookups to do so.
An [IEEE Std. 802.11] Infrastructure Basic Service Set (BSS) also An IEEE Std. 802.11 [IEEE Std. 802.11] Infrastructure Basic Service
provides a transitive closure of nodes as defined by the broadcast Set (BSS) also provides a transitive closure of nodes as defined by
domain of a central AP. The AP relays both unicast and broadcast the broadcast domain of a central AP. The AP relays both unicast and
packets and provides the symmetric and transitive emulation of a broadcast packets and provides the symmetric and transitive emulation
shared wire between the associated nodes, with the capability to of a shared wire between the associated nodes, with the capability to
signal link-up/link-down to the upper layer. Within a BSS, the signal link-up/link-down to the upper layer. Within a BSS, the
physical broadcast domain of the AP serves as emulated broadcast physical broadcast domain of the AP serves as emulated broadcast
domain for all the nodes that are associated to the AP. Broadcast domain for all the nodes that are associated to the AP. Broadcast
packets are relayed by the AP and are not acknowledged. To increase packets are relayed by the AP and are not acknowledged. To increase
the chances that all nodes in the BSS receive the broadcast the chances that all nodes in the BSS receive the broadcast
transmission, AP transmits at the slowest PHY speed. This translates transmission, AP transmits at the slowest PHY speed. This translates
into maximum co-channel interferences for others and the longest into maximum co-channel interferences for others and the longest
occupancy of the medium, for a duration that can be a hundred times occupancy of the medium, for a duration that can be a hundred times
that of the unicast transmission of a frame of the same size. that of the unicast transmission of a frame of the same size.
skipping to change at page 8, line 18 skipping to change at page 10, line 27
of unicast transmissions, or drop the message altogether, which may of unicast transmissions, or drop the message altogether, which may
impact the upper layer protocols. For instance, some APs may not impact the upper layer protocols. For instance, some APs may not
copy Router Solicitation (RS) messages under the assumption that copy Router Solicitation (RS) messages under the assumption that
there is no router across the wireless interface. This assumption there is no router across the wireless interface. This assumption
may be correct at some point of time and may become incorrect in the may be correct at some point of time and may become incorrect in the
future. Another strategy used in Wi-Fi APS is to proxy protocols future. Another strategy used in Wi-Fi APS is to proxy protocols
that heavily rely on broadcast, such as the Address Resolution in ARP that heavily rely on broadcast, such as the Address Resolution in ARP
and ND-Classic, and either respond on behalf or preferably forward and ND-Classic, and either respond on behalf or preferably forward
the broadcast frame as a unicast to the intended Target. the broadcast frame as a unicast to the intended Target.
In an [IEEE Std. 802.11] Infrastructure Extended Service Set (ESS), In an IEEE Std. 802.11 [IEEE Std. 802.11] Infrastructure Extended
infrastructure BSSes are interconnected by a bridged network, Service Set (ESS), infrastructure BSSes are interconnected by a
typically running Transparent Bridging and the Spanning tree Protocol bridged network, typically running Transparent Bridging and the
or a more advanced Layer 2 Routing (L2R) scheme. In the original Spanning tree Protocol or a more advanced Layer 2 Routing (L2R)
model of learning bridges, the forwarding state is set by observing scheme. In the original model of learning bridges, the forwarding
the source MAC address of the frames. When a state is missing for a state is set by observing the source MAC address of the frames. When
destination MAC address, the frame is broadcasted with the a state is missing for a destination MAC address, the frame is
expectation that the response will populate the state on the reverse broadcasted with the expectation that the response will populate the
path. This is a reactive operation, meaning that the state is state on the reverse path. This is a reactive operation, meaning
populated reactively to the need to reach a destination. It is also that the state is populated reactively to the need to reach a
possible in the original model to broadcast 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.
The process of the Wi-Fi association prepares a bridging state The process of the Wi-Fi association prepares a bridging state
proactively at the AP, which avoids the need for a reactive broadcast proactively at the AP, which avoids the need for a reactive broadcast
lookup over the wireless access. In an ESS, the AP may also generate lookup over the wireless access. In an ESS, the AP may also generate
a gratuitous broadcast sourced at the MAC address of the STA to a gratuitous broadcast sourced at the MAC address of the STA to
prepare or update the state in the learning bridges so they point prepare or update the state in the learning bridges so they point
towards the AP for the MAC address of the STA. WiND emulates that towards the AP for the MAC address of the STA. WiND emulates that
proactive method at the Network Layer for the operations of AR, DAD proactive method at the Network Layer for the operations of AR, DAD
and ND proxy. and ND proxy.
In some instances of WLANs and LoWPANs, a Mesh-Under technology In some instances of WLANs and LoWPANs, a Mesh-Under technology
(e.g., a IEEE Std. 802.11s or IEEE Std. 802.15.10) provides meshing (e.g., a IEEE Std. 802.11s or IEEE Std. 802.15.10) provides meshing
services that are similar to bridging, and the broadcast domain is services that are similar to bridging, and the broadcast domain is
well-defined by the membership of the mesh. Mesh-Under emulates a well-defined by the membership of the mesh. Mesh-Under emulates a
broadcast domain by flooding the broadcast packets at the Link Layer. broadcast domain by flooding the broadcast packets at the link-layer.
When operating on a single frequency, this operation is known to When operating on a single frequency, this operation is known to
interfere with itself, and requires inter-frame gaps to dampen the interfere with itself, and requires inter-frame gaps to dampen the
collisions, which reduces further the amount of available bandwidth. collisions, which reduces further the amount of available bandwidth.
As the cost of broadcast transmissions becomes increasingly As the cost of broadcast transmissions becomes increasingly
expensive, there is a push to rethink the upper Layer protocols to expensive, there is a push to rethink the upper Layer protocols to
reduce the dependency on broadcast operations. reduce the dependency on broadcast operations.
4.3. Mapping the IPv6 link Abstraction 4.3. Mapping the IPv6 link Abstraction
IPv6 defines a concept of Link, link Scope and Link-Local Addresses As introduced in Section 2.1, IPv6 defines a concept of Link, link
(LLA), an LLA being unique and usable only within the Scope of a Scope and Link-Local Addresses (LLA), an LLA being unique and usable
Link. The ND-Classic [RFC4861] DAD [RFC4862] process uses a only within the Scope of a Link. The ND-Classic [RFC4861] DAD
multicast transmission to detect a duplicate address, which requires [RFC4862] process uses a multicast transmission to detect a duplicate
that the owner of the address is connected to the Link Layer address, which requires that the owner of the address is connected to
broadcast domain of the sender. the link-layer broadcast domain of the sender.
On wired media, the link is often confused with the physical On wired media, the link is often confused with the physical
broadcast domain because both are determined by the serial cable or broadcast domain because both are determined by the serial cable or
the Ethernet shared wire. Ethernet Bridging reinforces that illusion the Ethernet shared wire. Ethernet Bridging reinforces that illusion
with a Link Layer broadcast domain that emulates a physical broadcast with a link-layer broadcast domain that emulates a physical broadcast
domain over the mesh of wires. But the difference shows on legacy domain over the mesh of wires. But the difference shows on legacy
Non-Broadcast Multi-Access (NBMA) networks such as ATM and Frame- Non-Broadcast Multi-Access (NBMA) networks such as ATM and Frame-
Relay, on shared links and on newer types of NBMA networks such as Relay, on shared links and on newer types of NBMA networks such as
radio and composite radio-wires networks. It also shows when private radio and composite radio-wires networks. It also shows when private
VLANs or Link Layer cryptography restrict the capability to read a VLANs or link-layer cryptography restrict the capability to read a
frame to a subset of the connected nodes. frame to a subset of the connected nodes.
In Mesh-Under and Infrastructure BSS, the IP link extends beyond the In Mesh-Under and Infrastructure BSS, the IP link extends beyond the
physical broadcast domain to the emulated Link Layer broadcast physical broadcast domain to the emulated link-layer broadcast
domain. Relying on Multicast for the ND operation remains feasible domain. Relying on Multicast for the ND operation remains feasible
but becomes highly detrimental to the unicast traffic, and becomes but becomes highly detrimental to the unicast traffic, and becomes
less and less energy-efficient and reliable as the network grows. less and less energy-efficient and reliable as the network grows.
On DMB radios, IP links between peers come and go as the individual On DMB radios, IP links between peers come and go as the individual
physical broadcast domains of the transmitters meet and overlap. The physical broadcast domains of the transmitters meet and overlap. The
DAD operation cannot provide once and for all guarantees over the DAD operation cannot provide once and for all guarantees over the
broadcast domain defined by one radio transmitter if that transmitter broadcast domain defined by one radio transmitter if that transmitter
keeps meeting new peers on the go. keeps meeting new peers on the go.
skipping to change at page 10, line 7 skipping to change at page 12, line 19
The DAD and AR procedures in ND-Classic expect that a node in a The DAD and AR procedures in ND-Classic expect that a node in a
subnet is reachable within the broadcast domain of any other node in subnet is reachable within the broadcast domain of any other node in
the subnet when that other node attempts to form an address that 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 would be a duplicate or attempts to resolve the MAC address of this
node. This is why ND is applicable for P2P and transit links, but node. This is why ND is applicable for P2P and transit links, but
requires extensions for more complex topologies. requires extensions for more complex topologies.
4.4. Mapping the IPv6 subnet Abstraction 4.4. Mapping the IPv6 subnet Abstraction
IPv6 also defines the concept of a subnet for Global and Unique Local As introduced in Section 2.2, IPv6 also defines the concept of a
Addresses (GLA and ULA). All the addresses in a subnet share the subnet for Global and Unique Local Addresses (GLA and ULA). All the
same prefix, and by extension, a node belongs to a subnet if it has addresses in a subnet share the same prefix, and by extension, a node
an address that derives from the prefix of the subnet. That address belongs to a subnet if it has an address that derives from the prefix
must be topologically correct, meaning that it must be installed on of the subnet. That address must be topologically correct, meaning
an interface that is connected to the subnet. that it must be installed on an interface that is connected to the
subnet.
Unless intently replicated in different locations for very specific Unless intently replicated in different locations for very specific
purposes, a subnet prefix is unique within a routing system; for purposes, a subnet prefix is unique within a routing system; for
ULAs, the routing system is typically a limited domain, whereas for ULAs, the routing system is typically a limited domain, whereas for
GLAs, it is the whole Internet. GLAs, it is the whole Internet.
For that reason, it is sufficient to validate that an address that is For that reason, it is sufficient to validate that an address that is
formed from a subnet prefix is unique within the scope of that subnet formed from a subnet prefix is unique within the scope of that subnet
to guarantee that it is globally unique within the whole routing to guarantee that it is globally unique within the whole routing
system. Note that a subnet may become partitioned due to the loss of system. Note that a subnet may become partitioned due to the loss of
a wired or wireless link, so even that operation is not necessarily a wired or wireless link, so even that operation is not necessarily
obvious, more in [DAD APPROACHES]. obvious, more in [DAD APPROACHES].
The IPv6 aggregation model relies on the property that a packet from The IPv6 aggregation model relies on the property that a packet from
the outside of a subnet can be routed to any router that belongs to the outside of a subnet can be routed to any router that belongs to
the subnet, and that this router will be able to either resolve the the subnet, and that this router will be able to either resolve the
destination Link Layer address and deliver the packet, or, in the destination link-layer address and deliver the packet, or, in the
case of an MLSN, route the packet to the destination within the case of an MLSN, route the packet to the destination within the
subnet. subnet.
If the subnet is known as on-link, then any node may also resolve the 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 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 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 Neighbor Cache Entry (NCE) for the destination will also need to pass
the packet to a router, more in [RFC5942]. the packet to a router, more in [RFC5942].
On Ethernet, an IP subnet is often congruent with an IP link because On Ethernet, an IP subnet is often congruent with an IP link because
both are determined by the physical attachment to a shared wire or an both are determined by the physical attachment to a shared wire or an
IEEE Std. 802.1 bridged domain. In that case, the connectivity over IEEE Std. 802.1 bridged domain. In that case, the connectivity over
the link is both symmetric and transitive, the subnet can appear as the link is both symmetric and transitive, the subnet can appear as
on-link, and any node can resolve a destination MAC address of any on-link, and any node can resolve a destination MAC address of any
other node directly using ND-Classic. other node directly using ND-Classic.
skipping to change at page 11, line 29 skipping to change at page 13, line 43
subnet. But the DAD operation is performed as a unicast exchange subnet. But the DAD operation is performed as a unicast exchange
with a central registrar, using new ND Extended Duplicate Address with a central registrar, using new ND Extended Duplicate Address
messages (EDAR and EDAC) [RFC6775][RFC8505]. This modernizes ND for messages (EDAR and EDAC) [RFC6775][RFC8505]. This modernizes ND for
application in overlays with Map Resolvers and enables unicast application in overlays with Map Resolvers and enables unicast
lookups [UNICAST AR] for addresses registered to the resolver. 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)
defined in [RFC8505]. This method allows to prepare and maintain the defined in [RFC8505]. This method allows to prepare and maintain the
host routes in the routers and avoids the reactive Address Resolution host routes in the routers and avoids the reactive Address Resolution
in ND-Classic and the associated Link Layer broadcasts transmissions. in ND-Classic and the associated link-layer broadcasts transmissions.
The EARO provides information to the router that is independent to The EARO provides information to the router that is independent to
the routing protocol and routing can take multiple forms, from a the routing protocol and routing can take multiple forms, from a
traditional IGP to a collapsed Hub-and-Spoke model where only one traditional IGP to a collapsed Hub-and-Spoke model where only one
router owns and advertises the prefix. [RFC8505] is already router owns and advertises the prefix. [RFC8505] is already
referenced as the registrtaion interface to "RIFT: Routing in Fat referenced as the registration interface to "RIFT: Routing in Fat
Trees" [I-D.ietf-rift-rift] and "RPL: IPv6 Routing Protocol for Trees" [I-D.ietf-rift-rift] and "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks" [RFC6550] with [RPL UNAWARE LEAVES]. Low-Power and Lossy Networks" [RFC6550] with [RPL UNAWARE LEAVES].
WiND also enables to span a subnet over an MLSN that federates edge WiND also enables to span a subnet over an MLSN that federates edge
wireless links with a high-speed, typically Ethernet, backbone. This wireless links with a high-speed, typically Ethernet, backbone. This
way, nodes can form any address they want and move freely from a way, nodes can form any address they want and move freely from a
wireless edge link to another, without renumbering. Backbone Routers wireless edge link to another, without renumbering. Backbone Routers
(6BBRs) placed along the wireless edge of the Backbone handle IPv6 (6BBRs) placed along the wireless edge of the Backbone handle IPv6
Neighbor Discovery and forward packets over the backbone on behalf of Neighbor Discovery and forward packets over the backbone on behalf of
the registered nodes on the wireless edge. the registered nodes on the wireless edge.
skipping to change at page 13, line 23 skipping to change at page 15, line 38
specified in [RPL UNAWARE LEAVES]. In a degraded mode, all the Hubs specified in [RPL UNAWARE LEAVES]. In a degraded mode, all the Hubs
are connected to a same high speed backbone such as an Ethernet are connected to a same high speed backbone such as an Ethernet
bridging domain where ND-Classic is operated. In that case, it is bridging domain where ND-Classic is operated. In that case, it is
possible to federate the Hub, Spoke and Backbone nodes as a single possible to federate the Hub, Spoke and Backbone nodes as a single
subnet, operating ND proxy operations [RFC8929] at the Hubs, acting subnet, operating ND proxy operations [RFC8929] at the Hubs, acting
as 6BBRs. It can be observed that this latter design builds a form as 6BBRs. It can be observed that this latter design builds a form
of Network Layer Infrastructure ESS. of Network Layer Infrastructure ESS.
6. WiND Applicability 6. WiND Applicability
WiND applies equally to P2P links, P2MP Hub-and-Spoke, Link Layer WiND applies equally to P2P links, P2MP Hub-and-Spoke, link-layer
Broadcast Domain Emulation such as Mesh-Under and Wi-Fi BSS, and Broadcast Domain Emulation such as Mesh-Under and Wi-Fi BSS, and
Route-Over meshes. Route-Over meshes.
There is an intersection where link and subnet are congruent and There is an intersection where link and subnet are congruent and
where both ND and WiND could apply. These includes P2P, the MAC where both ND and WiND could apply. These includes P2P, the MAC
emulation of a PHY broadcast domain, and the particular case of emulation of a PHY broadcast domain, and the particular case of
always on, fully overlapping physical radio broadcast domain. But always on, fully overlapping physical radio broadcast domain. But
even in those cases where both are possible, WiND is preferable vs. even in those cases where both are possible, WiND is preferable vs.
ND because it reduces the need of broadcast. ND because it reduces the need of broadcast.
This is discussed in more details in the introduction of [RFC8929]. This is discussed in more details in the introduction of [RFC8929].
There are also a number of practical use cases in the wireless world There are also a number of practical use cases in the wireless world
where links and subnets are not congruent: where links and subnets are not congruent:
* The IEEE Std. 802.11 infrastructure BSS enables one subnet per AP, * The IEEE Std. 802.11 infrastructure BSS enables one subnet per AP,
and emulates a broadcast domain at the Link Layer. The and emulates a broadcast domain at the link-layer. The
Infrastructure ESS extends that model over a backbone and Infrastructure ESS extends that model over a backbone and
recommends the use of an ND proxy [IEEE Std. 802.11] to recommends the use of an ND proxy [IEEE Std. 802.11] to
interoperate with Ethernet-connected nodes. WiND incorporates an interoperate with Ethernet-connected nodes. WiND incorporates an
ND proxy to serve that need, which was missing so far. ND proxy to serve that need, which was missing so far.
* BlueTooth is Hub-and-Spoke at the Link Layer. It would make * BlueTooth is Hub-and-Spoke at the link-layer. It would make
little sense to configure a different subnet between the central little sense to configure a different subnet between the central
and each individual peripheral node (e.g., sensor). Rather, and each individual peripheral node (e.g., sensor). Rather,
[RFC7668] allocates a prefix to the central node acting as router, [RFC7668] allocates a prefix to the central node acting as router,
and each peripheral host (acting as a host) forms one or more and each peripheral host (acting as a host) forms one or more
address(es) from that same prefix and registers it. address(es) from that same prefix and registers it.
* A typical Smartgrid networks puts together Route-Over MLSNs that * A typical Smartgrid networks puts together Route-Over MLSNs that
comprise thousands of IPv6 nodes. The 6TiSCH architecture comprise thousands of IPv6 nodes. The 6TiSCH architecture
[I-D.ietf-6tisch-architecture] presents the Route-Over model over [I-D.ietf-6tisch-architecture] presents the Route-Over model over
an IEEE Std. 802.15.4 Time-Slotted Channel-Hopping (TSCH) an IEEE Std. 802.15.4 Time-Slotted Channel-Hopping (TSCH)
skipping to change at page 15, line 34 skipping to change at page 17, line 46
Unreachability Detection, Address Resolution and Address Mobility to Unreachability Detection, Address Resolution and Address Mobility to
transfer a role of ND proxy to the AP where a STA is associated transfer a role of ND proxy to the AP where a STA is associated
following the mobility of the STA. following the mobility of the STA.
The WiND proxy ND specification that associated to the Address The WiND proxy ND specification that associated to the Address
Registration is [RFC8929]. With that specification, the AP Registration is [RFC8929]. With that specification, the AP
participates to the protocol as a Backbone Router, typically participates to the protocol as a Backbone Router, typically
operating as a bridging proxy though the routing proxy operation is operating as a bridging proxy though the routing proxy operation is
also possible. As a bridging proxy, the backbone router either also possible. As a bridging proxy, the backbone router either
replies to NS lookups with the MAC address of the STA, or preferably replies to NS lookups with the MAC address of the STA, or preferably
forwards the lookups to the STA as Link Layer unicast frames to let forwards the lookups to the STA as link-layer unicast frames to let
the STA answer. For the data plane, the backbone router acts as a the STA answer. For the data plane, the backbone router acts as a
normal AP and bridges the packets to the STA as usual. As a routing normal AP and bridges the packets to the STA as usual. As a routing
proxy, the backbone router replies with its own MAC address and then proxy, the backbone router replies with its own MAC address and then
routes to the STA at the IP layer. The routing proxy reduces the routes to the STA at the IP layer. The routing proxy reduces the
need to expose the MAC address of the STA on the wired side, for a need to expose the MAC address of the STA on the wired side, for a
better stability and scalability of the bridged fabric. better stability and scalability of the bridged fabric.
6.3. Case of Mesh Under Technologies 6.3. Case of Mesh Under Technologies
The Mesh-Under provides a broadcast domain emulation with symmetric The Mesh-Under provides a broadcast domain emulation with symmetric
skipping to change at page 21, line 19 skipping to change at page 23, line 19
<https://www.rfc-editor.org/info/rfc8415>. <https://www.rfc-editor.org/info/rfc8415>.
[I-D.ietf-rift-rift] [I-D.ietf-rift-rift]
Przygienda, T., Sharma, A., Thubert, P., Rijsman, B., and Przygienda, T., Sharma, A., Thubert, P., Rijsman, B., and
D. Afanasiev, "RIFT: Routing in Fat Trees", Work in D. Afanasiev, "RIFT: Routing in Fat Trees", Work in
Progress, Internet-Draft, draft-ietf-rift-rift-12, 26 May Progress, Internet-Draft, draft-ietf-rift-rift-12, 26 May
2020, 2020,
<https://tools.ietf.org/html/draft-ietf-rift-rift-12>. <https://tools.ietf.org/html/draft-ietf-rift-rift-12>.
[RPL UNAWARE LEAVES] [RPL UNAWARE LEAVES]
Thubert, P. and M. Richardson, "Routing for RPL Leaves", Thubert, P. and M. C. Richardson, "Routing for RPL
Work in Progress, Internet-Draft, draft-ietf-roll-unaware- (Routing Protocol for Low-Power and Lossy Networks)
leaves-23, 10 November 2020, <https://tools.ietf.org/html/ Leaves", Work in Progress, Internet-Draft, draft-ietf-
draft-ietf-roll-unaware-leaves-23>. roll-unaware-leaves-30, 22 January 2021,
<https://tools.ietf.org/html/draft-ietf-roll-unaware-
leaves-30>.
[DAD ISSUES] [DAD ISSUES]
Yourtchenko, A. and E. Nordmark, "A survey of issues Yourtchenko, A. and E. Nordmark, "A survey of issues
related to IPv6 Duplicate Address Detection", Work in related to IPv6 Duplicate Address Detection", Work in
Progress, Internet-Draft, draft-yourtchenko-6man-dad- Progress, Internet-Draft, draft-yourtchenko-6man-dad-
issues-01, 3 March 2015, <https://tools.ietf.org/html/ issues-01, 3 March 2015, <https://tools.ietf.org/html/
draft-yourtchenko-6man-dad-issues-01>. draft-yourtchenko-6man-dad-issues-01>.
[MCAST EFFICIENCY] [MCAST EFFICIENCY]
Vyncke, E., Thubert, P., Levy-Abegnoli, E., and A. Vyncke, E., Thubert, P., Levy-Abegnoli, E., and A.
Yourtchenko, "Why Network-Layer Multicast is Not Always Yourtchenko, "Why Network-Layer Multicast is Not Always
Efficient At Datalink Layer", Work in Progress, Internet- Efficient At Datalink Layer", Work in Progress, Internet-
Draft, draft-vyncke-6man-mcast-not-efficient-01, 14 Draft, draft-vyncke-6man-mcast-not-efficient-01, 14
February 2014, <https://tools.ietf.org/html/draft-vyncke- February 2014, <https://tools.ietf.org/html/draft-vyncke-
6man-mcast-not-efficient-01>. 6man-mcast-not-efficient-01>.
[I-D.ietf-6tisch-architecture] [I-D.ietf-6tisch-architecture]
Thubert, P., "An Architecture for IPv6 over the TSCH mode Thubert, P., "An Architecture for IPv6 over the TSCH mode
of IEEE 802.15.4", Work in Progress, Internet-Draft, of IEEE 802.15.4", Work in Progress, Internet-Draft,
draft-ietf-6tisch-architecture-29, 27 August 2020, draft-ietf-6tisch-architecture-30, 26 November 2020,
<https://tools.ietf.org/html/draft-ietf-6tisch- <https://tools.ietf.org/html/draft-ietf-6tisch-
architecture-29>. architecture-30>.
[MCAST PROBLEMS] [MCAST PROBLEMS]
Perkins, C., McBride, M., Stanley, D., Kumari, W., and J. Perkins, C. E., McBride, M., Stanley, D., Kumari, W., and
Zuniga, "Multicast Considerations over IEEE 802 Wireless J. C. Zuniga, "Multicast Considerations over IEEE 802
Media", Work in Progress, Internet-Draft, draft-ietf- Wireless Media", Work in Progress, Internet-Draft, draft-
mboned-ieee802-mcast-problems-12, 26 October 2020, ietf-mboned-ieee802-mcast-problems-13, 4 February 2021,
<https://tools.ietf.org/html/draft-ietf-mboned-ieee802- <https://tools.ietf.org/html/draft-ietf-mboned-ieee802-
mcast-problems-12>. mcast-problems-13>.
[SAVI] Bi, J., Wu, J., Wang, Y., and T. Lin, "A SAVI Solution for [SAVI] Bi, J., Wu, J., Wang, Y., and T. Lin, "A SAVI Solution for
WLAN", Work in Progress, Internet-Draft, draft-bi-savi- WLAN", Work in Progress, Internet-Draft, draft-bi-savi-
wlan-20, 14 November 2020, wlan-20, 14 November 2020,
<https://tools.ietf.org/html/draft-bi-savi-wlan-20>. <https://tools.ietf.org/html/draft-bi-savi-wlan-20>.
[UNICAST AR] [UNICAST AR]
Thubert, P. and E. Levy-Abegnoli, "IPv6 Neighbor Discovery Thubert, P. and E. Levy-Abegnoli, "IPv6 Neighbor Discovery
Unicast Lookup", Work in Progress, Internet-Draft, draft- Unicast Lookup", Work in Progress, Internet-Draft, draft-
thubert-6lo-unicast-lookup-00, 25 January 2019, thubert-6lo-unicast-lookup-00, 25 January 2019,
 End of changes. 37 change blocks. 
110 lines changed or deleted 197 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/