6lowpan Working Group Z. Shelby, Ed.
Internet-Draft Sensinode
Updates: 4944 (if approved) P. Thubert
Intended status: Standards Track Cisco
Expires: April 29, 2010 J. Hui
Arch Rock
S. Chakrabarti
IP Infusion
C. Bormann
Universitaet Bremen TZI
E. Nordmark
Sun
October 26, 2009
6LoWPAN Neighbor Discovery
draft-ietf-6lowpan-nd-07
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 29, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
Shelby, et al. Expires April 29, 2010 [Page 1]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document specifies an extension of Neighbor Discovery for
6LoWPAN. The 6LoWPAN format allows IPv6 to be used over energy and
bandwidth constrained wireless networks often making use of multihop
topologies. However, the use of classic IPv6 Neighbor Discovery with
6LoWPAN has several problems. Classic Neighbor Discovery was not
designed for non-transitive wireless links, and the traditional IPv6
link concept and heavy use of multicast makes it unpractical. This
document specifies an ND mechanism both sufficient for minimal for
LoWPAN operation which optimizes Neighbor Discovery.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Goals, Assumptions, and Guesses . . . . . . . . . . . . . 5
1.2. Why not classic IPv6 ND? . . . . . . . . . . . . . . . . . 6
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. 6LoWPAN Terminology . . . . . . . . . . . . . . . . . . . 7
2.2. ND Terminology . . . . . . . . . . . . . . . . . . . . . . 10
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12
3.1. Topology . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 14
3.4. Basic operation . . . . . . . . . . . . . . . . . . . . . 16
3.5. Extended LoWPAN operation . . . . . . . . . . . . . . . . 16
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 17
4.1. Node Registration/Confirmation Message . . . . . . . . . . 17
4.2. Router Solicitation Message . . . . . . . . . . . . . . . 21
4.3. Router Advertisement Message . . . . . . . . . . . . . . . 21
4.4. NS/NA Messages (Extended LoWPAN only) . . . . . . . . . . 22
4.5. Message Options . . . . . . . . . . . . . . . . . . . . . 22
4.5.1. 6LoWPAN Address Option . . . . . . . . . . . . . . . . 22
4.5.2. 6LoWPAN Information Option . . . . . . . . . . . . . . 24
4.5.3. 6LoWPAN Summary Option . . . . . . . . . . . . . . . . 26
4.5.4. Owner Interface Identifier Option . . . . . . . . . . 27
5. Protocol Specification . . . . . . . . . . . . . . . . . . . . 27
5.1. Interface initialization . . . . . . . . . . . . . . . . . 28
5.2. Node Registration . . . . . . . . . . . . . . . . . . . . 28
5.2.1. Processing a Node Registration Message . . . . . . . . 30
5.2.2. Relaying a Node Confirmation Message . . . . . . . . . 31
5.3. Duplicate Address Detection . . . . . . . . . . . . . . . 31
5.4. Next-hop Determination . . . . . . . . . . . . . . . . . . 31
Shelby, et al. Expires April 29, 2010 [Page 2]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
5.5. Address Resolution . . . . . . . . . . . . . . . . . . . . 32
5.6. Unreachability Detection . . . . . . . . . . . . . . . . . 32
5.7. Context Dissemination . . . . . . . . . . . . . . . . . . 32
6. LoWPAN Node Specification . . . . . . . . . . . . . . . . . . 33
6.1. Conceptual structures . . . . . . . . . . . . . . . . . . 33
6.2. Conceptual variables . . . . . . . . . . . . . . . . . . . 34
7. LoWPAN Router Specification . . . . . . . . . . . . . . . . . 35
7.1. Router Configuration Variables . . . . . . . . . . . . . . 35
7.2. Becoming an Advertising Interface . . . . . . . . . . . . 35
7.3. Router Advertisement Message Content . . . . . . . . . . . 35
7.4. Sending Unsolicited Router Advertisements . . . . . . . . 36
7.5. Ceasing To Be an Advertising Interface . . . . . . . . . . 36
7.6. Processing Router Solicitations . . . . . . . . . . . . . 36
7.7. Binding Table . . . . . . . . . . . . . . . . . . . . . . 37
8. LoWPAN Edge Router Specification . . . . . . . . . . . . . . . 37
8.1. The Whiteboard . . . . . . . . . . . . . . . . . . . . . . 38
8.2. Simple LoWPAN . . . . . . . . . . . . . . . . . . . . . . 39
8.3. Extended LoWPAN . . . . . . . . . . . . . . . . . . . . . 39
8.4. Ad-hoc LoWPAN . . . . . . . . . . . . . . . . . . . . . . 40
8.5. Registration process . . . . . . . . . . . . . . . . . . . 40
8.6. Forwarding packets between a LoWPAN and an IPv6
infrastructure . . . . . . . . . . . . . . . . . . . . . . 42
8.7. Address collision detection and resolution . . . . . . . . 43
8.8. Duplicate OII detection . . . . . . . . . . . . . . . . . 45
8.9. Fault tolerance . . . . . . . . . . . . . . . . . . . . . 47
9. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 48
10. Use of 6LoWPAN-ND under RFC4861-only stacks . . . . . . . . . 48
11. Message Examples . . . . . . . . . . . . . . . . . . . . . . . 49
11.1. Basic NR/NC message exchange . . . . . . . . . . . . . . . 49
11.2. Relaying an NR message . . . . . . . . . . . . . . . . . . 51
11.3. Router advertisement . . . . . . . . . . . . . . . . . . . 52
12. Security Considerations . . . . . . . . . . . . . . . . . . . 53
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54
15. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 54
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58
16.1. Normative References . . . . . . . . . . . . . . . . . . . 58
16.2. Informative References . . . . . . . . . . . . . . . . . . 58
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 59
Shelby, et al. Expires April 29, 2010 [Page 3]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
1. Introduction
The IPv6 over IEEE 802.15.4 [RFC4944] document has specified how to
carry IPv6 packets over IEEE 802.15.4 and similar networks (6LoWPANs
or LoWPANs for short) with the help of an adaptation header which
comes before the IP header. A link in such a 6LoWPAN is
characterized as lossy, low-power, low bit-rate, short range, with
many nodes saving energy with long deep sleep periods. Multicast as
used in classic IPv6 Neighbor Discovery [RFC4861] is not desirable in
such a wireless low-power, lossy network.
Moreover, LoWPAN links are asymmetric and non-transient in nature;
they are not always considered to be in a fixed network nor are they
bounded by our traditional definition of a wired-link. A LoWPAN is
potentially composed of a large amount of overlapping radio ranges,
eventually federated by a backbone or a backhaul link. Although a
given radio range has broadcast capabilities, the aggregation of
these is a complex Non-Broadcast MultiAccess (NBMA, [RFC2491])
structure with (generally) no LoWPAN-wide multicast capabilities.
Link-local scope is in reality defined by reachability and radio
strength. The classic IPv6 Neighbor Discovery [RFC4861] control
messages, the use of multicast and their default frequency also
attribute to unnecessary waste of energy in LoWPANs.
6LoWPAN Neighbor Discovery (6LoWPAN-ND) provides for basic
bootstrapping and network operation, along with advanced features
such as claim and defend address generation and Extended LoWPANs over
backbone links, while avoiding the use of multicast flooding. The
solution supports the use of both link-layer- or LoWPAN-level mesh
(Mesh Under) and IP routing (Route Over) solutions for multihop
forwarding. This specification is both sufficient and required for
LoWPAN operation. The 6LoWPAN-ND mechanism could also coexist with
[RFC4861], [RFC3122] or other future ND mechanisms (although the
motivation or detailed specification of such coexistence is out of
scope for the present document).
This specification introduces a registration mechanism over the radio
edge of the NBMA network and proxy operation over the federating
backbone or backhaul. That registration mechanism provides a service
somewhat similar to the Multicast Address Resolution Server (MARS)
[RFC2022] for a limited purpose, and in a much simpler and less
generic fashion. For those link scope multicasts that could not be
avoided, such as for Router Advertisements, optimizations may be used
to optimize the dissemination of the information in the Low Power
network.
The concept of a LoWPAN Whiteboard located at Edge Routers (ERs) is
introduced, which allows for Duplicate Address Detection for the
Shelby, et al. Expires April 29, 2010 [Page 4]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
entire LoWPAN. A new registration/confirmation message sequence is
specified, allowing nodes to register their IPv6 addresses with an
Edge Router.
The Whiteboard makes use of soft bindings, thus nodes send periodic
registration messages in order to maintain their bindings. Changes
in network topology, and mobility between ERs and LoWPANs are
supported. The dissemination of RA information between LoWPAN
Routers in multihop IP LoWPANs is also discussed.
This document also specifies the seamless integration of an Extended
LoWPAN with multiple edge routers on a shared backbone link (e.g.
Ethernet) to form a single IPv6 subnet. This allows nodes to keep
the same IPv6 address throughout a large network, and allows for easy
communications with nodes over the backbone link and with other IPv6
hosts.
The document defines two new ICMPv6 messages: Node Registration and
Node Confirmation. In addition a new 6LOWPAN_ER anycast address is
introduced, used by LoWPAN Routers in order to relay a registration
message to any Edge Router.
1.1. Goals, Assumptions, and Guesses
This document has the following main goals and assumptions, as well
as two guesses that may or may not be true in a specific LoWPAN but
still have shaped the optimizations.
Goals:
o Optimize ND with a mechanism that is minimal yet sufficient for
LoWPAN operation, supporting non-transitive links and both mesh-
under and route-over configurations.
o Minimize signalling by removing the use of multicast flooding and
reducing the frequency of link scope multicast messages inside the
LoWPANs.
o Disseminate context information throughout the LoWPAN used by
[I-D.ietf-6lowpan-hc].
o Minimize the complexity of LoWPAN Nodes.
o Interconnect LoWPANs with backbone links seamlessly.
Assumptions:
Shelby, et al. Expires April 29, 2010 [Page 5]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
o A subnet includes all the LoWPAN Nodes, Edge Router(s) and
optionally their backbone link sharing the same IPv6 prefix.
Guesses:
o Link layer technology may be e.g. IEEE 802.15.4 as in [RFC4944],
or any other link-layer exhibiting non-transitivity or a similar
topology.
o Link-local IPv6 addresses are derived from a unique identifier
(e.g. EUI-64) corresponding to a link-layer address.
1.2. Why not classic 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 initialization of the network in IPv6 Ethernet
networks, a node joins the solicited-node multicast address on the
interface and then performs duplicate address detection (DAD) for the
acquired link-local address by sending a solicited-node multicast
message to the link. After that it sends multicast messages to the
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
router advertisement (RA). Besides this, the IPv6 routers usually
send router advertisements periodically on the network. RAs are sent
to the all-node multicast address. Nodes send Neighbor Solicitation/
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 is assumed 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 -- for
example 16-bit short addresses and 64-bit unique addresses as defined
in [RFC4944]. Moreover, the available L2 payload size 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. 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 or periodic RAs is not practical. Also they are not capable
of processing address-resolution for their neighbors effectively.
Shelby, et al. Expires April 29, 2010 [Page 6]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
Due to the radio strength of its neighboring router or its own
strength, a node may often move from one router to another without
physically moving from one place to another. Considering the above
characteristics in a LoWPAN, and the IPv6 Neighbor Discovery
[RFC4861] base protocol requirements, it was concluded that classic
Neighbor Discovery is not suitable as it is and a 6LoWPAN-specific ND
definition would be useful and efficient for the wide deployment of
IPv6 over low-powered wireless networks of embedded devices.
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].
This specification requires readers to be familiar with all the terms
and concepts that are discussed in "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] ("oDAD") prior to
this specification for a clear understanding of state of the art in
ND proxy and binding.
This specification makes extensive use of the same terminology
defined in [RFC4861] unless otherwise redefined below.
2.1. 6LoWPAN Terminology
This section defines additional general terms related to the 6LoWPAN
architecture used in this specification:
IP Routing
The forwarding of datagrams at the IP layer between arbitrary
source-destination pairs, during which the IPv6 hop limit is
decremented. In the LoWPAN context, IP routing is performed by
LoWPAN Routers on a single interface within the same link to
overcome the non-transitive nature of the link. Exact match
search is performed on the destination address of the IP packet to
find the next-hop to the destination. Referred to as routing in
this document.
Shelby, et al. Expires April 29, 2010 [Page 7]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
Link
The link is a communication facility or medium over which nodes
can communicate at the link-layer, i.e., the layer directly below
IP ([RFC4861]). 6LoWPAN assumes the use of low-power and lossy
wireless links such as IEEE 802.15.4, which is a special type of
link as described in [RFC4861] exhibiting severe asymmetric
reachability with both asymmetric (A can reach B, but B can't
reach A) and non-transitive (A can reach B, and B can reach C, but
A can't reach C) qualities. Furthermore complex Non-broadcast
Multi-Access (NBMA) behavior is exhibited as these links do not
support native multicast, and broadcast reaches only a subset of
nodes on the link. Such a wireless link may consist of multiple
overlapping link-local scopes. Link-local scope multicast on such
a link is realized as a broadcast.
The use of link-layer mesh technology (see Mesh Under) emulates
transitivity across the link but still has problems with
asymmetricity. Multicast on a link-layer mesh, if available, is
often implemented as an expensive broadcast flood.
Link-local
Standard IPv6 link-local scope as defined in [RFC4291] and
[RFC4861] is supported by the 6LoWPAN link and subnet model.
Link-local scope is achieved by setting the hop limit to 1, using
a link-local prefix (FE80::) or link-local multicast scope
(FFx2::). If a link is non-transitive then link-local scope may
include only a subset of nodes on the link (the set of nodes
within symmetric radio range of a node). Nodes in the link-local
scope of a node are its neighbors, and this link-local scope may
differ from the perspective of each node.
The terms on-link and off-link no longer have clear meaning on
non-transitive links. Instead a node within link-local scope is
said to be local, and a node outside of link-local scope is said
to be non-local.
LoWPAN Host
A node that only sources or sinks IPv6 datagrams. Referred to as
a host in this document.
LoWPAN Node
Shelby, et al. Expires April 29, 2010 [Page 8]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
A node that composes a LoWPAN, referring to both hosts and
routers. Simply called a node in this document.
LoWPAN Router
A LoWPAN node that forwards datagrams between arbitrary source-
destination pairs using a single 6LoWPAN interface performing IP
routing on that interface.
LoWPAN Mesh node
A LoWPAN node that forwards data between arbitrary source-
destination pairs using link addresses (and thus only exists in
Mesh Under LoWPANs).
Mesh Under
A term referring to a configuration where the link-local scope is
defined by the boundaries of the LoWPAN (or a sizable part of it,
if Mesh Under is combined with Route Over) and includes all the
6LoWPAN interfaces within it. There are forwarding and multihop
routing functions at L2 to achieve transitivity on the link. In
this configuration the link may still exhibit lossy, asymmetric,
NBMA (non-availability of mesh-wide multicast) behavior.
Route Over
A term referring to a configuration where the link is non-
transitive and the link-local scope reaches only a subset of the
LoWPAN nodes. IP routing is performed by LoWPAN Routers to
overcome the nature of the link. A LoWPAN with this configuration
may consist of both routers and hosts. Route Over and Mesh Under
are not mutually exclusive, and IP routing may be used between
links that perform Mesh Under.
Subnet
A subnet is the collection of interfaces having the same IPv6
subnet prefix on a link, as defined in [RFC4291]. A LoWPAN is
made up of the interfaces of LoWPAN Nodes and Edge Routers sharing
the same subnet prefix. Due to the non-transitive nature of
LoWPAN links, IP routing may be used on the link to provide
transitivity. This Route Over configuration exhibits a multi-hop
subnet feature with regard to hop limit as discussed in [RFC4903],
and thus 6LoWPAN applications should be careful when making
assumptions about the hop limit as it may be decremented in a
LoWPAN.
Shelby, et al. Expires April 29, 2010 [Page 9]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
2.2. ND Terminology
This section defines Neighbor Discovery specific terminology used in
this specification:
Ad-hoc LoWPAN
An isolated LoWPAN, not connected to any other IP networks. Ad-
Hoc LoWPANs make use of Unique Local IPv6 Unicast Addresses (ULAs)
[RFC4193].
Backbone Link
This is an IPv6 link that interconnects two or more edge routers
in an Extended LoWPAN topology. It is expected to be deployed as
a high speed backbone in order to federate a potentially large set
of LoWPANs.
Binding
The association of the LoWPAN node IPv6 address and Owner
Interface ID with associated Whiteboard and ND states including
the remaining lifetime of that association.
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, shown in Figure 2.
LoWPAN Edge Router
An IPv6 router that interconnects the LoWPAN to another IP
network. Referred to as an Edge Router in this document.
Simple LoWPAN
A Simple LoWPAN consists of a single Edge Router and the set of
LoWPAN nodes on the same LoWPAN Subnet, shown in Figure 1. If the
Edge Router has a Whiteboard, all nodes belonging to its LoWPAN
have a whiteboard entry.
Registration
The process during which a LoWPAN node sends a Node Registration
ND message to an Edge Router causing a binding for the LoWPAN node
to be registered.
Shelby, et al. Expires April 29, 2010 [Page 10]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
Whiteboard
A conceptual data structure similar to a MIPv6 binding cache which
may be supported by Edge Routers. The Whiteboard is used for
performing DAD and NUD across the entire LoWPAN. The Whiteboard
contains bindings for LoWPAN nodes that contain, among others, an
Owner Interface Identifier, Owner Nonce, IPv6 address, TID and a
remaining lifetime of the binding.
Infrastructure Cloud
|
|
|
+-----+
| | Edge
| | router
+-----+
o o
o o o
o o o o o o: LoWPAN Node
o o o o
o o o
Simple LoWPAN
Figure 1: A simple LoWPAN topology
Shelby, et al. Expires April 29, 2010 [Page 11]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
Infrastructure Cloud
|
|
+-----+ +-----+
| | Router | | 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 2: Extended LoWPAN with a backbone link and edge routers
3. Protocol Overview
6LoWPAN Neighbor Discovery (6LoWPAN-ND) optimizes IPv6 ND with a
mechanism which is on its own minimal yet sufficient for LoWPAN IPv6
operation. 6LoWPAN-ND defines a node registration mechanism
optimizing the node-router interface. This mechanism requires no
flooding and reduces link-local multicast frequency. 6LoWPAN-ND
supports non-transitive links, the use of both mesh-under and route-
over techniques and makes no assumptions about node-node
synchronization. This specification is REQUIRED for LoWPAN
operation, but MAY also coexist with [RFC4861], [RFC3122] or other
future ND mechanisms. Any use of [RFC4944] without this
specification is NOT RECOMMENDED.
The following features are defined by 6LoWPAN-ND (see Section
Section 5 for details):
Node Registration: Method in which nodes in the LoWPAN register with
Routers and Edge Routers, creating state about nodes attached to
that router (binding table) and about all IPv6 addresses in the
LoWPAN (whiteboard).
Shelby, et al. Expires April 29, 2010 [Page 12]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
Duplicate Address Detection: The detection of duplicate addresses is
performed across the entire LoWPAN using a lookup on the
Whiteboard using the node registration mechanism. Edge routers in
an Extended LoWPAN formation perform DAD on the backbone link (as
appropriate for that link, usually [RFC4861]).
Whiteboard Resolution: This method is used in the Extended LoWPAN
topology (optional), using the backbone link to resolve conflicts
between the Whiteboards of Edge Routers.
Next-hop Determination: The specification defines a simple next-hop
determination rule.
Address Resolution: The node registration mechanism provides
sufficient a priori state in nodes and routers to resolve an IPv6
address to its associated link-layer address on the node-router
interface. Host-host resolution is out of scope of this
specification.
Unreachability Detection: Unreachability between a node and router
is determined based on link-layer acknowledgements to node
registration and unicast data messages. Host-host unreachability
detection is out of scope. Destination unreachability detection
is performed using ICMPv6 destination unreachable messages.
Context Dissemination: The dissemination of LoWPAN context as used
by [I-D.ietf-6lowpan-hc] is defined as an ICMPv6 option, along
with an associated summary option to reduce message size when many
contexts are advertised.
This specification makes use of RS/RA message exchanges similar to
classic ND, which in 6LoWPAN-ND may also carry additional options for
context dissemination (6LoWPAN Information Option, 6IO) and reducing
RA message size (6LoWPAN Summary Option, 6SO). In addition
6LoWPAN-ND defines two new ICMP packet types:
Node Registration (NR): Sent by a node to an Edge Router to register
a binding for an IPv6 address in the Whiteboard. Is relayed by an
intermediate router if there is no local Edge Router.
Node Confirmation (NC): The response sent by an Edge Router or
router back to the registering node. May be relayed by an
intermediate router.
Shelby, et al. Expires April 29, 2010 [Page 13]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
3.1. Topology
6LoWPAN-ND is designed to work with a wide variety of 6LoWPAN
topologies, including isolated Ad-hoc LoWPANs, Simple LoWPANs and
Extended LoWPANs. A Simple LoWPAN topology is assumed by default in
the text. The case of Ad-hoc LoWPAN operation is described in
Section 8.4. Edge Router operation and Extended LoWPAN functionality
are described in Section 8. Edge Routers which will operate only in
Simple LoWPANs do not need to support Extended LoWPAN functionality,
such as Edge Routers which do not have a Backbone Link (but instead
e.g. an ADSL interface). 6LoWPAN-ND makes little assumption about
synchronization between nodes in a LoWPAN except between a node and
the routers it has registered with.
3.2. Links
This specification is designed for use with IEEE 802.15.4 or any
other similar link-layer technology which exhibits the
characteristics defined for a 6LoWPAN link such as low data-rates,
packet loss, limited range, asymmetricity and long sleep-cycles.
This specification is able to deal with the non-transitive nature of
these links.
6LoWPAN-ND is compatible with the use of link-layer mesh or [RFC4944]
mesh techniques, which alleviate the otherwise non-transitive nature
of wireless links. If used throughout the LoWPAN, this so-called
Mesh Under topology thus makes the entire link appear to the IP layer
as having a link-local scope covering all the 6LoWPAN interfaces in
the LoWPAN. This kind of LoWPAN is made up of hosts and Edge
Routers. This link still exhibits lossy, low-rate, asymmetric
behavior along with sleep cycles. The non-transitive nature of the
link can also be overcome using IP routing within the LoWPAN, also
called a Route Over topology. LoWPAN Routers are used in the LoWPAN
to provide routing between all nodes in the LoWPAN. LoWPAN Router
operations are specified in Section 7. Link-local scope includes the
neighbors of each node within symmetric wireless range. Mesh Under
and Route Over techniques are not mutually exclusive, and it may
possible to combine IP routing and mesh link-layers within a LoWPAN.
3.3. Bootstrapping
1. A Host first performs stateless address autoconfiguration of its
link-local unicast address for each LoWPAN interface from its EUI-64
as in [RFC4944]. When a LoWPAN Node wants to join a LoWPAN, it does
so by listening for Router Advertisements, or by broadcasting a
Router Solicitation (RS) and receiving RA responses from local
routers (see Figure 3). If a valid prefix is advertised in the RA,
the host will also form an optimistic global unique address with
Shelby, et al. Expires April 29, 2010 [Page 14]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
stateless address autoconfiguration (or any other suitable method).
At this point the node has also chosen one or more default routers.
2. Next the node will attempt to perform initial node registration.
Registration is always performed with a link-local Edge Router or
LoWPAN Router by sending a unicast Node Registration (NR) message to
it. Registering directly with an Edge Router is of course preferred
as shown in Figure 4 (the ER is differentiated by the Prf flag in its
RA), although all LoWPAN Routers have the ability to relay NR/NC
messages on behalf of a node as shown in Figure 5. These message
exchanges are illustrated below. The NR contains the addresses the
node wants to register. A node may request a short address to be
generated on its behalf by including an Address Option with the A
flag and an address of length 0 in the NR.
3. The Edge Router replies either directly with a Node Confirmation
(NC), or through the relaying router. Note that routers only exist
in Route Over configurations, and in pure Mesh Under configurations
nodes are within link-local scope of an Edge Router. This NC
includes the set of addresses now confirmed to be bound to the
Whiteboard of the ER. The Host is now capable of using the LoWPAN.
Node Router
| |
| ---------- Router Solicitation --------> |
| |
| <-------- Router Advertisement --------- |
| |
Figure 3: Basic RS/RA exchange between a node and any local router
(LoWPAN Router or Edge Router)
Node Edge Router
| |
| ---------- Node Registration --------> |
| |
| <--------- Node Confirmation --------- |
| |
Figure 4: Basic ND registration exchange when the Edge Router is
local
Shelby, et al. Expires April 29, 2010 [Page 15]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
Node Router (ICMP relay) Edge Router
| | |
| ---- NR ---> | ---- NR ---> |
| | |
| <---- NC ---- | <---- NC ---- |
| | |
Figure 5: Registration exchange relayed by a router (no local ER),
the messages are ICMP relayed
3.4. Basic operation
The node may now send packets to any IPv6 address inside or outside
the LoWPAN. Next-hop determination assumes destinations are non-
local (and thus forwarded to a default router) except for link-local
scope addresses which are always local. The information needed for
resolving the link-layer address of default routers or registered
nodes is known a priori as a result of node registration.
The LoWPAN Router binding table and Edge Router Whiteboard entries
are soft, and thus must be renewed periodically as indicated by the
advertising interval and the lifetime of the binding. This is
achieved by periodically sending a new NR message. If a host moves,
or the network topology changes, and the current routers are no
longer available, the host then starts the registration process with
another router. If the host is still in the same LoWPAN (same subnet
prefix), its IPv6 addresses remain the same. Addresses bound by the
Whiteboard must be remembered by the host and refreshed in order to
keep the address. If the host moves to a different LoWPAN (thus with
a different subnet prefix), the bootstrapping process is initiated
again. See Section 6 for details on node operation.
LoWPAN Routers periodically send RAs to their neighbors. The Edge
Router initiates the first RAs, and information from these RAs is
included in the RAs of each further router, causing the information
to be disseminated throughout the LoWPAN. RA periods should be
optimized to reduce signalling. See Section 7 for detailed router
operation.
3.5. Extended LoWPAN operation
This documents specifies a method for forming Extended LoWPAN
networks with multiple ERs on a backbone link. This optional Edge
Router feature allows for the detection of duplicate addresses across
the entire Extended LoWPAN and backbone links, seen as a single
subnet. The method uniquely identifies the LoWPAN Host on the
backbone, and overrides the claim on an address on behalf of a LoWPAN
Shelby, et al. Expires April 29, 2010 [Page 16]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
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. See Section 8 for a description of Extended
LoWPAN operation. Extended LoWPAN operation is transparent to host
and router operation.
4. Message Formats
This section defines the message and option formats used in this
document. The new messages are all ICMPv6 messages. In addition,
new options for ICMPv6 messages are defined.
The following new ICMPv6 message types are defined:
o Node Registration
o Node Confirmation
In addition, the following new ICMPv6 options are defined:
o 6LoWPAN Address Option (6AO)
o 6LoWPAN Information Option (6IO)
o 6LoWPAN Summary Option (6SO)
o Owner Interface Identifier Option (OIIO)
The following [RFC4861] messages are used as specified in this
section:
o Router Solicitation (RS)
o Router Advertisement (RA)
o Neighbor Solicitation (NS, Extended LoWPAN only)
o Neighbor Advertisement (NA, Extended LoWPAN only)
4.1. Node Registration/Confirmation Message
The Node Registration (NR) and Node Confirmation (NC) messages are
used by a node to register with an ER, and for the ER to confirm the
binding. The NR is also used to refresh its registration with a
local router at a faster interval. Any option that is not recognized
MUST be skipped silently. The Node Registration message is sent by
the LoWPAN Node to the link-local unicast IPv6 address of a local
Shelby, et al. Expires April 29, 2010 [Page 17]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
Edge Router or LoWPAN Router. NR/NC messages may be relayed by the
first-hop router, i.e. sent on over multiple IP hops within the
LoWPAN to the Edge Router, thus received messages with a hop limit
less than 255 MUST be accepted by LoWPAN Routers from senders with a
source address in the same LoWPAN. Relaying routers may also use the
6LOWPAN_ER anycast address as the destination.
When registering the first time the node (which then still has
optimistic addresses) sends an NR message to the link-local unicast
address of a local ER or LoWPAN Router. The source address must be
the IPv6 unspecified address to comply with oDAD.
Nodes send subsequent NR messages to a local ER or router, however
the IPv6 source address is then the link-local IPv6 address of the
sender. NR local refresh messages SHOULD be sent more often than
normal registrations, thus reducing the amount of traffic sent to ERs
over multiple hops. The timings of registrations and local refresh
messages are indicated by the Binding Lifetime and Advertising
Interval fields, respectively.
This same message format is also used for relayed NR/NC messages,
with an alternative code that is set when the message has been
relayed. When relaying, a new message is created with an updated
checksum, and a code is used to indicate relaying. The hop limit is
not decremented when relaying.
Address Options are included in the NR message for each IPv6 address
to be registered, and included in the corresponding NC to indicate
success.
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 |Status | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TID |P|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding Lifetime | Advertising Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Owner Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Owner Interface Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration option(s)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+
Shelby, et al. Expires April 29, 2010 [Page 18]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
Figure 6: Node Registration/Confirmation message format
IP Fields:
Source Address: The IPv6 address of the source. This address
MUST be the IPv6 unspecified address for initial registration.
Destination Address: The link-local unicast IPv6 address of a
local router when sent by a node. The destination IPv6 address
of an Edge Router or the 6LOWPAN_ER anycast address when sent
by a relaying router.
Hop Limit: 255
ICMP Fields:
Type: TBD1 for Node Registration, TBD2 for Node Confirmation.
Status: 4-bit unsigned integer. Sent only in NC messages,
ignored in NR messages. Values 0-7 are reserved for success
codes:
0 is unqualified success.
Values 8-15 are reserved for error codes:
8 is sent to indicate that no ER is available.
9 is sent to indicate that Whiteboard registration is not
supported.
10 is send to indicate that the router is saturated and an
alternative router should be used.
Code: 4-bit unsigned integer.
0 indicates this NR is a request sent directly from the
originating host, or this NC is a corresponding response.
1 indicates that the NR message has been relayed by a
router, or that the NC is to be relayed by the router
indicated as the destination.
2 indicates this NC is a request for the node to re-
register.
Shelby, et al. Expires April 29, 2010 [Page 19]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
3 indicates this NR is a local refresh to the router, or
this NC is the reply to a refresh.
4-15 are reserved for future use.
Checksum: The ICMP checksum.
TID: 8-bit unsigned integer. A unique Transaction ID assigned by
the host and used to match replies. A lollipop mechanism is
used to increment the TID upon each new registration. The TID
is not incremented upon a local refresh. In a Node
Confirmation TID is that of the corresponding NR. TID is set
to 0 upon booting, and is incremented with each NR message.
After reaching 0xFF, the value loops to 16 (0x10) and is
incremented from there. Thus the values between 0-15 MUST only
used after a boot or reboot.
P: 1-bit Primary flag. Set to indicate that the Edge Router is
primary and MAY represent the node if used in a Extended
LoWPAN. If the flag is not set then the router MUST not
represent the node on the backbone. The flag is echoed in a
confirmation.
R: 1-bit Router flag. Used to indicate the role of node sending
the NR message. Set to 0 by hosts and to 1 by routers.
Binding Lifetime: 16-bit unsigned integer. The amount of time in
units of minutes remaining before the binding of this owner
interface identifier, and all associated address options and
configuration options, MUST be considered expired. A value of
zero indicates that the Binding Cache entries for the
registered owner interface identifier MUST be deleted. (The
16-bit field covers up to about 45.5 days of Binding Lifetime.)
Advertising Lifetime: 16-bit unsigned integer. The amount of
time in units of 10 seconds the node will advertise itself to
its local router using a NR local refresh. This field is
ignored if the Binding Lifetime is set to 0. (The 16-bit field
covers up to slightly more than a week of Advertising
Lifetime.)
Reserved: This field is unused. It MUST be initialized to zero
by the sender and MUST be ignored by the receiver.
Owner Interface Identifier (OII): A globally unique identifier
for the requesting host's interface. Typically the EUI-64
derived IID.
Shelby, et al. Expires April 29, 2010 [Page 20]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
Owner Nonce: A 32-bit Nonce generated randomly by the node upon
booting, and generated again each time the node re-boots. This
Nonce is used by ERs to detect duplicate OIIs Section 8.8.
Possible Options:
6LoWPAN Address Option(s): An Address Option is included for each
address the host wants to bind for this interface.
6LoWPAN Information Option: This option includes information
about the prefixes of the LoWPAN along with other context
information. Although normally carried in RA messages, a 6IO
option MAY also be carried in NC messages.
Future versions of this protocol may define new option types.
Receivers MUST silently ignore any options they do not recognize
and continue processing the message.
4.2. Router Solicitation Message
The RS message format for 6LoWPAN is identical to the classic
[RFC4861] RS message. The following clarifications are made
regarding the use of RS in LoWPANs.
If a node has only optimistic addresses, not yet confirmed by an Edge
Router, then the IPv6 source address in the RS MUST be the IPv6
unspecified address. The Source Link-Layer Address Option MUST NOT
be included in the RS at any time. Instead the Owner Interface
Identifier specified in this document MUST be included in the RS.
4.3. Router Advertisement Message
The RA message format for 6LoWPAN is identical to the classic
[RFC4861] RA message. The use of flags is however defined in the
6LoWPAN context, and additional new options are identified. RA
messages are sent either to link-local all-nodes multicast, or to a
link-local unicast address as a response to an RS.
Updated Flag Definitions:
Prf: 2-bit signed integer. Default Router Preference as defined
in [RFC4191]. Indicates whether to prefer this router over
other default routers. LoWPAN Routers with no ER available
MUST set Prf to (11) for low preference, LoWPAN Routers with ER
availability MUST set Prf to (00) for normal preference, and
LoWPAN Edge Routers MUST set Prf to (01) for high preference.
Shelby, et al. Expires April 29, 2010 [Page 21]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
Options:
6LoWPAN Information Option: This option includes information
about the prefixes of the LoWPAN along with other context
information.
6LoWPAN Summary Option: This option provides a sequence number
associated with the current prefix options. It allows the
prefix options themselves to be sent only periodically in
unsolicited RAs.
Prefix Information Option: If needed for backward compatibility,
an RA may also be sent using the classic [RFC4861] Prefix
Information Option which all LoWPAN nodes MUST be able to
parse. If possible, routers in the LoWPAN SHOULD make use of
6IO and 6SO options instead of PIO.
The MTU and SLLAO options defined in [RFC4861] are not used by
this specification.
Future versions of this protocol may define new option types.
Receivers MUST silently ignore any options they do not recognize
and continue processing the message.
4.4. NS/NA Messages (Extended LoWPAN only)
NS/NA messages are employed between ERs on the backbone link by this
specification for Extended LoWPAN mode. For this use a unique
identifier is required in the message as an option to uniquely
identify a host's interface. The classic NS/NA message is used in
this document is as per [RFC4861] with an additional Owner Interface
Identifier Option (OIIO) defined in this document. The Owner
Interface Identifier is the same as that carried in the associated
NR/NC messages and associated with bindings.
4.5. Message Options
This section defines the new 6LoWPAN-ND message options.
4.5.1. 6LoWPAN Address Option
The 6LoWPAN Address Option (6AO) is used to indicate the address
which a node wants to register with an ER in an NR, and to indicate
the success or failure of that binding in an NC. Multiple Address
Options can be included in a message. In order to be as compact as
possible, fields are used to indicate the compression of the IPv6
address. The 6AO also allows for duplicate addresses (e.g.
anycasts), the request of a generated address for claim and defend
Shelby, et al. Expires April 29, 2010 [Page 22]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
use, or for an address to be removed.
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 | Status | S | P |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|A|R| Reserved | IPv6 Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: 6LoWPAN Address Option format
Type: TBD3
Length: 8-bit unsigned integer. The length of the option (including
the type and length fields) in units of 8 octets.
Status: 8-bit unsigned integer. 0 means unqualified success. Any
value below 128 is a positive status that means that the binding
for this address was created or is being created optimistically.
Only used in a confirmation.
D: 1-bit Duplicate flag. When set, indicates that duplicates are
allowed for this address (to support anycast) in a request.
A: 1-bit Address Generation flag. Set to indicate that the host is
requesting a generated address for claim and defend addressing.
In a request when A is set the IPv6 address length is 0. Set to
indicate that an address has been assigned in a confirmation. P
and S are set to indicate the type of address requested and
assigned when A is set. Otherwise must be 0.
R: 1-bit Removal flag. When set, indicates that this particular
address binding MUST be removed from a whiteboard (in a request)
or MUST not be used any longer (in a confirmation).
P: 5-bit unsigned integer. Identifies prefix compression or type, if
any.
0-15: Prefix compressed; upon decompression, the prefix given by
the compression context with the same numerical CID as the P
field given is inserted.
16: Prefix is carried inline.
Shelby, et al. Expires April 29, 2010 [Page 23]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
17: Prefix compressed; upon decompression, the link-local prefix
(fe80::) is inserted.
18-31: Reserved.
S: 3-bit unsigned integer. Identifies suffix compression or type, if
any.
0: Suffix carried inline.
1: Suffix compressed and assumes the same value as the Owner
Interface Identifier field in the NR/NC message header.
2: Suffix compressed for an IID formed from an IEEE 802.15.4 16-
bit short addresses. Only the 16-bit short-address is carried
in-line. The IID is formed from this address as specified in
[RFC4944].
3-7: Reserved.
IPv6 Address: The IPv6 address to be registered with the ER, or
confirmed by the ER. Parts of the address may be elided as per
the P and S fields.
4.5.2. 6LoWPAN Information Option
This option carries prefix information for LoWPANs, and is similar in
use to the Prefix Information Option of [RFC4861]. However this
option allows for the dissemination of multiple contexts identified
by a Context Identifier (CID) for use in 6LoWPAN address compression.
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 | Info Length |L|A|C|V| CID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Prefix or Address Information .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: 6LoWPAN Information Option format
Shelby, et al. Expires April 29, 2010 [Page 24]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
Type: TBD4
Length: 8-bit unsigned integer. The length of the option (including
the type and length fields) in units of 8 octets. May be 1, 2 or
3 depending on the length of the Information field.
Info Length: 8-bit unsigned integer. The number of leading bits in
the Information field that are valid. The value ranges from 0 to
128. The info 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 [RFC4862], for which there may
be more restrictions on the info length.
L: 1-bit local flag, similar to the L flag in [RFC4861]. This flag
MUST be unset for Route Over LoWPANs and Extended LoWPANs, and MAY
be set for Mesh Under Simple LoWPANs.
A: 1-bit autonomous address-configuration flag. When set indicates
that this prefix can be used for stateless address configuration
as specified in [RFC4861].
C: 1-bit context flag. This flag indicates that this information
option also serves as a context on the LoWPAN, which is identified
by the CID field.
V: 1-bit context validity flag. This flag indicates if the context
is valid, and is used only in combination with the C flag. A
context that is not valid MUST not be used for compression, but
MAY be used in decompression in case another compressor still
considers the context as valid.
CID: 4-bit Context Identifier for this prefix information. CID is
used by context based header compression specified in
[I-D.ietf-6lowpan-hc]. The list of CIDs for a LoWPAN is
configured on Edge Routers, who distribute the prefix list to all
nodes in the LoWPAN.
Valid Lifetime: 32-bit unsigned integer. The length of time in
seconds (relative to the time the packet is sent) that the prefix
is valid for the purpose of local determination. A value of all
one bits (0xffffffff) represents infinity.
Information: The IPv6 prefix or context information indicated. This
may be a partial prefix, a partial context or even an entire IPv6
address for use as a context for compression.
Shelby, et al. Expires April 29, 2010 [Page 25]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
4.5.3. 6LoWPAN Summary Option
This option identifies the set of prefix information options by a
sequence number. This allows for the full set of prefix information
options to be sent only periodically in unsolicited RAs. If a host
detects a difference in the sequence number of this option, then the
prefix information has likely changed, and is then requested with an
RS. An RA sent in response to a unicast RS always includes the full
set of prefix information.
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 | ER Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: 6LoWPAN Summary Option
Type: TBD5
Length: 1
Sequence Number: 16-bit signed integer. Indicates the freshness of
the information advertised by the RA.
ER Metric: 16-bit unsigned integer. The ER Metric gives an
indication of the cost (in routing metric terms) of reaching nodes
outside the LoWPAN via an ER through this router. The metric
SHOULD be derived in a well-defined way from the routing protocol
used in the LoWPAN (possibly by structuring the 16 bits available
e.g. into a major and a minor metric), and has a mid-range default
value of 0x8000. Edge Routers most likely set this field to 0. A
host SHOULD take this metric into account when choosing default
routers by making a scalar comparison, preferring routers with
numerically lower ER Metric values.
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.
Shelby, et al. Expires April 29, 2010 [Page 26]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
4.5.4. Owner Interface Identifier Option
This option is for use with classic NS and NA messages between ERs
over a backbone link. By using this option, the binding in question
can be uniquely identified and matched with the whiteboard entries of
each ER.
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 | TID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Owner Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Owner Interface Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Owner Interface Identifier Option
Type: TBD6
Length: 2
TID: 8-bit unsigned integer. A unique Transaction ID assigned by
the host in the associated NR and used to match NC replies.
Reserved: This field is unused. It MUST be initialized to zero by
the sender and MUST be ignored by the receiver.
Owner Nonce: A 32-bit Owner Nonce generated randomly by the node
upon booting, and generated again each time the node re-boots.
This Owner Nonce is used by ERs to detect duplicate OIIs.
Owner Interface Identifier: A globally unique identifier for the
host's interface associated with the binding for the NS/NA message
in question. This is typically the EUI-64 derived IID of the
interface.
5. Protocol Specification
This section specifies the functions defined by this specification,
along with pointers to needed procedures from other specifications.
These basic procedures are sufficient and required for LoWPAN
operation.
Shelby, et al. Expires April 29, 2010 [Page 27]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
5.1. Interface initialization
All nodes are required to autoconfigure at least one address, a link-
local address, which is derived from the IEEE 64-bit extended MAC
address that is globally unique to the interface as in [RFC4944]. As
a result, knowledge of the 64-bit address of another LoWPAN Node is
enough to derive its link-local address and reach it on the same
link. 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
backbone link and the LoWPAN. The address SHOULD be created as
optimistic before it has been confirmed by node registration (Section
Section 5.2).
A node MUST join the all-nodes multicast address, which is used for
receiving RAs from routers. A router MUST also join the all-routers
multicast address. A node MAY join other multicast addresses such as
the solicited-node multicast address if its link-layer includes
multicast support, but that is not required by this specification.
Nodes MAY learn the address of Edge Routers or routers using
traditional means such as L2 configuration or Router Advertisement
messages as in [RFC4861]. When sending a Router Solicitation it MUST
not have the SLLAO Option, but instead MUST include the OII Option.
If the sender of the RS has only optimistic addresses, it MUST not
use them as the IPv6 source address for the RS, but instead uses the
IPv6 unspecified address. This procedure is to comply with the use
of optimistic addresses as per oDAD [RFC4429].
The node SHOULD also form a global unicast address for routing inside
the LoWPAN and reachability from outside the LoWPAN. If a valid
prefix is available from an RA ('A' flag is set), then a global
unicast address MAY be derived using Stateless Address
Autoconfiguration [RFC4862]. This address is marked optimistic until
confirmed by the ER. If the LoWPAN is operating in ad-hoc mode, then
the prefix is a Unique Local IPv6 Address (ULA) prefix [RFC4193] as
specified in Section 8.4 (use of a ULA prefix requires no changes to
node operation). A node MAY alternatively acquire a global unicast
address using other suitable means, e.g. DHCPv6, L2 assignment or
manual configuration.
5.2. Node Registration
The node registration 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 ER. There are two kinds of
Node Registrations. Requests NRs (Code = 0) are used for initial
Shelby, et al. Expires April 29, 2010 [Page 28]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
registration with an ER, and subsequent ER binding updates. Requests
are sent infrequently to minimize overhead (as they may be sent over
multiple hops). Refresh NRs (Code = 3) are only sent to the local
LoWPAN Router in order to refresh its binding table. Refresh
messages are sent more often than Request messages. If an ER is
local, then refresh messages are not sent.
The LoWPAN Node uses unicast Node Registrations with local ERs or
LoWPAN Routers to perform the binding. The destination address is
the link-local unicast address of an local ER or LoWPAN Router.
While a nodes addresses are still optimistic (first registration in a
LoWPAN), the IPv6 unspecified address must be used as the source.
Registration SHOULD be preferred with local ERs rather than LoWPAN
Routers if available. The Preference Flag of the RA is used to
differentiate between ERs (Prf=01) and LoWPAN Routers (Prf=00).
LoWPAN Routers with Prf=11 SHOULD NOT be used for registration.
Furthermore the ER Metric in the 6LoWPAN Summary Option SHOULD be
used to choose a router to use for registration.
A unique Owner Interface Identifier (OII) is included in the Node
Registration so the binding can be identified throughout the LoWPAN.
The OII SHOULD be formed from the EUI-64 of the interface in the same
way as the node's link-local address IID as defined in [RFC4944]. A
randomly generated 32-bit Owner Nonce is formed each time a node
boots or reboots. This is included in the NR and is used by ERs to
detect duplicate OIIs. While cryptographic randomness [RFC4086] is
not strictly required, the randomness SHOULD be derived using a
mechanism of similar quality.
The NR message includes an Address Option for each address to be
registered. Thus the message is structured as follows:
ICMPv6 (Node Registration (Address Option[0], Address Option[1],
Address Option[n]))
This registration method includes a way of requesting a unique
address from the ER by setting the 'A' flag in an Address Option
during registration. This is useful for receiving a unique short
link-layer address, and works in a claim and defend fashion.
Although the address is generated by the ER and checked for
uniqueness across the LoWPAN, it is just like any other address
binding in the whiteboard of the ER after assignment. Thus in order
to keep using this address the host must keep refreshing the address
binding, including when moving to another ER in the same LoWPAN.
A unique Transaction ID (TID) is included by the host in the NR
message and used to match replies. A lollipop mechanism is used.
TID is set to 0 upon booting, and is incremented with each Request NR
Shelby, et al. Expires April 29, 2010 [Page 29]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
message. The TID MUST NOT be incremented when sending a Refresh NR
message. After reaching 0xFF, the value loops to 16 (0x10) and is
incremented from there. Thus the values between 0-15 MUST only used
after a boot or reboot while not yet registered with an ER. A node
that has not heard a valid Node Confirmation for 16 Node Registration
messages in a row restarts with a local next TID of zero (the node
MAY, but need not, generate a new Owner Nonce).
The acknowledgment to a Node Registration is a unicast Node
Confirmation message that contains the status of the binding. The
source of the packet is the link-local address of the local ER or
LoWPAN Router. The destination address is the link-local address of
the node. An Address Option for each confirmed or assigned address
is included. Upon successful completion in the Node Confirmation
message, the LoWPAN Node sets the address from optimistic or
tentative to preferred. See Section 11 for message examples.
If a Node Confirmation is received with an error code (8 or greater),
then the registration has failed. See Section 4.1 for an explanation
of NR/NC codes. If no successful Node Confirmation is received
within the timeout (RegistrationTimeout) and number of retries
(RegistrationRetries), then there may be no Edge Routers in the
LoWPAN. See Section 8.4 for more information on ad-hoc network
operation.
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 on the same or different LoWPANs. The
'P' flag in the Node Registration Identity Request Option indicates
whether the binding is primary. A primary binding MUST be maintained
with exactly one Edge Router in each LoWPAN at any time. The use of
this mechanism for fault tolerance is explained in Section 8.9.
ER and Router bindings have timeouts associated with them, therefore
nodes must periodically send a new Node Registration message to renew
the bindings. The period between Request NR messages SHOULD be less
than BindingLifetime. The period between Refresh NR messages SHOULD
be less than AdvertiseInterval. If a node no longer receives Node
Confirmation messages from any router in the current subnet, the
registration process starts over.
5.2.1. Processing a Node Registration Message
When a router receives a Node Registration refresh message (Code = 3)
from a node, it immediately responds to the sender with a Node
Confirmation message (Code = 3). The information in the NR is used
to update its binding table.
Shelby, et al. Expires April 29, 2010 [Page 30]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
When a router receives a Node Registration request message (Code = 0)
from a node, it sets the Code field to 1 indicating that the message
has been relayed. The IPv6 source address is set to that of the
router. Furthermore the checksum is re-calculated and the hop limit
is set to 255.
By default, the router relays Node 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. If a target link-layer
address option is included, the router SHOULD take this into account
as the preferred ER of the node.
5.2.2. Relaying a Node Confirmation Message
When a router receives a Relay Node Confirmation message from an Edge
Router, the Code field is set to 1. The Owner Interface Identifier
and Address Option are used to form the link-local IPv6 Destination
Address for the Node Confirmation message. The IPv6 source address
is set to the link-local address of the Router. The Hop Limit of the
Node Confirmation message is set to 255.
Upon relaying a successful NC message back to a node, the router
SHOULD use the information in the NC to update its Binding Table.
5.3. Duplicate Address Detection
Duplicate address detection is performed as part of the node
registration process by the Edge Router and is specified in
Section 8.
5.4. Next-hop Determination
The IP address of the next-hop for a destination is determined as
follows. Destinations to the link-local prefix (FE80::) are sent on
the link to that destination. All other prefixes are assumed to be
non-local as the subnet with that prefix may be larger than link-
local scope. They are therefore sent to the IP address of a router
chosen from the Default Router List.
Multicast addresses are considered to be local and are resolved as
specified in [RFC4944] or relative future documents. A LoWPAN Node
is not required to maintain a minimum of one buffer per neighbor as
specified in [RFC4861], as address lookup is not performed as part of
next-hop determination. Anycast addresses are always considered to
be non-local.
Shelby, et al. Expires April 29, 2010 [Page 31]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
5.5. Address Resolution
The node registration mechanism provides sufficient a priori state in
nodes and routers to resolve an IPv6 address to its associated link-
layer address on the node-router interface. As prefixes are always
assumed to be non-local, resolution between hosts is not needed.
Information about link-layer addresses is stored by nodes about
routers in its default router list, and by routers about nodes in its
binding table. This information is stored during the node
registration process. In order to achieve LoWPAN compression, most
global addresses are also formed using a link-layer address. A node
can minimize memory usage by making use of an educated guess and
storing link-layer address information only if it differs from the
link-layer address corresponding to the IID of the IPv6 address
(i.e., differs in more than the local/global bit being inverted).
5.6. Unreachability Detection
Unreachability between a node and router is determined based on link-
layer acknowledgements to node registration and unicast data
messages. Host-host unreachability detection is out of scope.
In order to detect unreachable destinations, nodes SHOULD support
type 1 ICMPv6 destination unreachable messages [RFC4443]. LoWPAN
Routers or Edge Routers make use of ICMPv6 destination unreachable to
indicate that delivery to that destination is not possible.
5.7. Context Dissemination
Network configuration parameters carried in Router Advertisements
originate at edge routers and must disseminate to all routers and
hosts within the LoWPAN. RAs include either 6LoWPAN Information
Options (one for each context) and a 6LoWPAN Summary Option, or just
a 6LoWPAN Summary Option.
For the dissemination of context information using the 6IO, a strict
lifecycle SHOULD be used in order to ensure the context information
stays synchronized throughout the LoWPAN. New context information
SHOULD be introduced into the LoWPAN with C=1 and V=0, to ensure it
is known by all nodes that may have to decompress based on this
context information. Only when it is reasonable to assume that this
information was successfully disseminated SHOULD an option with C=1
and V=1 be sent, enabling the actual use of the context information
for compression.
Conversely, to avoid that nodes send packets making use of previous
values of contexts, resulting in ambiguity when receiving a packet
Shelby, et al. Expires April 29, 2010 [Page 32]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
that uses a recently changed context, old values of a context SHOULD
be taken out of use for a while before new values are assigned to
this specific context. That is, in preparation for a change of
context information, its dissemination SHOULD continue for at least
MIN_CONTEXT_CHANGE_DELAY with C=1 and V=0. Only when it is
reasonable to assume that the fact that the context is now invalid
was successfully disseminated, should the context ID be taken out of
dissemination or reused with a different Information field. In the
latter case, dissemination of the new value again SHOULD start with
C=1 and V=0, as above.
The 6LoWPAN Summary 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 which 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. The sequence number is incremented by
the originating Edge Router each time the set of prefix information
changes.
As the number of prefixes or addresses included for context
compression in an RA may be large (up to 16), it is beneficial to
avoid the need to always include all options in every RA. Therefore
routers SHOULD only include the 6LoWPAN Prefix Summary Option in
unsolicited RAs, unless a set of prefix information with a new
sequence number is being disseminated. In the case of a new sequence
number, or when answering an RS, the router SHOULD include all
6LoWPAN Information Options in the RA. Therefore a node may use an
RS in order to get the whole prefix information set in case it misses
the RA sent when the sequence number changes.
6. LoWPAN Node Specification
This section specifies the conceptual data structures and variables
of a LoWPAN Node.
6.1. Conceptual structures
LoWPAN Nodes make use of the following conceptual data structures:
Prefix List - The list of prefixes which are advertised in Router
Advertisements, along with an associated invalidation timer. Each
entry is associated with the sequence number last advertised in
the 6LoWPAN Summary Option. Unlike in [RFC4861], these prefixes
are always assumed to be non-local.
Shelby, et al. Expires April 29, 2010 [Page 33]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
Context List - The list of context and their associated CID which
are advertised in Router Advertisements, along with an associated
invalidation timer. Each entry is associated with the sequence
number last advertised in the 6LoWPAN Summary Option. This list
may be realized together with the Prefix List.
Default Router List - As in [RFC4861]. For networks where address
resolution needs to be performed, this list also contains link-
layer information about each router.
Edge Router List - This new structure contains the list of Edge
Routers the node is registered with an associated timeout and
primary flag. This list may be combined with the Default Router
List. Non-local ERs can be included in this list but this is not
required.
These conceptual data structures may be realized in many ways. As
LoWPAN Nodes have very limited memory the number of cache entries
should be limited, duplicate entries between caches referenced, and
full IPv6 addresses represented in a compressed format where
possible.
6.2. Conceptual variables
The following variables are kept for each interface on a node, and
default values are overridden by information in Router
Advertisements:
CurHopLimit The default hop limit to be used when sending IP
packets.
CurTID The current Transaction ID (TID) value for use in
NR messages.
BindingLifetime The binding lifetime sent in Node Registration
messages.
AdvertiseInterval The advertisement interval sent in Node
Registration messages. Should be less than
BindingLifetime.
RegistrationTimeout The time to wait for a Node Confirmation after
sending a Node Registration. SHOULD be at least
MIN_NR_TIMEOUT.
Shelby, et al. Expires April 29, 2010 [Page 34]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
RegistrationRetries The number of times to try to send a Node
Registration, which SHOULD be less than
MAX_NR_RETRIES.
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 extend classic ND as specified in [RFC4861] to operate over such
non-transitive LoWPAN links. This section describes ND for 6LoWPAN
router operations. Note that this section does not apply to pure
Mesh Under LoWPANs where the are no LoWPAN Routers.
7.1. Router Configuration Variables
A router MUST allow the configuration of conceptual variables as
defined in Section 6.2.1 of [RFC4861]. AdvReachableTime and
AdvRetransTimer are not used.
7.2. Becoming an Advertising Interface
An interface may become an advertising interface as specified in
Section 6.2.2 of [RFC4861].
A LoWPAN Router's interface MAY become an advertising interface
before all of its router variables have been initialized. The router
MUST learn these variables (e.g. AdvCurHopLimit, prefix and context
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 consistent with the message format
given in this document.
- 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.
Shelby, et al. Expires April 29, 2010 [Page 35]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
- In the Preference flag: this flag is set to 00 to indicate that
the sender is a LoWPAN Router.
- In the Cur Hop Limit field: the current value of CurHopLimit.
- In the Reachable Time field: not used, set to zero.
- In the Retrans Timer field: not used, set to zero.
- In the options:
- 6LoWPAN Summary 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.
- The ER Metric field is used by a routing algorithm to
indicate the cost of reaching an ER through this router.
- 6LoWPAN Information options: one 6LoWPAN Information option
for each prefix listed in AdvPrefixList with the option fields
set from the information in the AdvPrefxList entry as follows:
- In the "local" 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 [RFC4861].
7.5. Ceasing To Be an Advertising Interface
As specified in Section 6.2.5 of [RFC4861].
7.6. Processing Router Solicitations
As specified in Section 6.2.6 of [RFC4861].
Shelby, et al. Expires April 29, 2010 [Page 36]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
7.7. Binding Table
Routers maintain an set of information about nodes that are currently
registered through it called the binding table.
The binding table contains an entry with information such as the
registered node's OII, link-local IPv6 address and the advertisement
interval from the last NR. If address resolution is required, the
table will also include corresponding link-layer address information.
8. LoWPAN Edge Router Specification
Edge Routers are the routers that connect LoWPANs to an IPv6
infrastructure via backhaul or backbone links when such an
infrastructure is available. To achieve that role:
Edge Routers MUST implement LoWPAN Router features on their LoWPAN
interfaces,
Edge Routers MUST support Whiteboard registration for LoWPAN Nodes
within their subnets.
Edge Routers MAY support the Extended LoWPAN modality where a
LoWPAN subnet is aggregated over a higher speed backbone link.
Edge Routers supporting the extended LoWPAN modality MUST perform
ND proxy over the backbone on behalf of their registered LoWPAN
Nodes.
This specification documents the LoWPAN Whiteboard, a conceptual data
structure that is used by the Edge Routers to maintain LoWPAN Node
registrations. This specification documents extensions to the
classic IPv6 Neighbor Discovery Protocol [RFC4861] that enables a
LoWPAN Node to locate an Edge Router and then claim and register
addresses using unicast exchanges with that Edge Router.
Another function of the Edge Router is to perform 6LoWPAN compression
and decompression between the LoWPAN and the rest of the IP network
and ensure MTU compatibility. Packets flow uncompressed over the
Backbone or Backhaul Links and are routed normally towards a Gateway
or an Application sitting outside of the LoWPAN.
In the Extended LoWPAN case, the Edge Router also performs proxy ND
operations over the Backbone Link on behalf of the LoWPAN Nodes that
are registered to it. This section also documents the proxy ND
operation used by the Edge Routers over the Backbone link and the
conflict resolution process that enables transparent micro-mobility
Shelby, et al. Expires April 29, 2010 [Page 37]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
for the LoWPAN Nodes.
8.1. The Whiteboard
The Whiteboard is a conceptual data structure that is maintained by
the Edge Routers to store their knowledge of the registered LoWPAN
Nodes. Information maintained for each registered node includes:
IPv6 address: The IPv6 address being registered. This is an IPv6
unicast address of any scope.
Owner Interface Identifier: The 64-bit OII of the LoWPAN Node's
interface (usually formed from an EUI-64) is used for Address
collision detection and resolution (Section 8.7).
Owner Nonce: The 32-bit nonce generated by a node upon booting is
used for Duplicate OII detection (Section 8.8).
Primary flag: Influences the proxy ND operation in the Extended
LoWPAN case.
Registration Age and Lifetime: The registration age indicates how
long ago the last registration flow took place. When the age
reaches the registration lifetime, the whiteboard entry is
removed.
It can be noted that no link-layer information is stored in the
Whiteboard. If the Edge Router is also used as the default gateway
for a LoWPAN Node then it would possess link-layer address
information in its Neighbor Cache. Otherwise, it will route packets
towards the LoWPAN Nodes and thus will not need or use the link-layer
address of the LoWPAN Node.
It can also be noted that in the Extended LoWPAN case, an Edge Router
only maintains the information on the LoWPAN Nodes that are
registered to it. So the full registry of all the LoWPAN Nodes in a
subnet is actually distributed between the Edge Routers.
The Whiteboard conceptually requires 177 bits of storage per LoWPAN
Node entry, plus 128 bits per IPv6 address. Considerable
optimization when realizing a Whiteboard can be made with regard to
IPv6 addresses using default prefix, OII and other known information
along with lifetimes and TIDs. In practice IPv6 address information
can mostly be elided.
Shelby, et al. Expires April 29, 2010 [Page 38]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
8.2. Simple LoWPAN
The support of the Simple LoWPAN modality is REQUIRED of an Edge
Router. In that configuration, a single Edge Router serves a subnet
that is formed by the LoWPAN Nodes that are registered to that Edge
Router, as represented in Figure 1. The ER may be connected to an IP
infrastructure and may inject the prefixes for its subnet in the
routed infrastructure.
In a Simple LoWPAN, the Edge Router is the repository of all
registrations and can detect a registration collision by simply using
its Whiteboard, so the Whiteboard is the reference for Duplicate
Address Detection operations.
The prefix for the LoWPAN is configured on the Edge Router or
acquired using prefix delegation. In the absence of a global IPv6
prefix, an ER may generate a prefix based on Unique Local IPv6
Unicast Addresses (ULAs) as defined in [RFC4193]. A ULA is made up
of the prefix fc00::/7, a global ID and a subnet ID. The global ID
is randomly generated, and the subnet ID is not used. The Edge
Router is responsible for the generation of the ULA prefix to be
advertised to the LoWPAN and used by all nodes. ULA generation may
use the algorithm suggested Section 3.2.2 of [RFC4193] or something
appropriate to the Edge Router's capabilities.
The Edge Router forms a link-local address in exactly the same way as
any other node on the LoWPAN, for instance based on its link layer
addresses to enable 6LoWPAN Header Compression. If the resulting
address is not present in the Whiteboard then the Edge Router owns
the address right away. The Edge Router announces itself using
Router Advertisement (RA) messages that are broadcasted periodically
over the LOWPAN.
8.3. Extended LoWPAN
The support of the Extended LoWPAN modality is OPTIONAL. In that
modality, a high speed Backbone Link interconnects multiple devices
and Edge Routers to form a single subnet that encompasses IPv6 nodes
attached to the Backbone Link and LoWPAN Nodes registered to the Edge
Routers as represented in Figure 2. As a result, all further
reference to the Backbone Link and ND proxy operation over that link
is OPTIONAL but come as a whole.
In the Extended LoWPAN modality, the Backbone Link is used as a
reference for address ownership and registration collision detection.
Addresses that are not found in the Whiteboard are queried over the
backbone using the ND operation in place for that type of link,
typically classic ND [RFC4861]; Edge Routers represent themselves and
Shelby, et al. Expires April 29, 2010 [Page 39]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
the LoWPAN Nodes that are proactively registered to them. An ND
lookup over the backbone is not propagated over the LoWPANs, but
answered by the Edge Router 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.
As all ERs in an Extended LoWPAN advertise the same subnet prefix on
their LoWPAN interfaces, ERs acquire their LoWPAN subnet prefix from
the backbone link as in [RFC4861]. In the absence of a global IPv6
address, an IPv6 router can alternatively advertise a ULA prefix as
defined in Section 8.2.
8.4. Ad-hoc LoWPAN
LoWPAN networks by nature may often work in an ad-hoc fashion,
without an infrastructure or connectivity to the global Internet.
6LoWPAN-ND may still be applied in such networks.
If a LoWPAN Router in the Ad-hoc LoWPAN is configured to implement
basic Edge Router Whiteboard functionality and generates a ULA prefix
[RFC4193] (as described in Section 8.2), then 6LoWPAN-ND can be
applied throughout the LoWPAN. There SHOULD be only one Edge Router
in an Ad-hoc LoWPAN (just as in a Simple LoWPAN) to keep consistency
in the Whiteboard and ULA prefix. However if Edge Routers in an Ad-
hoc LoWPAN are able to emulate backbone link functionality between
each other, and to coordinate the ULA prefix then there MAY be
multiple Edge Routers if they implement Extended LoWPAN ER
functionality.
8.5. Registration process
An 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 Node Registration messages with a hop
limit that is lower than 255 but it MUST drop a Node Registration
that does not come from a LoWPAN interface that is associated to the
same subnet.
The new Owner Interface Identifier Option in Backbone Link ND
messages that carries the node OII, Owner Nonce and TID help
differentiate an address collision from a new registration from the
same node. Details on collision detection and resolution are
Shelby, et al. Expires April 29, 2010 [Page 40]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
provided in Section 8.7.
The Edge Router responds to a Node Registration with a Node
Confirmation. If the source address of the NR was not the
Unspecified Address, then the destination address in the confirmation
is the source in the NR. If the source address of the NR was the
Unspecified Address, then the ER acts as the LoWPAN Router for the
source, and the destination address is the optimistic address being
registered. The destination link-layer address is not taken from the
ND cache but from the source link-layer address in the NR. The
source address is a unicast address of the ER that matches the scope
of the destination, preferably the destination in the NR if it is not
anycast.
The remainder of this section deals with the case of an Extended
LoWPAN configuration. In that case:
When it inserts an address in its Whiteboard, an Edge Router SHOULD
perform Duplicate Address Detection (DAD) over the Backbone Link to
detect a collision. Upon a new registration for a link-local, unique
local or global unicast address based on an IEEE 64-bit extended MAC
address, the Edge Router MAY use Optimistic DAD [RFC4429] on the
Backbone Link. A positive acknowledgement can be sent to the 6LoWPAN
node right away if oDAD is used on the Backbone 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 renumbering. To enable this, the ND operation on the Backbone
Link upon a Node Registration/Confirmation flow wins the address
ownership over an ND 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 will yield and deprecate its binding.
The override (O) bit is used to differentiate a registration flow
from the asynchronous defense of an address by an Edge Router acting
as a proxy. Upon a registration flow, an Edge Router doing DAD or
accepting a reregistration SHOULD set the override (O) bit in its NA
messages. Asynchronously to the registration, the Edge Router 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 Backbone 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
Shelby, et al. Expires April 29, 2010 [Page 41]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
will yield should another Edge Router claim that address on the
Backbone Link.
This specification also introduces the concept of a 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. This feature
is used for fault tolerance, explained in Section 8.9.
If the Edge Router is primary for a registration as indicated by the
'P' flag and it is connected to a Backbone, then it SHOULD perform ND
operations on the backbone. In particular the Edge Router SHOULD
reject the registration if DAD fails on the backbone. When oDAD is
used over the backbone the Edge Router MAY issue the Node
Confirmation right away with a positive code, but if a collision is
finally detected, it cancels the registration with an asynchronous
Node Confirmation and a negative completion code on the same TID.
If the NR message includes an Address Option with the 'A' flag set,
this indicated the request of short address generation. The ER
acquires an appropriate, unique link-layer address for the network
either by generating it and performing DAD, or with some other
method. If successful, this address is returned in an Address Option
of the NC with the 'A' flag set. The IPv6 address is formed from the
generated link-layer address with the default prefix inline.
8.6. Forwarding packets between a LoWPAN and an IPv6 infrastructure
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; otherwise, the
Edge Router MUST discard the packet.
If the packet is to be transmitted over a Backbone or Backhaul Link,
then the 6LoWPAN sublayer is terminated and the full IPv6 packet is
reassembled and expanded. When forwarding a packet from the Backbone
or Backhaul 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.
From the standpoint of an Edge Router, the view of the subnet in the
Extended LoWPAN modality is that all nodes in the subnet are either
LoWPAN nodes registered to this ER or local on the Backbone Link,
though in fact they might be proxied for by other ERs. If the
destination is a LoWPAN node registered to this ER, the ER will
forward the packet over the LoWPAN interface either as a local
delivery if the node is local or via intermediate LoWPAN routers
using the routing in place in the LoWPAN. If the destination is not
Shelby, et al. Expires April 29, 2010 [Page 42]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
a registered LoWPAN node, then the ER acts as if the subnet was local
on the Backbone and looks up the node there using ND. If the node is
not found there either, it is assumed unreachable and an "Destination
Unreachable" ICMP message is sent to the source as prescribed by
[RFC4443].
8.7. Address collision detection and resolution
The assumption in this section is that the OII that is carried in the
registration messages and in the NS/NA messages is globally unique.
When this assumption fails, this is detected by an additional
collision resolution mechanism, as detailed in Section 8.8.
The address collision can be detected within the Edge Router if the
Edge Router already has a registration for a given address, or over
the Backbone Link using Duplicate Address Detection. In the latter
case, a new ND option, the Owner Interface Identifier Option is used
in NS/NA messages to carry the additional information required for
the resolution of conflicts: Transaction ID, Owner Interface
Identifier, and Owner Nonce. In any case, the Edge Router in charge
of the resolution is the Edge Router that handles the registration.
A registration is identified by the (OII, IPv6 address) pair. A
conflict occurs when a Node Registration is received for an IPv6
address that is already registered with a different OII at the same
or another Edge Router. The resolution of such conflict is explained
below.
Additionally, the following principles apply to the resolution in the
Extended LoWPAN modality:
Mobility within a subnet is supported and welcome. In an Extended
LoWPAN, a LoWPAN Node may migrate its registration to a new Edge
Router transparently and at any time. The protocol is designed to
recognize the mobility and silently cleanup the registration
states.
A synchronous operation wins against a delayed proxy operation.
An Edge Router that processes a Node Registration normally takes
over an existing registration maintained by a defendant Edge
Router.
The decision to migrate the registration from an Edge Router to
another is made by the Edge Router that processes a Node
Registration message based on its own states for that registration
and ND exchanges over the Backbone Link.
Shelby, et al. Expires April 29, 2010 [Page 43]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
A conflict may also occur with a node that is already present on
the Backbone Link when the registration occurs, or with a node
that appears on the Backbone Link while a registration already
exists for its claimed address. The resolution of such conflict
is done using classic Duplicate Address Detection as prescribed by
[RFC4862].
A claim for an address with a better proof of ownership wins. For
instance a node on the backbone that proves ownership of an
address by means of Secure ND [RFC3971] wins over a node that does
not. The concept of "better" is a policy and is not specified
hereafter, though it is REQUIRED for an implementation to enable
the enforcement of such a policy.
Upon receiving a Node Registration message, an Edge Router looks up
an existing registration for that IPv6 address in its LoWPAN
whiteboard. If the entry does not exist then the Edge Router looks
up the address over the Backbone Link using the NS (DAD) mechanism.
The Edge Router SHOULD include an Owner Interface Identifier Option
in the NS message. An Edge Router that defends that address for an
existing registration MUST include an Owner Interface Identifier
Option in the NA message and SHOULD NOT set the Override (O) bit.
If no entry is found for that address and DAD times out, the Edge
Router accepts the registration: it creates an entry on the
whiteboard, sends a positive Node Confirmation Message to the node,
and advertises the address on the Backbone Link. Since this happens
asynchronously to the Node Registration, the Edge Router SHOULD NOT
set Override (O) bit in the NA message.
If an entry is found in the whiteboard for the same (OII, IPv6
address) pair, additional checking is performed for duplicate OII
detection as detailed in Section 8.8. If no duplication is detected,
then the Edge Router accepts the update of the reservation: it
updates the entry on the whiteboard, sends a positive Node
Confirmation Message to the node, and advertises the address on the
Backbone Link. Since this happens synchronously to the Node
Registration, the Edge Router SHOULD set the Override (O) bit in the
NA message.
If the address is already present on the Backbone Link and defended
by a remote Edge Router, then that Edge Router defends the address
with the Override (O) bit reset and the Owner Interface Identifier
Option in the NA message.
If the Edge Router receives an NA message during the DAD period, it
checks for an Owner Interface Identifier Option in the NA message.
If there is no OII or the (O) bit is set then this is a duplicate
Shelby, et al. Expires April 29, 2010 [Page 44]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
address, DAD fails and the registration is rejected. If there is an
Owner Interface Identifier Option in the NA message and the OII is
different, then DAD fails and the registration is rejected. If the
OII is the same, additional checking is performed for duplicate OII
detection as detailed in Section 8.8. If there is no duplication
then the NA is ignored and the DAD timer keeps going.
If the Edge Router receives an NS (DAD) message from another node
during the DAD period, it checks for a Owner Interface Identifier
Option in the NS message. If there is no OII then DAD fails and the
registration is rejected. If there is an Owner Interface Identifier
Option in the NA message and the OII is different, then DAD fails and
the registration is rejected. If the OII is the same, then the
greatest TID wins. In other words, if the TID in the registration is
smaller than or equal to the TID in the OII Option then DAD fails and
the registration is rejected. Otherwise the NS is ignored and the
DAD timer keeps going.
Other Edge Routers are informed of a take over decision by an NA with
the Override (O) bit set and silently set their own state to non-
operational. An Edge Router that loses ownership should attempt to
keep the registration entry in the whiteboard till the end of the
registration lifetime for the purpose of duplicate OII detection if
memory capacity allows. The TID in the whiteboard entry is updated
with that in the OII option in the NA.
8.8. Duplicate OII detection
The address collision detection mechanism described in the previous
section only works if OII values are unique to each node. The
purpose of the duplicate OII detection mechanism specified in this
section is to find out where this is not the case. Note that such an
OII collision is a "cannot happen", as the EUI-64 assignment
mechanisms are supposed to ensure its uniqueness. Still, accidents
(as well as deliberate rogue behavior, e.g. by counterfeiters) do
happen. The objective here is to reliably detect, not to remedy,
such a situation.
In conjunction with the OII, two values are sent in each Node
Registration (and in the OII option sent with NS/NA) to help with
duplicate OII detection: The transaction ID (TID) and the Owner
Nonce. The TID is a sequence number that is also used to control the
normal operation of a registration exchange, relating a node
confirmation to its node registration. The TID is set by a node in
its Node Registration message and echoed by the Edge Router in the
Node Confirmation message.
The TID is maintained using the lollipop mechanism. When a node
Shelby, et al. Expires April 29, 2010 [Page 45]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
starts or restarts, it sets its local next TID to zero and its local
Owner Nonce to a random value. (While cryptographic randomness
[RFC4086] is not strictly required, the randomness SHOULD be derived
using a mechanism of similar quality.) After that, the node
increments the local next TID after sending each Request Node
Registration, but keeps the Owner Nonce constant. When the TID needs
to be incremented beyond its maximum value (0xFF), it wraps directly
to its looping value at the base of the lollipop that is 16 (0x10).
So a value in the straight part of the lollipop (between 0 and 0xF)
is only used after a reboot and before the circular part of the
lollipop is entered.
Upon a positive Node Confirmation, if the current local next TID is
less than 16, then the node sets it to 16. Regardless of its current
local next TID, a node that has not heard a valid Node Confirmation
for 16 Node Registration messages in a row restarts with a local next
TID of zero (the node MAY, but need not, generate a new Owner Nonce).
In summary, this means a TID less than 16 (in the straight part of
the lollipop) denotes a node that just started/restarted and did not
get registered yet (or did not hear the acknowledgement), so we call
such a TID an unacknowledged TID; conversely, TIDs of 16 or larger
are acknowledged TIDs.
To compare TID1 and TID2, the following rules apply:
If at least one of TID1 and TID2 is unacknowledged (smaller than
16) then they compare directly.
If both TID1 and TID2 are acknowledged, then TID2 is greater than
TID1 if (TID2 - TID1) is smaller than (TID1 - TID2).
A TID value is consistent with the preceding one if it is the same or
a small increment or decrement (more by or less by 0 to 16) from the
preceding one. If the TID arriving in a Node Registration message at
an Edge Router is the same or a small decrement as a preceding one,
then a registration message was duplicated or two of them crossed and
the most recent message should be ignored; this is not necessarily an
indication of an OII collision.
A Node Registration message is consistent with the Whiteboard entry
if the TIDs are consistent and the Owner Nonce values are the same.
As long a new Node Registration message is consistent with the
current whiteboard entry, it appears that the new message is coming
from the same source as the previous one and there is no OII
collision.
If the TID in a new Node Registration message jumps back to an
unacknowledged value, this can be interpreted as either a new node
Shelby, et al. Expires April 29, 2010 [Page 46]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
competing for the OII and a reboot by the node owning the
registration. With this specification, this situation is
optimistically interpreted as a reboot and not detected as a
collision, but an actual collision will be detected and filtered out
next. For now, TID and OII from the new Node Registration message
are copied into the Whiteboard entry.
Otherwise, i.e., the TID in a new Node Registration is an
acknowledged TID, if that is inconsistent with the most recently
accepted TID value, or if the Owner Nonce values do not match, then
the Node Registration message is rejected as an OII collision.
+--------------+-----------+-----------+---------+---------+--------+
| Case | OII | Nonce | TID | Address | Action |
+--------------+-----------+-----------+---------+---------+--------+
| Initial | Unique | * | * | Unique | Accept |
| Registration | | | | | |
| New Address | Duplicate | Same | > | * | Accept |
| or Movement | | | | | |
| Duplicate | Duplicate | Same | <= | * | Ignore |
| Message | | | | | |
| Node Reboot | Duplicate | Different | < 0x10 | * | Accept |
| OII | Duplicate | Different | >= 0x10 | * | Reject |
| Collision | | | | | |
+--------------+-----------+-----------+---------+---------+--------+
Table 1: The processing options for NR messages (* = wildcard)
8.9. Fault tolerance
This specification allows for a secondary registration. The
secondary registration enables the node to prepare states within the
network and make the move quicker between primary and secondary.
If an external keep alive mechanism is in place between the primary
and the secondary Edge Routers, then the secondary registration
enables the secondary Edge Router to start intercepting packets on
the backbone and forwarding them to the node before the node even
knows that the primary is no longer operational.
The secondary registration also enables the node to bicast a packet
for extra reliability, that is send a copy of a packet to both Edge
Routers without being subject to ingress filtering. The mechanism
that enables this filtering is not specified here.
Shelby, et al. Expires April 29, 2010 [Page 47]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
9. Protocol Constants
This section defines the protocol constants used in this document
based on a subset of [RFC4861] constants. (*) indicates constants
modified from [RFC4861] and (+) indicates new constants.
Additional protocol constants are defined in Section Section 4.
Edge Router Constants:
MIN_CONTEXT_CHANGE_DELAY+ 60 seconds
Router Constants:
MAX_INITIAL_RTR_ADVERT_INTERVAL* 60 seconds
MAX_INITIAL_RTR_ADVERTISEMENTS 3 transmissions
MAX_FINAL_RTR_ADVERTISEMENTS 3 transmissions
MIN_DELAY_BETWEEN_RAS* 10 seconds
MAX_RA_DELAY_TIME* 2 seconds
Host Constants:
MAX_RTR_SOLICITATION_DELAY* 2 second
RTR_SOLICITATION_INTERVAL* 10 seconds
MAX_RTR_SOLICITATIONS 3 transmissions
Node Constants:
MAX_NR_RETRIES+ 3 transmissions
MIN_NR_TIMEOUT+ 5 seconds
10. Use of 6LoWPAN-ND under RFC4861-only stacks
Some IPv6 stacks (e.g. on PCs) and tools (e.g. radvd) hard-wire the
mechanisms of RFC4861 for all links. This section explains the
adaptation needed in order to use a 6LoWPAN interface under such an
RFC4861-only implementation.
There are several ways to implement 6LoWPAN-ND in combination with an
IPv6 stack:
Shelby, et al. Expires April 29, 2010 [Page 48]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
o 6LoWPAN-ND is integrated with the IPv6 stack and its tools. This
is common for LoWPAN nodes.
o 6LoWPAN-ND is implemented as part of the interface, configuration
is used to turn off RFC4861 mechanisms in the IPv6 stack. For
example, Proxy-ND interfaces can be used in Linux to disable most
built-in ND mechanisms. This model is common for Edge Routers
running on a standard operating system.
o 6LoWPAN-ND is implemented as part of the interface, and it
performs adaptation for RFC4861 mechanisms running on the IPv6
stack. The binding cache (also whiteboard for an ER) are used to
answer RFC4861 messages, and appropriate options added to RA
messages.
Classic RS/RA messages can be used with a LoWPAN, thus allowing e.g.
for an unmodified radvd (with appropriate configuration) to be run on
an Edge Router as long as context dissemination is not needed. It is
however recommended that 6IO and 6SO options be used if possible,
which is easily achieved by patching existing RA tools or performing
adaptation.
11. Message Examples
This section provides basic examples of messages and options from
this document.
11.1. Basic NR/NC message exchange
In the basic case, when a host wanting to register to the whiteboard
is on the same link with an ER, a simple NR/NC request message
exchange occurs. In this example a host wants to register its
address generated with Stateless Address Autoconfiguration (SAA), and
in addition requests a generated short address.
First the Host sends an NR message to the link-local address of the
ER. In this example the host wants to use the Edge Router as
primary, a 10 minute binding lifetime, a 60 second advertisement
interval , and its modified EUI-64 as the Owner Interface Identifier.
The message has two Address Options. The host has just booted,
therefore the TID starts with 0. This example assumes that the
LoWPAN prefix has been assigned CID 0.
Shelby, et al. Expires April 29, 2010 [Page 49]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
IPv6 Source: Unspecified address
IPv6 Destination: ER's link-local address
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 = TBD | 0 | 0 | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TID = 0 |1|0| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding Lifetime = 10 | Advertising Interval = 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Owner Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Owner Interface Identifier = +
| Modified EUI-64 of the interface |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Basic NR request.
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 = TBD | Length = 1 | Status = 0 | S=1 | P=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0| Reserved | Padding = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: NR Address Option 1, for the SAA address.
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 = TBD | Length = 1 | Status = 0 | S=2 | P=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1|0| Reserved | Padding = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: NR Address Option 2, for the requested address.
Shelby, et al. Expires April 29, 2010 [Page 50]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
IPv6 Source: ER's link-local address
IPv6 Destination: Host's link-local address
The base NC message is identical to the base NR message above.
Figure 14: Corresponding NC message.
Address Option 1 is identical to Address Option 1 in the NR.
Figure 15: NC Address Option 1, for the SAA address.
Address Option 2 now includes the generated address.
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 = TBD | Length = 1 | Status = 0 | S=2 | P=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1|0| Reserved | Generated 16-bit address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: NC Address Option 2, for the requested address.
11.2. Relaying an NR message
In case an ER is non-local for initial node registration, then the NR
message from the previous example is sent to any local router in
exactly the same format. This router in turn relays the message to
an ER. As the OII of the Host is the same as its IID, the Router
simply sets Code = 1 to indicate that the message was relayed. The
destination IPv6 address is that of an Edge Router and the source
IPv6 address that of the relaying router. The Address Options are
not modified.
Shelby, et al. Expires April 29, 2010 [Page 51]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
IPv6 Source: Router's global address
IPv6 Destination: ER's global address
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 = TBD | 0 | 1 | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TID = 0 |1|0| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding Lifetime = 10 | Advertising Interval = 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Owner Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Owner Interface Identifier = +
| Modified EUI-64 of the interface |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Relayed NR message.
11.3. Router advertisement
Routers and Edge Routers in LoWPAN networks periodically send RA
messages. In the following example is of an RA message sent by a
router. The only difference if an Edge Router would send the message
is that the Preference flag would be 10.
In the example the Preference flag is 01 (router), and a 1200s Router
Lifetime is advertised. A 6LoWPAN Prefix Information Option is
included.
IPv6 Source: Router's link-local address
IPv6 Destination: All-nodes multicast address
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 = 134 | Code = 0 | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |0|0|0|0 0|Rsrvd| Router Lifetime = 1200 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Shelby, et al. Expires April 29, 2010 [Page 52]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
Figure 18: RA message example.
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 = TBD | Length = 2 | PL = 64 |0|1|1|1| CID=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime = 3000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Prefix = 2001:DB8::/64 .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: 6LoWPAN Information Option example.
12. Security Considerations
The security considerations of IPv6 Neighbor Discovery [RFC4861]
apply. Additional considerations can be found in [RFC3756].
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 other words, model 1
from [RFC3756] applies. 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 tampering 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.
The use of EUI-64 for forming the Interface ID in the link local
address prevents the usage of Secure ND ([RFC3971] and [RFC3972]) and
address privacy techniques. Considering the envisioned deployments
and the MAC layer security applied, this is not considered an issue
at this time.
The use of Secure ND has been considered for securing NS/NA messages
exchanged between Edge Routers on the backbone link.
The use of IP-level forwarding of NR/NC ND messages requires relaxed
checking of Hop Limit values in ND packets received, compared to the
validation required by [RFC4861]. This may make ND vulnerable to
off-LoWPAN senders that accidentally or intentionally send ND
messages. This specification states that Edge Routers MUST implement
measures to filter out such off-LoWPAN ND messages.
Shelby, et al. Expires April 29, 2010 [Page 53]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
13. IANA Considerations
This document requires two new ICMPv6 message types:
o Node Registration (TBD1)
o Node Confirmation (TBD2)
The document also requires four new ND option types under the
subregistry "IPv6 Neighbor Discovery Option Formats":
o 6LoWPAN Address Option (TBD3)
o 6LoWPAN Information Option (TBD4)
o 6LoWPAN Summary Option (TBD5)
o Owner Interface Identifier Option (TBD6)
[TO BE REMOVED: This registration should take place at the following
location: http://www.iana.org/assignments/icmpv6-parameters]
There is also the need for a new link local anycast address,
6LOWPAN_ER for 6LoWPAN edge routers and Routers; used as a functional
address.
[TO BE REMOVED: This registration should take place at the following
location: http://www.iana.org/assignments/ipv6-anycast-addresses]
14. Acknowledgments
The authors thank Richard Kelsey, Geoff Mulligan, Julien Abeille,
Alexandru Petrescu, Peter Siklosi, Pieter De Mil, Fred Baker, Anthony
Schoofs, Phil Roberts and Joakim Eriksson for useful discussions and
comments that have helped shaped and improve this document.
15. Changelog
Changes from -06 to -07:
o Updated addressing and address resolution (#60).
o Changed the Address Option to 6LoWPAN Address Option, fixed S
values (#61).
Shelby, et al. Expires April 29, 2010 [Page 54]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
o Added support for classic RFC4861 RA Prefix Information messages
to be processed (#62).
o Added a section on using 6LoWPAN-ND under a hard-wired RFC4861
stack (#63).
o Updated the NR/NC message with a new Router flag, combined the
Code and Status fields into one byte, and added the capability to
carry 6IOs (#64).
o Made co-existence with other ND mechanisms clear (#59).
o Added a new Protocol Specification section with all mechanisms
specified there (#59).
o Removed dependencies and conflicts with RFC4861 wherever
possible (#59).
o Some editorial cleanup.
Changes from -05 to -06:
o Fixed the Prf codes (#52).
o Corrected the OIIO TID field to 8-bits. Changed the Nonce/OII
order in both the OIIO and the NR/NC. (#53)
o Corrected an error in Table 1 (#54).
o Fixed asymmetric and a misplaced transient in the 6LoWPAN
terminology section.
o Added Updates RFC4861 to header
Changes from -04 to -05:
o Meaning of the RA's M-bit changed to original [RFC4861] meaning
(#46).
o Terms "local" and "non-local" used in place of "on-link" and
"off-link".
o Next-hop determination text simplified (#49).
o Neighbor cache and destination cache removed.
o IID to link-layer address requirement relaxed.
Shelby, et al. Expires April 29, 2010 [Page 55]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
o NR/NC changes to enable local refresh with routers (#48).
o Modified 6LoWPAN Information Option (#47).
o Added a Protocol Constants section (#24)
o Added the NR processing table (#51)
o Considered the use of SeND on backbone NS/NA messages (#50)
Changes from -03 to -04:
o Moved Ad-hoc LoWPAN operation to Section 7 and made ULA prefix
generation a features useful also in Simple and Extended LoWPANs.
(#41)
o Added a 32-bit Owner Nonce to the NR/NC messages and the
Whiteboard, removed the TID history. (#39)
o Improved the duplicate OII detection algorithm using the Owner
Nonce. (#39)
o Clarified the use of Source and Target link-layer options in
NR/NC. (#43)
o Included text on the use of alternative methods to acquire
addresses. (#38)
o Removed S=2 from Address Option (not needed). (#36)
o Added a section on router dissemination consistency. (#44)
o Small improvements and extensive editing. (#42, #37, #35)
Changes from -02 to -03:
o Updated terminology, with RFC4861 non-transitive link model.
o 6LoWPAN and ND terminology separated.
o Protocol overview explains RFC4861 diff in detail.
o RR/RC is now Node Registration/Confirmation (NR/NC).
o Added NR failure codes.
o ER Metric now included in 6LoWPAN Summary Option for use in
default router determination by hosts.
Shelby, et al. Expires April 29, 2010 [Page 56]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
o Examples of host data structures, and the Whiteboard given.
o Whiteboard is supported by all Edge Routers for option
simplicity.
o Edge Router Specification chapter re-structured, clarifying
optional Extended LoWPAN operation.
o NS/NA now completely optional for nodes. No address resolution
or NS/NA NUD required.
o Link-local operation now compatible with oDAD (was broken).
o Exception to hop limit = 255 for NR/NC messages.
o Security considerations improved.
o ICMPv6 destination unreachable supported.
Changes from -01 to -02:
o Fixed 16 != 0xff bug (ticket closed).
o Specified use of ULAs in ad-hoc LoWPAN section 9 (ticket
closed).
o Terminology cleanup based on Alex's comments.
o General editing improvements.
Changes from -00 to -01:
o Specified the duplicate owner interface identifier procedures.
A TID lollipop algorithm was sufficient (nonce unnecessary).
o Defined fault tolerance using secondary bindings.
o Defined ad-hoc network operation.
o Removed the E flag from RA and the X flag from RR/RC.
o Completed message examples.
o Lots of improvements in text quality and consistency were made.
16. References
Shelby, et al. Expires April 29, 2010 [Page 57]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
16.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6
over Non-Broadcast Multiple Access (NBMA) networks",
RFC 2491, January 1999.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[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.
16.2. Informative References
[I-D.ietf-6lowpan-hc]
Hui, J. and P. Thubert, "Compression Format for IPv6
Datagrams in 6LoWPAN Networks", draft-ietf-6lowpan-hc-06
(work in progress), October 2009.
[RFC2022] Armitage, G., "Support for Multicast over UNI 3.0/3.1
based ATM Networks", RFC 2022, November 1996.
Shelby, et al. Expires April 29, 2010 [Page 58]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
[RFC3122] Conta, A., "Extensions to IPv6 Neighbor Discovery for
Inverse Discovery Specification", RFC 3122, June 2001.
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756,
May 2004.
[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.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
Proxies (ND Proxy)", RFC 4389, April 2006.
[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903,
June 2007.
[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.
Authors' Addresses
Zach Shelby (editor)
Sensinode
Hallituskatu 13-17D
Oulu 90100
FINLAND
Phone: +358407796297
Email: zach@sensinode.com
Shelby, et al. Expires April 29, 2010 [Page 59]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
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
Carsten Bormann
Universitaet Bremen TZI
Postfach 330440
Bremen D-28359
Germany
Phone: +49-421-218-63921
Fax: +49-421-218-7000
Email: cabo@tzi.org
Shelby, et al. Expires April 29, 2010 [Page 60]
Internet-Draft 6LoWPAN Neighbor Discovery October 2009
Erik Nordmark
Sun Microsystems
17 Network Circle
Menlo Park, California 94025
USA
Phone:
Email: Erik.Nordmark@Sun.COM
Shelby, et al. Expires April 29, 2010 [Page 61]
