TOC 
6LoWPAN WGS. Chakrabarti
Internet-DraftIP Infusion
Expires: September 2, 2010E. Nordmark
 Oracle, Inc.
 March 01, 2010


IPv6 LoWPAN Neighbor Discovery and Addressing Choices
draft-chakrabarti-6lowpan-ipv6-nd-simple-00.txt

Abstract

IETF 6LoWPAN working group defines IPv6 over low-power personal area network (IEEE 802.15.4). IEEE 802.15.4 and other low-power wireless networks have limited or no usage of broadcast or multicast signaling due to energy conservation. Besides the wireless nodes may not strictly follow traditional concept of IP subnet and IP-links while connecting nodes and routers. This document describes simple optimizations to IPv6 Neighbor Discovery protocol(RFC4861), and addressing mechanisms that are useful for small scale 6LoWPAN networks in star and mesh topologies.

The optimizations include reducing the amount of Neighbor Discovery multicast traffic and allowing for a single subnet to span multiple routers in a "route-over" topology.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on September 2, 2010.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.



Table of Contents

1.  Introduction and Overview
    1.1.  IPv6 Neighbor Discovery shortcomings in low-power wireless network
    1.2.  Address Allocation Options in 6LoWPAN
    1.3.  Mesh-under and Route-over Concept and Behavior
2.  Definition Of Terms
3.  Assumptions
4.  Applicability Statement
5.  Autoconfiguration of 6LoWPAN Addresses
    5.1.  Address Assignment in Star Networks
    5.2.  Address Assignment in Mesh Network
    5.3.  DHCPv6 Address and Resource Allocation
6.  New Neighbor Discovery options
    6.1.  Authoritative Router option
    6.2.  Node-lifetime option
7.  Optimized Neighbor Discovery for 6LoWPANs
    7.1.  Operations Overview
    7.2.  Existing Neighbor Discovery Messages
    7.3.  6LoWPAN Optimized Neighbor Discovery Messages
    7.4.  Host Behavior
    7.5.  6LBR Behavior
    7.6.  6LR Behavior
8.  Remaining Multicast messages
9.  Security Considerations
10.  IANA Considerations
11.  Acknowledgements
12.  References
    12.1.  Normative References
    12.2.  Informative References
§  Authors' Addresses




 TOC 

1.  Introduction and Overview

The IPv6-over-IEEE 802.15.4 [3] (Montenegro, G. and N. Kushalnagar, “Transmission of IPv6 Packets over IEEE 802.15.4 networks,” September 2007.) document specifies IPv6 headers carried over IEEE 802.15.4 network with the help of an adaptation layer which sits between the MAC layer and the IP network layer. The LoWPAN network is characterized by low-powered, low bit-rate, short ranged, low cost nodes. Thus, all-node multicast defined in Neighbor Discovery [2] (Narten, T., Nordmark, E., Simpson, W., and H. Soliman, “Neighbor Discovery for IP version 6,” September 2007.) may be unsuitable in the LoWPAN network which does not have direct multicast support at the link-layer. Broadcast messages could be used in some cases to represent all-node multicast messages, but periodic broadcast messages should be minimized in the LoWPAN network in order to conserve energy.

This document provides an overview of IPv6 Neighbor Discovery options and describes a base mechanism for optimized 6LoWPAN neighbor discovery mechanism.

The optimizations include reducing the amount of Neighbor Discovery multicast traffic and allowing for a single subnet to span multiple routers in a "route-over" topology.



 TOC 

1.1.  IPv6 Neighbor Discovery shortcomings in low-power wireless network

IPv6 ND [2] (Narten, T., Nordmark, E., Simpson, W., and H. Soliman, “Neighbor Discovery for IP version 6,” September 2007.) is based on multicast signaling messages on the local link in order to avoid broadcast messages. 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 router solicitation (RS) messages to the all-router address to solicit router advertisements. Once the host receives a valid router advertisement (RA) with the "A" flag, it autoconfigures the IPv6 address with the advertised prefix in the router advertisement (RA). Besides this, the IPv6 routers usually send router advertisements periodically on the network. RAs are sent to the all-node multicast address. Nodes send Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages to resolve the IPv6 address of the destination on the link. These NS/NA messages are also often multicast messages and it is assumed that the node is on the same link and relies on the fact that the destination node is always powered and generally available.

