6LoWPAN Z. Shelby, Ed.
Internet-Draft Sensinode
Intended status: Standards Track P. Thubert
Expires: April 27, 2009 Cisco
J. Hui
Arch Rock
S. Chakrabarti
IP Infusion
E. Nordmark
Sun
October 24, 2008
Neighbor Discovery for 6LoWPAN
draft-shelby-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 April 27, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
The 6LoWPAN format allows IPv6 to be used over very low-power, low-
Shelby, et al. Expires April 27, 2009 [Page 1]
Internet-Draft Neighbor Discovery for 6LoWPAN October 2008
bandwidth wireless networks often making use of extended multihop
topologies. However, the use of standard IPv6 Neighbor Discovery
over 6LoWPAN networks has several problems. Standard ND was not
designed for wireless links, the standard IPv6 link concept and heavy
use of multicast makes it inefficient. This paper specifies Neighbor
Discovery optimized for 6LoWPAN.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Goals & Assumptions . . . . . . . . . . . . . . . . . . . 5
1.2. Why not standard IPv6 ND? . . . . . . . . . . . . . . . . 6
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 12
3.2. Basic operation . . . . . . . . . . . . . . . . . . . . . 13
3.3. Optional features . . . . . . . . . . . . . . . . . . . . 13
4. 6LoWPAN ND messages . . . . . . . . . . . . . . . . . . . . . 13
4.1. Router Registration/Confirmation message . . . . . . . . . 13
4.2. Relay RR/RC message . . . . . . . . . . . . . . . . . . . 15
4.3. Router Advertisement message . . . . . . . . . . . . . . . 16
4.4. Neighbor Solicitation message . . . . . . . . . . . . . . 18
4.5. 6LoWPAN ND Message Options . . . . . . . . . . . . . . . . 18
4.5.1. Identity Request Option . . . . . . . . . . . . . . . 18
4.5.2. Identity Reply Option . . . . . . . . . . . . . . . . 19
4.5.3. Address Option . . . . . . . . . . . . . . . . . . . . 21
4.5.4. 6LoWPAN Address Option . . . . . . . . . . . . . . . . 22
4.5.5. 6LoWPAN Prefix Information Option . . . . . . . . . . 22
4.5.6. Multihop Information Option . . . . . . . . . . . . . 23
5. LoWPAN Subnet . . . . . . . . . . . . . . . . . . . . . . . . 24
6. LoWPAN Node Specification . . . . . . . . . . . . . . . . . . 24
6.1. Forming addresses . . . . . . . . . . . . . . . . . . . . 25
6.2. Registration process . . . . . . . . . . . . . . . . . . . 26
6.3. Next-hop determination . . . . . . . . . . . . . . . . . . 27
6.4. Address lookup . . . . . . . . . . . . . . . . . . . . . . 27
7. LoWPAN Router Specification . . . . . . . . . . . . . . . . . 28
7.1. Router Configuration Variables . . . . . . . . . . . . . . 28
7.2. Becoming an Advertising Interface . . . . . . . . . . . . 29
7.3. Router Advertisement Message Content . . . . . . . . . . . 29
7.4. Sending Unsolicited Router Advertisements . . . . . . . . 30
7.5. Ceasing To Be an Advertising Interface . . . . . . . . . . 30
7.6. Processing Router Solicitations . . . . . . . . . . . . . 30
7.7. Router Advertisement Consistency . . . . . . . . . . . . . 31
7.8. Relaying a Router Registration Message . . . . . . . . . . 31
7.9. Relaying a Router Confirmation Message . . . . . . . . . . 31
8. LoWPAN Edge Router Specification . . . . . . . . . . . . . . . 31
8.1. Registration process . . . . . . . . . . . . . . . . . . . 32
Shelby, et al. Expires April 27, 2009 [Page 2]
Internet-Draft Neighbor Discovery for 6LoWPAN October 2008
8.2. Exposing the Edge Router . . . . . . . . . . . . . . . . . 33
8.3. Forwarding packets . . . . . . . . . . . . . . . . . . . . 34
8.4. Fault tolerance . . . . . . . . . . . . . . . . . . . . . 35
9. Security Considerations . . . . . . . . . . . . . . . . . . . 35
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
12.1. Normative References . . . . . . . . . . . . . . . . . . . 35
12.2. Informative References . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
Intellectual Property and Copyright Statements . . . . . . . . . . 39
Shelby, et al. Expires April 27, 2009 [Page 3]
Internet-Draft Neighbor Discovery for 6LoWPAN October 2008
1. Introduction
The IPv6 over IEEE 802.15.4 [RFC4944] document has specified IPv6
headers carried over an IEEE 802.15.4 network with the help of an
adaptation header which comes before the IP header. A LoWPAN network
is characterized as a low-power, low bit-rate, short range, low cost
network. Thus, all-node multicast defined in IPv6 Neighbor Discovery
[RFC4861] is not often desirable in a wireless low-power, lossy
network. In addition IEEE 802.15.4 and similar wireless technologies
do not have multicast support, but supports broadcast. Broadcast
messages could be used in some cases to represent all-node multicast
messages, but periodic broadcast messages should be minimized in
LoWPANs in order to conserve energy. Moreover, LoWPAN nodes are
transient in nature; they are not always considered to be in a fixed
network nor they are bounded by our standard definition of a wired-
link. The link is often defined by reachability and radio strength.
The standard IPv6 neighbor discovery [RFC4861] control messages and
their default frequency also attribute to unnecessary loss of power
in the 6lowpan network.
The goal of this document is to minimize/remove periodic multicast
signals used by IPv6 Neighbor Discovery [RFC4861] while enabling the
LoWPAN to work as efficiently and optimally as possible and reducing
the complexity of LoWPAN node implementations.
Neighbor discovery for 6LoWPAN provides for basic bootstrapping, and
network operation, along with advanced features such as address
assignment and ND Proxy, while avoiding the use of multicast and
providing both mesh under and route over support. Unlike standard
IPv6 ND [RFC4861], this document takes the lossy characteristics of
wireless networks into account.
The concept of a LoWPAN Whiteboard located at Edge Routers is
introduced, which allows for duplicate address detection and address
assignment for the entire LoWPAN. Address resolution simplifications
are made to make LoWPAN operation efficient and reduce LoWPAN Nodes
complexity. A new registration/confirmation message sequence is
specified, allowing nodes to register their IPv6 addresses with an
Edge Router, and to request global unique address assignment.
The ND for 6LoWPAN whiteboard makes use of soft bindings, thus nodes
send periodic registration messages in order to maintain their
binding and address assignments. Changes in network topology, and
mobility between ERs and subnets are supported. The dissemination of
RA information throughout multihop route over networks is also
discussed.
This paper also specifies an extension to ND Proxy and its use by
Shelby, et al. Expires April 27, 2009 [Page 4]
Internet-Draft Neighbor Discovery for 6LoWPAN October 2008
Edge Routers, allowing for the seamless integration of an extended
LoWPAN and multiple Edge Routers on a shared backbone link (e.g.
Ethernet) to form a single IPv6 subnet. This allows hosts to keep
the same IPv6 address throughout a large network, and allows for easy
communications with backbone link IPv6 hosts.
This paper defines two new ICMPv6 message sets: Router Registration/
Confirmation and Relay RR/RC messages. In addition a new 6LOWPAN_ER
anycast address is introduced, allowing for nodes to send register
without knowing the specific Edge Router's or Router's unicast
address.
1.1. Goals & Assumptions
This document has the following main goals and makes several
assumptions.
Goals:
o Avoid the use of multicast for ND messages inside the LoWPANs.
o Disseminate prefix and context information throughout the
LoWPAN.
o Minimize the complexity of LoWPAN nodes.
o Interconnect LoWPANs with backbone links seamlessly.
o Provide a mechanism for address assignment.
Assumptions:
o Either [RFC4944] or [draft-ietf-6lowpan-hc-01] 6LoWPAN header
compression.
o Link layer technology may be IEEE 802.15.4 as in [RFC4944], or
any other suitable link-layer.
o Link-local addresses are derived from an EUI-64 identifier.
o The use of optimistic DAD.
o Mesh-under nodes know the edge router link-layer addresses of
their mesh network from some L2 mechanism.
o A subnet covers all the LoWPANs and their backbone link with the
same IPv6 global or local prefix.
Shelby, et al. Expires April 27, 2009 [Page 5]
Internet-Draft Neighbor Discovery for 6LoWPAN October 2008
1.2. Why not standard IPv6 ND?
IPv6 Neighbor Discovery [RFC4861] provides several important
functions such as Router Discovery, Address Resolution, Duplicate
Address Detection, Redirect, Prefix and Parameter Discovery.
Following power-on and initialisation of the network in IPv6 ethernet
networks, a node joins the solicited-node multicast address on the
interface and then it performs duplicate address detection (DAD) for
the acquired link-local address by sending solicited-node multicast
message to the link. After that it sends multicast messages to all-
router address to solicit router advertisements. Once the host
receives a valid router advertisement with the "A" flag, it
autoconfigures the IPv6 address with the advertised prefix in the
rotuer advertisement (RA). Besides this, the IPv6 routers usually
send router advertisements periodically on the network. It sends the
RA to all-node multicast address. Nodes send Neighbor Solicitation/
Neighbor Advertisement messages to resolve the IPv6 address of the
destination on the link. These NS/NA messages are also often
multicast messages and it assumes that the node is on the same link
and relies on the fact that the destination node is always powered
and generally reliable.
A LoWPAN network typically uses two types of L2 addresses - 16-bit
short addresses and 64-bit unique addresses as defined in [RFC4944].
Moreover, the link bandwidth is often on the order of less than 100
bytes where we often might need to use header compression and use a
minimum payload. The network is lossy and low-powered, and it does
not provide multicast capability at the link-layer, thus simulating
multicast behavior by both using broadcast or sending a number of
unicast messages, both expensive for the low-powered network and the
low-processing capable nodes. Besides often these low-powered nodes
conserve energy by using sleep schedules; waking them up to receive
IPv6 signaling messages such as multicast messages for NS, and
periodic RA is not practical. Nor they are capable of processing
address-resolution for its neighbors effectively. Besides due to
radio strength of its neighboring router or its own strength, a node
may often move between one subnet to another without physically
moving from one place to another. Considering the above
characteristics in a LoWPAN, and IPv6 Neighbor Discovery [RFC4861]
base protocol requirements, it was concluded that standard Neighbor
Discovery is not suitable as it is and a 6lowpan-specific ND protocol
would be useful and efficient for wide deployment of IPv6 over low-
powered wireless networks of embedded devices.
Shelby, et al. Expires April 27, 2009 [Page 6]
Internet-Draft Neighbor Discovery for 6LoWPAN October 2008
2. Terminology
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].
Readers are expected to be familiar with all the terms and concepts
that are discussed in "Neighbor Discovery for IP version 6"
[RFC4861], "IPv6 Stateless Address Autoconfiguration" [RFC4862],
"IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals" [RFC4919] and
"Transmission of IPv6 Packets over IEEE 802.15.4 Networks" [RFC4944].
Readers would benefit from reading "Mobility Support in IPv6"
[RFC3775], "Neighbor Discovery Proxies (ND Proxy)" [RFC4389] and
"Optimistic Duplicate Address Detection" [RFC4429] prior to this
specification for a clear understanding of state of the art in ND
proxy and binding.
This document defines additional terms:
LoWPAN Host
A node that only sources or sinks IPv6 datagrams. Referred to as
a Host in this document. The term Node is used when the the
differentiation between Host and Router is not important.
LoWPAN Edge Router
An IPv6 router that interconnects the LoWPAN to another network.
Referred to as an Edge Router in this document.
LoWPAN Router
A node that forwards datagrams between arbitrary source-
destination pairs using a single 6LoWPAN/802.15.4 interface. A
LoWPAN Router may also serve as a LoWPAN Host - both sourcing and
sinking IPv6 datagrams. Refered to as a Router in this document.
All LoWPAN Routers perform ND message relay on behalf of other
nodes.
Mesh Under
A LoWPAN configuration where the link-local scope is defined by
the boundaries of the LoWPAN and includes all nodes within.
Multihop forwarding is achieved at L2 between mesh nodes.
Shelby, et al. Expires April 27, 2009 [Page 7]
Internet-Draft Neighbor Discovery for 6LoWPAN October 2008
Route Over
A LoWPAN 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. Multihop is achieved using IP routing.
Backbone Link
This is an IPv6 link that interconnects 2 or more Edge Routers.
It is expected to be deployed as a high speed backbone in order to
federate a potentially large set of LoWPANS.
Backhaul Link
This is an IPv6 link that connects a single Edge Router to another
network.
Extended LoWPAN
This is the aggregation of multiple LoWPANs as defined in
[RFC4919] interconnected by a backbone link via Edge Routers and
forming a single subnet.
LoWPAN Subnet
A subnet including a LoWPAN or Extended LoWPAN, together with the
backbone link sharing the same prefix.
Binding
The association of the LoWPAN node IPv6 address and Interface ID
with associated whiteboard and proxy states including the
remaining lifetime of that association.
Registration
The process during which a LoWPAN node sends a Router Registration
ND message to an Edge Router causing a binding for the LoWPAN node
to be registered.
3. Protocol Overview
Neighbor discovery for 6LoWPAN provides additions and optimizations
to IPv6 ND [RFC4861] supporting 6LoWPAN low-power wireless stub
networks. Basic bootstrapping and network maintenenace mechanisms
Shelby, et al. Expires April 27, 2009 [Page 8]
Internet-Draft Neighbor Discovery for 6LoWPAN October 2008
are provided, and the use of multicast for ND messages is avoided.
Duplicate address detection and global address assignment are
supported as part of bootstrapping. This is achieved using a
whiteboard located on the 6LoWPAN Edge Routers of the LoWPAN network.
Multihop route-over networks are supported by relaying ND messages.
Finally, advanced features include ND Proxy extensions, and secondary
Edge Router registrations. ND for 6LoWPAN is designed to work with
many network topologies, including isolated ad-hoc networks, single
ER networks, and networks with multiple ERs interconnected by a
backbone link. The use of both IEEE 802.15.4 and other suitable
6LoWPAN link-layer technologies is considered. Both the use of mesh
under forwarding and route over routing are supported.
|
|
|
+-----+
| | Edge
| | router
+-----+
m m
m m
m m m m m: Mesh node
m m m m
m m m
LoWPAN
Figure 1: A Mesh under LoWPAN.
In a mesh under network, shown above, multihop forwarding is dealt
with below layer 3. Thus the entire LoWPAN forms a link-layer mesh.
This means that the IPv6 link-local scope includes all the nodes of
the LoWPAN. The implication of this on ND for 6LoWPAN, is that it
can always be assumed that the ER and hosts are on the same link.
Multicast with mesh under technologies most often induces flooding,
and therefore it is avoided.
Shelby, et al. Expires April 27, 2009 [Page 9]
Internet-Draft Neighbor Discovery for 6LoWPAN October 2008
|
|
|
+-----+
| | Edge
| | router
+-----+
r h
r r r
h r h r h h: Host
h r r h r: Router
h h h
LoWPAN
Figure 2: A Route over LoWPAN.
A route over network performs multihop using standard layer 3 IP
routing. The link-local scope is defined by those nodes reachable
over a single radio transmission. The implication for ND for 6LoWPAN
is that if the ER is out of radio range of a host, the ND messages
require relaying by intermediate Routers. Multicast may also involve
flooding in such networks, and is avoided.
Infrastructure
Cloud
z
z
z Backhaul link
z
z
+-----+
| | Edge
| | router
+-----+
o o
o o o
o o o o o o: Any node
o o o o
o o o
LoWPAN
Figure 3: A LoWPAN connected to a backhaul link.
Shelby, et al. Expires April 27, 2009 [Page 10]
Internet-Draft Neighbor Discovery for 6LoWPAN October 2008
The simplest topology is a LoWPAN connected by a single Edge Router
to another network, over a so-called backhaul link. The Edge Router
maintains a whiteboard of all hosts in the network, and assigns
addresses. The Edge Router terminates 6LoWPAN framing from the
LoWPAN, and forwards packets. Multiple such networks may also
overlap to form an Extended LoWPAN.
Infrastucture Cloud
|
|
+-----+ +-----+
| | Gateway | | Host
| | | |
+-----+ +-----+
| |
| Backbone link |
+--------------------+------------------+
| | |
+-----+ +-----+ +-----+
| | Edge | | Edge | | Edge
| | router | | router | | router
+-----+ +-----+ +-----+
o o o o o o o o
o o o o o o o o o o o o o o o o o
o o o o o o o o o o o o o o o o
o o o o o o o o o o o o
o o o o o o o o o
Extended LoWPAN
Figure 4: Backbone link and edge routers with a 6LoWPAN subnet
In the backbone link topology, a backbone link federates multiple
LoWPANs as a single IP link, the Extended LoWPAN. Each LoWPAN is
anchored at one or more Edge Router. The Edge Routers interconnect
the LoWPANs over the backbone link. A node can move freely from a
LoWPAN anchored at an Edge Router to a LoWPAN anchored at another
Edge Router on the same backbone link and conserve its link local and
any other IPv6 address it has formed. If ND Proxy is used, a
standard IPv6 Host on the backbone link can communicate with any host
in the Extended LoWPAN and vice versa.
The following sections explain the basics of how ND for 6LoWPAN
works, starting with bootrapping on the network, maintenance of the
network, and finally optional features such as ND Proxy.
Shelby, et al. Expires April 27, 2009 [Page 11]
Internet-Draft Neighbor Discovery for 6LoWPAN October 2008
3.1. Bootstrapping
A Host first performs stateless autoconfiguration of its link-local
address for each 6LoWPAN interface from its EUI-64 as in [RFC4944].
When a LoWPAN Host wants to join a LoWPAN network, it does so by
listening for Route Advertisements from Edge Routers or Routers, or
by broadcasting a Router Solicitations. If a global prefix is
included in the RA, the host may form an optimistic global unique
address with stateless autoconfiguration.
Next the Host registers with an on-link Edge Router or Router by
sending a Router Registration (RR) message to it, either unicast or
using the 6LOWPAN_ER anycast address. These message exchanges are
illustrated below. The RR contains the addresses the node wants to
register, and a possible request for a global assigned address. An
RR message is structured as follows, with nested Address Options
inside an Identity Request Option.
ICMP (Router Registration (Identity Request Option (Address
Options)))
The Edge Router replies either directly with a Router Confirmation
(RC), or through a Router. This Confirmation includes the set of
addresses now bound to the whiteboard of the ER, including assigned
addresses. The RC may also include other network configuration
information. The Host is now capable of using the LoWPAN, and the ER
forwards on its behalf.
Node Edge Router
| |
| ---------- Router Registration --------> |
| |
| <--------- Router Confirmation --------- |
| |
Figure 5: Basic ND registration exchange.
Node Router (relay) Edge Router
| | |
| ---- RR ---> | ---- Relay RR ---> |
| | |
| <---- RC ---- | <---- Relay RC ---- |
| | |
Shelby, et al. Expires April 27, 2009 [Page 12]
Internet-Draft Neighbor Discovery for 6LoWPAN October 2008
Figure 6: Relay ND registration exchange.
3.2. Basic operation
The whiteboard address binding and assignment are soft, and thus must
be renewed periodically as indicated by the lifetime of the identity.
This is achieved by periodically sending a new RR to the ER. If a
host moves, or the network topology changes, and the current ER is no
longer available, the host then starts the registration process with
another ER. If the host is still in the same Extended LoWPAN, its
IPv6 addresses remain the same. If the host moves to a different
LoWPAN, with a different global prefix, the bootstrapping process is
initiated again. In route over networks, Routers that act as relays
must disseminate RAs to their neighbors. The Edge Router
disseminates RAs, and this information is included in the RAs of each
Router.
3.3. Optional features
ND Proxy is specified in [RFC4389], and allows for two segments to be
merged into a single IPv6 link. This specification extends ND Proxy
for use with Extended LoWPAN networks with multiple ERs on a backbone
link. This optional feature allows for the entire Extended LoWPAN
and backbone links to appear as a single IPv6 link. The extended ND
Proxy includes an option to uniquely identify the LoWPAN Host on the
backbone, and override the claim on an address on behalf of a LoWPAN
Host. Thus a Host can keep the same address, and appears the same to
other Hosts on the backbone link, regardless of moving its binding
from one ER to another. Forwarding is automatic regardless of which
ER the host is proxied by.
4. 6LoWPAN ND messages
This section introduces message formats for all messages used in this
specification. The new messages are all ICMPv6 messages and extend
the capabilities of "The IPv6 Neighbor Discovery Protocol" [RFC4861].
4.1. Router Registration/Confirmation message
The Router Registration (RR) and Router Confirmation (RC) messages
are used by a Host to register with an ER, and for the ER to confirm
the binding. Any option that is not recognized MUST be skipped
silently. The Router Registration message is sent by the LoWPAN Node
to an on-link ER or Router, and may be sent unicast or to the
6LOWPAN_ER anycast address.
Shelby, et al. Expires April 27, 2009 [Page 13]
Internet-Draft Neighbor Discovery for 6LoWPAN October 2008
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Host Interface Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option(s)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Router Registration/Confirmation message format (16 octets)
IP Fields:
Source Address: A Link-local IPv6 address. This address may be
an optimistic address.
Destination Address: A link-local IPv6 address of an Edge Router
or Edge Router Relay.
Hop Limit: 255
ICMP Fields:
Type: TBD by IANA.
Code: 0
Checksum: The ICMP checksum.
TID: A unique Transaction ID assigned by the host to match
replies.
Reserved: This field is unused. It MUST be initialized to zero
by the sender and MUST be ignored by the receiver.
Host Interface Identifier: A globally unique identifier for the
requesting host's interface.
Possible Options:
Shelby, et al. Expires April 27, 2009 [Page 14]
Internet-Draft Neighbor Discovery for 6LoWPAN October 2008
Identity Request Option
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.2. Relay RR/RC message
The Relay Router Registration/Confirmation message is used between
Routers and Edge Routers in order to relay the content of RR/RC
messages from nodes multiple IP hops from the ER. When a Host sends
an RR message to a Router, the Router copies the RR message TID, HII
and options to this Relay RR message format. When the ER Relay is
sending a confirmation message back to the Host, it is converted to a
standard RC message format.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Host Interface Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Host Link-Local Address Interface Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. 6LoWPAN ND Options (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Relay RR/RC message format (24 octets)
IP Fields:
Source Address: The IPv6 address of the Edge Router or Router
that is originating this message.
Destination Address: The IPv6 address of the Edge Router or
Router that is consuming this message.
Shelby, et al. Expires April 27, 2009 [Page 15]
Internet-Draft Neighbor Discovery for 6LoWPAN October 2008
Hop Limit: 255
ICMP Fields:
Type: TBD by IANA.
Code: 0
Checksum: The ICMP checksum.
TID: A unique Transaction ID assigned by the requesting host to
match replies.
Reserved: This field is unused. It MUST be initialized to zero
by the sender and MUST be ignored by the receiver.
Host Interface Identifier: A globally unique identifier for the
requesting host's interface.
Host Link-Local Address Interface Identifier: The interface
identifier of the requesting hosts's link-local address used by
the relay to communicate replies to the requesting client.
Possible Options:
Identity Request Option
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. Router Advertisement message
The RA message for 6LoWPAN is based on the [RFC4861] RA message with
the addition of a new flag "E". In addition new options are
identified.
Shelby, et al. Expires April 27, 2009 [Page 16]
Internet-Draft Neighbor Discovery for 6LoWPAN October 2008
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|S|E| rsv | Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Router Advertisement Message Format (16 octets)
IP Fields:
Source Address: MUST be the link-local address assigned to the
interface from which this message is sent.
Destination Address: Typically the Source Address of an invoking
Router Solicitation or the all-nodes multicast address.
Hop Limit: 255
ICMP Fields:
Type: 134
Code: 0
Checksum: The ICMP checksum.
Cur Hop Limit: As specified in [RFC4861].
M: As specified in [RFC4861] with the exception that managed mode
here refers to the address assignment mechanism specified in
this paper, not DHCPv6 as in [RFC4861].
O: As specified in [RFC4861].
S: 1-bit "Router Solicitation" flag. When set, it indicates that
the router is requesting neighboring routers to generate Router
Advertisement messages.
Shelby, et al. Expires April 27, 2009 [Page 17]
Internet-Draft Neighbor Discovery for 6LoWPAN October 2008
E: 1-bit "Edge Router" flag. When set, it indicates that the
router is an Edge Router.
Reserved: A 3-bit unused field. It MUST be initialized to zero
by the sender and MUST be ignored by the receiver.
Router Lifetime: As specified in [RFC4861].
Reachable Time: As specified in [RFC4861].
Possible Options:
6LoWPAN Prefix Information Option
Multihop Information Option
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.4. Neighbor Solicitation message
NS message employed between ERs on the backbone link when ND proxy is
used. A unique identifier needs to be added to the message as an
option to uniquely identify a host's interface. The NS message is
used in this document is as in [RFC4861] with the addition of the
Host Interface Identifier Option.
4.5. 6LoWPAN ND Message Options
This section defines the common ND for 6LoWPAN message options.
4.5.1. Identity Request 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 |G|P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option(s)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Identity Request Option format
Shelby, et al. Expires April 27, 2009 [Page 18]
Internet-Draft Neighbor Discovery for 6LoWPAN October 2008
Type: TBD.
Length: 8-bit unsigned integer. The length of the option (including
the type and length fields) in units of 8 octets.
G: 1-bit Global Address Request flag. Set to indicate that the
client is requesting global addresses.
P: 1-bit Primary flag. Set to indicate that the router is primary
and MAY proxy for the node if Proxy ND is used on the backbone
link. If the flag is not set then the router MUST not proxy for
the node.
Reserved: This field is unused. It MUST be initialized to zero by
the sender and MUST be ignored by the receiver.
Lifetime: 32-bit unsigned integer. The amout of time in units of
seconds remaining before the binding MUST be considered expired.
A value of zero indicates that the Binding Cache entry for the
registered node MUST be deleted.
Possible Options:
Address Option
6LoWPAN Address Option
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.5.2. Identity Reply 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 |G|P|X| rsv | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option(s)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Identity Reply Option format
Shelby, et al. Expires April 27, 2009 [Page 19]
Internet-Draft Neighbor Discovery for 6LoWPAN October 2008
Type: TBD.
Length: 8-bit unsigned integer. The length of the option (including
the type and length fields) in units of 8 octets.
G: 1-bit Global Address Request flag. Set to indicate that the
client is requesting global addresses.
P: 1-bit Primary flag. Set to indicate that the router is primary
and MAY proxy for the node if Proxy ND is used on the backbone
link. If the flag is not set then the router MUST not proxy for
the node.
X: 1-bit Proxy Flag. Indicates that the router actually proxies for
all of the addresses in the options field that are being assigned
to the node. This can only happen if the P flag is set as well.
Status: 8-bit unsigned integer. Values TBD. 0 means unqualified
success. Any value below 128 is a positive status that means that
the binding was created or is being created optimistically.
Lifetime: 32-bit unsigned integer. The amout of time in units of
seconds remaining before the binding MUST be considered expired.
A value of zero indicates that the Binding Cache entry for the
registered node MUST be deleted.
Possible Options:
Address Option
6LoWPAN Address Option
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.
Shelby, et al. Expires April 27, 2009 [Page 20]
Internet-Draft Neighbor Discovery for 6LoWPAN October 2008
4.5.3. Address 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 | P | S |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. IPv6 Address (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Address Option format
Type: TBD.
Length: 8-bit unsigned integer. The length of the option (including
the type and length fields) in units of 8 octets.
P: 8-bit unsigned integer. Identifies prefix compression in use, if
any.
0: Prefix is carried inline.
1: Prefix compressed and link-local (fe80:/10) is assumed.
2-255: Reserved.
S: 8-bit unsigned integer. Identifies suffix compression in use, if
any.
0: Suffix carried inline.
1: Suffix compressed and assumes the same value as the Host
Interface Identifier field in the RR/RC message header.
2: Suffix compressed and is derived from the 6LoWPAN PAN ID/SHORT
address option as defined in RFC 4944.
3-255: Reserved.
D: 1-bit Duplicate flag. When set, indicates that duplicates are
allowed for this address (to support anycast).
Shelby, et al. Expires April 27, 2009 [Page 21]
Internet-Draft Neighbor Discovery for 6LoWPAN October 2008
Reserved: This field is unused. It MUST be initialized to zero by
the sender and MUST be ignored by the receiver.
IPv6 Address:
4.5.4. 6LoWPAN Address 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PAN ID | Short Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: 6LoWPAN Address Option format
Type: TBD.
Length: 1
Reserved: This field is unused. It MUST be initialized to zero by
the sender and MUST be ignored by the receiver.
PAN ID: PAN ID of the client node. When included in a reply, the
PAN ID MUST be echoed from the request.
Short Address: Short address of the client node. A value of 0xffff
indicates an unspecified short address.
4.5.5. 6LoWPAN Prefix Information Option
Note: Context Identifier field to be added in rsv for use with HC.
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 | Prefix Length |L|A| CID | r |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Prefix .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: 6LoWPAN Prefix Information Option format
Shelby, et al. Expires April 27, 2009 [Page 22]
Internet-Draft Neighbor Discovery for 6LoWPAN October 2008
Type: TBD.
Length: 8-bit unsigned integer. The length of the option (including
the type and length fields) in units of 8 octets.
Prefix Length: 8-bit unsigned integer. The number of leading bits
in the Prefix that are valid. The value ranges from 0 to 128.
The prefix length field provides necessary information for on-link
determination (when combined with the L flag in the prefix
information option). It also assists with address
autoconfiguration as specified in [ADDRCONF], for which there may
be more restrictions on the prefix length.
L: 1-bit on-link flag. When set, indicates that this prefix can be
used for on-link determination. When not set the advertisement
makes no statement about on-link or off-link properties of the
prefix. In other words, if the L flag is not set a host MUST NOT
conclude that an address derived from the prefix is off-link.
That is, it MUST NOT update a previous indication that the address
is on-link.
A: 1-bit autonomous address-configuration flag. When set indicates
that this prefix can be used for stateless address configuration
as specified in [ADDRCONF].
CID: 4-bit Context Identifier for this prefix information. This is
used as defined in [draft-ietf-6lowpan-hc-01].
Prefix: IPv6 Prefix.
4.5.6. Multihop 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 | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Multihop Information Option
Type: TBD.
Length: 1
Shelby, et al. Expires April 27, 2009 [Page 23]
Internet-Draft Neighbor Discovery for 6LoWPAN October 2008
Sequence Number: 16-bit signed integer. Indicates the freshness of
the information advertised by the RA.
V: 1-bit flag. Indicates if the sequence number is valid and the
router is advertising information obtained from another router.
Reserved: This field is unused. It MUST be initialized to zero by
the sender and MUST be ignored by the receiver.
5. LoWPAN Subnet
In a LoWPAN, a link can be a very instable set of nodes, for instance
the set of nodes that can receive a packet that is broadcast over the
air. Such a set may vary from one packet to the next as the node
moves or as the radio propagation conditions change. As a result, a
link does not define the proper set of nodes to perform ND operations
such as Duplicate Address Detection and Neighbor lookup. So in ND
for 6LoWPAN, those operations are performed over a subnet. A subnet
is a collection of LoWPAN links interconnected by routers that may
share one or more global prefixes. In particular, DAD is performed
over a subnet for all types of addresses, inclucing link local.
In the backhaul model, an Edge Router and all the LoWPAN Nodes
registered to that Edge Router form a subnet. In that model, the
Edge Router serves all the prefixes that are defined on its subnet
and can be connected to an IP routed infrastructure.
In the backbone model, a Backbone Link federates multiple LoWPANs
into a single IP subnet. Each LoWPAN is a collection of links
anchored at an Edge Router. The Edge Routers interconnect the
LoWPANs over the Backbone Link. A node can move freely from a LoWPAN
anchored at an Edge Router to a LoWPAN anchored at another Edge
Router in the same subnet and conserve its link local and any other
IPv6 address it has formed.
6. LoWPAN Node Specification
Instead of relying on multicast ND messages for DAD and neighbor
address resolution, LoWPAN Nodes make use of an Edge Router in the
LoWPAN which keeps a whiteboard of all bound addresses from nodes
attached to the same ER. In addition, ERs may perform ND proxy on a
backbone link, creating an extended LoWPAN sharing the same subnet
prefix. ND proxy allows nodes to change their point of attachment
without changing its IPv6 addresses. This specification simplifies
address resolution compared to standard IPv6 ND. Global address
assignment is also specified as part of the binding process, avoiding
Shelby, et al. Expires April 27, 2009 [Page 24]
Internet-Draft Neighbor Discovery for 6LoWPAN October 2008
the need for additional mechanisms such as DHCPv6.
6.1. Forming addresses
All nodes are required to autoconfigure at least one address, a link-
local address that is derived from the IEEE 64-bit extended MAC
address that is globally unique to the device as in [RFC4944]. Link-
local addresses are described in section 2.5.6 of [RFC4291].
Appendix A of that specification explains how the node builds an
interface-ID based on the IEEE 64-bit extended MAC address by
inverting the "u" (universal/local) bit.
As a result, knowledge of the 64-bit address of another node on the
same extended LoWPAN is enough to derive its link-local address and
reach it over IP. Another consequence is that the link local address
is presumably unique on the Extended LoWPAN, which enables the use of
Optimistic Duplicate Address Detection (oDAD) [RFC4429] over the
Transit Link and the LoWPAN. The address SHOULD be created as
optimistic to enable its use in the binding process with the Edge
Router.
Nodes MAY learn the address of Edge Routers or Routers using
traditional means such as L2 configuration or Router Advertisement
messages. This specification also introduces a new anycast address
6LOWPAN_ER that the node can use to reach any Edge Router or Router
on the link. This specification tolerates movement within the LoWPAN
so the node does not have to stick with a given ER and MAY keep using
the 6LOWPAN_ER anycast address for all its registrations.
The node might also form Unique Local and Global Unicast addresses,
for instance if it needs to be reachable from the outside of the
Extended LoWPAN. If a Global Prefix is available from an RA ('A'
flag is set), then a Global Unicast address can be derived from the
IEEE-64-bit extended MAC address using SAA. This address is marked
optimistic until confirmed by the ER.
This specification includes a method for requesting a unique assigned
Global Unicast address from the Edge Router by setting the 'G' flag
of the Identity Request Option during registration. This is useful
in the case of e.g. short addresses and avoids the need for a
separate mechanism such as DHCPv6.
To simplify address resolution it is assumed that LoWPAN nodes are
assigned addresses in a homogeneous so that the unicast IPv6
addresses IID resolve directly to a corresponding link-layer address.
Thus avoiding address resolution when possible.
Shelby, et al. Expires April 27, 2009 [Page 25]
Internet-Draft Neighbor Discovery for 6LoWPAN October 2008
6.2. Registration process
The binding process is very similar to that of a MIPv6 mobile node,
though the messages used are new Neighbor Discovery ICMP messages. A
LoWPAN Node address is tentative or optimistic as long as the binding
is not confirmed by the Edge Router.
The LoWPAN node uses unicast Router Registrations to perform the
binding. The destination Address is that of an on-link Edge Router
or Router or the 6LOWPAN_ER anycast address. The source address is
the link local address of the node. A unique Host Interface
Indentifier is included in the Router Registration so the binding can
be identified throughout the subnet. This is usually the EUI-64
identifier of the sending node. The RR message includes an Identity
Request Option. If the node would like to be assigned a Global
Unique address the Global Flag 'G' is set. For each address to be
bound an Address Option is included in the Identity Request Option.
Thus the message is structured as follows.
ICMP (Router Registration (Identity Request Option (Address
Options)))
The acknowledgment to a Router Registration is a unicast Router
Confirmation message that contains the status of the binding. The
source of the packet is the link-local address of the Edge Router or
Router. The destination address is the link local address of the
node. An Address Option for each confirmed or assigned address is
included in the Identity Reply Option. Upon successful completion in
the Router Confirmation message, the LoWPAN Node sets the address
from optimistic or tentative to preferred.
The 'X' flag in the Router Confirmation Indentity Reply Option
indicates that the Edge Router has completed DAD and now owns the
Binding Address over the Transit Link.
This specification also introduces the concept of a secondary
binding. For redundancy, a node might place a secondary binding with
one or more other Edge Routers over a same or different LoWPANs. The
'P' flag in the Router Registration Indentity Request Option
indicates whether the binding is primary.
ER bindings have a timeout associated with them, therefore nodes must
periodically send a new Router Registration message to renew the
bindings. If a node no longer receives RCs from any ER in the
current subnet (with the same network prefix), the registration
process begins from the beginning.
Shelby, et al. Expires April 27, 2009 [Page 26]
Internet-Draft Neighbor Discovery for 6LoWPAN October 2008
6.3. Next-hop determination
Next-hop determination is performed as in Section 5.2 of [RFC4861]
with the following exceptions. Global and Local prefix are assumed
to be off-link as the LoWPAN subnet with that prefix may be much
larger than the link in route over topologies, unless the destination
address exists in the neighbor cache. Link-layer information should
be used to maintain the neighbor cahce whenever possible rather than
using ND traffic. The ERs and Routers used for registration are kept
in the Default Router List. Multihop addresses resolve to a
broadcast as specified in [RFC4944].
6.4. Address lookup
A LoWPAN node does not use multicast for its Neighbor Solicitation as
prescribed by the ND protocol [RFC4861] and oDAD [RFC4429]. When
lookup is necessary, all NS messages are sent in unicast to the Edge
Router, that answers in unicast as well. The message is a standard
Neighbor Solicitation but for the destination is set to the Edge
Router address or the well known 6LOWPAN_ER anycast address as
opposed to the solicited-node multicast address for the destination
address. A LoWPAN Node SHOULD retain a small queue for packets to
neighbors awaiting to be delivered while address lookup is being
performed. The size of the queue should be suitable to the available
RAM of the node, and is not required to be a minimum of one buffer
per neighbor as in [RFC4861].
The Target link-layer address in the response is either that of the
destination if a short cut is possible over the LoWPAN, or that of
the Edge Router if the destination is reachable over the Transit
Link, in which case the Edge Router will terminate 6LoWPAN and relay
the packet.
A LoWPAN Node does not need to join the solicited-node multicast
address for its own addresses and SHOULD NOT have to answer a
multicast Neighbor Solicitation. It MAY be configured to answer a
unicast NS but that is not required by this specification.
Care must be used with the 6LOWPAN_ER and other anycast addresses, as
anycast resolution is normally performed with a multicast NS/NA
exchange. As nodes are not required to answer NS messages, the next
hop determination process SHOULD map the anycast address to the link
layer address of a neighbor using available L2 or other ND
information.
Shelby, et al. Expires April 27, 2009 [Page 27]
Internet-Draft Neighbor Discovery for 6LoWPAN October 2008
7. LoWPAN Router Specification
LoWPAN Routers are used in a route-over configuration where the
network is composed of overlapping link-local scopes. As a result,
we must extend ND as specified in [RFC4861] to operate over an entire
subnet, specifically the subnet controlled by Edge Routers, rather
than a single IP link.
Network configuration parameters carried in Router Advertisements
originate at Edge Routers and must disseminate to all Routers and
Hosts within the LoWPAN. The Multihop Information option is used to
support information dissemination from one or more Edge Routers to
all other nodes in the LoWPAN. The option includes a "V" flag that
indicates that the information contained in the Router Advertisement
is valid. The option also includes a sequence number to ensure that
all nodes converge on the same settings.
Because Router Registration/Confirmation exchanges only occur over
link-local scope, such messages must be relayed between Hosts and
Edge Routers when separated by multiple IP hops. Every LoWPAN Router
MUST also serve as a Relay to ensure that any neighboring node can
successfully participate in the LoWPAN.
7.1. Router Configuration Variables
A router MUST allow the following conceptual variables to be
configured by system management. The specific variable names are
used for demonstration purposes only, and an implementation is not
required to have them, so long as its external behavior is consistent
with that described in this document. The meaning of these variables
are as defined in Section 6.2.1 of [RFC 4861]. Default values are
specified to simplify configuration in common cases.
- IsRouter
- MaxRtrAdvInterval
- MinRtrAdvInterval
- AdvDefaultLifetime
A router MUST allow the following conceptual variables to be
configured by information received in Router Advertisement messages.
The specific variable names are used for demonstration purposes only,
and an implementation is not required to have them, so long as its
external behavior is consistent with that described in this document.
The meaning of these variables are as defined in Section 6.2.1 of
[RFC 4861]. However, default values are not relevant as a router
Shelby, et al. Expires April 27, 2009 [Page 28]
Internet-Draft Neighbor Discovery for 6LoWPAN October 2008
should not be advertising such values until they have been received
from other neighboring routers.
- AdvManagedFlag
- AdvOtherConfigFlag
- AdvReachableTime
- AdvRetransTimer
- AdvCurHopLimit
- AdvPrefixList
7.2. Becoming an Advertising Interface
An interface may become an advertising interace as specified in
Section 6.2.2 of [RFC 4861].
A LoWPAN Router's interface MAY become an advertising interface
before all of its router variables have been initializes. The router
MUST learn these variables (e.g. AdvCurHopLimit, AdvReachableTime,
prefix information, etc.) from neighboring routers. While the
variables are not initialized, the router MAY send Router
Advertisement with the "Solicit" flag set to solicit Router
Advertisements from neighboring routers. However, the router MUST
set the Router Lifetime field to zero while one or more of its
variables are uninitialized.
7.3. Router Advertisement Message Content
A router sends periodic as well as solicited Router Advertisements
out its advertising interface. Outgoing Router Advertisements are
filled with the following values constistent with the message format
given in [ramess].
- In the Router Lifetime field: if the router has a default route,
the interface's configured AdvDefaultLifetime. If the router does
not have a default route, zero.
- In the M and O flags: the current value of AdvManagedFlag and
AdvOtherConfigFlag, respectively.
- The E flag is not set.
- In the S flag: One if the router is soliciting Router
Advertisements from neighboring nodes. Zero if the router is not
Shelby, et al. Expires April 27, 2009 [Page 29]
Internet-Draft Neighbor Discovery for 6LoWPAN October 2008
soliciting Router Advertisements from neighboring nodes.
- In the Cur Hop Limit field: the current value of CurHopLimit.
- In the Reachable Time field: the current value of
AdvReachableTime.
- In the Retrans Timer field: the current value of
AdvRetransTimer.
- In the options:
- Multihop Information option: to indicate if the information
contained in the Router Advertisement is valid and, if so, the
freshness of the information contained in the Router
Advertisement message. The option fields are set as follows:
- In the "valid" flag: the current value of
AdvInformationValid.
- In the Sequence Number field: the current value of
AdvInformationSequence.
- Prefix Information options: one Prefix Information option for
each prefix listed in AdvPrefixList with the option fields set
from the information in the AdvPrefxList entry as follows:
- In the "on-link" flag: the entry's AdvOnLinkFlag.
- In the "Autonomous address configuration" flag: the
entry's AdvAutonomousFlag.
- In the Valid Lifetime field: the entry's AdvValidLifetime.
7.4. Sending Unsolicited Router Advertisements
As specified in Section 6.2.4 of [RFC 4861].
7.5. Ceasing To Be an Advertising Interface
As specified in Section 6.2.5 of [RFC 4861].
7.6. Processing Router Solicitations
As specified in Section 6.2.6 of [RFC 4861].
Shelby, et al. Expires April 27, 2009 [Page 30]
Internet-Draft Neighbor Discovery for 6LoWPAN October 2008
7.7. Router Advertisement Consistency
TBD
7.8. Relaying a Router Registration Message
When a router receives a Router Registration message from a LoWPAN
Node, the router copies the information from the Router Registration
message into the Relay Router Registration message. The Host Link-
Local Address Interface Identifier is the only differing field from
the Router Registration message, and the router copies the value from
the IID of the Router Registration's IP Source Address.
By default, the router relays Router Registration messages to the
6LOWPAN_ER anycast address. However, the router MAY be configured to
use a list of destination addresses, which MAY include unicast
addresses, the 6LOWPAN_ER anycast address, or other addresses
selected by the network administrator.
7.9. Relaying a Router Confirmation Message
When the router receives a Relay Router Confirmation message from an
Edge Router, the router copies the information from the Relay message
into a Router Confirmation message. The Host Link-Local Address
Interface Identifier is used to form the IPv6 Destination Address for
the Router Confirmation message. The Hop Limit of the Router
Confirmation message is set to 255.
8. LoWPAN Edge Router Specification
Edge Routers are introduced to scale the Neighbor Discovery
Operations by reducing the amount of costly multicast ND messages
over a subnet that may cover hundreds or thousands of nodes.
Instead of multicasting ND messages, a LoWPAN Node performs unicast
exchanges to its Edge Router to claim and lookup addresses using
unicast and anycast addresses, and the Edge Router proxies the ND
requests over the Backbone Link when necessary.
This specification documents the extensions to IPv6 Neighbor
Discovery that enables a LoWPAN Node to claim and lookup addresses
using a Edge Router as an intermediate proxy. The draft also
documents the use of EUI-64 based link-local addresses and the way
they are claimed by the Edge Routers over the Backbone link.
For the purpose of Neighbor Discovery proxying, this specification
documents the LoWPAN registration table, a conceptual data structure
Shelby, et al. Expires April 27, 2009 [Page 31]
Internet-Draft Neighbor Discovery for 6LoWPAN October 2008
that is similar to the MIPv6 binding cache.
Another function of the Edge Router is to perform 6LowPAN compression
and uncompression between the LoWPAN and the Backbone Link and ensure
MTU compatibility. Packets flow uncompressed over the Backbone Link
and are routed normally towards a Gateway or an Application sitting
on the Backbone link or on a different link that is reachable via IP.
8.1. Registration process
Upon a new registration for a link-local address based on an IEEE 64-
bit extended MAC address, the Edge Router MAY use Optimistic DAD on
the Transit Link. A positive acknowledgement can be sent to the
6LoWPAN node right away if oDAD is used on the Transit Link.
A LoWPAN Node should be able to join a different Edge Router at any
time without the complexities of terminating a current registration
and renumber. To enable this, the ND proxy operation upon a Router
Registration/Confirmation flow wins the address ownership over a ND
proxy operation that is done asynchronously, on behalf of the same
LoWPAN Node, upon a prior registration. So an Edge Router that would
happen to have a binding for that same address for the same LoWPAN
Node identified by its EUI-64 address will yield and deprecate its
binding.
A new option in NS/NA messages that carries the node EUI-64 address
enables to differentiate an address collision from a movement of a
node from one Edge Router to the next. Upon a registration flow, a
node doing DAD SHOULD ignore NA without the the override (O) bit, and
set the override (O) bit in its own NA messages. Asynchronously to
the registration, a node SHOULD NOT set the override (O) bit in its
NA messages and should yield to an NA message with the override (O)
bit set.
So the Edge Router operation on the transit link is similar to that
of a Home Agent as specified in "Mobility Support for IPv6" [RFC3775]
yet different. In particular, the Neighbor Advertisement message is
used as specified in section "10.4.1. Intercepting Packets for a
Mobile Node" with the exception that the override (O) bit is not set,
indicating that this Edge Router acts as a proxy for the LoWPAN and
will yield should another Edge Router claim that address on the
Backbone Link.
This specification also introduces the concept of secondary binding.
Upon a secondary binding, the Edge Router will not announce or defend
the address on the backbone link, but will be able to forward packets
to the node over its LoWPAN interface.
Shelby, et al. Expires April 27, 2009 [Page 32]
Internet-Draft Neighbor Discovery for 6LoWPAN October 2008
The Edge Router responds to a Router Registration with a Router
Confirmation. The source address is a link local address of the
router and the destination is the optimistic address of the node.
The ER responds to Relay RR messages with a Relay RC message, where
the destination address is the address of the Router which sent the
Relay RR message.
If the Edge Router is primary for a registration as indicated by the
'P' flag in the Identity Request Option and it is connected to a
Backbone, then it SHOULD perform proxy ND operations on the backbone
and indicate so in the Router Confirmation message using the 'X' flag
of the Identity Reply Option. In particular the Egde Router SHOULD
reject the registration if DAD fails on the backbone. When oDAD is
used over the backbone the Edge Router MAY issue the Router
Confirmation right away with a positive code, but if a collision is
finally detected, it cancels the registration with an asynchronous
Router Confirmation and a negative completion code on the same TID.
8.2. Exposing the Edge Router
The Backbone link is used as reference for Neighbor Discovery
operations. When an Edge Router does not have an entry in its
registration table for a target node, it looks it up over the
backbone using ND operation in place for that medium. Edge Routers
also perform ND proxying for the LoWPAN Nodes that are proactively
registered to them. That way, a lookup over the backbone is not
propagated over the LoWPANs, but answered by the proxy that has the
registration for the target, if any.
To enable proxying over the backbone Link, an Edge Router must join
the solicited-node multicast address on that link for all the
registered addresses of the nodes in its LoWPANs. The Edge Router
answers the Neighbor Solicitation with a Neighbor Advertisement that
indicates its own link-layer address in the Target link-layer address
option.
An Edge Router expects and answers unicast Neighbor Solicitations for
all nodes in its LoWPANs. It answers as a proxy for the real target.
The target link-layer address in the response is either that of the
destination if a short cut is possible over the LoWPAN, or that of
the Backbone Router if the destination is reachable over the Transit
Link, in which case the Backbone Router will terminate 6LoWPAN and
relay the packet.
The Edge Router forms a link-local address in exactly the same way as
any other node on the LoWPAN. It uses the same link local address
for the Backbone Link and for all the associated LoWPAN(s) connected
to that Edge Router.
Shelby, et al. Expires April 27, 2009 [Page 33]
Internet-Draft Neighbor Discovery for 6LoWPAN October 2008
The Edge Router configures the well known 6LOWPAN_ER anycast address
on the LoWPAN interfaces where it serves as Edge Router. Note that
the Edge Router will accept registration packets with a hop limit
that is lower than 255 on that specific address.
The Edge Router announces itself using Router Advertisement (RA)
messages that are broadcasted periodically over the LOWPAN and the
backbone link.
A new (E) bit in the RA indicates the Edge Router capability. In
this way a node can learn the PAN-ID and the 16-bit short address for
the Edge Router if it was not already acquired from another process
that is not covered by this specification.
The Edge Router MAY also announce any prefix that is configured on
the transit link, and serve as the default gateway for any node on
the Transit Link or on the attached LoWPANs.
The transit link Maximum Transmission Unit serves as base for Path
MTU discovery and Transport layer Maximum Segment Size negotiation
(see section 8.3 of [RFC2460]) for all nodes in the LoWPANs. To
achieve this, the Edge Router announces the MTU of the transit link
over the LoWPAN using the MTU option in the RA message as prescribed
in section "4.6.4. MTU" of IPv6 Neighbor Discovery [RFC4861].
LoWPAN Nodes SHOULD form IPv6 packets that are smaller than that MTU.
As a result, those packets should not require any fragmentation over
the transit link though they might be intranet-fragmented over the
LoWPAN itself as prescribed by [RFC4944]).
More information on the MTU issue with regard to ND-proxying can be
found in Neighbor Discovery Proxies [RFC4389] and
[I-D.van-beijnum-multi-mtu].
8.3. Forwarding packets
Upon receiving packets on one of its LoWPAN interfaces, the Edge
Router checks whether it has a binding for the source address. If it
does, then the Edge Router can forward the packet to another LoWPAN
Node or over the Backbone link. Otherwise, the Edge Router MUST
discard the packet. If the packet is to be transmitted over the
Transit link, then the 6LoWPAN sublayer is terminated and the full
IPv6 packet is reassembled and expanded.
When forwarding a packet from the Backbone Link towards a LoWPAN
interface, the Edge Router performs the 6LoWPAN sublayer operations
of compression and fragmentation and passes the packet to the lower
layer for transmission.
Shelby, et al. Expires April 27, 2009 [Page 34]
Internet-Draft Neighbor Discovery for 6LoWPAN October 2008
8.4. Fault tolerance
TBD : to be provided in the next revision.
9. Security Considerations
This specification expects that the link layer is sufficiently
protected, either by means of physical or IP security for the
backbone link or MAC sublayer cryptography. In particular, it is
expected that the LoWPAN MAC provides secure unicast to/from Routers
and secure broadcast from the Routers in a way that prevents
tempering with or replaying the RA messages. However, any future
6LoWPAN security protocol that applies to Neighbor Discovery for
6LoWPAN protocol, is out of scope of this document.
10. IANA Considerations
This specification requires four new ICMP types for binding
registration. The is also a need for a new link local anycast
address, 6LOWPAN_ER for the Edge Routers and Routers; used as a
functional address.
11. Acknowledgments
The authors thank Carsten Bormann, Geoff Mulligan and Julien Abeille
for useful discussions and comments that have helped shaped and
improve this document.
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
Shelby, et al. Expires April 27, 2009 [Page 35]
Internet-Draft Neighbor Discovery for 6LoWPAN October 2008
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD)
for IPv6", RFC 4429, April 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.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, 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.
12.2. Informative References
[I-D.van-beijnum-multi-mtu]
Beijnum, I., "Extensions for Multi-MTU Subnets",
draft-van-beijnum-multi-mtu-02 (work in progress),
February 2008.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, January 2005.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
Proxies (ND Proxy)", RFC 4389, April 2006.
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals",
RFC 4919, August 2007.
Shelby, et al. Expires April 27, 2009 [Page 36]
Internet-Draft Neighbor Discovery for 6LoWPAN October 2008
Authors' Addresses
Zach Shelby (editor)
Sensinode
Kidekuja 2
Vuokatti 88600
FINLAND
Phone: +358407796297
Email: zach@sensinode.com
Pascal Thubert
Cisco Systems
Village d'Entreprises Green Side
400, Avenue de Roumanille
Batiment T3
Biot - Sophia Antipolis 06410
FRANCE
Phone: +33 4 97 23 26 34
Email: pthubert@cisco.com
Jonathan W. Hui
Arch Rock Corporation
501 2nd St. Ste. 410
San Francisco, California 94107
USA
Phone: +415 692 0828
Email: jhui@archrock.com
Samita Chakrabarti
IP Infusion
1188 Arquest Street
Sunnyvale, California
USA
Phone:
Email: samitac@ipinfusion.com
Shelby, et al. Expires April 27, 2009 [Page 37]
Internet-Draft Neighbor Discovery for 6LoWPAN October 2008
Erik Nordmark
Sun Microsystems, Inc.
17 Network Circle
Menlo Park, California 94025
USA
Phone:
Email: Erik.Nordmark@Sun.COM
Shelby, et al. Expires April 27, 2009 [Page 38]
Internet-Draft Neighbor Discovery for 6LoWPAN October 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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Shelby, et al. Expires April 27, 2009 [Page 39]