< draft-thubert-6man-ipv6-over-wireless-01.txt   draft-thubert-6man-ipv6-over-wireless-02.txt >
6MAN P. Thubert, Ed. 6MAN P. Thubert, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Informational April 30, 2019 Intended status: Informational May 2, 2019
Expires: November 1, 2019 Expires: November 3, 2019
IPv6 Neighbor Discovery on Wireless Networks IPv6 Neighbor Discovery on Wireless Networks
draft-thubert-6man-ipv6-over-wireless-01 draft-thubert-6man-ipv6-over-wireless-02
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 1, 2019. This Internet-Draft will expire on November 3, 2019.
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. IP Models . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Physical Broadcast Domain . . . . . . . . . . . . . . . . 2 3. IP Models . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. MAC-Layer Broadcast Emulations . . . . . . . . . . . . . 3 3.1. Physical Broadcast Domain . . . . . . . . . . . . . . . . 6
2.3. Mapping the IPv6 Link Abstraction . . . . . . . . . . . . 5 3.2. MAC-Layer Broadcast Emulations . . . . . . . . . . . . . 7
2.4. Mapping the IPv6 Subnet Abstraction . . . . . . . . . . . 6 3.3. Mapping the IPv6 Link Abstraction . . . . . . . . . . . . 8
3. Wireless ND . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.4. Mapping the IPv6 Subnet Abstraction . . . . . . . . . . . 9
3.1. Introduction to WiND . . . . . . . . . . . . . . . . . . 6 4. Wireless ND . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Links and Link-Local Addresses . . . . . . . . . . . . . 7 4.1. Introduction to WiND . . . . . . . . . . . . . . . . . . 10
3.3. Subnets and Global Addresses . . . . . . . . . . . . . . 8 4.2. Links and Link-Local Addresses . . . . . . . . . . . . . 11
4. WiND Applicability . . . . . . . . . . . . . . . . . . . . . 9 4.3. Subnets and Global Addresses . . . . . . . . . . . . . . 11
4.1. Case of LPWANs . . . . . . . . . . . . . . . . . . . . . 10 5. WiND Applicability . . . . . . . . . . . . . . . . . . . . . 12
4.2. Case of Infrastructure BSS and ESS . . . . . . . . . . . 10 5.1. Case of LPWANs . . . . . . . . . . . . . . . . . . . . . 13
4.3. Case of Mesh Under Technologies . . . . . . . . . . . . . 11 5.2. Case of Infrastructure BSS and ESS . . . . . . . . . . . 13
4.4. Case of DMC radios . . . . . . . . . . . . . . . . . . . 11 5.3. Case of Mesh Under Technologies . . . . . . . . . . . . . 14
4.4.1. Using IPv6 ND only . . . . . . . . . . . . . . . . . 11 5.4. Case of DMC radios . . . . . . . . . . . . . . . . . . . 14
4.4.2. Using Wireless ND . . . . . . . . . . . . . . . . . . 11 5.4.1. Using IPv6 ND only . . . . . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 5.4.2. Using Wireless ND . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
2. IP Models IEEE STD. 802.1 [IEEEstd8021] Ethernet Bridging provides an efficient
and reliable broadcast service for wired networks; applications and
protocols have been built that heavily depend on that feature for
their core operation. Unfortunately, Low-Power Lossy Networks (LLNs)
and local wireless networks generally do not provide the broadcast
capabilities of Ethernet Bridging in an economical fashion.
2.1. Physical Broadcast Domain As a result, protocols designed for bridged networks that rely on
multicast and broadcast often exhibit disappointing behaviours when
employed unmodified on a local wireless medium (see
[I-D.ietf-mboned-ieee802-mcast-problems]).
Wi-Fi [IEEEstd80211] Access Points (APs) deployed in an Extended
Service Set (ESS) act as Ethernet Bridges [IEEEstd8021], with the
property that the bridging state is established at the time of
association. This ensures connectivity to the node (STA) and
protects the wireless medium against broadcast-intensive Transparent
Bridging reactive Lookups.
In other words, the association process is used to register the MAC
Address of the STA to the AP. The AP subsequently proxies the
bridging operation and does not need to forward the broadcast Lookups
over the radio.
Like Transparent Bridging, IPv6 [RFC8200] Neighbor Discovery
[RFC4861] [RFC4862] Protocol (IPv6 ND) is a reactive protocol, based
on multicast transmissions to locate an on-link correspondent and
ensure the uniqueness of an IPv6 address. The mechanism for
Duplicate Address Detection (DAD) [RFC4862] was designed for the
efficient broadcast operation of Ethernet Bridging. Since broadcast
can be unreliable over wireless media, DAD often fails to discover
duplications [I-D.yourtchenko-6man-dad-issues]. In practice, IPv6
addresses very rarely conflict because of the entropy of the 64-bit
Interface IDs, not because address duplications are detected and
resolved.
The IPv6 ND Neighbor Solicitation (NS) [RFC4861] message is used for
DAD and address Lookup when a node moves, or wakes up and reconnects
to the wireless network. The NS message is targeted to a Solicited-
Node Multicast Address (SNMA) [RFC4291] and should in theory only
reach a very small group of nodes. But in reality, IPv6 multicast
messages are typically broadcast on the wireless medium, and so they
are processed by most of the wireless nodes over the subnet (e.g.,
the ESS fabric) regardless of how few of the nodes are subscribed to
the SNMA. As a result, IPv6 ND address Lookups and DADs over a large
wireless and/or a LowPower Lossy Network (LLN) can consume enough
bandwidth to cause a substantial degradation to the unicast traffic
service.
Because IPv6 ND messages sent to the SNMA group are broadcasted at
the radio MAC Layer, wireless nodes that do not belong to the SNMA
group still have to keep their radio turned on to listen to multicast
NS messages, which is a total waste of energy for them. In order to
reduce their power consumption, certain battery-operated devices such
as IoT sensors and smartphones ignore some of the broadcasts, making
IPv6 ND operations even less reliable.
These problems can be alleviated by reducing the IPv6 ND broadcasts
over wireless access links. This has been done by splitting the
broadcast domains and by routing between subnets, at the extreme by
assigning a /64 prefix to each wireless node (see [RFC8273]).
Another way is to proxy at the boundary of the wired and wireless
domains the Layer-3 protocols that rely on MAC Layer broadcast
operations. For instance, IEEE 802.11 [IEEEstd80211] situates proxy-
ARP (IPv4) and proxy-ND (IPv6) functions at the Access Points (APs).
But proxying ND requires a perfect knowledge of the peer IPv6
addresses for which proxying is provided. In a generic fashion,
radio connectivity changes with movements and variations in the
environment, which makes forming and maintaining that knowledge a
hard problem in the general case.
Discovering peer addresses by snooping the IPV6 ND protocol as
proposed for SAVI [I-D.bi-savi-wlan] was found to be unreliable. An
IPv6 address may not be discovered immediately due to a packet loss,
or if a "silent" node is not currently using one of its addresses,
e.g., a node that waits in wake-on-lan state. A change of state,
e.g. due to a movement, may be missed or misordered, leading to
unreliable connectivity and an incomplete knowledge of the set of
peers.
Wireless ND (WiND) introduces a new approach to IPv6 ND that is
designed to apply to the WLANs and WPANs types of networks. On the
one hand, WiND avoids the use of broadcast operation for Address
Lookup and Duplicate Address Detection, and on the other hand, WiND
supports use cases where Subnet and MAC-level domains are not
congruent, which is common in those types of networks unless a
specific MAC-Level emulation is provided.
To achieve this, WiND applies routing inside the Subnets, which
enables MultiLink Subnets. Hosts register their addresses to their
serving routers with [RFC8505]. With the registration, routers have
a complete knowledge of the hosts they serve and in return, hosts
obtain routing services for their registered addresses. The
registration is abstract to the routing protocol, and it can be
protected to prevent impersonation attacks with [I-D.ietf-6lo-ap-nd].
The routing service can be a simple reflexion in a Hub-and-Spoke
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
[RFC6550] that was designed to adapt to various LLNs such as WLAN and
WPAN radio meshes with the concept of Objective Function. Finally,
the routing service can also be ND proxy that emulates an IEEE Std
802.11 Infrastructure ESS at Layer 3. WiND specifies the IPv6
Backbone Router for that purpose in [I-D.ietf-6lo-backbone-router].
More details on WiND can be found in Section 4.1.
2. Acronyms
This document uses the following abbreviations:
6BBR: 6LoWPAN Backbone Router
6LBR: 6LoWPAN Border Router
6LN: 6LoWPAN Node
6LR: 6LoWPAN Router
6CIO: Capability Indication Option
ARO: Address Registration Option
DAC: Duplicate Address Confirmation
DAD: Duplicate Address Detection
DAR: Duplicate Address Request
EDAC: Extended Duplicate Address Confirmation
EDAR: Extended Duplicate Address Request
DODAG: Destination-Oriented Directed Acyclic Graph
MLSN: Multi-Link Subnet
LLN: Low-Power and Lossy Network
NA: Neighbor Advertisement
NBMA: Non-Broadcast Multi-Access
NCE: Neighbor Cache Entry
ND: Neighbor Discovery
NDP: Neighbor Discovery Protocol
NS: Neighbor Solicitation
ROVR: Registration Ownership Verifier
RPL: IPv6 Routing Protocol for LLNs
RA: Router Advertisement
RS: Router Solicitation
TID: Transaction ID
WiND: Wireless Neighbor Discovery
WLAN: Wireless Local Area Network
WPAN: Wireless Personal Area Network
3. IP Models
3.1. Physical Broadcast Domain
At the physical (PHY) Layer, a broadcast domain is the set of all At the physical (PHY) Layer, a broadcast domain is the set of all
peers that may receive a datagram that one sends over an interface. peers that may receive a datagram that one sends over an interface.
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-
to-point (P2P) link. It may also comprise multiple peer nodes on a to-point (P2P) link. It may also comprise multiple peer nodes on a
broadcast radio or a shared physical resource such as the legacy broadcast radio or a shared physical resource such as the legacy
Ethernet shared wire. Ethernet shared wire.
On WLAN and WPAN radios, the physical broadcast domain is defined by On WLAN and WPAN radios, the physical broadcast domain is defined by
a particular transmitter, as the set of nodes that can receive what a particular transmitter, as the set of nodes that can receive what
skipping to change at page 3, line 25 skipping to change at page 6, line 50
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 talk to connectivity is generally not transitive, meaning that A may talk to
B and B may talk to C does not necessarily imply that A can talk to B and B may talk to C does not necessarily imply that A can talk to
C. C.
We define MAC-Layer Direct Broadcast (DMC) a transmission mode where We define MAC-Layer Direct 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 [IEEE80211] OCB (for Out of the Context of a BSS) are examples 802.11 [IEEEstd80211] OCB (for Out of the Context of a BSS) are
of DMC radios. This constrasts with a number of MAC-layer Broadcast examples of DMC radios. This constrasts with a number of MAC-layer
Emulation schemes that are described in the next section. Broadcast Emulation schemes that are described in the next section.
2.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 Briging emulates the broadcast properties of that wire wire, Ethernet Briging emulates the broadcast properties of that wire
over a whole physical mesh of Ethernet links. For the upper layer, over a whole physical mesh of Ethernet links. For the upper layer,
the qualities of the shared wire are essentially conserved, with a the qualities of the shared wire are essentially conserved, with a
reliable and cheap broadcast operation over a closure of nodes reliable and cheap broadcast operation over a closure of nodes
defined by their connectivity to the emulated wire. defined by their connectivity to the emulated wire.
In large switched fabrics, overlay techniques enable a limited In large switched fabrics, overlay techniques enable a limited
connectivity between nodes that are known to a mapping server. The connectivity between nodes that are known to a mapping server. The
skipping to change at page 4, line 21 skipping to change at page 7, line 48
duration that can be 100 times that of a unicast. For that reason, duration that can be 100 times that of a unicast. For that reason,
upper layer protocols should tend to avoid the use of broadcast when upper layer protocols should tend to avoid the use of broadcast when
operating over Wi-Fi. operating over Wi-Fi.
In an IEEE Std 802.11 Infrastructure Extended Service Set (ESS), the In an IEEE Std 802.11 Infrastructure Extended Service Set (ESS), the
process of the association also prepares a bridging state proactively process of the association also prepares a bridging state proactively
at the AP, so as to avoid the reactive broadcast lookup that takes at the AP, so as to avoid the reactive broadcast lookup that takes
place in the process of transparent bridging over a spanning tree. place in the process of transparent bridging over a spanning tree.
This model provides a more reliable operation than the reactive This model provides a more reliable operation than the reactive
transparent bridging and avoid the need of multicast, and it is only transparent bridging and avoid the need of multicast, and it is only
logical that IPv6 [RFC8200] Neighbor Discovery (ND) logical that IPv6 ND evolved towards proposes similar methods at
[RFC4861][RFC4862] evolved towards proposes similar methods at
Layer-3 for its operation. Layer-3 for its operation.
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 bridgeing, and the broadcast domain is well defined by the similar to bridgeing, 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.
skipping to change at page 5, line 5 skipping to change at page 8, line 29
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.11p, which operates Out of the Context of a
BSS (DMC radios) is an example of a network that does not have a MAC- BSS (DMC radios) is an example of a network that does not have a MAC-
Layer broadcast domain emulation, which means that it will exhibit Layer broadcast domain emulation, which means that it will exhibit
mostly reflexive and mostly non-transitive transmission properties. mostly reflexive and mostly non-transitive transmission properties.
2.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
operation is always a MAC_Layer broadcast for the lack of a Layer-2 operation is always a MAC_Layer broadcast for the lack of a Layer-2
multicast operation that could handle a possibly very large number of multicast operation that could handle a possibly very large number of
skipping to change at page 6, line 5 skipping to change at page 9, line 25
DAD operation cannot provide once and for all guarantees on the DAD operation cannot provide once and for all guarantees on the
broadcast domain defined by one radio transmitter if that transmitter broadcast domain defined by one radio transmitter if that transmitter
keeps meeting new peers on the go. The nodes may need to form new keeps meeting new peers on the go. The nodes may need to form new
LLAs to talk to one another and the scope where LLA uniqueness can be LLAs to talk to one another and the scope where LLA uniqueness can be
dynamically checked is that pair of nodes. As long as there's no dynamically checked is that pair of nodes. As long as there's no
conflict a node may use the same LLA with multiple peers but it has conflict a node may use the same LLA with multiple peers but it has
to revalidate DAD with every new peer node. In practice, each pair to revalidate DAD with every new peer node. In practice, each pair
of nodes defines a temporary P2P link, which can be modeled as a sub- of nodes defines a temporary P2P link, which can be modeled as a sub-
interface of the radio interface. interface of the radio interface.
2.4. Mapping the IPv6 Subnet Abstraction 3.4. Mapping the IPv6 Subnet Abstraction
IPv6 also defines a concept of Subnet for Glocal and Unique Local IPv6 also defines a concept of Subnet for Glocal and Unique Local
Addresses. Addresses in a same Subnet share a same prefix and by Addresses. Addresses in a same Subnet share a same prefix and by
extension, a node belongs to a Subnet if it has an interface with an extension, a node belongs to a Subnet if it has an interface with an
address on that Subnet. A Subnet prefix is Globally Unique so it is address on that Subnet. A Subnet prefix is Globally Unique so it is
sufficient to validate that an address that is formed from a Subnet sufficient to validate that an address that is formed from a Subnet
prefix is unique within that Subnet to guarantee that it is globally prefix is unique within that Subnet to guarantee that it is globally
unique. IPv6 aggregation relies on the property that a packet from unique. IPv6 aggregation relies on the property that a packet from
the outside of a Subnet can be routed to any router that belongs to the 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
skipping to change at page 6, line 44 skipping to change at page 10, line 16
the Subnet, the Subnet is not onlink and it extends beyond any of the the Subnet, the Subnet is not onlink and it extends beyond any of the
federated Links. federated Links.
The DAD and lookup procedures in IPv6 ND expects that a node in a The DAD and lookup procedures in IPv6 ND expects 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 only applicable for P2P and transit links, node. This is why ND is only applicable for P2P and transit links,
and requires extensions for other topologies. and requires extensions for other topologies.
3. Wireless ND 4. Wireless ND
3.1. Introduction to WiND 4.1. Introduction to WiND
Wireless Neighbor Discovery (WiND) Wireless Neighbor Discovery (WiND)
[RFC6775][RFC8505][I-D.ietf-6lo-backbone-router][I-D.ietf-6lo-ap-nd] [RFC6775][RFC8505][I-D.ietf-6lo-backbone-router][I-D.ietf-6lo-ap-nd]
defines a new ND operation that is based on 2 major paradigm changes, defines a new ND operation that is based on 2 major paradigm changes,
proactive address registration by hosts to their attachment routers proactive address registration by hosts to their attachment routers
and routing to host routes (/128) within the subnet. This allows and routing to host routes (/128) within the subnet. This allows
WiND to avoid the classical ND expectations of transit links and WiND to avoid the classical ND expectations of transit links and
Subnet-wide broadcast domains. Subnet-wide broadcast domains.
The proactive address registration is performed with a new option in The proactive address registration is performed with a new option in
skipping to change at page 7, line 36 skipping to change at page 11, line 9
central registrar, using new ND Extended Duplicate Address messages central registrar, using new ND Extended Duplicate Address messages
(EDAR and EDAC) [RFC8505]. This operation modernizes ND for (EDAR and EDAC) [RFC8505]. This operation modernizes ND for
application in overlays with Map Resolvers and enables unicast application in overlays with Map Resolvers and enables unicast
lookups [I-D.thubert-6lo-unicast-lookup] for addresses registered to lookups [I-D.thubert-6lo-unicast-lookup] for addresses registered to
the resolver. the resolver.
WiND also enables to extend a legacy /64 on Ethernet with ND proxy WiND also enables to extend a legacy /64 on Ethernet with ND proxy
over the wireless. This way nodes can form any address the want and over the wireless. This way nodes can form any address the want and
move freely from an L3-AP (that is really a backbone router in move freely from an L3-AP (that is really a backbone router in
bridging mode, more in [I-D.ietf-6lo-backbone-router]) to another, bridging mode, more in [I-D.ietf-6lo-backbone-router]) to another,
without renumbering. without renumbering. Backbone Routers federate multiple LLNs over a
Backbone Link to form a MultiLink Subnet (MLSN). Backbone Routers
placed along the LLN edge of the Backbone handle IPv6 Neighbor
Discovery, and forward packets on behalf of registered nodes.
An LLN node (6LN) registers all its IPv6 Addresses using an NS(EARO)
as specified in [RFC8505] to the 6BBR. The 6BBR is also a Border
Router that performs IPv6 Neighbor Discovery (IPv6 ND) operations on
its Backbone interface on behalf of the 6LNs that have registered
addresses on its LLN interfaces without the need of a broadcast over
the wireless medium.
WiND is also compatible with DHCPv6 and other forms of address WiND is also compatible with DHCPv6 and other forms of address
assignment in which case it can still be used for DAD. assignment in which case it can still be used for DAD.
3.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) [RFC7668] Ior instance, in the case of a Bluetooth Low Energy (BLE)
Hub-and Spoke configuration, Uniqueness of Link local Addresses need [RFC7668][IEEEstd802151] Hub-and Spoke configuration, Uniqueness of
only to be verified between the pairs of communicating nodes, a Link local Addresses need only to be verified between the pairs of
central router and a peripheral host. In that example, 2 peripheral communicating nodes, a central router and a peripheral host. In that
hosts connected to the same central router can not have the same Link example, 2 peripheral hosts connected to the same central router can
Local Address because the Binding Cache Entries (BCEs) would collide not have the same Link Local Address because the Binding Cache
at the central router which could not talk to both over the same Entries (BCEs) would collide at the central router which could not
interface. The WiND operation is appropriate for that DAD operation, talk to both over the same interface. The WiND operation is
but the one from ND is not, because peripheral hosts are not on the appropriate for that DAD operation, but the one from ND is not,
same broadcast domain. On the other hand, Global and ULA DAD is because peripheral hosts are not on the same broadcast domain. On
validated at the Subnet Level, using a registrar hosted by the the other hand, Global and ULA DAD is validated at the Subnet Level,
central router. using a registrar hosted by the central router.
3.3. Subnets and Global Addresses 4.3. Subnets and Global Addresses
WiND extends IPv6 ND for Hub-and-Spoke (e.g., BLE) and Route-Over WiND extends IPv6 ND for Hub-and-Spoke (e.g., BLE) and Route-Over
(e.g., RPL) Multi-Link Subnets (MLSNs). (e.g., RPL) Multi-Link Subnets (MLSNs).
In the Hub-and-Spoke case, each Hub-Spoke pair is a distinct IP Link, In the Hub-and-Spoke case, each Hub-Spoke pair is a distinct IP Link,
and a Subnet can be mapped on a collection of Links that are and a Subnet can be mapped on a collection of Links that are
connected to the Hub. The Subnet prefix is associated to the Hub. connected to the Hub. The Subnet prefix is associated to the Hub.
Acting as 6LR, the Hub advertises the prefix as not-onlink to the Acting as 6LR, the Hub advertises the prefix as not-onlink to the
spokes in RA messages Prefix Information Options (PIO). Acting as spokes in RA messages Prefix Information Options (PIO). Acting as
6LNs, the Spokes autoconfigure addresses from that prefix and 6LNs, the Spokes autoconfigure addresses from that prefix and
register them to the Hub with a corresponding lifetime. Acting as a register them to the Hub with a corresponding lifetime. Acting as a
6LBR, the Hub maintains a binding table of all the registered IP 6LBR, the Hub maintains a binding table of all the registered IP
addresses and rejects duplicate registrations, thus ensuring a DAD addresses and rejects duplicate registrations, thus ensuring a DAD
protection for a registered address even if the registering node is protection for a registered address even if the registering node is
sleeping. Acting as 6LR, the Hub also maintains an NCE for the sleeping. Acting as 6LR, the Hub also maintains an NCE for the
registered addresses and can deliver a packet to any of them for registered addresses and can deliver a packet to any of them for
their respective lifetimes. It can be observed that this design their respective lifetimes. It can be observed that this design
builds a form of Layer-3 Infrastructure BSS. builds a form of Layer-3 Infrastructure BSS.
A Route-Over MLSN is considered as a collection of Hub-and-Spoke A Route-Over MLSN is considered as a collection of Hub-and-Spoke
where the Hubs form a connected dominating set of the member nodes of where the Hubs form a connected dominating set of the member nodes of
the Subnet, and IPv6 routing takes place between the Hubs within the the Subnet, and IPv6 routing takes place between the Hubs within the
Subnet. A single logical 6LBR is deployed to serve the whole mesh. Subnet. A single logical 6LBR is deployed to serve the whole mesh.
The registration in [RFC8505] is abstract to the routing protocol and The registration in [RFC8505] is abstract to the routing protocol and
provides enough information to feed a routing protocol such as RPL provides enough information to feed a routing protocol such as RPL as
[draft unaware leaf]. In a degraded mode, all the Hubs are connected specified in [I-D.thubert-roll-unaware-leaves]. In a degraded mode,
to a same high speed backbone such as an Ethernet bridging domain all the Hubs are connected to a same high speed backbone such as an
where IPv6 ND is operated. In that case, it is possible to federate Ethernet bridging domain where IPv6 ND is operated. In that case, it
the Hub, Spoke and Backbone nodes as a single Subnet, operating IPv6 is possible to federate the Hub, Spoke and Backbone nodes as a single
ND proxy operations [I-D.ietf-6lo-backbone-router] at the Hubs, Subnet, operating IPv6 ND proxy operations
acting as 6BBRs. It can be observed that this latter design builds a [I-D.ietf-6lo-backbone-router] at the Hubs, acting as 6BBRs. It can
form of Layer-3 Infrastructure ESS. be observed that this latter design builds a form of Layer-3
Infrastructure ESS.
4. WiND Applicability 5. WiND Applicability
WiND allows P2P, P2MP hub-and spoke, MAC-level broadcast domain WiND allows P2P, P2MP hub-and spoke, MAC-level broadcast domain
emulation such as mesh-under and Wi-Fi BSS, and route over meshes.^ emulation such as mesh-under and Wi-Fi BSS, and route over meshes.^
There is an intersection where Link and Subnet are congruent and There is an intersection where Link and Subnet are congruent and
where both ND and WiND could apply. These includes P2P, the MAC where both ND and WiND could apply. These includes P2P, the MAC
emulation of a PHY broadcast domain, and the particular case of emulation of a PHY broadcast domain, and the particular case of
always on, fully overlapping physical radio broadcast domain. But always on, fully overlapping physical radio broadcast domain. But
even in those cases where both are possible, WiND is preferable vs. even in those cases where both are possible, WiND is preferable vs.
ND because it reduces the need of broadcast ( this is discussed in ND because it reduces the need of broadcast ( this is discussed in
the introduction of [I-D.ietf-6lo-backbone-router]). the introduction of [I-D.ietf-6lo-backbone-router]).
There are also numerous practical use cases in the wireless world There are also numerous practical use cases in the wireless world
where Links and Subnets are not P2P and not congruent: where Links and Subnets are not P2P and not congruent:
o IEEE std 802.11 infrastructure BSS enables one subnet per AP, and o IEEE std 802.11 infrastructure BSS enables one subnet per AP, and
emulates a broadcast domain at L2. Infra ESS extends that and emulates a broadcast domain at L2. Infra ESS extends that and
recommends to use an IPv6 ND proxy [IEEE80211] to coexist with recommends to use an IPv6 ND proxy [IEEEstd80211] to coexist with
Ethernet connected nodes. WiND incorporates an ND proxy to serve Ethernet connected nodes. WiND incorporates an ND proxy to serve
that need and that was missing so far. that need and that was missing so far.
o BlueTooth is Hub-and-Spoke at the MAC layer. It would make little o BlueTooth is Hub-and-Spoke at the MAC layer. It would make little
sense to configure a different subnet between the central and each sense to configure a different subnet between the central and each
individual peripheral node (e.g., sensor). Rather, [RFC7668] individual peripheral node (e.g., sensor). Rather, [RFC7668]
allocates a prefix to the central node acting as router (6LR), and allocates a prefix to the central node acting as router (6LR), and
each peripheral host (acting as a host (6LR) forms one or more each peripheral host (acting as a host (6LR) forms one or more
address(es) from that same prefix and registers it. address(es) from that same prefix and registers it.
o A typical Smartgrid networks puts together Route-Over MLSNs that o 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] reflects the Route-Over model, and [I-D.ietf-6tisch-architecture] presents the Route-Over model over
a [IEEEstd802154] Time-Slotted Channel-Hopping mesh, and
generalizes it for multiple other applications. Each node in a generalizes it for multiple other applications. Each node in a
Smartgrid network may have tens to a hundred others nodes in Smartgrid network may have tens to a hundred others nodes in
range. A key problem for the routing protocol is which other range. A key problem for the routing protocol is which other
node(s) should this node peer with, because most of the possible node(s) should this node peer with, because most of the possible
peers do not provide added routing value. When both energy and peers do not provide added routing value. When both energy and
bandwidth are constrained,talking to them is a bad idea and most bandwidth are constrained,talking to them is a bad idea and most
of the possible P2P links are not even used. Peerings that are of the possible P2P links are not even used. Peerings that are
actually used come and go with the dynamics of radio signal actually used come and go with the dynamics of radio signal
propagation. It results that allocating prefixes to all the propagation. It results that allocating prefixes to all the
possible P2P Links and maintain as many addresses in all nodes is possible P2P Links and maintain as many addresses in all nodes is
not even considered. not even considered.
4.1. Case of LPWANs 5.1. Case of LPWANs
LPWANs are by nature so constrained that the addresses and Subnets LPWANs are by nature so constrained that the addresses and Subnets
are fully pre-configured and operate as P2P or Hub-and-Spoke. This are fully pre-configured and operate as P2P or Hub-and-Spoke. This
saves the steps of neighbor Discovery and enables a very efficient saves the steps of neighbor Discovery and enables a very efficient
stateful compression of the IPv6 header. stateful compression of the IPv6 header.
4.2. Case of Infrastructure BSS and ESS 5.2. Case of Infrastructure BSS and ESS
In contrast to IPv4, IPv6 enables a node to form multiple addresses, In contrast to IPv4, IPv6 enables a node to form multiple addresses,
some of them temporary to elusive, and with a particular attention some of them temporary to elusive, and with a particular attention
paid to privacy. Addresses may be formed and deprecated paid to privacy. Addresses may be formed and deprecated
asynchronously to the association. Even if the knowledge of IPv6 asynchronously to the association. Even if the knowledge of IPv6
addresses used by a STA can be obtained by snooping protocols such as addresses used by a STA can be obtained by snooping protocols such as
IPv6 ND and DHCPv6, or by observing data traffic sourced at the STA, IPv6 ND and DHCPv6, or by observing data traffic sourced at the STA,
such methods provide only an imperfect knowledge of the state of the such methods provide only an imperfect knowledge of the state of the
STA at the AP. This may result in a loss of connectivity for some STA at the AP. This may result in a loss of connectivity for some
IPv6 addresses, in particular for addresses rarely used and in a IPv6 addresses, in particular for addresses rarely used and in a
skipping to change at page 11, line 7 skipping to change at page 14, line 29
[I-D.ietf-6lo-backbone-router]. With that specification, the AP [I-D.ietf-6lo-backbone-router]. With that specification, the AP
participates to the protocol as a Backbone Router, typically participates to the protocol as a Backbone Router, typically
operating as a bridging proxy though the routing proxy operation is operating as a bridging proxy though the routing proxy operation is
also possible. As a bridging proxy, the proxy replies to NS lookups also possible. As a bridging proxy, the proxy replies to NS lookups
with the MAC address of the STA, and then bridges packets to the STA with the MAC address of the STA, and then bridges packets to the STA
normally; as a routing proxy, it replies with its own MAC address and normally; as a routing proxy, it replies with its own MAC address and
then routes to the STA at the IP layer. The routing proxy reduces then routes to the STA at the IP layer. The routing proxy reduces
the need to expose the MAC address of the STA on the wired side, for the need to expose the MAC address of the STA on the wired side, for
a better stability and scalability of the bridged fabric. a better stability and scalability of the bridged fabric.
4.3. Case of Mesh Under Technologies 5.3. Case of Mesh Under Technologies
The Mesh-Under provides a broadcast domain emulation with reflexive The Mesh-Under provides a broadcast domain emulation with reflexive
and Transitive properties and defines a transit Link for IPv6 and Transitive properties and defines a transit Link for IPv6
operations. It results that the model for IPv6 operation is similar operations. It results that the model for IPv6 operation is similar
to that of a BSS, with the root of the mesh operating an Access Point to that of a BSS, with the root of the mesh operating an Access Point
does in a BSS/ESS. While it is still possible to operate IPv6 ND, does in a BSS/ESS. While it is still possible to operate IPv6 ND,
the inefficiencies of the flooding operation make the IPv6 ND the inefficiencies of the flooding operation make the IPv6 ND
operations even less desirable than in a BSS, and the use of WiND is operations even less desirable than in a BSS, and the use of WiND is
highly recommended. highly recommended.
4.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.
4.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 OCB (outside the context of a BSS), which uses IEEE Std.
802.11 transmissions but does not provide the BSS functions. 802.11 transmissions but does not provide the BSS functions.
It is possible to form P2P IP Links between each individual pairs of It is possible to form P2P IP Links between each individual pairs of
nodes and operate IPv6 ND over those Links with Link Local addresses. nodes and operate IPv6 ND over those Links with Link Local addresses.
DAD must be performed for all addresses on all P2P IP Links. DAD must be performed for all addresses on all P2P IP Links.
If special deployment care is taken so that the physical broadcast If special deployment care is taken so that the physical broadcast
domains of a collection of the nodes fully overlap, then it is also domains of a collection of the nodes fully overlap, then it is also
possible to build an IP Subnet within that collection of nodes and possible to build an IP Subnet within that collection of nodes and
operate IPv6 ND. operate IPv6 ND.
The model can be stretched beyond the scope of IPv6 ND if an external The model can be stretched beyond the scope of IPv6 ND if an external
mechanism avoids duplicate addresses and if the deployment ensures mechanism avoids duplicate addresses and if the deployment ensures
the connectivity between peers. This can be achieved for instance in the connectivity between peers. This can be achieved for instance in
a Hub-and-Spoke deployment if the Hub is the only router in the a Hub-and-Spoke deployment if the Hub is the only router in the
Subnet and the Prefix is advertised as not onlink. Subnet and the Prefix is advertised as not onlink.
4.4.2. Using Wireless ND 5.4.2. Using Wireless ND
Though this can be achieved with IPv6 ND, WiND is the recommended Though this can be achieved with IPv6 ND, WiND is the recommended
approach since it uses more unicast communications which are more approach since it uses more unicast communications which are more
reliable and less impacting for other users of the medium. reliable and less impacting for other users of the medium.
Router and Hosts respectively send a compressed RA/NA with a SLLAO at Router and Hosts respectively send a compressed RA/NA with a SLLAO at
a regular period. The period can be indicated in a RA as in an RA- a regular period. The period can be indicated in a RA as in an RA-
Interval Option [RFC6275]. If available, the message can be Interval Option [RFC6275]. If available, the message can be
transported in a compressed form in a beacon, e.g., in OCB Basic transported in a compressed form in a beacon, e.g., in OCB Basic
Safety Messages (BSM) that are nominally sent every 100ms. An active Safety Messages (BSM) that are nominally sent every 100ms. An active
skipping to change at page 14, line 5 skipping to change at page 17, line 47
An example Hub-and-Spoke is an OCB Road-Side Unit (RSU) that owns a An example Hub-and-Spoke is an OCB Road-Side Unit (RSU) that owns a
prefix, provides Internet connectivity using that prefix to On-Board prefix, provides Internet connectivity using that prefix to On-Board
Units (OBUs) within its physical broadcast domain. An example of Units (OBUs) within its physical broadcast domain. An example of
Route-Over MLSN is a collection of cars in a parking lot operating Route-Over MLSN is a collection of cars in a parking lot operating
RPL to extend the connectivity provided by the RSU beyond its RPL to extend the connectivity provided by the RSU beyond its
physical broadcast domain. Cars may then operate NEMO [RFC3963] for physical broadcast domain. Cars may then operate NEMO [RFC3963] for
their own prefix using their address derived from the prefix of the their own prefix using their address derived from the prefix of the
RSU as CareOf Address. RSU as CareOf Address.
5. IANA Considerations 6. IANA Considerations
This specification does not require IANA action. This specification does not require IANA action.
6. Security Considerations 7. Security Considerations
This specification refers to the security sections of IPv6 ND and This specification refers to the security sections of IPv6 ND and
WiND, respectively. WiND, respectively.
7. Acknowledgments 8. Acknowledgments
Many thanks to the participants of the 6lo WG where a lot of the work Many thanks to the participants of the 6lo WG where a lot of the work
discussed here happened. Also ROLL, 6TiSCH, and 6LoWPAN. discussed here happened. Also ROLL, 6TiSCH, and 6LoWPAN.
8. References 9. References
8.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-11 (work
skipping to change at page 15, line 20 skipping to change at page 19, line 16
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
Perkins, "Registration Extensions for IPv6 over Low-Power Perkins, "Registration Extensions for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Neighbor Wireless Personal Area Network (6LoWPAN) Neighbor
Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
<https://www.rfc-editor.org/info/rfc8505>. <https://www.rfc-editor.org/info/rfc8505>.
8.2. Informative References 9.2. Informative References
[I-D.bi-savi-wlan]
Bi, J., Wu, J., Wang, Y., and T. Lin, "A SAVI Solution for
WLAN", draft-bi-savi-wlan-16 (work in progress), November
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-20 (work
in progress), March 2019. in progress), March 2019.
[I-D.ietf-mboned-ieee802-mcast-problems]
Perkins, C., McBride, M., Stanley, D., Kumari, W., and J.
Zuniga, "Multicast Considerations over IEEE 802 Wireless
Media", draft-ietf-mboned-ieee802-mcast-problems-05 (work
in progress), April 2019.
[I-D.ietf-rift-rift] [I-D.ietf-rift-rift]
Team, T., "RIFT: Routing in Fat Trees", draft-ietf-rift- Team, T., "RIFT: Routing in Fat Trees", draft-ietf-rift-
rift-05 (work in progress), April 2019. rift-05 (work in progress), April 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.
[IEEE80211] [I-D.yourtchenko-6man-dad-issues]
"IEEE Standard 802.11 - IEEE Standard for Information Yourtchenko, A. and E. Nordmark, "A survey of issues
Technology - Telecommunications and information exchange related to IPv6 Duplicate Address Detection", draft-
between systems Local and metropolitan area networks - yourtchenko-6man-dad-issues-01 (work in progress), March
Specific requirements - Part 11: Wireless LAN Medium 2015.
Access Control (MAC) and Physical Layer (PHY)
Specifications.".
[IEEE802154] [IEEE802154]
IEEE standard for Information Technology, "IEEE Std. IEEE standard for Information Technology, "IEEE Std.
802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)
and Physical Layer (PHY) Specifications for Low-Rate and Physical Layer (PHY) Specifications for Low-Rate
Wireless Personal Area Networks". Wireless Personal Area Networks".
[IEEEstd8021]
IEEE standard for Information Technology, "IEEE Standard
for Information technology -- Telecommunications and
information exchange between systems Local and
metropolitan area networks Part 1: Bridging and
Architecture".
[IEEEstd80211]
IEEE standard for Information Technology, "IEEE Standard
for Information technology -- Telecommunications and
information exchange between systems Local and
metropolitan area networks-- Specific requirements Part
11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) Specifications".
[IEEEstd802151]
IEEE standard for Information Technology, "IEEE Standard
for Information Technology - Telecommunications and
Information Exchange Between Systems - Local and
Metropolitan Area Networks - Specific Requirements. - Part
15.1: Wireless Medium Access Control (MAC) and Physical
Layer (PHY) Specifications for Wireless Personal Area
Networks (WPANs)".
[IEEEstd802154]
IEEE standard for Information Technology, "IEEE Standard
for Local and metropolitan area networks -- Part 15.4:
Low-Rate Wireless Personal Area Networks (LR-WPANs)".
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>. 2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903,
DOI 10.17487/RFC4903, June 2007, DOI 10.17487/RFC4903, June 2007,
<https://www.rfc-editor.org/info/rfc4903>. <https://www.rfc-editor.org/info/rfc4903>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
skipping to change at page 16, line 31 skipping to change at page 21, line 23
Bormann, "Neighbor Discovery Optimization for IPv6 over Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)", Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012, RFC 6775, DOI 10.17487/RFC6775, November 2012,
<https://www.rfc-editor.org/info/rfc6775>. <https://www.rfc-editor.org/info/rfc6775>.
[RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low
Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015,
<https://www.rfc-editor.org/info/rfc7668>. <https://www.rfc-editor.org/info/rfc7668>.
[RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix
per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017,
<https://www.rfc-editor.org/info/rfc8273>.
Author's Address Author's Address
Pascal Thubert (editor) Pascal Thubert (editor)
Cisco Systems, Inc Cisco Systems, Inc
Building D Building D
45 Allee des Ormes - BP1200 45 Allee des Ormes - BP1200
MOUGINS - Sophia Antipolis 06254 MOUGINS - Sophia Antipolis 06254
FRANCE FRANCE
Phone: +33 497 23 26 34 Phone: +33 497 23 26 34
 End of changes. 38 change blocks. 
84 lines changed or deleted 306 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/