In 6LoWPAN 802.15.4 network, primarily two types of configurations are used - 1) Star network and 2) Mesh network. A star network is similar to regular IPv6 subnet with a router and a set of nodes connected to it via the same link. But in low-power mesh networks, the nodes are capable of routing and forwarding packets but due to lossy nature of wireless communication, the IPv6-link node sets may change due to external physical factors and thus the link and connection becomes unreliable.

Thus optimizing the regular IPv6 Neighbor Discovery [2] (Narten, T., Nordmark, E., Simpson, W., and H. Soliman, “Neighbor Discovery for IP version 6,” September 2007.) to minimize total number of related signaling messages without loosing generality of Neighbor Discovery and autoconfiguration and making host and router communication reliable, is desirable in 6LoWPAN mesh configuration.



 TOC 

1.2.  Address Allocation Options in 6LoWPAN

As 6LoWPAN and IEEE 802.15.4 technologies are evolving we can anticipate that regular IPv6 ND [2] (Narten, T., Nordmark, E., Simpson, W., and H. Soliman, “Neighbor Discovery for IP version 6,” September 2007.) might be used in some configuration where the physical medium and hardware support higher bandwidth and processing power with low-power consumption.

Thus the following options of address allocations are envisioned in a 6LoWPAN network depending on the configuration and network capacity.

It is noted that all the above address allocation methods MUST follow the address allocation principles described in [8] (Baccelli, E. and M. Townsley, “IP Addressing Model in Adhoc Networks,” December 2009.).



 TOC 

1.3.  Mesh-under and Route-over Concept and Behavior

In 6LoWPAN network context, often the link-layer mesh routing mechanism for carrying IP packets as a data message is referred as "mesh-under" while routing/forwarding packets using IP-layer addresses are referred as "route-over". The difference between mesh-under and route-over networks is similar to a bridged-network and IP-routing network in the Ethernet. Thus, in a mesh-under network all nodes are considered part of an IPv6 subnet when a 6LoWPAN network is considered as one IPv6 subnet served by one or more 6LoWPAN border routers (6LBR). The 6LBR could also be a gateway to the legacy IPv4 or IPv6 network.

In a route-over network, there are multiple IPv6 subnets connecting to each other in a 6LoWPAN network. However, unlike fixed IP networks, these subnet members may be changing due to the nature of the low-power and lossy behavior of wireless LoWPANs. Thus a route-over network is almost always a flexible set of mesh networks. The design considerations are based on the above properties. The optimized 6LoWPAN neighbor discovery are applicable to both "mesh-under" and "route-over" implementations. However, in "route-over" networks, we like to define two types of routers - 6LoWPAN border Routers(6LBR) and 6LoWPAN-routers(6LR). 6LoWPAN border Routers sit at the boundary of the 6LoWPAN and the backbone network while 6LoWPAN-routers are inside the 6LoWPAN network and they can not communicate to a different network routers directly. The 6LoWPAN-routers are assumed to be running a routing protocol. In "route-over" configuration, the hosts are unable to take part in routing and forwarding packets and they are acting as simple IPv6 hosts.

These neighbor discovery optimizations for "mesh-under" configuration where the 6LBR is acting as the IPv6 router where all the hosts in 6LoWPAN are part of one subnet and they are only one IP hop away and no 6LR concept exist in "mesh-under" topology. Thus, the IPv6 packet is carried as the data via a link-layer mesh routing protocol.

When "route-over" configuration is used, the IPv6 Neighbor Discovery operation takes place between the requesting node and the 6LRs or 6LBRs. The 6LR nodes are able to send and receive Router Advertisements, Router Solicitations as well as forward and route IPv6 packets. The packet forwarding happens at the routing layer.

