Skip to main content

1. Introduction

1. Introduction​

The IPv6-over-IEEE 802.15.4 [RFC4944] document specifies how IPv6 is carried over an IEEE 802.15.4 network with the help of an adaptation layer that sits between the Media Access Control (MAC) layer and the IP network layer. A link in a Low-power Wireless Personal Area Network (LoWPAN) is characterized as lossy, low-power, low-bit-rate, short-range; with many nodes saving energy with long sleep periods. Multicast as used in IPv6 Neighbor Discovery (ND) [RFC4861] is not desirable in such a wireless low-power and lossy network. Moreover, LoWPAN links are asymmetric and non-transitive in nature. A LoWPAN is potentially composed of a large number of overlapping radio ranges. Although a given radio range has broadcast capabilities, the aggregation of these is a complex Non-Broadcast Multiple Access (NBMA) [RFC2491] structure with generally no LoWPAN-wide multicast capabilities. Link-local scope is in reality defined by reachability and radio strength. Thus, we can consider a LoWPAN to be made up of links with undetermined connectivity properties as in [RFC5889], along with the corresponding address model assumptions defined therein.

This specification introduces the following optimizations to IPv6 Neighbor Discovery [RFC4861] specifically aimed at low-power and lossy networks such as LoWPANs:

  • Host-initiated interactions to allow for sleeping hosts.
  • Elimination of multicast-based address resolution for hosts.
  • A host address registration feature using a new option in unicast Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages.
  • A new Neighbor Discovery option to distribute 6LoWPAN header compression context to hosts.
  • Multihop distribution of prefix and 6LoWPAN header compression context.
  • Multihop Duplicate Address Detection (DAD), which uses two new ICMPv6 message types.

The two multihop items can be substituted by a routing protocol mechanism if that is desired; see Section 1.4.

The document defines three new ICMPv6 message options: the Address Registration Option (ARO), the Authoritative Border Router Option (ABRO), and the 6LoWPAN Context Option (6CO). It also defines two new ICMPv6 message types: the Duplicate Address Request (DAR) and the Duplicate Address Confirmation (DAC).

1.1. The Shortcomings of IPv6 Neighbor Discovery​

IPv6 Neighbor Discovery [RFC4861] provides several important mechanisms used for router discovery, address resolution, Duplicate Address Detection, and Redirect messages, along with prefix and parameter discovery.

Following power-on and initialization of the network in IPv6 Ethernet networks, a node joins the solicited-node multicast address on the interface and then performs Duplicate Address Detection (DAD) for the acquired link-local address by sending a solicited-node multicast message to the link. After that, it sends multicast messages to the all-routers multicast address to solicit Router Advertisements (RAs). If the host receives a valid RA with the A (autonomous address configuration) flag, it autoconfigures the IPv6 address with the advertised prefix in the RA message. Besides this, the IPv6 routers usually send RAs periodically on the network. RAs are sent to the all-nodes multicast address. Nodes send Neighbor Solicitation/Neighbor Advertisement messages to resolve the IPv6 address of the destination on the link. The Neighbor Solicitation messages used for address resolution are multicast. The Duplicate Address Detection procedure and the use of periodic Router Advertisement messages assume that the nodes are powered on and reachable most of the time.

In Neighbor Discovery, the routers find the hosts by assuming that a subnet prefix maps to one broadcast domain, and then they multicast Neighbor Solicitation messages to find the host and its link-layer address. Furthermore, the DAD use of multicast assumes that all hosts that autoconfigure IPv6 addresses from the same prefix can be reached using link-local multicast messages.

Note that the L (on-link) bit in the Prefix Information Option (PIO) can be set to zero in Neighbor Discovery, which makes the host not use multicast Neighbor Solicitation (NS) messages for address resolution of other hosts, but routers still use multicast NS messages to find the hosts.

Due to the lossy nature of wireless communication and a changing radio environment, the IPv6-link node-set may change due to external physical factors. Thus, the link is often unstable, and the nodes appear to be moving without necessarily moving physically.

A LoWPAN can use two types of link-layer addresses: 16-bit short addresses and 64-bit unique addresses as defined in [RFC4944]. Moreover, the available link-layer payload size is on the order of less than 100 bytes; thus, header compression is very useful.

Considering the above characteristics in a LoWPAN, and the IPv6 Neighbor Discovery [RFC4861] protocol design, some optimizations and extensions to Neighbor Discovery are useful for the wide deployment of IPv6 over low-power and lossy networks (example: 6LoWPAN and other homogeneous low-power networks).

1.2. Applicability​

In its Section 1, [RFC4861] foresees a document that covers operating IP over a particular link type and defines an exception to the otherwise general applicability of unmodified [RFC4861]. The present specification improves the usage of IPv6 Neighbor Discovery for LoWPANs in order to save energy and processing power of such nodes. This document thus updates [RFC4944] to specify the use of the optimizations defined here.

