Network Working Group J. Hui
Internet-Draft Arch Rock Corporation
Intended status: Standards Track July 28, 2008
Expires: January 29, 2009
Neighbor Discovery and Autoconfiguration for Route-Over 6LoWPAN Networks
draft-hui-6lowpan-nd-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 January 29, 2009.
Hui Expires January 29, 2009 [Page 1]
Internet-Draft 6LoWPAN Neighbor Discovery and Autoconf July 2008
Abstract
This document specifies a simple version of IPv6 Neighbor Discovery
for route-over 6LoWPAN networks. 6LoWPAN ND allows nodes to discover
routers, discover network configuration parameters, and IPv6 prefixes
for use with stateless address autoconfiguration and context-based
6LoWPAN compression for IPv6 headers. This document also specifies
autoconfiguration mechanism for use in 6LoWPAN networks.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Addressing and Prefix Model . . . . . . . . . . . . . . . 6
3.2. Neighbor Discovery . . . . . . . . . . . . . . . . . . . . 6
3.3. Autoconfiguration . . . . . . . . . . . . . . . . . . . . 8
4. 6LoWPAN ND Message Formats . . . . . . . . . . . . . . . . . . 10
4.1. Router Solicitation . . . . . . . . . . . . . . . . . . . 10
4.2. Router Advertisement . . . . . . . . . . . . . . . . . . . 11
4.3. Prefix Information Option . . . . . . . . . . . . . . . . 12
4.4. Prefix Summary Option . . . . . . . . . . . . . . . . . . 13
5. DHCPv6 Option Formats . . . . . . . . . . . . . . . . . . . . 15
5.1. DHCPv6 IA_6LOWPAN Option . . . . . . . . . . . . . . . . . 15
5.2. IA_6LOWPAN Prefix Option . . . . . . . . . . . . . . . . . 16
5.3. IA_6LOWPAN Local Interface Identifier Option . . . . . . . 16
6. Router and Prefix Discovery . . . . . . . . . . . . . . . . . 18
7. Autoconfiguration . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Stateless Autoconfiguration . . . . . . . . . . . . . . . 19
7.2. DHCPv6 Autoconfiguration . . . . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . . . 24
Hui Expires January 29, 2009 [Page 2]
Internet-Draft 6LoWPAN Neighbor Discovery and Autoconf July 2008
1. Introduction
This document specifies the mechanisms necessary to configure a
route-over IPv6/6LoWPAN network. In a route-over configuration, the
link-local scope is defined by the radio transmission range. This is
in contrast to a mesh-under configuration where the link-local scope
is defined by the boundaries of the PAN and includes all nodes
within. Compared to mesh-under, a route-over configuration gives
nodes IP-level visibility into the underlying radio connectivity.
Using link-local addresses, nodes can address and communicate to
their radio neighbors directly without requiring any routing support.
Nodes can also communicate with their radio neighbors using link-
local multicast addresses. However, the underlying link-layer power
management protocol may preclude the use of broadcast operations. In
either case, the underlying link does not guarantee reflexive or
transitive reachability (as defined in [RFC4861]). For both route-
over and mesh-under, we assume that global routing prefixes used to
configure IPv6 addresses will often be assigned to all nodes in a
PAN.
6LoWPAN networks differ from traditional IPv6 networks in their
available resources. Nodes are often powered using autonomous power
sources with limited capacity. The IEEE 802.15.4 link supports up to
250 kbps with a 128 byte MTU, including the length byte.
Furthermore, due to the nature of wireless communication, nodes
within radio transmission range must share the wireless medium.
Microcontrollers typically coupled with IEEE 802.15.4 radios are also
limited in memory (typically less than 8KB RAM and 64KB ROM) and
computation capability (typically around 4MHz). In the most general
case, nodes cannot maintain state about all of its radio neighbors.
These resource constraints can prohibit many of the IPv6 ND
mechanisms specified in [RFC4861]. For example, neighbor
unreachability detection requires nodes to continuously communicate
with neighboring nodes and address resolution requires communication
to resolve the mapping between IPv6 and link-layer addresses. Both
also require nodes to maintain per-neighbor state. Duplicate address
detection requires nodes to communicate with all other nodes that may
utilize the same global routing prefix to configure and IPv6 address.
The severe resource constraints motivate us to develop a simplified
version of IPv6 ND optimized for 6LoWPAN networks. By making some
simplifying assumptions, we can remove the need for many of the
mechanisms defined in [RFC4861]. To remove the communication and
state requirements for Address Resolution, we require that an IPv6
address assigned to a 6LoWPAN interface has an IID derived from a
link-layer address. 6LoWPAN Neighbor Discovery assumes that th
uniqueness of link-layer addresses is maintained by other mechanisms
(e.g, upper-layer mechanisms such as DHCPv6 or lower-layer mechanisms
Hui Expires January 29, 2009 [Page 3]
Internet-Draft 6LoWPAN Neighbor Discovery and Autoconf July 2008
provided by IEEE 802.15.4). By assuming that the uniqueness of link-
layer addresses are maintained through other means, we do not require
nodes to perform duplicate address detection using neighbor
discovery. However, optimistic methods SHOULD be applied through
other means (e.g. through routing protocols or other registration
mechanisms). 6LoWPAN Neighbor Discovery also does not provide
Neighbor Unreachability Detection, expecting that application-
specific protocols will be used to discover and maintain reachability
with radio neighbors.
The basic mechanisms that 6LoWPAN Neighbor Discovery provides are
router discovery, prefix discovery, and parameter discovery. This
document specifies how to propagate prefix information over multiple
hops, for use with context-based header compression and stateless
address autoconfiguration. In contrast, IPv6 ND only specifies
operation over a single link and does not provide any means to
support context-based header compression.
This document also specifies address autoconfiguration for route-over
6LoWPAN networks. This document specifies a protocol for stateless
address autoconfiguration using prefix information carried in Router
Advertisements. This document also specifies stateful address
autoconfiguration using DHCPv6.
Hui Expires January 29, 2009 [Page 4]
Internet-Draft 6LoWPAN Neighbor Discovery and Autoconf July 2008
2. Terminology
6LoWPAN Host
A 6LoWPAN node that only sources or sinks IPv6 datagrams.
6LoWPAN Router
A 6LoWPAN node that forwards datagrams between arbitrary
source-destination pairs using a single 6LoWPAN/802.15.4
interface. A 6LoWPAN router may also serve as a 6LoWPAN host -
both sourcing and sinking IPv6 datagrams.
6LoWPAN Border Router
A standard IPv6 router that forwards datagrams between
different media, at least one of which is a 6LoWPAN/802.15.4
interface.
Mesh-Under
A 6LoWPAN network configuration where the link-local scope is
defined by the boundaries of the PAN and includes all nodes
within.
PAN
Personal Area Network.
Radio Neighbor
A node within radio transmission range.
Route-Over
A 6LoWPAN network configuration where the link-local scope is
defined by those nodes reachable over a single radio
transmission. Due to the time-varying characteristics of
wireless communication, the neighbor set may change over time
even when nodes maintain the same physical locations.
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 [RFC2119].
Hui Expires January 29, 2009 [Page 5]
Internet-Draft 6LoWPAN Neighbor Discovery and Autoconf July 2008
3. Overview
3.1. Addressing and Prefix Model
All IPv6 addresses MUST contain a 64-bit IID derived from IEEE
802.15.4 addresses. Either the IEEE EUI-64 or short address combined
with the PAN ID may be used to generate an IID, as specified in
[RFC4944]. By generating an IID from link-layer addresses, address
resolution becomes trivial as appropriate link-layer address can be
regenerated from the IID. As a result, no explicit communication is
required to resolve mappings between network- and link-layer
addresses. Note that the short address can be used go generate local
scope interface identifiers.
The uniqueness of link-layer addresses MUST be maintained by some
mechanism, but MAY be implemented in upper- or lower-layer services.
IEEE EUI-64 addresses are assumed to have global scope. Short IEEE
802.15.4 addresses may be assigned using link-layer mechanisms (e.g.
using an IEEE 802.15.4 PAN Coordinator). The short IEEE 802.15.4
addresses may also be derived using information provided in DHCPv6
responses when using DHCPv6.
6LoWPAN nodes within a PAN generally assign IPv6 addresses that are
common to the PA. By assigning the same prefix set, 6LoWPAN nodes
can utilize shared context to efficiently compress both source and
destination addresses in the IPv6 header. Nodes may autoconfigure
IPv6 addresses and compression context using stateless and/or
stateful (DHCPv6) mechanisms.
No prefix (other than the link-local prefix) may be considered on-
link. Because the IPv6 link model does not support transitive
reachability, one nodes view of the link-local scope may be different
than another node's view of link-local scope. As a result, any
prefix assigned to 6LoWPAN interfaces MUST be a /128.
6LoWPAN Border Routers route datagrams between different media, one
or more of which is a 6LoWPAN interface. Border Routers MUST
subscribe to the reserved subnet anycast address for each prefix
assigned to the PAN, as described in [RFC4291]. 6LoWPAN nodes can
communicate with an arbitrary border router using the reserved subnet
router anycast address for any of the global routing prefixes
assigned to the PAN.
3.2. Neighbor Discovery
This protocol addresses the following problems:
Hui Expires January 29, 2009 [Page 6]
Internet-Draft 6LoWPAN Neighbor Discovery and Autoconf July 2008
Router Discovery: How hosts locate routers that reside on an
attached link.
Prefix Discovery: How hosts discover the set of address prefixes
used for Stateless Address Autoconfiguration and 6LoWPAN IPv6
Header Compression.
Parameter Discovery: How a node learns parameters used for outgoing
packets, such as the initial hop limit value.
6LoWPAN Neighbor Discovery defines two different ICMP packet types
that mirror those used with IPv6 Neighbor Discovery: a Router
Advertisement message and a Router Solicitation message.
Each 6LoWPAN router periodically multicasts a Router Advertisement
message to announce its presence and availability. All 6LoWPAN nodes
learn of their presence through Router Advertisements and utilize its
containing information to configure themselves. Configured nodes
will advertise the latest information in its own Router
Advertisements to propagate the information over multiple hops. Note
that 6LoWPAN ND allows routers to configure other neighboring
routers. In contrast, IPv6 ND only allows routers to configure
hosts. While 6LoWPAN ND does not specify a routing protocol, routing
information MAY be included in Router Advertisements.
Routers manage the transmission period for Router Advertisements
using the Trickle algorithm [levis04trickle]. Routers set the
transmission period to MIN_RTR_ADVERT_INTERVAL when becoming an
advertising interface or there is new information to communicate.
After each transmission, the router doubles the transmission period
up to a maximum, MAX_RTR_ADVERT_INTERVAL. Given a transmission
period, nodes select a random offset by multiplying by a random
factor between MIN_RANDOM_FACTOR and MAX_RANDOM_FACTOR.
Using a Prefix Information Option, Router Advertisements may contain
one or more prefixes for use with 6LoWPAN-based IPv6 header
compression and stateless address autoconfiguration - fields within
the option indicate the particular uses of the prefix information.
Note that unlike IPv6 ND, no prefixes may be designated as on-link.
Because prefix information must propagate over multiple hops, the
Prefix Information Option includes a sequence number to indicate
freshness. Changing the prefix information represents a change in
information and the router resets its Router Advertisement
transmission period to MIN_RTR_ADVERT_INTERVAL. Nodes MAY include
only a subset of the prefix information in a Router Advertisement.
Like IPv6 ND, Router Advertisements contain flags that inform hosts
how to perform Address Autoconfiguration. Routers can specify
Hui Expires January 29, 2009 [Page 7]
Internet-Draft 6LoWPAN Neighbor Discovery and Autoconf July 2008
whether hosts should use DHCPv6 and/or stateless address
autoconfiguration. If DHCPv6 should be used, a flag in the Router
Advertisement indicates whether or not the node is acting as a DHCPv6
Relay. Advertisements also contain Internet parameters such as the
hop limit should use in outgoing packets.
Hosts may send Router Solicitations to request neighboring routers to
generate Router Advertisements more quickly, rather than waiting
until the next scheduled Router Advertisement transmission from those
routers. Hosts may either multicast the Router Solicitation to
generate Router Advertisements from multiple routers or unicast the
Router Solicitation to a particular router.
3.3. Autoconfiguration
All 6LoWPAN nodes MUST assign a link-local unicast address to their
6LoWPAN interface using an interface identifier derived from the IEEE
EUI-64 address. Using this link-local address, nodes can communicate
with other radio neighbors.
Through Router Advertisements, nodes may learn additional
autoconfiguration information. Nodes may learn information about
Internet parameters, such as the default hop limit value to place in
outgoing packets. Nodes may also learn the lifetime of the router
sending the Router Advertisement.
Router Advertisements may include one or more prefix information
options. Each prefix information entry contains a sequence number
that indicates its freshness. All 6LoWPAN nodes MUST accept the
newest prefix information. All 6LoWPAN routers MUST include that
prefix information in its Router Advertisement messages. Doing so
effectively allows the prefix information to propagate over multiple
hops to all 6LoWPAN nodes in a PAN.
Prefix Information entries within a Router Advertisement include a
flag to indicate whether those prefixes are intended to be used with
stateless address autoconfiguration. If so, nodes should form one or
more addresses using the prefix information, one using an interface
identifier derived from the IEEE EUI-64 address and, if available,
another using an interface identifier derived from the short IEEE
802.15.4 address.
Two flags in the Router Advertisement indicate if DHCPv6 should be
use to autoconfigure addresses or other configuration parameters. A
third flag indicates if the sending router is also serving as a
DHCPv6 Relay. All 6LoWPAN routers and border routers SHOULD serve as
a DHCPv6 Relay and all 6LoWPAN nodes are configured, by default, to
forward DHCPv6 requests to a subnet anycast address. Border routers
Hui Expires January 29, 2009 [Page 8]
Internet-Draft 6LoWPAN Neighbor Discovery and Autoconf July 2008
can either service DHCPv6 requests directly or act as a DHCPv6 Relay
and forward the request to the intended server.
To request an address, nodes unicast a DHCPv6 request to a
neighboring DHCPv6 Relay using link-local communication. The DHCPv6
Relay may be another 6LoWPAN router or a border router. In the
former case, the node simply forwards the payload on to the border
router. One subtle difference is that the node need not encapsulate
the DHPCv6 request in a DHCPv6 Relay header, as it can be
reconstructed using the DUID information contained in the request.
The border router, however, must properly expand the DHCPv6 Relay
header when forwarding it further or compress the header when
forwarding a reply back to a 6LoWPAN node. Note that DHCPv6 requires
nodes to form routes between them and one or more border routers.
Because this document specifies that an IID MUST be derived from a
link-layer address, DHCPv6 replies are composed of one or more
prefixes and up to one interface identifier. The latter allows the
DHCPv6 server to effectively assign short 16-bit addresses to
requesting nodes. Not carrying full IPv6 addresses makes the DHCPv6
response more compact. With the prefix information, 6LoWPAN nodes
autoconfigure addresses similar to stateless address
autoconfiguration described above.
As usual, DHCPv6 and stateless autoconfiguration MAY be used
together. For example, the DHCPv6 may provide the short address,
while stateless autoconfiguration provides the prefixes.
Hui Expires January 29, 2009 [Page 9]
Internet-Draft 6LoWPAN Neighbor Discovery and Autoconf July 2008
4. 6LoWPAN ND Message Formats
4.1. Router Solicitation
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 1: Router Solicitation Message Format
IP Fields:
o Source Address: An IP address assigned to the sending interface.
o Destination Address: The link-local all-routers multicast address.
o Hop Limit: 255
ICMP Fields:
o Type: 133
o Code: 0
o Checksum: The ICMP checksum. See [RFC4443].
Possible Options: None
Future versions of this protocol may define new option types.
Receivers MUST silently ignore any options they do not recognized and
continue processing the message.
Hui Expires January 29, 2009 [Page 10]
Internet-Draft 6LoWPAN Neighbor Discovery and Autoconf July 2008
4.2. Router Advertisement
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |M|O|D|S| rsv | Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Router Advertisement Message Format
IP Fields:
o Source Address: MUST be a link-local address assigned to the
interface when this message is sent.
o Destination Address: The link-local all nodes multicast address or
the Source Address of an invoking Router Solicitation.
o Hop Limit: 255
ICMP Fields:
o Type: 134
o Code: 0
o Checksum: The ICMP checksum. See [RFC4443].
o Cur Hop Limit: 8-bit unsigned integer. The default value that
should be placed in the Hop Count field of the IP header for
outgoing IP packets. A value of zero means unspecified (by this
router).
o M: 1-bit "Managed address configuration" flag as specified in
[RFC4861].
o O: 1-bit "Other configuration" flag as specified in [RFC4861].
o D: 1-bit "DHCPv6 relay" flag. When set, it indicates that the
router is acting as a DHCPv6 Relay and is capable of forwarding
DHCPv6 requests to a DHCPv6 server.
Hui Expires January 29, 2009 [Page 11]
Internet-Draft 6LoWPAN Neighbor Discovery and Autoconf July 2008
o S: 1-bit "Router Solicitation" flag. When set, it indicates that
the router is requesting neighboring routers to generate Router
Advertisement messages.
o rsv: This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
o Router Lifetime: 16-bit unsigned integer as specified in
[RFC4861].
Possible options:
o Prefix Information: One or more may appear in a Router
Advertisement message and indicate what prefixes to use for
stateless address autoconfiguration and/or 6LoWPAN IPv6 header
compression.
Future versions of this protocol may define new option types.
Receivers MUST silently ignore any options they do not recognized and
continue processing the message.
4.3. Prefix Information Option
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 |CID|V|A|D| rsv | Sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Prefix +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Prefix Information Option Format
Fields:
o Type: 8-bit unsigned integer. TBD
o Length: 8-bit unsigned integer. 12
o CID: 2-bit unsigned integer. Identifies the specific context that
the prefix information pertains to for use with 6LoWPAN IPv6
Header Compression.
Hui Expires January 29, 2009 [Page 12]
Internet-Draft 6LoWPAN Neighbor Discovery and Autoconf July 2008
o V: 1-bit valid flag. When set, indicates that the prefix
information is valid and neighboring nodes should inspect the
option for newer information.
o D: 1-bit deprecated flag. Indicates that the prefix information
is deprecated. Nodes MUST unconfigure any IPv6 addresses assigned
to the 6LoWPAN interface using this prefix. However, nodes MUST
continue accepting packets using this context.
o A: 1-bit autonomous address-configuration flag. When set,
indicates that this prefix can be used for stateless address
autoconfiguration.
o rsv: This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
o Sequence: 8-bit signed integer. A sequence number used for
indicating freshness of the prefix information. Nodes MUST choose
the newest prefix information if the versions differ.
o Prefix: A 64-bit IPv6 prefix. A router SHOULD NOT send a prefix
option for the link-local prefix and a host SHOULD ignore such a
prefix option.
4.4. Prefix Summary Option
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 |CID|V|A|D| rsv | Sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|CID|V|A|D| rsv | Sequence |CID|V|A|D| rsv | Sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Prefix Summary Option Format
Fields:
o Type: 8-bit unsigned integer. TBD
o Length: 8-bit unsigned integer. 8
o CID: 2-bit unsigned integer. Identifies the specific context that
the prefix information pertains to for use with 6LoWPAN IPv6
Header Compression.
Hui Expires January 29, 2009 [Page 13]
Internet-Draft 6LoWPAN Neighbor Discovery and Autoconf July 2008
o V: 1-bit valid flag. When set, indicates that the prefix
information is valid and neighboring nodes should inspect the
option for newer information.
o D: 1-bit deprecated flag. Indicates that the prefix information
is deprecated. Nodes MUST unconfigure any IPv6 addresses assigned
to the 6LoWPAN interface using this prefix. However, nodes MUST
continue accepting packets using this context.
o A: 1-bit autonomous address-configuration flag. When set,
indicates that this prefix can be used for stateless address
autoconfiguration.
o rsv: This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
o Sequence: 8-bit signed integer. A sequence number used for
indicating freshness of the prefix information. Nodes MUST choose
the newest prefix information if the versions differ.
Hui Expires January 29, 2009 [Page 14]
Internet-Draft 6LoWPAN Neighbor Discovery and Autoconf July 2008
5. DHCPv6 Option Formats
5.1. DHCPv6 IA_6LOWPAN Option
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-type | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ server-id +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ client-id +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| options ...
+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: DHCPv6 IA_6LOWPAN Option Format
Fields:
o option-type: 16-bit unsigned integer. TBD.
o option-length: 16-bit unsigned integer. 12 + length of Options
field.
o server-id: 64-bit IEEE EUI-64 of the server.
o client-id: 64-bit IEEE EUI-64 of the client.
o options: Options associated with this 6LoWPAN IA.
Possible options:
o IA_6LOWPAN Prefix Option: One or more may appear in a IA_6LOWPAN
Option and indicates IPv6 addresses to assign to the 6LoWPAN
interface and the context for use with 6LoWPAN compression of IPv6
headers.
o IA_6LOWPAN Interface Identifier Option: Up to one may appear in a
IA_6LOWPAN Option and assigns a short address to a 6LoWPAN
interface.
Hui Expires January 29, 2009 [Page 15]
Internet-Draft 6LoWPAN Neighbor Discovery and Autoconf July 2008
Future versions of this protocol may define new option types.
Receivers MUST silently ignore any options they do not recognized and
continue processing the message.
5.2. IA_6LOWPAN Prefix Option
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 | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ prefix +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| valid-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: IA_6LOWPAN Prefix Option Format
Fields:
o Type: 8-bit unsigned integer. TBD.
o Length: 8-bit unsigned integer. 32.
o Prefix: A 64-bit prefix.
o Valid-Lifetime: 32-bit unsigned integer. Valid lifetime of the
associated IPv6 address.
5.3. IA_6LOWPAN Local Interface Identifier Option
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 | short-address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| valid-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+
Hui Expires January 29, 2009 [Page 16]
Internet-Draft 6LoWPAN Neighbor Discovery and Autoconf July 2008
Figure 7: IA_6LOWPAN Local Interface Identifier Option Format
Fields:
o Type: 8-bit unsigned integer. TBD.
o Length: 8-bit unsigned integer. 8.
o Short Address: Lower 16 bits of an Interface Identifier derived
from a short IEEE 802.15.4 address, which is equivalent to the
short address itself.
o Valid-Lifetime: 32-bit unsigned integer. Preferred lifetime of
the associated IPv6 address.
Hui Expires January 29, 2009 [Page 17]
Internet-Draft 6LoWPAN Neighbor Discovery and Autoconf July 2008
6. Router and Prefix Discovery
Hui Expires January 29, 2009 [Page 18]
Internet-Draft 6LoWPAN Neighbor Discovery and Autoconf July 2008
7. Autoconfiguration
7.1. Stateless Autoconfiguration
7.2. DHCPv6 Autoconfiguration
Hui Expires January 29, 2009 [Page 19]
Internet-Draft 6LoWPAN Neighbor Discovery and Autoconf July 2008
8. IANA Considerations
TODO.
Hui Expires January 29, 2009 [Page 20]
Internet-Draft 6LoWPAN Neighbor Discovery and Autoconf July 2008
9. Security Considerations
TODO.
Hui Expires January 29, 2009 [Page 21]
Internet-Draft 6LoWPAN Neighbor Discovery and Autoconf July 2008
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007.
[ieee802.15.4]
IEEE Computer Society, "IEEE Std. 802.15.4-2006",
October 2006.
[levis04trickle]
Levis, Patel, Culler, and Shenker, "Trickle: A Self-
Regulating Algorithm for Code Propagation and Maintenance
in Wireless Sensor Networks", March 2004.
10.2. Informative References
[I-D.hui-6lowpan-hc]
Hui, J., "Compression Format for IPv6 Datagrams in 6LoWPAN
Networks", draft-hui-6lowpan-hc-00 (work in progress),
March 2008.
Hui Expires January 29, 2009 [Page 22]
Internet-Draft 6LoWPAN Neighbor Discovery and Autoconf July 2008
Author's Address
Jonathan W. Hui
Arch Rock Corporation
501 2nd St. Ste. 410
San Francisco, California 94107
USA
Phone: +415 692 0828
Email: jhui@archrock.com
Hui Expires January 29, 2009 [Page 23]
Internet-Draft 6LoWPAN Neighbor Discovery and Autoconf July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Hui Expires January 29, 2009 [Page 24]