With "route-over" there is a need to allow a host to attach to different 6LRs over time (e.g., to handle changes in the radio conditions) while the host keeps the same IPv6 addresses. Thus one (or more) subnet prefixes (see [8] (Baccelli, E. and M. Townsley, “IP Addressing Model in Adhoc Networks,” December 2009.)) should be assigned to the 6LoWPAN. This implies that a 6LRs need to reliably know which IP addresses are directly reachable from that particular 6LR; this information will be used by the routing protocol that is used by the 6LRs and 6LBRs.

This document assumes that an implementation will have configuration knobs to determine whether it is running in "mesh-under" mode or "route-over" mode if the implementation supports both mechanisms.



 TOC 

2.  Definition Of Terms

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

6LoWPAN-link:
It is a wireless link determined by single hop reachability of neighboring nodes.
6LoWPAN-router (6LR):
These are the intermediate routers in the 6LoWPAN network who can communicate with other 6LoWPAN-routers in the same 6LoWPAN network. These are also the immediate first-hop router for 6LoWPAN hosts. 6LoWPAN routers are present only in "route-over" topologies.
6LoWPAN Border Router (6LBR):
It is a border router located at the junction of separate 6LoWPAN networks or between a 6LoWPAN network and a non-6LoWPAN IP network. There may be one or more 6LBR at the 6LoWPAN network border. 6LBR is the responsible authority for IPv6 Prefix propagation for the 6LoWPAN network it is serving. An isolated 6LoWPAN network also contains a 6LBR in the network, which provides the prefix(es) for the isolated network.
Host:
A host in 6LoWPAN network is considered a IPv6 node without routing and forwarding capability.
Mesh-under:
It is a configuration topology where 6LoWPAN hosts are connected to the 6LBR through a mesh using Layer-2 forwarding. Thus in a "mesh-under" configuration all IPv6 hosts in a 6LoWPAN network are only one IP hop away from the 6LBR. This topology simulates the typical IP-subnet topology with one router with multiple nodes in the same subnet.
Route-over:
It is a configuration topology where 6LoWPAN hosts are connected to the 6LBR through the use of intermediate Layer-3 (IP) routing. Here hosts are typically multiple IP hops away from the 6LBR. The Route-over topology typically consists of a 6LBR, a set of 6LRs and possibly some hosts.



 TOC 

3.  Assumptions



 TOC 

4.  Applicability Statement

This document aims to guide the implementors to choose an appropriate IPv6 neighbor discovery and Address configuration procedures suitable for a 6LoWPAN network. If the 6LoWPAN network does not have Multicast capability at the link-layer, then it SHOULD use the Optimized IPv6 Neighbor Discovery for the 6LoWPAN network.

This document does not specify a method for ensuring address uniqueness across a LoWPAN. In general such a mechanism is needed for the IPv6 addresses autoconfigured in the subnet prefix(es). In the general case of ND we use multicast Neighbor Solicitation to perform Duplicate Address Detection (DAD) [6] (Thomson, S., Narten, T., and T. Jinmei, “IPv6 Stateless Autoconfiguration,” September 2007.) but that is both undesirable in a 6LoWPAN due to the undesirability of multicast packets, and insufficient in the case of "route-over" when the subnet prefix spans several links and 6LRs.

The scope of this document is limited to addresses that are autoconfigured based on EUI-64 based Interface-ids. For such addresses DAD is not required. Other IPv6 addresses, including those based on 16-bit IEEE 802.15.4 short addresses, are out of scope. Potentially DHCPv6 can be used to allocate unique addresses for short addresses.



 TOC 

5.  Autoconfiguration of 6LoWPAN Addresses

The following discussion will include address auto-configuration procedure at the IP-layer.



 TOC 

5.1.  Address Assignment in Star Networks

In a star network, all the nodes are one hop away from the IPv6-router and from each-other. Upon starting a node sends an IPv6 ND [2] (Narten, T., Nordmark, E., Simpson, W., and H. Soliman, “Neighbor Discovery for IP version 6,” September 2007.) Router Solicitation (RS) to the All-Routers multicast address. The 6LBR sends unicast Router Advertisement (RA) and the node configures its IPv6 address using autoconfiguration [6] (Thomson, S., Narten, T., and T. Jinmei, “IPv6 Stateless Autoconfiguration,” September 2007.). If the nodes are using EUI-64 style MAC address, the Duplicate Address Detection SHOULD be skipped. The 6LBR is assumed to be the only router in the 6LoWPAN network - thus it should use a unique id, for example IEEE 802.15.4 PAN-ID as its subnet-id of the IPv6-address.

