1. Introduction
This document updates IPv6 Neighbor Discovery and related 6LoWPAN/RPL specifications to allow a node to register an IPv6 prefix with neighbor routers. Key protocol details are preserved below from the RFC text.
1. Introduction
The design of Low Power and Lossy Networks (LLNs) is generally
focused on saving energy, which is the most constrained resource of
all. Other design constraints (such as a limited memory capacity,
duty cycling of the LLN devices, and low-power lossy transmissions)
derive from that primary concern. The radio (both transmitting or
simply listening) is a major energy drain, and the LLN protocols must
be adapted to allow the nodes to remain sleeping with the radio
turned off at most times.
Examples of LLNs include hub-and-spoke access links such as (Low-
Power) Wi-Fi [IEEE80211] and Bluetooth (Low Energy) [IEEE802151],
Mesh-Under networks where the routing operation is handled at Layer 2
(L2), and route-over networks such as the Wi-SUN [WI-SUN] and 6TiSCH
[RFC9030] mesh networks, which leverage 6LoWPAN [RFC4919] [RFC6282]
and RPL [RFC6550] over [IEEE802154].
LLNs and constrained devices are the original domain of application
for 6LoWPAN protocols. It is thus a foremost concern, when designing
those protocols, to minimize energy spendings. In non-LLN
environments where lowering carbon emissions is also a priority, it
could make sense to apply the 6LoWPAN designs and extend some of the
6LoWPAN protocols. The general design points include:
* Placing the protocol complexity in the less-constrained routers to
simplify the host implementation and avoid expanding the control
traffic to all nodes.
* Using host-triggered operations to enable transient disconnections
with the routers, e.g., to conserve power (sleep), but also to
cope with inconsistent connectivity.
These points translate into:
* Stateful proactively built knowledge in the routers that is
available at any point of time.
* Unicast host-to-router operations triggered by the host and its
applications.
* Minimal use of asynchronous L2 broadcast operations that would
keep the host awake and listening with no application-level need
to do so.
"RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks"
[RFC6550] provides IPv6 [RFC8200] routing services within such
constraints. To save signaling and routing state in constrained
networks, the RPL routing is only performed along a Destination-
Oriented Directed Acyclic Graph (DODAG) that is optimized to reach a
Root node, as opposed to along the shortest path between two peers,
whatever that would mean in each LLN.
The classical Neighbor Discovery Protocol (NDP) [RFC4861] [RFC4862]
was defined for serial links and shared transit media such as
Ethernet at a time when L2 broadcast was cheap on those media, while
memory for neighbor cache was expensive. Thus, it was designed as a
reactive protocol that relies on caching and multicast operations for
the Duplicate Address Detection (DAD) and Address Resolution (AR),
aka address discovery or address lookup, of IPv6 unicast addresses.
Those multicast operations typically impact every node on-link when
at most one is really targeted, which is a waste of energy, and imply
that all nodes are awake to hear the request, which is inconsistent
with power-saving (sleeping) modes.
"Architecture and Framework for IPv6 over Non-Broadcast Access"
[IPv6-over-NBMA] introduces an evolution of IPv6 ND towards a
proactive AR method. Because the IPv6 model for NBMA depends on a
routing protocol to reach inside the subnet, the IPv6 ND extension
for NBMA is referred to as Subnet Neighbor Discovery (SND). SND is
based on work done in the context of Internet of Things (IoT), known
as 6LoWPAN ND. As opposed to the classical IPv6 ND protocol, this
evolution follows the energy conservation principles discussed above:
* The original 6LoWPAN ND, "Neighbor Discovery Optimization for IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs)"
[RFC6775], was introduced to avoid the excessive use of multicast
messages and enable IPv6 ND for operations over energy-constrained
nodes. [RFC6775] changes the classical IPv6 ND model to
proactively establish the Neighbor Cache Entry (NCE) associated to
the unicast address of a 6LoWPAN Node (6LN) in the one or more
6LoWPAN Routers (6LRs) that serve it. To that effect, [RFC6775]
defines a new Address Registration Option (ARO) that is placed in
unicast Neighbor Solicitation (NS) and Neighbor Advertisement (NA)
messages between the 6LN and the 6LRs.
* "Registration Extensions for IPv6 over Low-Power Wireless Personal
Area Network (6LoWPAN) Neighbor Discovery>" [RFC8505] updates
[RFC6775] into a generic Address Registration mechanism and is the
foundation for Subnet Neighbor Discovery (SND). SND introduces
the Extended Address Registration Option (EARO) to enable the
registering node to access services such as routing inside a
subnet and ND proxy operations [RFC8929]. This provides a
routing-protocol-agnostic method for a host to request that the
router inject a unicast IPv6 address in the local routing protocol
and provide return reachability for that address.
* "Listener Subscription for IPv6 Neighbor Discovery Multicast and
Anycast Addresses" [RFC9685] updates [RFC8505] to enable a
listener to subscribe to an IPv6 anycast or multicast address; the
document also updates [RFC9010] to enable a 6LR to inject the
anycast and multicast addresses in RPL. Similarly, this
specification updates [RFC8505] and [RFC9010] to add the
capability for a 6LN to register unicast prefixes up to 120 bits
long, as opposed to addresses, and to signal in a routing-
protocol-independent fashion to a 6LR that it is expected to
redistribute the prefixes.
This specification updates the above registration and subscription
methods to enable a node to register a unicast prefix to the routing
system and get it injected in the routing protocol. As with
[RFC8505], the prefix registration is agnostic to the routing
protocol in which the router injects the prefix, and the router is
agnostic to the method that was used to allocate the prefix to the
node. The energy conservation principles in [RFC8505] are retained
as well, meaning that the node does not have to send or expect
asynchronous multicast messages.
Please note that an energy-conserving node is not necessarily a
router, so even when a node is advertising a prefix, it is a design
choice not to use Router Advertisement (RA) messages that would make
the node appear as a router to peer nodes. From the design
principles above, it is clearly a design choice not to leverage (1)
broadcasts from or to the node or (2) complex state machines in the
node. It is also a design choice to use and extend the EARO as
opposed to the Route Information Option (RIO) [RFC4191] because the
RIO is not intended to inject routes in routing, and is lacking
related control information like the R bit in the EARO.
Additionally, an RA with RIO cannot be trusted for a safe injection
in the routing protocol for the lack of the equivalent of the
Registration Ownership Verifier (ROVR) [RFC8928] in the EARO.