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]