If the node uses a short(16-bit) MAC addresses, address assignment through DHCP is advised.



 TOC 

5.2.  Address Assignment in Mesh Network

In a "mesh-under" configuration, the nodes are considered one hop away. Thus address assignment/auto-configuration happens the same way as in Star Network configuration. However, 6LBR is acts as an Prefix authority and initial delegator of that prefix.

In a "route-over" configuration, one or more 6LBR advertise the global prefix(es) along with a new IPv6 Router Advertisement option called Authoritative Router option. This option contains information about the 6LBR IP-address and a sequence number. The next-level 6LR receive the RA from 6LBR and store/auto-config with the advertised prefix. The received prefix from 6LBR and the new Authoritative Router option option are then propagated throughout the 6LoWPAN network hop by hop. The hosts use the address prefix to configure the address when they receive the Router Advertisements from their respective Neighborhood 6LR.



 TOC 

5.3.  DHCPv6 Address and Resource Allocation

DHCP address allocation procedure for 6LoWPAN is out of scope of this document.



 TOC 

6.  New Neighbor Discovery options

The optimized ND uses two new Neighbor Discovery options - Authoritative Router option option and Node-lifetime option.



 TOC 

6.1.  Authoritative Router option

The Prefix Information options originate at the 6LBRs and are propagated by the 6LRs. Thus 6LRs receive Prefix Information options from other 6LRs. This implies that we can't just have the most recently received RA win. In order to be able to reliably remove prefixes from the 6LoWPAN we need to carry information from the authoritative 6LBR. We do that by introducing a sequence number which the 6LRs propagate as they propagate the prefixes. When there are multiple 6LBRs they would have a separate sequence number spaces. Thus we need to carry the IP address of the 6LBR that created the sequence number.

The Authoritative Router option is included in Router Advertisement messages. It is required in "route-over" configurations.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length = 3 |          Reserved             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Sequence Number                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                          6LBR Address                         +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                            Address[1] etc                     ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Fields:

Type:
TBD [To be allocated by the IANA.]
Length:
8-bit unsigned integer. The length of the option in units of 8 octets. Always 3.
Reserved:
16-bits. This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
Registration Period:
32-bit unsigned integer. The amount of time in seconds between successive registration messages for the same IP address.
6LBR Address:
IP address of 6LBR that is authoritative for the sequence number.



 TOC 

6.2.  Node-lifetime option

The 6LRs need to know the set of IP addresses that are directly reachable. This needs to be maintained as the radio reachability changes. We introduce a Node-Lifetime option that is carried in the unicast NS and NA messages sent by hosts. Thus it can be used on the unicast NS messages that that a host sends as part of NUD to determine that it can still reach a default router. This Node-Lifetime is used by the 6LR to reliably maintain its Neighbor Cache.

The Node-lifetime is required for 6LoWPAN network for reliability and power saving to minimize frequent need for updating Neighbor status with the neighboring 6LR for liveliness. Thus the requested Node-lifetime provides flexibility to the requester to receive an address which should be usable (continue to be advertised by the 6LR in the routing protocol etc) during its intended of sleep schedule.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |   Length = 1  |          Reserved             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Registration Lifetime                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Fields:

Type:
TBD [To be allocated by the IANA.]
Length:
8-bit unsigned integer. The length of the option in units of 8 octets. Always 1.
Reserved:
16-bits. This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
Registration Lifetime:
32-bit unsigned integer. The amount of time in seconds that the 6LR should retain the Neighbor Cache entry for the sender of the NS/NA that includes this option.



 TOC 

7.  Optimized Neighbor Discovery for 6LoWPANs

The goal of having an optimized Neighbor Discovery is to basically use regular IPv6 Neighbor Discovery [2] (Narten, T., Nordmark, E., Simpson, W., and H. Soliman, “Neighbor Discovery for IP version 6,” September 2007.) with some optimization for low-power networks. The main objective is to minimize the multicast messages and use unicast messages instead of multicast messages when possible. Note that IPv6 use multicast messages instead of broadcast messages. But layer-2 technologies that do not support multicast but provides broadcast support, usually map the IP multicast messages to L2 broadcast messages. IEEE 802.15.4 networks do this.



 TOC 

