What makes IPv6 Neighbor Discovery useful in 6LoWPAN and other networks.
It wasn’t too long ago that I first saw 6LoWPAN working group (WG) cochair Geoff Mulligan conducting a demonstration of smoke detectors’ communicating using IPv6, User Datagram Protocol, Internet Control Message Protocol version 6, and Simple Network Management Protocol over an Institute of Electronics Engineers (IEEE) 802.15.4 low-power wireless network in the hallways of Sun Microsystems. That day I was part of a discussion with Geoff and my colleagues Gabriel Montenegro and Erik Nordmark to launch at IETF a birds of a feather on running IPv6 on tiny devices (4K to 64K RAM, 8- to 16-bit CPU) over IEEE 802.15.4 networks. Shortly after that, 6LoWPAN WG was born.
The low-power network (LoWPAN) is characterized by a low-powered, short-range, low-bit-rate, low-maximum-transmission-unit, low-cost network. The devices on the network, most of which are battery powered and have limited-capacity processing power, are designed to perform in sleep-wake cycles. Although LoWPAN is closely associated with sensors, it can be composed of many different devices that may or may not always require sensing functions, such as home and ZigBee devices. Given that IPv4 addresses are in short supply and that these low-power networks constitute huge number of tiny devices, IPv6 is the obvious choice for IP-addressing a device. While IEEE 802.15.4 layer 2 technology is gaining momentum as a low-power, wireless, personal-area network, HomePlug and power-line communication technologies are also candidates for using the 6LoWPAN stack for end-to-end IP communications. Recently, IPv6 over IEEE 802.15.4 (http://www.ietf.org/rfc/rfc4944.txt) was selected as one of the protocol requirements for Smart Energy 2.0 (http://tools.ietf.org/html/draft-sturek-6lowapp -smartenergy-00). ZigBee (http://www.zigbee.org), too, decided to use Smart Energy 2.0 and a standard-compliant IPv6 and 6LoWPAN stacks. The ZigBee Alliance’s IP group is the first user of IPv6 Neighbor Discovery Optimization for Low-power and Lossy Networks (http://tools.ietf.org/html/draft-ietf-6lowpan-nd-12) as part of IPv6 address autoconfiguration inside a building network or a home network.
So, the obvious question is, Why should I implement 6LoWPAN–neighbor discovery (ND) optimization? In theory, the traditional IPv6 ND should be able to run as it is. 6LoWPAN is the adaptation layer between the IPv6 stack and the IEEE 802.15.4 data link layer. While IEEE 802.15.4 supports broadcast at the link layer, it does not specify multicast support at the link layer. RFC 4861 was developed primarily for wired traffic on the shared medium, and it uses periodic router-advertisement multicast addresses with router solicitation, neighbor solicitation, address resolution, and duplicate-address detection. While periodic multicast signalling and solicited-node multicast signalling are useful for network stability in the standard Ethernet-based shared network, the limited-lifetime, battery-operated devices in the IEEE 802.15.4 network conserve energy with less signalling and by sending broadcast messages only once in a while. The multicast messages in the IPv6 ND are translated to broadcast messages in the network. In most cases, the 6LoWPAN-ND (http://tools.ietf.org/html/draft-ietf-6lowpan-nd-12) optimizes multicast messages to unicast messages. It eliminates the need for relatively expensive address resolution by sending a neighbor registration option along with a neighbor solicitation; it supports sleepy nodes in the networks; and it optimizes the protocol constants while eliminating periodic router-advertisement messages. Thus, if measurements taken on the IPv6-ND-control messages in the local network are compared with those taken on 6LoWPAN-ND, we may observe a significant drop in signalling messages. By saving a number of controlling messages in a network of hundreds of nodes, a sizable amount of energy is saved; and at the same time, the lifetime of the node battery increases, which contributes to cost savings in maintaining such a huge network.
Another interesting and unique property of a low-power and lossy network is that the boundary of a link or IP subnet is redefined by the short radio range of these devices. The devices are usually configured for lower-than-maximum radio strength to save battery life. Thus, the local link of a node depends on the neighbors it can reach. The list of such neighbors also may change in time due to the lossy nature of the low-power radio link. Thus, the 6LoWPAN-ND supports two types of topology: route-over topology and mesh-under topology. The difference between mesh under and route over is similar to that between a bridged network and an IP routing using Ethernet: In a mesh-under network, all nodes are on the same link, which is served by one or more routers and which we call 6LoWPAN Border Routers (6LBR). In a route-over network, there are multiple links in the 6LoWPAN. Unlike fixed IP links, these links’ members may be changing due to the nature of the low-power and lossy behaviour of LoWPAN wireless technology. Thus, a route-over network is made up of a flexible set of links interconnected by interior routers, which we call 6LoWPAN routers (6LR). However, for purposes of simplicity and compatibility with the existing concept, we assume that each route-over network shares a single global IPv6 prefix and that the interior routers (6LR) either (1) use a default router to forward the packets to the destination in an inefficient way or (2) run a hop-by-hop routing protocol such as RPL (http://tools.ietf.org/html/draft-ietf-roll-rpl-11).
Since 6LoWPAN-ND assumes that a 6LoWPAN (mesh under or route over) shares the same IPv6 prefix across the network, it ensures local mobility in route-over topology. In mesh-under topology, the whole network is regarded as a single IPv6 subnet served by the border router (6LBR), which has regular IPv6 on one interface and 6LoWPAN on the IEEE 802.15.4 interface. Note that an IPv6-over-IPv4, 6RD, or 6to4-style tunnel technology may be applied on the IPv6-interface of the 6LBR if the IPv6 interface side is attached by way of an IPv4 network. Moreover, 6LBR may be capable of running an Internet gateway routing protocol on the IP-network side of the interface in order to offer seamless connectivity of the 6LoWPAN devices to the IP network. Border router 6LBR also acts as a gateway between the IPv6 interface and 6LoWPAN interface.
In the 6LoWPAN-ND optimization, the 6LBR is capable of disseminating the IPv6 prefix and header compression context information across the 6LoWPAN. The border router may also maintain a 6LoWPAN-wide cache of the nodes’ IPv6 addresses and unique identifiers. The IEEE 802.15.4 device contains an extended unique identifier (EUI)-64 identification number and can form 64-bit MAC addresses based on EUI-64 ID. They are also allowed to allocate 16-bit media-access-control (MAC) addresses or short addresses for local use due to the low maximum transmission unit (127 bytes) of today’s deployed 802.15.4 networks. However, the 6LoWPAN-ND optimization work assumes that each IPv6 address is derived from an EUI-64 unique MAC address. Thus, by default it requires neither any duplicate address detection nor address resolution, because the mapping of MAC address to IPv6 address is as accurate as possible. But the document provides an optional mechanism for duplicate-address detection (DAD) for IPv6 addresses that are not derived from an EUI-64 identifier. However, the specification requires that the node possess an IEEE-assigned EUI-64-compliant device number, even if the node uses an IPv6 address that is not derived from the EUI-64 number. In route-over topology, the intermediate router (6LR) acts as a first-hop default router; if it is configured to do multihop DAD, it sends the EUI-64 and address-to-register information to the border router (6LBR), which maintains the network-wide information and thus is able to catch duplicate addresses. This technique of multihop DAD has limitations in a large network when all nodes are started at the same time. Therefore, the multihop DAD technique should be configured carefully for a low-density 6LoWPAN. And the intermediate routers should be brought up gradually, as if a wave is propagating from the 6LBR to the leaves or hosts of the network. Note that alternatively, DHCPv6 may be used to ensure unique 16-bit MAC addresses as well as the unique IPv6 addresses in the network when the devices do not support EUI-64-style MAC addresses, but this requires modification in DHCPv6 service and specifications, which is out of the scope of this discussion.
Figure 1 illustrates the basic components of a 6LoWPAN in a route-over topology and optional prefix and context dissemination from the border router to the hosts via the intermediate routers. The 6LBR acts as a gateway between the regular IPv6 network and 6LoWPAN that facilitates connectivity across nodes in different networks.
As mentioned earlier, neighbor discovery optimization simplifies ND signalling for low-power and lossy networks and replaces address resolution with address registration for a specific lifetime during which the address should stay valid. The length of time it is valid is configurable, and the system is refreshed periodically. Address registration allows for ease of mobility of the 6LoWPAN nodes in the future and provides useful information about the neighboring hosts for the routing protocol. The address registration takes place in the nearest default intermediate routers of a host unless multihop DAD is requested. In the case of multihop DAD, address registration and duplicate detection are also performed at the central location (6LBR) because 6LBR has a view of the whole network. The message sequence in figure 2 provides a typical view of optimized neighbor discovery messages.
Although the IPv6 neighbor discovery protocol has been extended for the 6LoWPANs for running IPv6 over IEEE 802.15.4-2003 networks, the optimizations are also applicable to future versions of IEEE 802.15.4 specifications and other networks where optimizations are useful for saving control messages and power. The solution of optimization of neighbor discovery is designed to expand so as to consider secure neighbor discovery usage and other possible extensions in the future. The current solution of optimized ND is not a replacement for DHCPv6, yet it offers limited provisioning capability for a small and simple network, such as a home network. Since the entire 6LoWPAN uses a single prefix in the current 6LoWPAN architecture, the optimized ND automatically offers local mobility of the nodes within a single 6LoWPAN.
In the future, the work may be extended to provide different levels of functionalities as the usage and applications in the sensor networks and home or enterprise networks are deployed. Finally, the author acknowledges her coauthors of the optimized neighbor discovery specification—Erik Nordmark and Zach Shelby—for their original ideas and contributions, which shaped the optimized IPv6 neighbor discovery document.
This article was posted on 31 January 2011