< draft-thubert-6man-ipv6-over-wireless-03.txt   draft-thubert-6man-ipv6-over-wireless-04.txt >
6MAN P. Thubert, Ed. 6MAN P. Thubert, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Informational May 2, 2019 Intended status: Informational September 26, 2019
Expires: November 3, 2019 Expires: March 29, 2020
IPv6 Neighbor Discovery on Wireless Networks IPv6 Neighbor Discovery on Wireless Networks
draft-thubert-6man-ipv6-over-wireless-03 draft-thubert-6man-ipv6-over-wireless-04
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 November 3, 2019. This Internet-Draft will expire on March 29, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. IP Models . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. IP Models . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Physical Broadcast Domain . . . . . . . . . . . . . . . . 6 3.1. Physical Broadcast Domain . . . . . . . . . . . . . . . . 6
3.2. MAC-Layer Broadcast Emulations . . . . . . . . . . . . . 7 3.2. MAC-Layer Broadcast Emulations . . . . . . . . . . . . . 7
3.3. Mapping the IPv6 Link Abstraction . . . . . . . . . . . . 8 3.3. Mapping the IPv6 Link Abstraction . . . . . . . . . . . . 8
3.4. Mapping the IPv6 Subnet Abstraction . . . . . . . . . . . 9 3.4. Mapping the IPv6 Subnet Abstraction . . . . . . . . . . . 9
4. Wireless ND . . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Wireless ND . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Introduction to WiND . . . . . . . . . . . . . . . . . . 10 4.1. Introduction to WiND . . . . . . . . . . . . . . . . . . 10
4.2. Links and Link-Local Addresses . . . . . . . . . . . . . 11 4.2. Links and Link-Local Addresses . . . . . . . . . . . . . 11
4.3. Subnets and Global Addresses . . . . . . . . . . . . . . 11 4.3. Subnets and Global Addresses . . . . . . . . . . . . . . 12
5. WiND Applicability . . . . . . . . . . . . . . . . . . . . . 12 5. WiND Applicability . . . . . . . . . . . . . . . . . . . . . 12
5.1. Case of LPWANs . . . . . . . . . . . . . . . . . . . . . 13 5.1. Case of LPWANs . . . . . . . . . . . . . . . . . . . . . 13
5.2. Case of Infrastructure BSS and ESS . . . . . . . . . . . 13 5.2. Case of Infrastructure BSS and ESS . . . . . . . . . . . 13
5.3. Case of Mesh Under Technologies . . . . . . . . . . . . . 14 5.3. Case of Mesh Under Technologies . . . . . . . . . . . . . 14
5.4. Case of DMC radios . . . . . . . . . . . . . . . . . . . 14 5.4. Case of DMC radios . . . . . . . . . . . . . . . . . . . 15
5.4.1. Using IPv6 ND only . . . . . . . . . . . . . . . . . 15 5.4.1. Using IPv6 ND only . . . . . . . . . . . . . . . . . 15
5.4.2. Using Wireless ND . . . . . . . . . . . . . . . . . . 15 5.4.2. Using Wireless ND . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . 18 9.1. Normative References . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
skipping to change at page 3, line 23 skipping to change at page 3, line 23
ensure the uniqueness of an IPv6 address. The mechanism for ensure the uniqueness of an IPv6 address. The mechanism for
Duplicate Address Detection (DAD) [RFC4862] was designed for the Duplicate Address Detection (DAD) [RFC4862] was designed for the
efficient broadcast operation of Ethernet Bridging. Since broadcast efficient broadcast operation of Ethernet Bridging. Since broadcast
can be unreliable over wireless media, DAD often fails to discover can be unreliable over wireless media, DAD often fails to discover
duplications [I-D.yourtchenko-6man-dad-issues]. In practice, IPv6 duplications [I-D.yourtchenko-6man-dad-issues]. In practice, IPv6
addresses very rarely conflict because of the entropy of the 64-bit addresses very rarely conflict because of the entropy of the 64-bit
Interface IDs, not because address duplications are detected and Interface IDs, not because address duplications are detected and
resolved. resolved.
The IPv6 ND Neighbor Solicitation (NS) [RFC4861] message is used for The IPv6 ND Neighbor Solicitation (NS) [RFC4861] message is used for
DAD and address Lookup when a node moves, or wakes up and reconnects DAD and Address Resolution (AR) when a node moves, or wakes up and
to the wireless network. The NS message is targeted to a Solicited- reconnects to the wireless network. The NS message is targeted to a
Node Multicast Address (SNMA) [RFC4291] and should in theory only Solicited-Node Multicast Address (SNMA) [RFC4291] and should in
reach a very small group of nodes. But in reality, IPv6 multicast theory only reach a very small group of nodes. It must be noted that
messages are typically broadcast on the wireless medium, and so they in the the case of Ethernet LANs as well as most WLANs and LPWANs,
are processed by most of the wireless nodes over the subnet (e.g., the Layer-3 multicast operation becomes a MAC_Layer broadcast for the
the ESS fabric) regardless of how few of the nodes are subscribed to lack of a Layer-2 multicast operation that could handle a possibly
the SNMA. As a result, IPv6 ND address Lookups and DADs over a large very large number of groups in order to make the unicast efficient.
wireless and/or a LowPower Lossy Network (LLN) can consume enough It results that IPv6 ND messages are processed by most of the
bandwidth to cause a substantial degradation to the unicast traffic wireless nodes over the subnet (e.g., the ESS fabric) regardless of
service [I-D.vyncke-6man-mcast-not-efficient]. how few of the nodes are subscribed to the SNMA.
Because IPv6 ND messages sent to the SNMA group are broadcasted at IPv6 ND address Lookups and DADs over a large fabric can generate
the radio MAC Layer, wireless nodes that do not belong to the SNMA hnudreds of broadcasts per second. If the broadcasts were blindly
group still have to keep their radio turned on to listen to multicast copied over Wi-Fi and/or over a LowPower Lossy Network (LLN), the ND-
NS messages, which is a total waste of energy for them. In order to related multicast could consume enough bandwidth to cause a
reduce their power consumption, certain battery-operated devices such substantial degradation to the unicast traffic service
as IoT sensors and smartphones ignore some of the broadcasts, making [I-D.vyncke-6man-mcast-not-efficient]. To protect their bandwidth,
IPv6 ND operations even less reliable. some networks throttle ND-related broadcasts, which reduces the
capability of the protocol to perform as expected.
Conversely, a Wi-Fi station must keep its radio turned on to listen
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 can be alleviated by reducing the IPv6 ND broadcasts These problems can be alleviated by reducing the IPv6 ND broadcasts
over wireless access links. This has been done by splitting the over wireless access links. This has been done by splitting the
broadcast domains and by routing between subnets, at the extreme by broadcast domains and by routing between subnets, at the extreme by
assigning a /64 prefix to each wireless node (see [RFC8273]). assigning a /64 prefix to each wireless node (see [RFC8273]).
Another way is to proxy at the boundary of the wired and wireless Another way is to proxy at the boundary of the wired and wireless
domains the Layer-3 protocols that rely on MAC Layer broadcast domains the Layer-3 protocols that rely on MAC Layer broadcast
operations. For instance, IEEE 802.11 [IEEEstd80211] situates proxy- operations. For instance, IEEE 802.11 [IEEEstd80211] situates proxy-
ARP (IPv4) and proxy-ND (IPv6) functions at the Access Points (APs). ARP (IPv4) and proxy-ND (IPv6) functions at the Access Points (APs).
skipping to change at page 4, line 22 skipping to change at page 4, line 32
proposed for SAVI [I-D.bi-savi-wlan] was found to be unreliable. An proposed for SAVI [I-D.bi-savi-wlan] was found to be unreliable. An
IPv6 address may not be discovered immediately due to a packet loss, IPv6 address may not be discovered immediately due to a packet loss,
or if a "silent" node is not currently using one of its addresses, or if a "silent" node is not currently using one of its addresses,
e.g., a node that waits in wake-on-lan state. A change of state, e.g., a node that waits in wake-on-lan state. A change of state,
e.g. due to a movement, may be missed or misordered, leading to e.g. due to a movement, may be missed or misordered, leading to
unreliable connectivity and an incomplete knowledge of the set of unreliable connectivity and an incomplete knowledge of the set of
peers. peers.
Wireless ND (WiND) introduces a new approach to IPv6 ND that is Wireless ND (WiND) introduces a new approach to IPv6 ND that is
designed to apply to the WLANs and WPANs types of networks. On the designed to apply to the WLANs and WPANs types of networks. On the
one hand, WiND avoids the use of broadcast operation for Address one hand, WiND avoids the use of broadcast operation for DAD and AR,
Resolution and Duplicate Address Detection, and on the other hand, and on the other hand, WiND supports use cases where Subnet and MAC-
WiND supports use cases where Subnet and MAC-level domains are not level domains are not congruent, which is common in those types of
congruent, which is common in those types of networks unless a networks unless a specific MAC-Level emulation is provided. WiND
specific MAC-Level emulation is provided. applies routing inside the Subnets, which enables MultiLink Subnets.
Hosts register their addresses to their serving routers with
To achieve this, WiND applies routing inside the Subnets, which [RFC8505]. With the registration, routers have a complete knowledge
enables MultiLink Subnets. Hosts register their addresses to their of the hosts they serve and in return, hosts obtain routing services
serving routers with [RFC8505]. With the registration, routers have for their registered addresses. The registration is abstract to the
a complete knowledge of the hosts they serve and in return, hosts routing protocol, and it can be protected to prevent impersonation
obtain routing services for their registered addresses. The attacks with [I-D.ietf-6lo-ap-nd].
registration is abstract to the routing protocol, and it can be
protected to prevent impersonation attacks with [I-D.ietf-6lo-ap-nd].
The routing service can be a simple reflexion in a Hub-and-Spoke The routing service can be a simple reflexion in a Hub-and-Spoke
Subnet that emulates an IEEE Std 802.11 Infrastructure BSS at Layer Subnet that emulates an IEEE Std 802.11 Infrastructure BSS at Layer
3. It can also be a full-fledge routing protocol, in particular RPL 3. 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 [RFC6550] that was designed to adapt to various LLNs such as WLAN and
WPAN radio meshes with the concept of Objective Function. Finally, WPAN radio meshes with the concept of Objective Function. Finally,
the routing service can also be ND proxy that emulates an IEEE Std the routing service can also be ND proxy that emulates an IEEE Std
802.11 Infrastructure ESS at Layer 3. WiND specifies the IPv6 802.11 Infrastructure ESS at Layer 3. WiND specifies the IPv6
Backbone Router for that purpose in [I-D.ietf-6lo-backbone-router]. Backbone Router for that purpose in [I-D.ietf-6lo-backbone-router].
More details on WiND can be found in Section 4.1. More details on WiND can be found in Section 4.1.
2. Acronyms 2. Acronyms
This document uses the following abbreviations: This document uses the following abbreviations:
6BBR: 6LoWPAN Backbone Router 6BBR: 6LoWPAN Backbone Router
6LBR: 6LoWPAN Border Router 6LBR: 6LoWPAN Border Router
6LN: 6LoWPAN Node 6LN: 6LoWPAN Node
6LR: 6LoWPAN Router 6LR: 6LoWPAN Router
ARO: Address Registration Option ARO: Address Registration Option
DAC: Duplicate Address Confirmation DAC: Duplicate Address Confirmation
skipping to change at page 6, line 43 skipping to change at page 6, line 46
of the hardware (e.g., crystals, PAs and antennas) that may affect of the hardware (e.g., crystals, PAs and antennas) that may affect
the balance to the point that the connectivity becomes mostly uni- the balance to the point that the connectivity becomes mostly uni-
directional, e.g., A to B but practically not B to A. It takes a 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 particular effort to place a set of devices in a fashion that all
their physical broadcast domains fully overlap, and it can not be their physical broadcast domains fully overlap, and it can not be
assumed in the general case. In other words, the property of radio assumed in the general case. In other words, the property of radio
connectivity is generally not transitive, meaning that A may be in 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 range with B and B may be in range with C does not necessarily imply
that A is in range with C. that A is in range with C.
We define MAC-Layer Direct Broadcast (DMC) a transmission mode where We define Direct MAC-Layer Broadcast (DMC) a transmission mode where
the broadcast domain that is usable at the MAC layer is directly the the broadcast domain that is usable at the MAC layer is directly the
physical broadcast domain. IEEE 802.15.4 [IEEE802154] and IEEE physical broadcast domain. IEEE 802.15.4 [IEEE802154] and IEEE
802.11 [IEEEstd80211] OCB (for Out of the Context of a BSS) are 802.11 OCB [IEEEstd80211] (for Out of the Context of a BSS) are
examples of DMC radios. This constrasts with a number of MAC-layer examples of DMC radios. This contrasts with a number of MAC-layer
Broadcast Emulation schemes that are described in the next section. Broadcast Emulation schemes that are described in the next section.
3.2. MAC-Layer Broadcast Emulations 3.2. MAC-Layer Broadcast Emulations
While a physical broadcast domain is constrained to a single shared While a physical broadcast domain is constrained to a single shared
wire, Ethernet Bridging emulates the broadcast properties of that wire, Ethernet Bridging emulates the broadcast properties of that
wire over a whole physical mesh of Ethernet links. For the upper wire over a whole physical mesh of Ethernet links. For the upper
layer, the qualities of the shared wire are essentially conserved, layer, the qualities of the shared wire are essentially conserved,
with a reliable and cheap broadcast operation over a closure of nodes with a reliable and cheap broadcast operation over a closure of nodes
defined by their connectivity to the emulated wire. defined by their connectivity to the emulated wire.
skipping to change at page 7, line 41 skipping to change at page 7, line 41
acknowledged. To ensure that all nodes in the BSS receive the acknowledged. To ensure that all nodes in the BSS receive the
broadcast transmission, AP transmits at the slowest PHY speed. This broadcast transmission, AP transmits at the slowest PHY speed. This
translates into maximum co-channel interferences for others and translates into maximum co-channel interferences for others and
longest occupancy of the medium, for a duration that can be 100 times longest occupancy of the medium, for a duration that can be 100 times
that of a unicast. For that reason, upper layer protocols should that of a unicast. For that reason, upper layer protocols should
tend to avoid the use of broadcast when operating over Wi-Fi. tend to avoid the use of broadcast when operating over Wi-Fi.
In an IEEE Std 802.11 Infrastructure Extended Service Set (ESS), In an IEEE Std 802.11 Infrastructure Extended Service Set (ESS),
infrastructure BSSes are interconnected by a bridged network, infrastructure BSSes are interconnected by a bridged network,
typically running Transparent Bridging and Spanning tree Protocol. typically running Transparent Bridging and Spanning tree Protocol.
In the original model, the state in the Transparent Bridge is set by In the original model of learning bridges, the state in the
observing the source MAC address of the frames. When a state is Transparent Bridge is set by observing the source MAC address of the
missing for a destination MAC address, the frame is broadcasted with frames. When a state is missing for a destination MAC address, the
the expectation that the response will populate the state. This is a frame is broadcasted with the expectation that the response will
reactive operation, meaning that the state is populated reactively to populate the state. This is a reactive operation, meaning that the
a need for forwarding. It is also possible to send a gratuitous state is populated reactively to a need for forwarding. It is also
frame to advertise self throughout the bridged network, and that is possible in the original model to send a gratuitous frame to
also a broadcast. The process of the association prepares a bridging advertise self throughout the bridged network, and that is also a
state proactively at the AP, so as to avoid the reactive broadcast broadcast.
lookup. It may also generates a gratuitous broadcast sourced at the
MAC address of the STA to prepare or update the state in the In contrast, the process of the Wi-Fi association prepares a bridging
Transparent Bridges. This model avoids the need of multicast over state proactively at the AP, which avoids the need for a reactive
the wireless access, and it is only logical that IPv6 ND evolved broadcast lookup over the wireless access. The AP may also generate
towards proposes similar methods at Layer-3 for its operation. 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 proactive methods at Layer-3 for its
operation of address discovery (AD) and duplicate address detection
(DAD).
In some cases of WLAN and WPAN radios, a mesh-under technology (e.g., In some cases of WLAN and WPAN radios, a mesh-under technology (e.g.,
a IEEE 802.11s or IEEE 802.15.10) provides meshing services that are a IEEE 802.11s or IEEE 802.15.10) provides meshing services that are
similar to bridging, and the broadcast domain is well defined by the similar to bridging, and the broadcast domain is well defined by the
membership of the mesh. Mesh-Under emulates a broadcast domain by membership of the mesh. Mesh-Under emulates a broadcast domain by
flooding the broadcast packets at Layer-2. When operating on a flooding the broadcast packets at Layer-2. When operating on a
single frequency, this operation is known to interfere with itself, single frequency, this operation is known to interfere with itself,
forcing deployment to introduce delays that dampen the collisions. forcing deployment to introduce delays that dampen the collisions.
All in all, the mechanism is slow, inefficient and expensive. All in all, the mechanism is slow, inefficient and expensive.
Going down the list of cases above, the cost of a broadcast Going down the list of cases above, the cost of a broadcast
transmissions becomes increasingly expensive, and there is a push to transmissions becomes increasingly expensive, and there is a push to
rethink the upper-layer protocols so as to reduce the depency on rethink the upper-layer protocols so as to reduce the depency on
broadcast operations. broadcast operations.
There again, a MAC-layer communication can be established between 2 There again, a MAC-layer communication can be established between 2
nodes if their MAC-layer broadcast domains overlap. In the absence nodes if their MAC-layer broadcast domains overlap. In the absence
of a MAC-layer emulation such as a mesh-under or an Infrastructure of a MAC-layer emulation such as a mesh-under or an Infrastructure
BSS, the MAC-layer broadcast domain is congruent with that of the BSS, the MAC-layer broadcast domain is congruent with that of the
PHY-layer and inherits its properties for reflexivity and PHY-layer and inherits its properties for reflexivity and
transitivity. IEEE 802.11p, which operates Out of the Context of a transitivity. IEEE 802.11 OCB, which operates Out of the Context of
BSS (DMC radios) is an example of a network that does not have a MAC- a BSS (DMC radios) is an example of a network that does not have a
Layer broadcast domain emulation, which means that it will exhibit MAC-Layer broadcast domain emulation, which means that it will
mostly reflexive and mostly non-transitive transmission properties. exhibit mostly reflexive and mostly non-transitive transmission
properties.
3.3. Mapping the IPv6 Link Abstraction 3.3. Mapping the IPv6 Link Abstraction
IPv6 defines a concept of Link, Link Scope and Link-Local Addresses IPv6 defines a concept of Link, Link Scope and Link-Local Addresses
(LLA), an LLA being unique and usable only within the Scope of a (LLA), an LLA being unique and usable only within the Scope of a
Link. The IPv6 Neighbor Discovery (ND) [RFC4861][RFC4862] Duplicate Link. The IPv6 Neighbor Discovery (ND) [RFC4861][RFC4862] Duplicate
Adress Detection (DAD) process leverages a multicast transmission to Adress Detection (DAD) process leverages a multicast transmission to
ensure that an IPv6 address is unique as long as the owner of the ensure that an IPv6 address is unique as long as the owner of the
address is connected to the broadcast domain. It must be noted that address is connected to the broadcast domain. It must be noted that
in all the cases in this specification, the Layer-3 multicast in all the cases in this specification, the Layer-3 multicast
skipping to change at page 11, line 34 skipping to change at page 11, line 42
assignment in which case it can still be used for DAD. assignment in which case it can still be used for DAD.
4.2. Links and Link-Local Addresses 4.2. Links and Link-Local Addresses
For Link-Local Addresses, DAD is performed between communicating For Link-Local Addresses, DAD is performed between communicating
pairs of nodes. It is carried out as part of a registration process 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 is based on a NS/NA exchange that transports an EARO. During
that process, the DAD is validated and a Neighbor Cache Entry (NCE) that process, the DAD is validated and a Neighbor Cache Entry (NCE)
is populated with a single unicast exchange. is populated with a single unicast exchange.
Ior instance, in the case of a Bluetooth Low Energy (BLE) For instance, in the case of a Bluetooth Low Energy (BLE)
[RFC7668][IEEEstd802151] Hub-and Spoke configuration, Uniqueness of [RFC7668][IEEEstd802151] Hub-and Spoke configuration, Uniqueness of
Link local Addresses need only to be verified between the pairs of Link local Addresses need only to be verified between the pairs of
communicating nodes, a central router and a peripheral host. In that communicating nodes, a central router and a peripheral host. In that
example, 2 peripheral hosts connected to the same central router can example, 2 peripheral hosts connected to the same central router can
not have the same Link Local Address because the Binding Cache not have the same Link Local Address because the Binding Cache
Entries (BCEs) would collide at the central router which could not Entries (BCEs) would collide at the central router which could not
talk to both over the same interface. The WiND operation is talk to both over the same interface. The WiND operation is
appropriate for that DAD operation, but the one from ND is not, appropriate for that DAD operation, but the one from ND is not,
because peripheral hosts are not on the same broadcast domain. On because peripheral hosts are not on the same broadcast domain. On
the other hand, Global and ULA DAD is validated at the Subnet Level, the other hand, Global and ULA DAD is validated at the Subnet Level,
skipping to change at page 15, line 8 skipping to change at page 15, line 13
highly recommended. highly recommended.
5.4. Case of DMC radios 5.4. Case of DMC radios
IPv6 over DMC radios uses P2P Links that can be formed and maintained IPv6 over DMC radios uses P2P Links that can be formed and maintained
when a pair of DMC radios transmitters are in range from one another. when a pair of DMC radios transmitters are in range from one another.
5.4.1. Using IPv6 ND only 5.4.1. Using IPv6 ND only
DMC radios do not provide MAC level broadcast emulation. An example DMC radios do not provide MAC level broadcast emulation. An example
of that is OCB (outside the context of a BSS), which uses IEEE Std. of that is IEEE Std. 802.11 OCB which uses IEEE Std. 802.11 MAC/PHYs
802.11 transmissions but does not provide the BSS functions. but does not provide the BSS functions.
It is possible to form P2P IP Links between each individual pairs of It is possible to form P2P IP Links between each individual pairs of
nodes and operate IPv6 ND over those Links with Link Local addresses. nodes and operate IPv6 ND over those Links with Link Local addresses.
DAD must be performed for all addresses on all P2P IP Links. DAD must be performed for all addresses on all P2P IP Links.
If special deployment care is taken so that the physical broadcast If special deployment care is taken so that the physical broadcast
domains of a collection of the nodes fully overlap, then it is also domains of a collection of the nodes fully overlap, then it is also
possible to build an IP Subnet within that collection of nodes and possible to build an IP Subnet within that collection of nodes and
operate IPv6 ND. operate IPv6 ND.
skipping to change at page 18, line 27 skipping to change at page 18, line 27
9.1. Normative References 9.1. Normative References
[I-D.ietf-6lo-ap-nd] [I-D.ietf-6lo-ap-nd]
Thubert, P., Sarikaya, B., Sethi, M., and R. Struik, Thubert, P., Sarikaya, B., Sethi, M., and R. Struik,
"Address Protected Neighbor Discovery for Low-power and "Address Protected Neighbor Discovery for Low-power and
Lossy Networks", draft-ietf-6lo-ap-nd-12 (work in Lossy Networks", draft-ietf-6lo-ap-nd-12 (work in
progress), April 2019. progress), April 2019.
[I-D.ietf-6lo-backbone-router] [I-D.ietf-6lo-backbone-router]
Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6
Backbone Router", draft-ietf-6lo-backbone-router-11 (work Backbone Router", draft-ietf-6lo-backbone-router-13 (work
in progress), February 2019. in progress), September 2019.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol", Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, DOI 10.17487/RFC3963, January 2005, RFC 3963, DOI 10.17487/RFC3963, January 2005,
<https://www.rfc-editor.org/info/rfc3963>. <https://www.rfc-editor.org/info/rfc3963>.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
November 2005, <https://www.rfc-editor.org/info/rfc4191>. November 2005, <https://www.rfc-editor.org/info/rfc4191>.
skipping to change at page 19, line 20 skipping to change at page 19, line 20
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
Perkins, "Registration Extensions for IPv6 over Low-Power Perkins, "Registration Extensions for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Neighbor Wireless Personal Area Network (6LoWPAN) Neighbor
Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
<https://www.rfc-editor.org/info/rfc8505>. <https://www.rfc-editor.org/info/rfc8505>.
9.2. Informative References 9.2. Informative References
[I-D.bi-savi-wlan] [I-D.bi-savi-wlan]
Bi, J., Wu, J., Wang, Y., and T. Lin, "A SAVI Solution for Bi, J., Wu, J., Wang, Y., and T. Lin, "A SAVI Solution for
WLAN", draft-bi-savi-wlan-16 (work in progress), November WLAN", draft-bi-savi-wlan-17 (work in progress), May 2019.
2018.
[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", draft-ietf-6tisch-architecture-20 (work of IEEE 802.15.4", draft-ietf-6tisch-architecture-26 (work
in progress), March 2019. in progress), August 2019.
[I-D.ietf-mboned-ieee802-mcast-problems] [I-D.ietf-mboned-ieee802-mcast-problems]
Perkins, C., McBride, M., Stanley, D., Kumari, W., and J. Perkins, C., McBride, M., Stanley, D., Kumari, W., and J.
Zuniga, "Multicast Considerations over IEEE 802 Wireless Zuniga, "Multicast Considerations over IEEE 802 Wireless
Media", draft-ietf-mboned-ieee802-mcast-problems-05 (work Media", draft-ietf-mboned-ieee802-mcast-problems-08 (work
in progress), April 2019. in progress), August 2019.
[I-D.ietf-rift-rift] [I-D.ietf-rift-rift]
Team, T., "RIFT: Routing in Fat Trees", draft-ietf-rift- Przygienda, T., Sharma, A., Thubert, P., and D. Afanasiev,
rift-05 (work in progress), April 2019. "RIFT: Routing in Fat Trees", draft-ietf-rift-rift-08
(work in progress), September 2019.
[I-D.thubert-6lo-unicast-lookup] [I-D.thubert-6lo-unicast-lookup]
Thubert, P. and E. Levy-Abegnoli, "IPv6 Neighbor Discovery Thubert, P. and E. Levy-Abegnoli, "IPv6 Neighbor Discovery
Unicast Lookup", draft-thubert-6lo-unicast-lookup-00 (work Unicast Lookup", draft-thubert-6lo-unicast-lookup-00 (work
in progress), January 2019. in progress), January 2019.
[I-D.thubert-roll-unaware-leaves] [I-D.thubert-roll-unaware-leaves]
Thubert, P., "Routing for RPL Leaves", draft-thubert-roll- Thubert, P., "Routing for RPL Leaves", draft-thubert-roll-
unaware-leaves-07 (work in progress), April 2019. unaware-leaves-07 (work in progress), April 2019.
 End of changes. 22 change blocks. 
73 lines changed or deleted 86 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/