7.1.  Operations Overview

The mandatory part of the optimized Neighbor Discovery protocol is described here. Upon starting up, a node figures out whether it is configured as a router or a simple host. The procedure of determining this node behavior is local to the system and it is implementation specific.

The use of subnet and link-local address prefixes is specified in [8] (Baccelli, E. and M. Townsley, “IP Addressing Model in Adhoc Networks,” December 2009.)). In this case, the link-local addresses can only reach the set of nodes that are reachable from the sender at the time it sends a packet. We can define that as 6LoWPAN-link.



 TOC 

7.2.  Existing Neighbor Discovery Messages

IPv6 Neighbor Discovery [2] (Narten, T., Nordmark, E., Simpson, W., and H. Soliman, “Neighbor Discovery for IP version 6,” September 2007.) protocol operates with Router Solicitation(RS), Router Advertisement(RA), Neighbor Solicitation(NS), Neighbor Advertisement (NA), and Redirect messages, link-layer address options, prefix options, MTU options etc., and a set of protocol constants. Moreover, duplicate address detection (DAD) is performed during address assignment.

The following sections describe optimizations (if any) of the above messages of IPv6 Neighbor Discovery Protocol[2] (Narten, T., Nordmark, E., Simpson, W., and H. Soliman, “Neighbor Discovery for IP version 6,” September 2007.) for 6LoWPAN.



 TOC 

7.3.  6LoWPAN Optimized Neighbor Discovery Messages

  1. Router Advertisement(RA): Periodic RAs SHOULD be avoided. Only solicited RAs are recommended for the 6LBRs (on their 6LoWPAN interfaces) and 6LRs. An RA MUST contain the Source Link-layer Address option containing Router's link-layer address (this is optional in [2] (Narten, T., Nordmark, E., Simpson, W., and H. Soliman, “Neighbor Discovery for IP version 6,” September 2007.). An RA MUST carry Prefix information option with L bit being unset, so that hosts do not multicast any NS messages as part of address resolution. In addition to the Prefix option the RA should carry Authoritative Router option option generated by the 6LBR.
  2. Router Solicitation(RS): Upon system startup, the node sends a multicast or link broadcast (when multicast is not supported at the link-layer) RS to find out the available routers in the wireless link. An RS may be sent at other times as described in section 6.3.7 of RFC 4861. A Router Solicitation MUST carry Source Link-layer Address option. Since no periodic RAs are allowed in a 6LoWPAN network, the host may restart sending multicast RS messages after NUD declares a default router unreachable.
  3. Default Router Selection: Same as in section 6.3.6 of RFC 4861.
  4. Neighbor Solicitation (NS): Neighbor solicitation is used between the hosts and the default-router as part of NUD and registering the host's address(es). An NS messages MUST use the Node-lifetime option in order to accomplish the registration.
  5. Neighbor Advertisement (NA): As defined in [2] (Narten, T., Nordmark, E., Simpson, W., and H. Soliman, “Neighbor Discovery for IP version 6,” September 2007.)
  6. Redirect Messages: A router in the 6LoWPAN network may send a Redirect message to a host. When to send the redirect message is implementation specific; a router may be overloaded or by some means it can determine the proximity of source and destination and decide that they should directly talk to each other. The host behavior is same as described in section 8.3 of RFC 4861 [2] (Narten, T., Nordmark, E., Simpson, W., and H. Soliman, “Neighbor Discovery for IP version 6,” September 2007.).
  7. Message Validation: Same as in RFC 4861[2] (Narten, T., Nordmark, E., Simpson, W., and H. Soliman, “Neighbor Discovery for IP version 6,” September 2007.)
  8. MTU option: As per the RFC 4861.
  9. Address Resolution: No multicast NS/NA are sent as the prefixes are treated as off-link. Thus no address resolution is performed at the hosts. The routers keep track of Neighbor Solicitations with Node-Lifetime options and create a neighbor cache of directly reachable addresses. The router also knows the nexthop link-local address and corresponding link-layer address when it wants to route a packet.
  10. Neighbor Unreachability Detection(NUD): NUD is performed in "forward-progress" fashion as described in section 7.3.1 of [2] (Narten, T., Nordmark, E., Simpson, W., and H. Soliman, “Neighbor Discovery for IP version 6,” September 2007.). The unicast Neighbor Solicitation and Advertisement messages sent by a host as part of NUD include the Node-Lifetime option.



 TOC 