The applicability of this specification is limited to LoWPANs where all nodes on the subnet implement these optimizations in a homogeneous way. Although it is noted that some of these optimizations may be useful outside of 6LoWPANs, for example, in general IPv6 low-power and lossy networks and possibly even in combination with [RFC4861], the usage of such combinations is out of scope of this document.

In this document, we specify a set of behaviors between hosts and routers in LoWPANs. An implementation that adheres to this document MUST implement those behaviors. The document also specifies a set of behaviors (multihop prefix or context dissemination and, separately, multihop Duplicate Address Detection) that are needed in route-over configurations. An implementation of this specification MUST support those pieces, unless the implementation supports some alternative ("substitute") from some other specification.

The optimizations described in this document apply to different topologies. They are most useful for route-over and mesh-under configurations in Mesh topologies. However, Star topology configurations will also benefit from the optimizations due to reduced signaling, robust handling of the non-transitive link, and header compression context information.

1.3. Goals and Assumptions​

The document has the following main goals and assumptions.

Goals:

  • Optimize Neighbor Discovery with a mechanism that is minimal yet sufficient for the operation in both mesh-under and route-over configurations.
  • Minimize signaling by avoiding the use of multicast flooding and reducing the use of link-scope multicast messages.
  • Optimize the interfaces between hosts and their default routers.
  • Provide support for sleeping hosts.
  • Disseminate context information to hosts as needed by 6LoWPAN header compression [RFC6282].
  • Disseminate context information and prefix information from the border to all routers in a LoWPAN.
  • Provide a multihop Duplicate Address Detection mechanism suitable for route-over LoWPANs.

Assumptions:

  • 64-bit Extended Unique Identifier (EUI-64) [EUI64] addresses are globally unique, and the LoWPAN is homogeneous.
  • All nodes in the network have an EUI-64 Interface ID in order to do address autoconfiguration and detect duplicate addresses.
  • The link-layer technology is assumed to be low-power and lossy, exhibiting undetermined connectivity, such as IEEE 802.15.4 [RFC4944]. However, the address registration mechanism might be useful for other link-layer technologies.
  • A 6LoWPAN is configured to share one or more global IPv6 address prefixes to enable hosts to move between routers in the LoWPAN without changing their IPv6 addresses.
  • When using the multihop DAD mechanism (Section 8.2), each 6LoWPAN Router (6LR) registers with all the 6LoWPAN Border Routers (6LBRs) available in the LoWPAN.
  • If IEEE 802.15.4 16-bit short addresses are used, then some technique is used to ensure the uniqueness of those link-layer addresses. That could be done using DHCPv6, Address Registration Option-based Duplicate Address Detection (specified in Section 8.2), or other techniques outside of the scope of this document.
  • In order to preserve the uniqueness of addresses (see Section 5.4 of [RFC4862]) not derived from an EUI-64, they must be either assigned or checked for duplicates in the same way throughout the LoWPAN. This can be done using DHCPv6 for assignment and/or using the Duplicate Address Detection mechanism specified in Section 8.2 (or any other protocols developed for that purpose).
  • In order for 6LoWPAN header compression [RFC6282] to operate correctly, the compression context must match for all the hosts, 6LRs, and 6LBRs that can send, receive, or forward a given packet. If Section 8.1 is used to distribute context information, this implies that all the 6LBRs must coordinate the context information they distribute within a single LoWPAN.
  • This specification describes the operation of ND within a single LoWPAN. The participation of a node in multiple LoWPANs simultaneously may be possible but is out of scope of this document.
  • Since the LoWPAN shares its prefix(es) throughout the network, mobility of nodes within the LoWPAN is transparent. Inter-LoWPAN mobility is out of scope of this document.

1.4. Substitutable Features​

This document defines the optimization of Neighbor Discovery messages for the host-router interface and introduces two new mechanisms in a route-over topology.

Unless specified otherwise (in a document that defines a routing protocol that is used in a 6LoWPAN), this document applies to networks with any routing protocol. However, because the routing protocol may provide good alternate mechanisms, this document defines certain features as "substitutable", meaning they can be substituted by a routing protocol specification that provides mechanisms achieving the same overall effect.

The features that are substitutable (individually or in a group):

  • Multihop distribution of prefix and 6LoWPAN header compression context
  • Multihop Duplicate Address Detection

Thus, multihop prefix distribution (the ABRO) and the 6LoWPAN Context Option (6CO) for distributing header compression contexts go hand in hand. If substitution is intended for one of them, then both of them MUST be substituted.

Guidelines for feature implementation and deployment are provided in Section 14.

Last updated on