< draft-thubert-6man-ipv6-over-wireless-09.txt   draft-thubert-6man-ipv6-over-wireless-10.txt >
6MAN P. Thubert, Ed. 6MAN P. Thubert, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Informational 17 May 2021 Intended status: Informational 18 November 2021
Expires: 18 November 2021 Expires: 22 May 2022
IPv6 Neighbor Discovery on Wireless Networks IPv6 Neighbor Discovery on Wireless Networks
draft-thubert-6man-ipv6-over-wireless-09 draft-thubert-6man-ipv6-over-wireless-10
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 18 November 2021. This Internet-Draft will expire on 22 May 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 19 skipping to change at page 2, line 19
2.1. IP Links . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. IP Links . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. IP Subnets . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. IP Subnets . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 6
3. ND-Classic, Wireless ND and ND-Proxies . . . . . . . . . . . 6 3. ND-Classic, Wireless ND and ND-Proxies . . . . . . . . . . . 6
4. IP Models . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. IP Models . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Physical Broadcast Domain . . . . . . . . . . . . . . . . 8 4.1. Physical Broadcast Domain . . . . . . . . . . . . . . . . 8
4.2. link-layer Broadcast Emulations . . . . . . . . . . . . . 9 4.2. link-layer Broadcast Emulations . . . . . . . . . . . . . 9
4.3. Mapping the IPv6 link Abstraction . . . . . . . . . . . . 11 4.3. Mapping the IPv6 link Abstraction . . . . . . . . . . . . 11
4.4. Mapping the IPv6 subnet Abstraction . . . . . . . . . . . 12 4.4. Mapping the IPv6 subnet Abstraction . . . . . . . . . . . 12
5. Wireless Neighbor Discovery . . . . . . . . . . . . . . . . . 13 5. Wireless Neighbor Discovery . . . . . . . . . . . . . . . . . 13
5.1. Introduction to Wireless ND . . . . . . . . . . . . . . . 13 5.1. Introduction to Stateful Address Autoconfiguration . . . 13
5.2. links and Link-Local Addresses . . . . . . . . . . . . . 14 5.2. links and Link-Local Addresses . . . . . . . . . . . . . 14
5.3. subnets and Global Addresses . . . . . . . . . . . . . . 14 5.3. Subnets and Global Addresses . . . . . . . . . . . . . . 14
6. WiND Applicability . . . . . . . . . . . . . . . . . . . . . 15 5.4. Anycast and Multicast Addresses . . . . . . . . . . . . . 15
6.1. Case of LPWANs . . . . . . . . . . . . . . . . . . . . . 16 6. WiND Applicability . . . . . . . . . . . . . . . . . . . . . 16
6.2. Case of Infrastructure BSS and ESS . . . . . . . . . . . 16 6.1. Case of LPWANs . . . . . . . . . . . . . . . . . . . . . 17
6.2. Case of Infrastructure BSS and ESS . . . . . . . . . . . 17
6.3. Case of Mesh Under Technologies . . . . . . . . . . . . . 18 6.3. Case of Mesh Under Technologies . . . . . . . . . . . . . 18
6.4. Case of DMB radios . . . . . . . . . . . . . . . . . . . 18 6.4. Case of DMB radios . . . . . . . . . . . . . . . . . . . 18
6.4.1. Using ND-Classic only . . . . . . . . . . . . . . . . 18 6.4.1. Using ND-Classic only . . . . . . . . . . . . . . . . 18
6.4.2. Using Wireless ND . . . . . . . . . . . . . . . . . . 18 6.4.2. Using Wireless ND . . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
10. Normative References . . . . . . . . . . . . . . . . . . . . 21 10. Normative References . . . . . . . . . . . . . . . . . . . . 22
11. Informative References . . . . . . . . . . . . . . . . . . . 22 11. Informative References . . . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
IEEE Std. 802.1 [IEEE Std. 802.1] Ethernet Bridging provides an IEEE Std. 802.1 [IEEE Std. 802.1] Ethernet Bridging provides an
efficient and reliable broadcast service for wired networks; efficient and reliable broadcast service for wired networks;
applications and protocols have been built that heavily depend on applications and protocols have been built that heavily depend on
that feature for their core operation. Unfortunately, Low-Power that feature for their core operation. Unfortunately, Low-Power
Lossy Networks (LLNs) and Wireless Local Area Networks (WLANs) Lossy Networks (LLNs) and Wireless Local Area Networks (WLANs)
generally do not benefit from the same reliable and cheap broadcast generally do not benefit from the same reliable and cheap broadcast
capabilities as Ethernet links. capabilities as Ethernet links.
skipping to change at page 4, line 42 skipping to change at page 4, line 23
For a long time, the term link has been used to refer to the layer 2 For a long time, the term link has been used to refer to the layer 2
communication medium that can be leveraged at layer 3 to instantiate communication medium that can be leveraged at layer 3 to instantiate
one IP hop. In this document we conserve that term but differentiate one IP hop. In this document we conserve that term but differentiate
it from an IP link, which is a layer 3 abstraction that represents it from an IP link, which is a layer 3 abstraction that represents
the layer 2 link but is not the layer 2 link, like the map is not the the layer 2 link but is not the layer 2 link, like the map is not the
country. country.
With IPv6, IP has moved to layer 3 abstractions for its operations, With IPv6, IP has moved to layer 3 abstractions for its operations,
e.g., with the use of link local address (LLA), and that of IP e.g., with the use of link local address (LLA), and that of IP
multicast for link-scoped operations. At the same time, the concept multicast for link-scoped operations. At the same time, the concept
of an IP link emerged as an abstraction that represents how the IPv6 of an IP link emerged as an abstraction that represents how IP layer
considers the layer 2 link: considers the layer 2 link:
* An IP link connects an IP node to one or more other IP nodes using * An IP link connects an IP node to one or more other IP nodes using
a lower layer network. The lower layer network may comprise a lower layer subnetwork. The lower layer subnetwork may comprise
multiple lower layer links, e.g., in the case of a switched fabric multiple lower layer links, e.g., in the case of a switched fabric
or a mesh-under LLN. or a mesh-under LLN.
* an IP link defines the scope of an LLA, and defines the domain in * an IP link defines the scope of an LLA, and defines the domain in
which the LLA must be unique which the LLA must be unique
* an IP link provides a subset of the connectivity that is offered * an IP link provides a subset of the connectivity that is offered
by the lower layer; if the IP link is narrower than the layer 2 by the lower layer; if the IP link is narrower than the layer 2
reachable domain, then layer 3 filters must restrict the link- reachable domain, then layer 3 filters must restrict the link-
scoped communication to remain between peers on a same IP link, scoped communication to remain between peers on a same IP link,
skipping to change at page 5, line 27 skipping to change at page 5, line 16
over a given lower layer network, e.g., to map a Frame Relay network over a given lower layer network, e.g., to map a Frame Relay network
as a P2MP IP link, or as a collection of P2P IP links. As another as a P2MP IP link, or as a collection of P2P IP links. As another
example, an Ethernet fabric may be bridged, in which case the nodes example, an Ethernet fabric may be bridged, in which case the nodes
that interconnect the layer 2 links are L2 switches, and the fabric that interconnect the layer 2 links are L2 switches, and the fabric
can be abstracted as a single transit IP link; or the fabric can be can be abstracted as a single transit IP link; or the fabric can be
routed, in which case the P2P IP links are congruent with the layer 2 routed, in which case the P2P IP links are congruent with the layer 2
links, and the nodes that interconnect the links are routers. links, and the nodes that interconnect the links are routers.
2.2. IP Subnets 2.2. IP Subnets
IPv6 builds another abstraction, the subnet, over one shared or over IPv6 builds another abstraction, the IP subnet, over one shared IP
multiple IP links, forming a MLSN in the latter case. An MLSN is link or over a collection IP links, forming a MLSN in the latter
formed over IP links (e.g., P2P or P2MP) that are interconnected by case. An MLSN is formed over IP links (e.g., P2P or P2MP) that are
routers that either inject hosts routes in an IGP, in which case the interconnected by routers that either inject hosts routes in an IGP,
topology can be anything, or perform ND proxy operations, in which in which case the topology can be anything, or perform ND proxy
case the structure of links must be strictly hierarchical to avoid operations, in which case the structure of links must be strictly
loops. hierarchical to avoid loops.
[RFC8929] defines bridging and routing IPv6 ND proxies. Both forms [RFC8929] defines bridging and routing IPv6 ND proxies. Both forms
of ND proxies interconnect IP links and enable to isolate the layer 2 of ND proxies interconnect IP links and enable to isolate the layer 2
broadcast domains. But in the case of a bridging proxy, the layer 2 broadcast domains. But in the case of a bridging proxy, the layer 2
unicast communication can still exist between the layer 2 domains unicast communication can still exist between the layer 2 domains
that are coverered by the layer 3 links, whereas in the base of a that are coverered by the layer 3 links, whereas in the base of a
routing proxy, they are isolated and packets must be routed back and routing proxy, they are isolated and packets must be routed back and
forth. Bridging proxies are possible between compatible technologies forth. Bridging proxies are possible between compatible technologies
and translational bridges (e.g., Wi-Fi to Ethernet), whereas routing and translational bridges (e.g., Wi-Fi to Ethernet), whereas routing
proxies are required between non-bridgeable technologies and proxies are required between non-bridgeable technologies and
desirable to avoid exposing the layer 2 addresses across, e.g., for desirable to avoid exposing the layer 2 addresses across, e.g., for
reasons of stability and scalability. reasons of stability and scalability.
It is another network design decision to use one IP subnet model or It is another network design decision to use one IP subnet model or
another over a given lower layer network. A switched fabric can host another over a given lower layer network. A switched fabric can host
one or more IP subnets, in which case the IP links can reach all and one or more IP subnets, in which case the IP links can reach all and
beyond one subnet. On the other hand, a subnet can encompass a beyond one subnet. On the other hand, a subnet can encompass a
collection of links; in that case, the scope of the link local collection of links; in that case, the scope of the link local
addresses, which is the IP Link, is narrower than that of the subnet. addresses, which is the IP Link, is narrower than the span of the
subnet.
A subnet prefix is associated with the IP subnet, and a node is a
member of an IP subnet when it has an IP address that derives from
that prefix. The IP address is either a Unique Local (ULA) or a
Global Unicast Address (GUA), and as opposed to the case of LLAs, the
scope of the address is not limited to the IP subnet.
The switched and routed fabric above could be the exact same network The switched and routed fabric above could be the exact same network
of physical links and boxes, what changes is the way the networking of physical links and boxes, what changes is the way the networking
abstractions are mapped onto the system, and the implication of such abstractions are mapped onto the system, and the implication of such
decision include the capability to reach another node at layer-2, and decision include the capability to reach another node at layer-2, and
the size of the broadcast domain and related broadcast storms. the size of the broadcast domain and related broadcast storms.
2.3. Acronyms 2.3. Acronyms
This document uses the following abbreviations: This document uses the following abbreviations:
skipping to change at page 6, line 50 skipping to change at page 6, line 50
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 Detection (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. It is intended for one Target, that may or may not be of nodes. It is intended for one Target, that may or may not be
present in the network, but it is often turned into a MAC-Layer present in the network, but it is often turned into a MAC-Layer
broadcast and effectively reaches most of the nodes on link. broadcast and effectively reaches most of the nodes that are attached
to the layer 2 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.
Multicast NS transmissions may occur when a node joins the network, Multicast NS transmissions may occur when a node joins the network,
skipping to change at page 8, line 35 skipping to change at page 8, line 35
details on WiND can be found in Section 5.1. details on WiND can be found in Section 5.1.
4. IP Models 4. IP Models
4.1. Physical Broadcast Domain 4.1. Physical Broadcast Domain
At the physical (PHY) Layer, a broadcast domain is the set of nodes At the physical (PHY) Layer, a broadcast domain is the set of nodes
that may receive a transmission that one sends over an interface, in that may receive a transmission that one sends over an interface, in
other words the set of nodes in range of the radio transmission. other words the set of nodes in range of the radio transmission.
This set can comprise a single peer on a serial cable used as point- This set can comprise a single peer on a serial cable used as point-
to-point (P2P) link. It may also comprise multiple peer nodes on a to-point link. It may also comprise multiple peer nodes on a
broadcast radio or a shared physical resource such as the Ethernet broadcast radio or a shared physical resource such as the Ethernet
wires and hubs for which ND-Classic was initially designed. wires and hubs for which ND-Classic was initially designed.
On WLAN and LoWPAN radios, the physical broadcast domain is defined On WLAN and LoWPAN radios, the physical broadcast domain is defined
relative to a particular transmitter, as the set of nodes that can relative to a particular transmitter, as the set of nodes that can
receive what this transmitter is sending. Literally every frame receive what this transmitter is sending. Literally every frame
defines its own broadcast domain since the chances of reception of a defines its own broadcast domain since the chances of reception of a
given frame are statistical. In average and in stable conditions, given frame are statistical. In average and in stable conditions,
the broadcast domain of a particular node can be still be seen as the broadcast domain of a particular node can be still be seen as
mostly constant and can be used to define a closure of nodes on which mostly constant and can be used to define a closure of nodes on which
skipping to change at page 11, line 20 skipping to change at page 11, line 20
When operating on a single frequency, this operation is known to When operating on a single frequency, this operation is known to
interfere with itself, and requires inter-frame gaps to dampen the interfere with itself, and requires inter-frame gaps to dampen the
collisions, which reduces further the amount of available bandwidth. collisions, which reduces further the amount of available bandwidth.
As the cost of broadcast transmissions becomes increasingly As the cost of broadcast transmissions becomes increasingly
expensive, there is a push to rethink the upper Layer protocols to expensive, there is a push to rethink the upper Layer protocols to
reduce the dependency on broadcast operations. reduce the dependency on broadcast operations.
4.3. Mapping the IPv6 link Abstraction 4.3. Mapping the IPv6 link Abstraction
As introduced in Section 2.1, IPv6 defines a concept of Link, link As introduced in Section 2.1, IPv6 defines a concept of link, link
Scope and Link-Local Addresses (LLA), an LLA being unique and usable scope and Link-Local Addresses (LLA), an LLA being unique and usable
only within the Scope of a Link. The ND-Classic [RFC4861] DAD only within the Scope of a Link. The ND-Classic [RFC4861] DAD
[RFC4862] process uses a multicast transmission to detect a duplicate [RFC4862] process uses a multicast transmission to detect a duplicate
address, which requires that the owner of the address is connected to address, which requires that the owner of the address is connected to
the link-layer broadcast domain of the sender. the link-layer broadcast domain of the sender.
On wired media, the link is often confused with the physical On a wired medium, the IP link is often confused with the physical
broadcast domain because both are determined by the serial cable or broadcast domain because both are determined by the serial cable or
the Ethernet shared wire. Ethernet Bridging reinforces that illusion the Ethernet shared wire. Ethernet Bridging reinforces that illusion
with a link-layer broadcast domain that emulates a physical broadcast with a link-layer broadcast domain that emulates a physical broadcast
domain over the mesh of wires. But the difference shows on legacy domain over the mesh of wires. But the difference shows on legacy
Non-Broadcast Multi-Access (NBMA) networks such as ATM and Frame- P2MP and NBMA networks such as ATM and Frame-Relay, on shared links
Relay, on shared links and on newer types of NBMA networks such as and on newer types of NBMA networks such as radio and composite
radio and composite radio-wires networks. It also shows when private radio-wires networks. It also shows when private VLANs or link-layer
VLANs or link-layer cryptography restrict the capability to read a cryptography restrict the capability to read a frame to a subset of
frame to a subset of the connected nodes. the connected nodes.
In Mesh-Under and Infrastructure BSS, the IP link extends beyond the In Mesh-Under and Infrastructure BSS, the IP link extends beyond the
physical broadcast domain to the emulated link-layer broadcast physical broadcast domain to the emulated link-layer broadcast
domain. Relying on Multicast for the ND operation remains feasible domain. Relying on Multicast for the ND operation remains feasible
but becomes highly detrimental to the unicast traffic, and becomes but becomes highly detrimental to the unicast traffic, and becomes
less and less energy-efficient and reliable as the network grows. less and less energy-efficient and reliable as the network grows.
On DMB radios, IP links between peers come and go as the individual On DMB radios, IP links between peers come and go as the individual
physical broadcast domains of the transmitters meet and overlap. The physical broadcast domains of the transmitters meet and overlap. The
DAD operation cannot provide once and for all guarantees over the DAD operation cannot provide once and for all guarantees over the
skipping to change at page 13, line 8 skipping to change at page 13, line 8
If the subnet is known as on-link, then any node may also resolve the If the subnet is known as on-link, then any node may also resolve the
destination link-layer address and deliver the packet, but if the destination link-layer address and deliver the packet, but if the
subnet is not on-link, then a host in the subnet that does not have a subnet is not on-link, then a host in the subnet that does not have a
Neighbor Cache Entry (NCE) for the destination will also need to pass Neighbor Cache Entry (NCE) for the destination will also need to pass
the packet to a router, more in [RFC5942]. the packet to a router, more in [RFC5942].
On Ethernet, an IP subnet is often congruent with an IP link because On Ethernet, an IP subnet is often congruent with an IP link because
both are determined by the physical attachment to a shared wire or an both are determined by the physical attachment to a shared wire or an
IEEE Std. 802.1 bridged domain. In that case, the connectivity over IEEE Std. 802.1 bridged domain. In that case, the connectivity over
the link is both symmetric and transitive, the subnet can appear as the IP link is both symmetric and transitive, the subnet can appear
on-link, and any node can resolve a destination MAC address of any as on-link, and any node can resolve a destination MAC address of any
other node directly using ND-Classic. other node directly using ND-Classic.
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 5.1. Introduction to Stateful Address Autoconfiguration
WiND [RFC6775][RFC8505][RFC8929][RFC8928] defines a new operation for Stateful Address Autoconfiguration (SFAAC)
ND that is based on 2 major paradigm changes, proactive address [RFC6775][RFC8505][RFC8929][RFC8928] defines a new operation for ND
that is based on 2 major paradigm changes, proactive address
registration by hosts to their attachment routers and routing to host registration by hosts to their attachment routers and routing to host
routes (/128) within the subnet. This allows WiND to avoid the routes (/128) within the subnet. This allows ND to avoid 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., SFAAC 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.
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 14, line 5 skipping to change at page 14, line 5
in ND-Classic and the associated link-layer broadcasts transmissions. in ND-Classic and the associated link-layer broadcasts transmissions.
The EARO provides information to the router that is independent to The EARO provides information to the router that is independent to
the routing protocol and routing can take multiple forms, from a the routing protocol and routing can take multiple forms, from a
traditional IGP to a collapsed Hub-and-Spoke model where only one traditional IGP to a collapsed Hub-and-Spoke model where only one
router owns and advertises the prefix. [RFC8505] is already router owns and advertises the prefix. [RFC8505] is already
referenced as the registration interface to "RIFT: Routing in Fat referenced as the registration interface to "RIFT: Routing in Fat
Trees" [I-D.ietf-rift-rift] and "RPL: IPv6 Routing Protocol for Trees" [I-D.ietf-rift-rift] and "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks" [RFC6550] with [RPL UNAWARE LEAVES]. Low-Power and Lossy Networks" [RFC6550] with [RPL UNAWARE LEAVES].
WiND also enables to span a subnet over an MLSN that federates edge Wireless ND (WiND) combines SFAAC with the not-onlink model on the
wireless links with a high-speed, typically Ethernet, backbone. This wireless interfaces, and a Backbone Router (6BBR) ND proxy function
way, nodes can form any address they want and move freely from a (more in [RFC8929]) operating as a Layer-3 AP. Multiple 6BBRs placed
wireless edge link to another, without renumbering. Backbone Routers along the wireless edge of a Backbone link handle IPv6 Neighbor
(6BBRs) placed along the wireless edge of the Backbone handle IPv6 Discovery and forward packets over the backbone on behalf of the
Neighbor Discovery and forward packets over the backbone on behalf of registered nodes on the wireless edge. This enables to span a subnet
the registered nodes on the wireless edge. over an MLSN that federates edge wireless links with a high-speed,
typically Ethernet, backbone (as a Layer-3 ESS). The ND proxy
For instance, a 6BBR in bridging proxy mode (more in [RFC8929]) can maintains the reachability for Global Unicast and Link-LOcal
operate as a Layer-3 AP to serve wireless IPv6 hosts that are Wi-Fi Addresses within the federated MLSN, either as a routing proxy where
STAs and maintain the reachability for Global Unicast and Link-LOcal it replies with its own MAC address or as a bridging proxy that
Addresses within the federated MLSN. typically forwards the multicast ND messages as unicast Layer-2
frames to their target. The wireless nodes can form any address they
want and move freely from a wireless edge link to another, without
renumbering.
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
proxied there as well. proxied there as well.
For instance, in the case of Bluetooth Low Energy (BLE) For instance, in the case of Bluetooth Low Energy (BLE)
[RFC7668][IEEEstd802151], the uniqueness of Link-Local Addresses [RFC7668][IEEEstd802151], the uniqueness of Link-Local Addresses
needs only to be verified between the pair of communicating nodes, needs only to be verified between the pair of communicating nodes,
the central router and the peripheral host. In that example, 2 the central router and the peripheral host. In that example, 2
peripheral hosts connected to the same central router can not have peripheral hosts connected to the same central router can not have
the same Link-Local Address because the addresses would collision at the same Link-Local Address because the addresses would collision at
the central router which could not talk to both over the same the central router which could not talk to both over the same
interface. The DAD operation from WiND is appropriate for that use interface. The DAD operation from SFAAC is appropriate for that use
case, but the one from ND is not, because the peripheral hosts are case, but the one from ND is not, because the peripheral hosts are
not on the same broadcast domain. not on the same broadcast domain.
On the other hand, the uniqueness of Global and Unique-Local On the other hand, the uniqueness of Global and Unique-Local
Addresses is validated at the subnet Level, using a logical registrar Addresses is validated at the subnet Level, using a logical registrar
that is global to the subnet. that is global to the subnet.
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 SFAAC 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 a router, 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. register them to the Hub with a corresponding lifetime.
skipping to change at page 15, line 36 skipping to change at page 15, line 36
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 [RFC8929] at the Hubs, acting subnet, operating ND proxy operations [RFC8929] at the Hubs, acting
as 6BBRs. It can be observed that this latter design builds a form as 6BBRs. It can be observed that this latter design builds a form
of Network Layer Infrastructure ESS. of Network Layer Infrastructure ESS.
5.4. Anycast and Multicast Addresses
While IPv6 ND is defined for unicast addresses only,
[I-D.ietf-6lo-multicast-registration] extends [RFC8505] for anycast
and multicast IPv6 addresses.
[I-D.ietf-6lo-multicast-registration] can be used as a replacement
for MLDv2 [RFC3810] for use cases where broadcast are not desirable,
and when a device push model such as SFAAC is preferred over a
network pull such as MDv2 and classical ND. With [RFC8505], the host
does not need to define SNMAs for its unicast addresses and does not
perform the associated MLDv2 operation. With
[I-D.ietf-6lo-multicast-registration], MLDv2 and its extensive use of
broadcast can be totally eliminated.
In the case of anycast, the signal enables the 6BBRs to accept more
than one registration for the same address, and collectively elect
the registering host receives a packet for a given anycast address.
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 The IP link and the IP subnet are
where both ND and WiND could apply. These includes P2P, the MAC congruent and where both ND and WiND could apply. These includes
emulation of a PHY broadcast domain, and the particular case of P2P, the MAC emulation of a PHY broadcast domain, and the particular
always on, fully overlapping physical radio broadcast domain. But case of always on, fully overlapping physical radio broadcast domain.
even in those cases where both are possible, WiND is preferable vs. But even in those cases where both are possible, WiND is preferable
ND because it reduces the need of broadcast. vs. ND because it reduces the need of broadcast.
This is discussed in more details in the introduction of [RFC8929]. This is discussed in more details in the introduction of [RFC8929].
There are also a number of practical use cases in the wireless world There are also a number of practical use cases in the wireless world
where links and subnets are not congruent: where links and subnets are not congruent:
* The IEEE Std. 802.11 infrastructure BSS enables one subnet per AP, * The IEEE Std. 802.11 infrastructure BSS enables one subnet per AP,
and emulates a broadcast domain at the link-layer. The and emulates a broadcast domain at the link-layer. The
Infrastructure ESS extends that model over a backbone and Infrastructure ESS extends that model over a backbone and
recommends the use of an ND proxy [IEEE Std. 802.11] to recommends the use of an ND proxy [IEEE Std. 802.11] to
skipping to change at page 19, line 16 skipping to change at page 19, line 32
can be indicated in the RA-Interval Option [RFC6275]. If available, can be indicated in the RA-Interval Option [RFC6275]. If available,
the message can be transported in a compressed form in a beacon, the message can be transported in a compressed form in a beacon,
e.g., in OCB Basic Safety Messages (BSM) that are nominally sent e.g., in OCB Basic Safety Messages (BSM) that are nominally sent
every 100ms. every 100ms.
An active beaconing mode is possible whereby the Host sends broadcast An active beaconing mode is possible whereby the Host sends broadcast
RS messages to which a router can answer with a unicast RA. RS messages to which a router can answer with a unicast RA.
A router that has Internet connectivity and is willing to serve as an A router that has Internet connectivity and is willing to serve as an
Internet Access may advertise itself as a default router [RFC4191] in Internet Access may advertise itself as a default router [RFC4191] in
its RA messages. The RA is sent over an unspecified link where it its RA messages. The RA is sent over an unspecified IP link where it
does not conflict to anyone, so DAD is not necessary at that stage. does not conflict to anyone, so DAD is not necessary at that stage.
The host instantiates a link where the router's address is not a The host instantiates an IP link where the router's address is not a
duplicate. To achieve this, it forms an LLA that does not conflict duplicate. To achieve this, it forms an LLA that does not conflict
with that of the router and registers to the router using [RFC8505]. with that of the router and registers to the router using [RFC8505].
If the router sent an RA(PIO), the host can also autoconfigure an If the router sent an RA(PIO), the host can also autoconfigure an
address from the advertised prefix and register it. address from the advertised prefix and register it.
(host) (router) (host) (router)
| | | |
| DMB link | | DMB link |
| | | |
| IPv6 ND RS | | IPv6 ND RS |
skipping to change at page 19, line 49 skipping to change at page 20, line 29
| NA(EARO) | | NA(EARO) |
|<--------------| |<--------------|
| | | |
Figure 1: Initial Registration Flow Figure 1: Initial Registration Flow
The lifetime in the registration should start with a small value The lifetime in the registration should start with a small value
(X=RMin, TBD), and exponentially grow with each re-registration to a (X=RMin, TBD), and exponentially grow with each re-registration to a
larger value (X=Rmax, TBD). The IP link is considered down when larger value (X=Rmax, TBD). The IP link is considered down when
(X=NbBeacons, TDB) expected messages are not received in a row. It (X=NbBeacons, TDB) expected messages are not received in a row. It
must be noted that the link flapping does not affect the state of the must be noted that the physical link flapping does not affect the
registration and when a link comes back up, the active registrations state of the registration and when a physical link comes back up, the
(i.e., registrations for which lifetime is not elapsed) are still active registrations (i.e., registrations for which lifetime is not
usable. Packets should be held or destroyed when the link is down. elapsed) are still usable. Packets should be held or destroyed when
the IP link is down.
P2P links may be federated in Hub-and-Spoke and then in Route-Over P2P links may be federated in Hub-and-Spoke and then in Route-Over
MLSNs as illustrated in Figure 2. More details on the operation of MLSNs as illustrated in Figure 2. More details on the operation of
WiND and RPL over the MLSN can be found in section 3.1, 3.2, 4.1 and WiND and RPL over the MLSN can be found in section 3.1, 3.2, 4.1 and
4.2.2 of [I-D.ietf-6tisch-architecture]. 4.2.2 of [I-D.ietf-6tisch-architecture].
6LoWPAN Node 6LR 6LBR 6BBR 6LoWPAN Node 6LR 6LBR 6BBR
(RPL leaf) (router) (root) (RPL leaf) (router) (root)
| | | | | | | |
| 6LoWPAN ND |6LoWPAN ND+RPL | 6LoWPAN ND | ND-Classic | 6LoWPAN ND |6LoWPAN ND+RPL | 6LoWPAN ND | ND-Classic
skipping to change at page 22, line 22 skipping to change at page 23, line 22
"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", RFC 8928, DOI 10.17487/RFC8928, November
2020, <https://www.rfc-editor.org/info/rfc8928>. 2020, <https://www.rfc-editor.org/info/rfc8928>.
[RFC8929] Thubert, P., Ed., Perkins, C.E., and E. Levy-Abegnoli, [RFC8929] Thubert, P., Ed., Perkins, C.E., and E. Levy-Abegnoli,
"IPv6 Backbone Router", RFC 8929, DOI 10.17487/RFC8929, "IPv6 Backbone Router", RFC 8929, DOI 10.17487/RFC8929,
November 2020, <https://www.rfc-editor.org/info/rfc8929>. November 2020, <https://www.rfc-editor.org/info/rfc8929>.
11. Informative References 11. Informative References
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
DOI 10.17487/RFC3810, June 2004,
<https://www.rfc-editor.org/info/rfc3810>.
[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 23, line 12 skipping to change at page 24, line 16
per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017, per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017,
<https://www.rfc-editor.org/info/rfc8273>. <https://www.rfc-editor.org/info/rfc8273>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters, Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018, RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>. <https://www.rfc-editor.org/info/rfc8415>.
[I-D.ietf-rift-rift] [I-D.ietf-rift-rift]
Przygienda, T., Sharma, A., Thubert, P., Rijsman, B., and Sharma, A., Thubert, P., Rijsman, B., and D. Afanasiev,
D. Afanasiev, "RIFT: Routing in Fat Trees", Work in "RIFT: Routing in Fat Trees", Work in Progress, Internet-
Progress, Internet-Draft, draft-ietf-rift-rift-12, 26 May Draft, draft-ietf-rift-rift-13, 12 July 2021,
2020, <https://datatracker.ietf.org/doc/html/draft-ietf-rift-
<https://tools.ietf.org/html/draft-ietf-rift-rift-12>. rift-13>.
[RPL UNAWARE LEAVES] [RPL UNAWARE LEAVES]
Thubert, P. and M. C. Richardson, "Routing for RPL Thubert, P. and M. C. Richardson, "Routing for RPL
(Routing Protocol for Low-Power and Lossy Networks) (Routing Protocol for Low-Power and Lossy Networks)
Leaves", Work in Progress, Internet-Draft, draft-ietf- Leaves", Work in Progress, Internet-Draft, draft-ietf-
roll-unaware-leaves-30, 22 January 2021, roll-unaware-leaves-30, 22 January 2021,
<https://tools.ietf.org/html/draft-ietf-roll-unaware- <https://datatracker.ietf.org/doc/html/draft-ietf-roll-
leaves-30>. unaware-leaves-30>.
[DAD ISSUES] [DAD ISSUES]
Yourtchenko, A. and E. Nordmark, "A survey of issues Yourtchenko, A. and E. Nordmark, "A survey of issues
related to IPv6 Duplicate Address Detection", Work in related to IPv6 Duplicate Address Detection", Work in
Progress, Internet-Draft, draft-yourtchenko-6man-dad- Progress, Internet-Draft, draft-yourtchenko-6man-dad-
issues-01, 3 March 2015, <https://tools.ietf.org/html/ issues-01, 3 March 2015,
draft-yourtchenko-6man-dad-issues-01>. <https://datatracker.ietf.org/doc/html/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://datatracker.ietf.org/doc/html/
6man-mcast-not-efficient-01>. draft-vyncke-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 Time-
of IEEE 802.15.4", Work in Progress, Internet-Draft, Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)",
draft-ietf-6tisch-architecture-30, 26 November 2020, Work in Progress, Internet-Draft, draft-ietf-6tisch-
<https://tools.ietf.org/html/draft-ietf-6tisch- architecture-30, 26 November 2020,
<https://datatracker.ietf.org/doc/html/draft-ietf-6tisch-
architecture-30>. architecture-30>.
[MCAST PROBLEMS] [MCAST PROBLEMS]
Perkins, C. E., McBride, M., Stanley, D., Kumari, W., and Perkins, C. E., McBride, M., Stanley, D., Kumari, W., and
J. C. Zuniga, "Multicast Considerations over IEEE 802 J. C. Zuniga, "Multicast Considerations over IEEE 802
Wireless Media", Work in Progress, Internet-Draft, draft- Wireless Media", Work in Progress, Internet-Draft, draft-
ietf-mboned-ieee802-mcast-problems-13, 4 February 2021, ietf-mboned-ieee802-mcast-problems-15, 28 July 2021,
<https://tools.ietf.org/html/draft-ietf-mboned-ieee802- <https://datatracker.ietf.org/doc/html/draft-ietf-mboned-
mcast-problems-13>. ieee802-mcast-problems-15>.
[SAVI] Bi, J., Wu, J., Wang, Y., and T. Lin, "A SAVI Solution for [SAVI] Bi, J., Wu, J., Lin, T., and Y. Wang, "A SAVI Solution for
WLAN", Work in Progress, Internet-Draft, draft-bi-savi- WLAN", Work in Progress, Internet-Draft, draft-bi-savi-
wlan-20, 14 November 2020, wlan-21, 10 May 2021,
<https://tools.ietf.org/html/draft-bi-savi-wlan-20>. <https://datatracker.ietf.org/doc/html/draft-bi-savi-wlan-
21>.
[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-02, 8 November 2021,
<https://tools.ietf.org/html/draft-thubert-6lo-unicast- <https://datatracker.ietf.org/doc/html/draft-thubert-6lo-
lookup-00>. unicast-lookup-02>.
[DAD APPROACHES] [DAD APPROACHES]
Nordmark, E., "Possible approaches to make DAD more robust Nordmark, E., "Possible approaches to make DAD more robust
and/or efficient", Work in Progress, Internet-Draft, and/or efficient", Work in Progress, Internet-Draft,
draft-nordmark-6man-dad-approaches-02, 19 October 2015, draft-nordmark-6man-dad-approaches-02, 19 October 2015,
<https://tools.ietf.org/html/draft-nordmark-6man-dad- <https://datatracker.ietf.org/doc/html/draft-nordmark-
approaches-02>. 6man-dad-approaches-02>.
[I-D.ietf-6lo-multicast-registration]
Thubert, P., "IPv6 Neighbor Discovery Multicast Address
Listener Registration", Work in Progress, Internet-Draft,
draft-ietf-6lo-multicast-registration-01, 22 October 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-6lo-
multicast-registration-01>.
[IEEE Std. 802.15.4] [IEEE Std. 802.15.4]
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".
[IEEE Std. 802.11] [IEEE Std. 802.11]
IEEE standard for Information Technology, "IEEE Standard IEEE standard for Information Technology, "IEEE Standard
for Information technology -- Telecommunications and for Information technology -- Telecommunications and
 End of changes. 41 change blocks. 
95 lines changed or deleted 143 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/