7.4.  Host Behavior

A 6LoWPAN host sends Router Solicitation at the system startup and also when it suspects that one of its default routers have become unreachable (after NUD fails). The latter part is a behavioral change from RFC 4861 [2] (Narten, T., Nordmark, E., Simpson, W., and H. Soliman, “Neighbor Discovery for IP version 6,” September 2007.), since RFC 4861 assumes that when NUD fails for a router there will be some multicast RA messages that will make the host find out a new set of working default routers. Here we avoid multicast RA messages completely which implies that the host needs to send a RS after NUD fails, just as it does in the case when the interface is reinitialized after a temporary interface failure in section 6.3.7 in [2] (Narten, T., Nordmark, E., Simpson, W., and H. Soliman, “Neighbor Discovery for IP version 6,” September 2007.). Thus in essence we treat a NUD failure for a default router the same way as a temporary interface failure, which seems consistent with how [2] (Narten, T., Nordmark, E., Simpson, W., and H. Soliman, “Neighbor Discovery for IP version 6,” September 2007.) operates on a wired network.

A host SHOULD be able to autoconfigure its IPv6 addresses and optionally it can act as a simple DHCPv6 client.

A host always sends packets to (one of) its default router(s). This is accomplished by the 6LBRs and 6LRs never setting the 'L' flag in the Prefix options. A router can control the host's selection of a default router by sending Redirect messages, however care must be taken to ensure that that router is indeed reachable from the host. Should this not be the case then normal operation of NUD per RFC 4861 will end up deleting the redirect.

The host is unable to forward routes or participate in a routing protocol.



 TOC 

7.5.  6LBR Behavior

A 6LBR normally has multiple interfaces and connects the 6LoWPAN to other 6LoWPAN networks or to non-6LoWPAN network(s). The 6LBR is responsible for distributing one or more /64 prefixes to the 6LoWPAN nodes to identify a packet belonging to the particular 6LoWPAN network.

When the 6LBR sends a Router Advertisement it SHOULD include a Authoritative Router option that includes its own address and a sequence number. (The Authoritative Router option is required in the "route-over" configuration.) Each time the information in the RA changes (such as adding or deleting prefixes, or changing the lifetime of the prefixes) the sequence number should be increased by one. The 6LBR SHOULD keep the sequence number in stable storage or otherwise ensure that after a reboot it will not reuse "old" sequence numbers.

A 6LBR keeps a cache for all the 6LoWPAN nodes' IP addresses, created from the routing protocol. The 6LBR may act as a DHCPv6 server for the 6LoWPAN network as well. It does not send unsolicited Router Advertisements on 6LoWPAN interfaces. 6LBR holds the authority of Prefix generation and initial Prefix allocation in the 6LoWPAN network.



 TOC 

7.6.  6LR Behavior

6LRs are only present in "Route-over" mesh topology. They participate in forwarding packets in from a host to another host or to the nexthop router. They may configure their own address based on the /64-bit prefix(es) they receive in RAs.

A 6LR keeps a cache of neighbor information collected from the Node-Lifetime options in Neighbor messages. This information is made available to the routing protocol. When receiving a packet the 6LR compares the destination against this neighbor cache. If present the host is directly connected to the 6LR and it can forward the packet to the host. Otherwise the packet is forwarded using the routing protocol.

