< draft-thubert-6man-ipv6-over-wireless-06.txt   draft-thubert-6man-ipv6-over-wireless-07.txt >
6MAN P. Thubert, Ed. 6MAN P. Thubert, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track 1 June 2020 Intended status: Standards Track 24 November 2020
Expires: 3 December 2020 Expires: 28 May 2021
IPv6 Neighbor Discovery on Wireless Networks IPv6 Neighbor Discovery on Wireless Networks
draft-thubert-6man-ipv6-over-wireless-06 draft-thubert-6man-ipv6-over-wireless-07
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 3 December 2020. This Internet-Draft will expire on 28 May 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (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
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. ND-Classic, Wireless ND and ND-Proxies . . . . . . . . . . . 4 3. ND-Classic, Wireless ND and ND-Proxies . . . . . . . . . . . 4
4. IP Models . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. IP Models . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Physical Broadcast Domain . . . . . . . . . . . . . . . . 6 4.1. Physical Broadcast Domain . . . . . . . . . . . . . . . . 6
4.2. Link Layer Broadcast Emulations . . . . . . . . . . . . . 7 4.2. Link Layer Broadcast Emulations . . . . . . . . . . . . . 7
4.3. Mapping the IPv6 link Abstraction . . . . . . . . . . . . 9 4.3. Mapping the IPv6 link Abstraction . . . . . . . . . . . . 9
4.4. Mapping the IPv6 subnet Abstraction . . . . . . . . . . . 10 4.4. Mapping the IPv6 subnet Abstraction . . . . . . . . . . . 10
5. Wireless Neighbor Discovery . . . . . . . . . . . . . . . . . 10 5. Wireless Neighbor Discovery . . . . . . . . . . . . . . . . . 11
5.1. Introduction to Wireless ND . . . . . . . . . . . . . . . 11 5.1. Introduction to Wireless ND . . . . . . . . . . . . . . . 11
5.2. links and Link-Local Addresses . . . . . . . . . . . . . 12 5.2. links and Link-Local Addresses . . . . . . . . . . . . . 12
5.3. subnets and Global Addresses . . . . . . . . . . . . . . 12 5.3. subnets and Global Addresses . . . . . . . . . . . . . . 12
6. WiND Applicability . . . . . . . . . . . . . . . . . . . . . 13 6. WiND Applicability . . . . . . . . . . . . . . . . . . . . . 13
6.1. Case of LPWANs . . . . . . . . . . . . . . . . . . . . . 14 6.1. Case of LPWANs . . . . . . . . . . . . . . . . . . . . . 14
6.2. Case of Infrastructure BSS and ESS . . . . . . . . . . . 14 6.2. Case of Infrastructure BSS and ESS . . . . . . . . . . . 14
6.3. Case of Mesh Under Technologies . . . . . . . . . . . . . 15 6.3. Case of Mesh Under Technologies . . . . . . . . . . . . . 15
6.4. Case of DMB radios . . . . . . . . . . . . . . . . . . . 16 6.4. Case of DMB radios . . . . . . . . . . . . . . . . . . . 16
6.4.1. Using ND-Classic only . . . . . . . . . . . . . . . . 16 6.4.1. Using ND-Classic only . . . . . . . . . . . . . . . . 16
6.4.2. Using Wireless ND . . . . . . . . . . . . . . . . . . 16 6.4.2. Using Wireless ND . . . . . . . . . . . . . . . . . . 16
skipping to change at page 4, line 39 skipping to change at page 4, line 39
RS: Router Solicitation RS: Router Solicitation
VLAN: Virtual Local Area Network VLAN: Virtual Local Area Network
WiND: Wireless Neighbor Discovery WiND: Wireless Neighbor Discovery
WLAN: Wireless Local Area Network WLAN: Wireless Local Area Network
WPAN: Wireless Personal Area Network WPAN: Wireless Personal Area Network
3. ND-Classic, Wireless ND and ND-Proxies 3. ND-Classic, Wireless ND and ND-Proxies
The ND-Classic Neighbor Solicitation (NS) [RFC4861] message is used The ND-Classic Neighbor Solicitation (NS) [RFC4861] message is used
as a multicast IP packet for Address Resolution (AR) and Duplicate as a multicast IP packet for Address Resolution (AR) and Duplicate
Address Setection (DAD) [RFC4862]. In those cases, the NS message is Address Detection (DAD) [RFC4862]. In those cases, the NS message is
sent at the Network Layer to a Solicited-Node Multicast Address sent at the Network Layer to a Solicited-Node Multicast Address
(SNMA) [RFC4291] and should in theory only reach a very small group (SNMA) [RFC4291] and should in theory only reach a very small group
of nodes. Those messages are generated individually for each of nodes. It is intended for one Target, that may or may not be
address, and may occur when a node joins the network, moves, or wakes present in the network, but it is often turned into a MAC-Layer
up and reconnects to the network. broadcast and effectively reaches most of the nodes on link.
DAD was designed for the efficient broadcast operation of Ethernet. DAD was designed for the efficient broadcast operation of Ethernet.
Experiments show that DAD often fails to discover the duplication of Experiments show that DAD often fails to discover the duplication of
IPv6 addresses in large wireless access networks [DAD ISSUES]. In IPv6 addresses in large wireless access networks [DAD ISSUES]. In
practice, IPv6 addresses very rarely conflict, not because the practice, IPv6 addresses very rarely conflict, not because the
address duplications are detected and resolved by the DAD operation, address duplications are detected and resolved by the DAD operation,
but thanks to the entropy of the 64-bit Interface IDs (IIDs) that but thanks to the entropy of the 64-bit Interface IDs (IIDs) that
makes a collision quasi-impossible for randomized IIDs. makes a collision quasi-impossible for randomized IIDs.
ND-Classic Address Lookups and DADs over a very large fabric can Multicast NS transmissions may occur when a node joins the network,
generate hundreds of broadcasts per second. If the broadcasts were moves, or wakes up and reconnects to the network. Over a very large
blindly copied over Wi-Fi, the ND-related multicast traffic could fabric, this can generate hundreds of broadcasts per second. If the
consume enough bandwidth to cause a substantial degradation to the broadcasts were blindly copied over Wi-Fi, the MAC-layer broadcast
unicast service [MCAST EFFICIENCY]. To protect their bandwidth, some traffic associated to ND IP-layer multicast could consume enough
networks throttle ND-related broadcasts, which reduces the capability bandwidth to cause a substantial degradation to the unicast service
for the ND protocol to operate as expected. [MCAST EFFICIENCY]. To protect their bandwidth, some networks
throttle ND-related broadcasts, which reduces the capability for the
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. For protocols that rely on Link Layer broadcast operations. [IEEE Std.
instance, [IEEE Std. 802.11] recommends to deploy proxies for the 802.11] recommends to deploy proxies for the IPv4 Address Resolution
IPv4 Address Resolution Protocl (ARP)) and IPv6 Neighbor Discosvery Protocol (ARP) and IPv6 ND at the APs. This requires the exhaustive
functions at the Access Points (APs). But proxying ND requires the list of the IP addresses for which proxying is provided. Forming and
full list of the IPv6 addresses for which proxying is provided. maintaining that knowledge a hard problem in the general case of
Forming and maintaining that knowledge a hard problem in the general radio connectivity, which keeps changing with movements and
case of radio connectivity, which keeps changing with movements and variations in the environment that alter the range of transmissions.
other variations in the environment.
[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
discovered in the case of a "silent" node that is not currently using discovered in the case of a "silent" node that is not currently using
one of its addresses, e.g., a printer that waits in wake-on-lan 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 IPv6 addresses to be proxied for. 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. creating a large broadcast domain at the Link Layer. In a fashion
similar to a Wi-Fi Association, IPv6 Hosts register their addresses
In a fashion similar to a Wi-Fi Association, IPv6 Hosts register to their serving router(s), using [RFC8505]. With the registration,
their addresses to their serving router(s), using [RFC8505]. With the routers have a complete knowledge of the hosts they serve and in
the registration, the routers have a complete knowledge of the hosts return, hosts obtain routing services for their registered addresses.
they serve and in return, hosts obtain routing services for their The registration is abstract to the routing service, and it can be
registered addresses. The registration is abstract to the routing protected to prevent impersonation attacks with [RFC8928].
service, and it can be protected to prevent impersonation attacks
with [ADDR PROTECT].
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
[BB ROUTER]. [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
skipping to change at page 9, line 5 skipping to change at page 8, line 50
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.
Going down the list of cases above, the cost of a broadcast As the cost of broadcast transmissions becomes increasingly
transmissions becomes increasingly expensive, and there is a push to expensive, there is a push to rethink the upper Layer protocols to
rethink the upper Layer protocols so as to reduce the depency on reduce the dependency on broadcast operations.
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 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 ND-Classic [RFC4861] DAD [RFC4862] process uses a Link. The ND-Classic [RFC4861] DAD [RFC4862] process uses a
multicast transmission to detect a duplicate address, which requires multicast transmission to detect a duplicate address, which requires
that the owner of the address is connected to the Link Layer that the owner of the address is connected to the Link Layer
broadcast domain of the sender. broadcast domain of the sender.
skipping to change at page 10, line 5 skipping to change at page 9, line 46
The scope on which the uniqueness of an LLA must be checked is each The scope on which the uniqueness of an LLA must be checked is each
new pair of nodes for the duration of their conversation. As long as new pair of nodes for the duration of their conversation. As long as
there's no conflict, a node may use the same LLA with multiple peers there's no conflict, a node may use the same LLA with multiple peers
but it has to perform DAD again with each new peer. A node may need but it has to perform DAD again with each new peer. A node may need
to form a new LLA to talk to a new peer, and multiple LLAs may be to form a new LLA to talk to a new peer, and multiple LLAs may be
present in the same radio interface to talk to different peers. In present in the same radio interface to talk to different peers. In
practice, each pair of nodes defines a temporary P2P link, which can practice, each pair of nodes defines a temporary P2P link, which can
be modeled as a sub-interface of the radio interface. be modeled as a sub-interface of the radio interface.
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
the subnet when that other node attempts to form an address that
would be a duplicate or attempts to resolve the MAC address of this
node. This is why ND is applicable for P2P and transit links, but
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 IPv6 also defines the concept of a subnet for Global and Unique Local
Addresses (GLA and ULA). All the addresses in a subnet share the Addresses (GLA and ULA). All the addresses in a subnet share the
same prefix, and by extension, a node belongs to a subnet if it has same prefix, and by extension, a node belongs to a subnet if it has
with an address in that subnet. an address that derives from the prefix of the subnet. That address
must be topologically correct, meaning 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
skipping to change at page 11, line 4 skipping to change at page 11, line 6
other node directly using ND-Classic. other node directly using ND-Classic.
But an IP link and an IP subnet are not always congruent. In the But an IP link and an IP subnet are not always congruent. In the
case of a Shared Link, individual subnets may each encompass only a case of a Shared Link, individual subnets may each encompass only a
subset of the nodes connected to the link. Conversely, in Route-Over subset of the nodes connected to the link. Conversely, in Route-Over
Multi-link subnets (MLSN) [RFC4903], routers federate the links Multi-link subnets (MLSN) [RFC4903], routers federate the links
between nodes that belong to the subnet, the subnet is not on-link between nodes that belong to the subnet, the subnet is not on-link
and it extends beyond any of the federated links. and it extends beyond any of the federated links.
5. Wireless Neighbor Discovery 5. Wireless Neighbor Discovery
5.1. Introduction to Wireless ND
The DAD and AR procedures in ND-Classic expect that a node in a 5.1. Introduction to Wireless ND
subnet is reachable within the broadcast domain of any other node in
the subnet when that other node attempts to form an address that
would be a duplicate or attempts to resolve the MAC address of this
node. This is why ND is applicable for P2P and transit links, but
requires extensions for more complex topologies.
WiND [RFC6775][RFC8505][BB ROUTER][ADDR PROTECT] defines a new WiND [RFC6775][RFC8505][RFC8929][RFC8928] defines a new operation for
operation for ND that is based on 2 major paradigm changes, proactive ND that is based on 2 major paradigm changes, proactive address
address registration by hosts to their attachment routers and routing registration by hosts to their attachment routers and routing to host
to host routes (/128) within the subnet. This allows WiND to avoid routes (/128) within the subnet. This allows WiND to avoid the
the expectations of transit links and subnet-wide broadcast domains. expectations of transit links and subnet-wide broadcast domains.
WiND is agnostic to the method used for Address Assignment, e.g., WiND is agnostic to the method used for Address Assignment, e.g.,
Stateless Address Autoconfiguration (SLAAC) [RFC4862] or DHCPv6 Stateless Address Autoconfiguration (SLAAC) [RFC4862] or DHCPv6
[RFC8415]. It does not change the IPv6 addressing [RFC4291] or the [RFC8415]. It does not change the IPv6 addressing [RFC4291] or the
current practices of assigning prefixes, typically a /64, to a current practices of assigning prefixes, typically a /64, to a
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.
skipping to change at page 12, line 5 skipping to change at page 11, line 47
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.
For instance, a 6BBR in bridging proxy mode (more in [BB ROUTER]) can For instance, a 6BBR in bridging proxy mode (more in [RFC8929]) can
operate as a Layer-3 AP to serve wireless IPv6 hosts that are Wi-Fi operate as a Layer-3 AP to serve wireless IPv6 hosts that are Wi-Fi
STAs and maintain the reachability for Global Unicast and Link-LOcal STAs and maintain the reachability for Global Unicast and Link-LOcal
Addresses within the federated MLSN. Addresses within the federated MLSN.
5.2. links and Link-Local Addresses 5.2. links and Link-Local Addresses
For Link-Local Addresses, DAD is typically performed between For Link-Local Addresses, DAD is typically performed between
communicating pairs of nodes and an NCE can be populated with a communicating pairs of nodes and an NCE can be populated with a
single unicast exchange. In the case of a bridging proxies, though, single unicast exchange. In the case of a bridging proxies, though,
the Link-Local traffic is bridged over the backbone and the DAD must the Link-Local traffic is bridged over the backbone and the DAD must
skipping to change at page 12, line 42 skipping to change at page 12, line 37
5.3. subnets and Global Addresses 5.3. subnets and Global Addresses
WiND extends ND-Classic for Hub-and-Spoke (e.g., BLE) and Route-Over WiND extends ND-Classic 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 routers, the Hub advertises the prefix as not-on-link to Acting as a router, the Hub advertises the prefix as not-on-link to
the spokes in RA messages Prefix Information Options (PIO). Acting the spokes in RA messages Prefix Information Options (PIO). Acting
as hosts, the Spokes autoconfigure addresses from that prefix and as hosts, the Spokes autoconfigure addresses from that prefix and
register them to the Hub with a corresponding lifetime. Acting as a register them to the Hub with a corresponding lifetime.
registrar, the Hub maintains a binding table of all the registered IP
addresses and rejects duplicate registrations, thus ensuring a DAD Acting as a registrar, the Hub maintains a binding table of all the
protection for a registered address even if the registering node is registered IP addresses and rejects duplicate registrations, thus
sleeping. The Hub also maintains an NCE for the registered addresses ensuring a DAD protection for a registered address even if the
and can deliver a packet to any of them during their respective registering node is sleeping.
lifetimes. It can be observed that this design builds a form of
Network Layer Infrastructure BSS. The Hub also maintains an NCE for the registered addresses and can
deliver a packet to any of them during their respective lifetimes.
It can be observed that this design builds a form of Network Layer
Infrastructure BSS.
A Route-Over MLSN is considered as a collection of Hub-and-Spoke A Route-Over MLSN is considered as a collection of Hub-and-Spoke
where the Hubs form a connected dominating set of the member nodes of where the Hubs form a connected dominating set of the member nodes of
the subnet, and IPv6 routing takes place between the Hubs within the the subnet, and IPv6 routing takes place between the Hubs within the
subnet. A single logical registrar is deployed to serve the whole subnet. A single logical registrar is deployed to serve the whole
mesh. mesh.
The registration in [RFC8505] is abstract to the routing protocol and The registration in [RFC8505] is abstract to the routing protocol and
provides enough information to feed a routing protocol such as RPL as provides enough information to feed a routing protocol such as RPL as
specified in [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 [BB ROUTER] 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 [BB ROUTER]. 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.
skipping to change at page 15, line 15 skipping to change at page 15, line 15
The recommended alternative method is to use the WiND Registration The recommended alternative method is to use the WiND Registration
for IPv6 Addresses. This way, the AP exposes its capability to proxy for IPv6 Addresses. This way, the AP exposes its capability to proxy
ND to the STA in Router Advertisement messages. In turn, the STA may ND to the STA in Router Advertisement messages. In turn, the STA may
request proxy ND services from the AP for all of its IPv6 addresses, request proxy ND services from the AP for all of its IPv6 addresses,
using the Extended Address Registration Option, which provides the using the Extended Address Registration Option, which provides the
following elements: following elements:
* The registration state has a lifetime that limits unwanted state * The registration state has a lifetime that limits unwanted state
remanence in the network. remanence in the network.
* The registration is optionally secured using [ADDR PROTECT] to * The registration is optionally secured using [RFC8928] to prevent
prevent address theft and impersonation. address theft and impersonation.
* The registration carries a sequence number, which enables to * The registration carries a sequence number, which enables to
figure the order of events in a fast mobility scenario without figure the order of events in a fast mobility scenario without
loss of connectivity. loss of connectivity.
The ESS mode requires a proxy ND operation at the AP. The proxy ND The ESS mode requires a proxy ND operation at the AP. The proxy ND
operation must cover Duplicate Address Detection, Neighbor operation must cover Duplicate Address Detection, Neighbor
Unreachability Detection, Address Resolution and Address Mobility to Unreachability Detection, Address Resolution and Address Mobility to
transfer a role of ND proxy to the AP where a STA is associated transfer a role of ND proxy to the AP where a STA is associated
following the mobility of the STA. 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 [BB ROUTER]. 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
skipping to change at page 20, line 11 skipping to change at page 20, line 11
(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>.
[ADDR PROTECT] [RFC8928] Thubert, P., Ed., 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", RFC 8928, DOI 10.17487/RFC8928, November
Lossy Networks", Work in Progress, Internet-Draft, draft- 2020, <https://www.rfc-editor.org/info/rfc8928>.
ietf-6lo-ap-nd-23, 30 April 2020,
<https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-23>.
[BB ROUTER] [RFC8929] Thubert, P., Ed., Perkins, C.E., and E. Levy-Abegnoli,
Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 "IPv6 Backbone Router", RFC 8929, DOI 10.17487/RFC8929,
Backbone Router", Work in Progress, Internet-Draft, draft- November 2020, <https://www.rfc-editor.org/info/rfc8929>.
ietf-6lo-backbone-router-20, 23 March 2020,
<https://tools.ietf.org/html/draft-ietf-6lo-backbone-
router-20>.
11. Informative References 11. Informative References
[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>.
skipping to change at page 21, line 25 skipping to change at page 21, line 21
[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. Richardson, "Routing for RPL Leaves",
Work in Progress, Internet-Draft, draft-ietf-roll-unaware- Work in Progress, Internet-Draft, draft-ietf-roll-unaware-
leaves-15, 15 April 2020, <https://tools.ietf.org/html/ leaves-23, 10 November 2020, <https://tools.ietf.org/html/
draft-ietf-roll-unaware-leaves-15>. draft-ietf-roll-unaware-leaves-23>.
[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-28, 29 October 2019, draft-ietf-6tisch-architecture-29, 27 August 2020,
<https://tools.ietf.org/html/draft-ietf-6tisch- <https://tools.ietf.org/html/draft-ietf-6tisch-
architecture-28>. architecture-29>.
[MCAST PROBLEMS] [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", Work in Progress, Internet-Draft, draft-ietf- Media", Work in Progress, Internet-Draft, draft-ietf-
mboned-ieee802-mcast-problems-11, 11 December 2019, mboned-ieee802-mcast-problems-12, 26 October 2020,
<https://tools.ietf.org/html/draft-ietf-mboned-ieee802- <https://tools.ietf.org/html/draft-ietf-mboned-ieee802-
mcast-problems-11>. mcast-problems-12>.
[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-19, 14 May 2020, wlan-20, 14 November 2020,
<https://tools.ietf.org/html/draft-bi-savi-wlan-19>. <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,
<https://tools.ietf.org/html/draft-thubert-6lo-unicast- <https://tools.ietf.org/html/draft-thubert-6lo-unicast-
lookup-00>. lookup-00>.
[DAD APPROACHES] [DAD APPROACHES]
Nordmark, E., "Possible approaches to make DAD more robust Nordmark, E., "Possible approaches to make DAD more robust
 End of changes. 32 change blocks. 
87 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/