A 6LR receives Router Advertisements from 6LBRs and 6LRs and uses the received Prefix options and Authoritative Router option to construct the Router Advertisements it sends. The 6LR MUST ignore any RA that does not contain an Authoritative Router option. When a RA is received it compares the sequence number and 6LBR Address against a cache of such information. If it has information for the 6LBR Address and the received sequence number is less or equal to last sequence number, then it MUST ignore the received Prefix options. Otherwise it updates the prefixes and the sequence number to what was received. This mechanism needs to be able to handle different 6LBRs advertising different prefixes. Among other things that implies that a RA sent by the 6LR can only include prefixes (and the Authoritative Router option) originated from one of the 6LBRs.

Unlike regular routers, 6LRs send multicast RS messages once upon startup to receive a RA message. After that they are not required to send RS messages, since they run a routing protocol.



 TOC 

8.  Remaining Multicast messages

With the optimizations specified above the only place where Neighbor Discovery messages are multicast is Router Solicitations. Such messages must be conceptually multicast, both when a host is powered on and also when the NUD indicates that a default router is unreachable, since the host needs to be able to find at least one new router at that point in time.

Potentially this could be further optimized if there is some L2 mechanism to perform some form of anycast, since all that is needed is for the host to reach at least one router. However, it isn't known to the authors whether 6LoWPAN has an L2 anycast address can be used to reach routers. If such an address can be used, then the RS messages can be multicast at L3 (sent to the "all-routers" IPv6 multicast address) while being anycast at L2.



 TOC 

9.  Security Considerations

These optimizations are not known to introduce any new threats against Neighbor Discovery beyond what is already documented for IPv6 [RFC 3756]. However, the effect of a rogue router is more severe in Low-power wireless network than in the network of powered systems. The 6LoWPAN security analysis [12] (Park, D., Kim, K., Seo, E., and S. Chakrabarti, “IPv6 over Low Power WPAN Security Analysis,” January 2007.) discusses possible threats. The security of 6LoWPAN Neighbor Discovery will be handled in a separate follow-up IETF publication.



 TOC 

10.  IANA Considerations

If this document is approved then two Neighbor Discovery option types need to be allocated.



 TOC 

11.  Acknowledgements

The primary idea and inspiration of this document to note different addressing mechanism and simple ND procedures are from Geoff Mulligan.

Also thanks to the 6LoWPAN and 6man working group members to provide ideas on simplification. Part of the ideas are also discussed at the IETF mailing list as a summary of base 6LoWPAN-ND requirement.



 TOC 

12.  References



 TOC 

12.1. Normative References

[1] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[2] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, “Neighbor Discovery for IP version 6,” RFC 4861, September 2007.
[3] Montenegro, G. and N. Kushalnagar, “Transmission of IPv6 Packets over IEEE 802.15.4 networks,” RFC 4944, September 2007.
[4] Kushalnagar, N. and G. Montenegro, “6LoWPAN: Overview, Assumptions, Problem Statement and Goals,” RFC 4919, August 2007.


 TOC 

12.2. Informative References

[5] Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6), Specification,” RFC 2460, December 1998.
[6] Thomson, S., Narten, T., and T. Jinmei, “IPv6 Stateless Autoconfiguration,” RFC 4862, September 2007.
[7] Arkko, J., Kempf, J., Zill, B., and P. Nikander, “Secure Neighbor Discovery,” RFC 3971, March 2005.
[8] Baccelli, E. and M. Townsley, “IP Addressing Model in Adhoc Networks,” draft-ietf-autoconf-adhoc-addr-model-02.txt (work in progress), December 2009.
[9] IEEE Computer Society, “IEEE Std. 802.15.4-2003,”  , October 2003.
[10] Miwakawya, S., “Requirements for Prefix Delegation,” RFC 3769, June 2004.
[11] Unique Local IPv6 Addresses,” RFC 4193.
[12] Park, D., Kim, K., Seo, E., and S. Chakrabarti, “IPv6 over Low Power WPAN Security Analysis,” draft-daniel-6lowpan-security-analysis-02.txt (work in progress), January 2007.


 TOC 

Authors' Addresses

  Samita Chakrabarti
  IP Infusion
  1188 Arquest Street
  Sunnyvale, CA
  USA
Email:  samitac@ipinfusion.com
  
  Erik Nordmark
  Oracle, Inc.
  17 Network Circle
  Menlo Park, CA 94025
  USA
Email:  Erik.Nordmark@Sun.COM