One document matched: draft-ietf-6lowpan-nd-08.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2022 SYSTEM "reference.RFC.2022.xml">
<!ENTITY RFC2119 SYSTEM "reference.RFC.2119.xml">
<!ENTITY RFC2491 SYSTEM "reference.RFC.2491.xml">
<!ENTITY RFC3122 SYSTEM "reference.RFC.3122.xml">
<!ENTITY RFC3971 SYSTEM "reference.RFC.3971.xml">
<!ENTITY RFC3972 SYSTEM "reference.RFC.3972.xml">
<!ENTITY RFC3756 SYSTEM "reference.RFC.3756.xml">
<!ENTITY RFC4086 SYSTEM "reference.RFC.4086.xml">
<!ENTITY RFC4191 SYSTEM "reference.RFC.4191.xml">
<!ENTITY RFC4193 SYSTEM "reference.RFC.4193.xml">
<!ENTITY RFC4291 SYSTEM "reference.RFC.4291.xml">
<!ENTITY RFC4429 SYSTEM "reference.RFC.4429.xml">
<!ENTITY RFC4443 SYSTEM "reference.RFC.4443.xml">
<!ENTITY RFC4861 SYSTEM "reference.RFC.4861.xml">
<!ENTITY RFC4862 SYSTEM "reference.RFC.4862.xml">
<!ENTITY RFC4903 SYSTEM "reference.RFC.4903.xml">
<!ENTITY RFC4919 SYSTEM "reference.RFC.4919.xml">
<!ENTITY RFC4944 SYSTEM "reference.RFC.4944.xml">
<!ENTITY I-D.ietf-6lowpan-hc SYSTEM "reference.I-D.ietf-6lowpan-hc.xml">
<!ENTITY I-D.ietf-autoconf-adhoc-addr-model SYSTEM "reference.I-D.ietf-autoconf-adhoc-addr-model.xml">
<!ENTITY sixlowpan-terminology SYSTEM "../6lowpan-terminology.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" ipr="trust200902" updates="4944" docName="draft-ietf-6lowpan-nd-08">
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<front>
<title>6LoWPAN Neighbor Discovery</title>
<author initials="Z" surname="Shelby" fullname="Zach Shelby" role="editor">
<organization>
Sensinode
</organization>
<address>
<postal>
<street>Hallituskatu 13-17D</street>
<city>Oulu</city>
<code>90100</code>
<country>FINLAND</country>
</postal>
<phone>+358407796297</phone>
<email>zach@sensinode.com</email>
</address>
</author>
<author initials="P" surname="Thubert" fullname="Pascal Thubert">
<organization abbrev="Cisco">
Cisco Systems
</organization>
<address>
<postal>
<street>Village d'Entreprises Green Side</street>
<street>400, Avenue de Roumanille</street>
<street>Batiment T3</street>
<city>Biot - Sophia Antipolis</city>
<code>06410</code>
<country>FRANCE</country>
</postal>
<phone>+33 4 97 23 26 34</phone>
<email>pthubert@cisco.com</email>
</address>
</author>
<author fullname="Jonathan W. Hui" initials="J.H." surname="Hui">
<organization abbrev="Arch Rock">Arch Rock Corporation</organization>
<address>
<postal>
<street>501 2nd St. Ste. 410</street>
<city>San Francisco</city>
<region>California</region>
<code>94107</code>
<country>USA</country>
</postal>
<phone>+415 692 0828</phone>
<email>jhui@archrock.com</email>
</address>
</author>
<author fullname="Samita Chakrabarti" initials="S" surname="Chakrabarti">
<organization>IP Infusion</organization>
<address>
<postal>
<street>1188 Arquest Street</street>
<city>Sunnyvale</city>
<region>California</region>
<code></code>
<country>USA</country>
</postal>
<phone></phone>
<email>samitac@ipinfusion.com</email>
</address>
</author>
<author initials="C." surname="Bormann" fullname="Carsten Bormann">
<organization>Universität Bremen TZI</organization>
<address>
<postal>
<street>Postfach 330440</street>
<city>Bremen</city>
<code>D-28359</code>
<country>Germany</country>
</postal>
<phone>+49-421-218-63921</phone>
<facsimile>+49-421-218-7000</facsimile>
<email>cabo@tzi.org</email>
</address>
</author>
<author fullname="Erik Nordmark" initials="E" surname="Nordmark">
<organization abbrev="Sun">Sun Microsystems</organization>
<address>
<postal>
<street>17 Network Circle</street>
<city>Menlo Park</city>
<region>California</region>
<code>94025</code>
<country>USA</country>
</postal>
<phone></phone>
<email>Erik.Nordmark@Sun.COM</email>
</address>
</author>
<date year="2010"/>
<area>Internet</area>
<workgroup>6lowpan Working Group</workgroup>
<abstract>
<t>
This document specifies a new Neighbor Discovery mechanism suitable for LoWPANs.
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 a simple Neighbor Discovery mechanism both sufficient yet minimal for LoWPAN operation.
</t>
</abstract>
</front>
<middle>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='introduction' title="Introduction">
<t>The IPv6 over IEEE 802.15.4 <xref target="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 <xref target="RFC4861"/> is not desirable in such a wireless low-power, lossy network. </t>
<t>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, <xref target="RFC2491"/>) structure with (generally) no LoWPAN-wide multicast capabilities. link-local scope is in reality defined by reachability and radio strength. Thus we can consider a LoWPAN to be made up of links with undetermined connectivity properties as defined in <xref target="I-D.ietf-autoconf-adhoc-addr-model"/>, along with the corresponding assumptions defined therein. The classic IPv6 Neighbor Discovery <xref target="RFC4861"/> control messages, the use of multicast and their default frequency also attribute to unnecessary waste of energy in LoWPANs.</t>
<t>This specification introduces a new mechanism called Node Registration, used to optimize the interface between hosts and routers in a LoWPAN. That registration mechanism provides a service somewhat similar to the Multicast Address Resolution Server (MARS) <xref target="RFC2022"/> for a limited purpose, and in a much simpler and less generic fashion. The use of Router Advertisements to disseminate prefix and header compression context throughout the LoWPAN is also specified. 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 <xref target="RFC4861"/>, <xref target="RFC3122"/> or other future ND mechanisms (although the motivation or detailed specification of such coexistence is out of scope for the present document).
</t>
<t>The document defines two new ICMPv6 messages: Node Registration and Node Confirmation.</t>
<section anchor='goalsnassumptions' title="Goals, Assumptions, and Guesses">
<t>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.</t>
<t>Goals:
<list style="symbols">
<t>Optimize ND with a mechanism that is minimal yet sufficient for LoWPAN operation in both mesh-under and route-over configurations.</t>
<t>Minimize signalling by avoiding the use of multicast flooding and reducing the frequency of link scope multicast messages inside the LoWPANs.</t>
<t>Disseminate context information throughout the LoWPAN used by <xref target="I-D.ietf-6lowpan-hc"/>.</t>
<t>Minimize the complexity of LoWPAN Nodes.</t>
<t>Optimize the interfaces between nodes and their default routers.</t>
</list>
</t>
<t>Assumptions:
<list style="symbols">
<t>A subnet includes all the LoWPAN Nodes sharing the same IPv6 prefix.</t>
<t>A single LoWPAN is configured in a homogeneous way, i.e., IIDs are formed by nodes in a uniform matter and DAD is performed by routers in a uniform way.</t>
<t>Link layer technology is e.g. IEEE 802.15.4 as in <xref target="RFC4944"/>, or any other link-layer exhibiting non-transitivity or a similar topology.</t>
</list>
</t>
</section>
<section anchor='why_not' title="Why not classic IPv6 ND?">
<t>IPv6 Neighbor Discovery <xref target="RFC4861"/> provides several
important functions such as Router Discovery, Address Resolution, Duplicate
Address Detection, Redirect, Prefix and Parameter Discovery.</t>
<t>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.</t>
<t>A LoWPAN network typically uses two types of L2 addresses — for example 16-bit short addresses and 64-bit unique addresses as defined in <xref target="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. 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 <xref target="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.</t>
</section>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='terminology' title="Terminology">
<t>
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 <xref target="RFC2119"/>.
</t>
<t>
This specification requires readers to be familiar with all the terms and concepts that are discussed in <xref target="RFC4862">"IPv6 Stateless Address Autoconfiguration"</xref>, <xref target="RFC4919">"IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals"</xref>, <xref target="RFC4944"> "Transmission of IPv6 Packets over IEEE 802.15.4 Networks"</xref> and <xref target="I-D.ietf-autoconf-adhoc-addr-model">"IP Addressing Model in Ad Hoc Networks"</xref>.
</t>
<t>
Readers would benefit from reading <xref target="RFC4429">"Optimistic Duplicate Address Detection" </xref> ("oDAD") prior to this specification.
</t>
<t>
This specification makes extensive use of the same terminology defined in
<xref target="RFC4861"/> unless otherwise redefined below.
</t>
<section anchor='sixlowpanterminology' title="6LoWPAN Terminology">
&sixlowpan-terminology;
</section>
<section anchor='ndterminology' title="ND Terminology">
<t>This section defines Neighbor Discovery specific terminology used in this specification:
<list style="hanging">
<t hangText="Simple LoWPAN"></t>
<t>A Simple LoWPAN consists of a single Edge Router and the set of LoWPAN nodes on the same LoWPAN Subnet, shown in <xref target="figsimple"/>.
</t>
<t hangText="Ad-hoc LoWPAN"></t>
<t>An isolated LoWPAN, not connected to any other IP networks. Ad-Hoc LoWPANs make use of Unique on-link IPv6 Unicast Addresses (ULAs) <xref target="RFC4193"/>.
</t>
<t hangText="Backbone Link"></t>
<t>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.
</t>
<t hangText="LoWPAN Edge Router"></t>
<t>An IPv6 router that interconnects the LoWPAN to another IP network. Referred to as an Edge Router in this document.
</t>
<t hangText="Registration"></t>
<t>The process during which a LoWPAN node sends a Node Registration message to a Router creating a binding for the LoWPAN node.
</t>
</list>
</t>
<figure anchor='figsimple'
title="A simple LoWPAN topology">
<artwork><![CDATA[
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
]]></artwork>
</figure>
</section>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='overview' title="Protocol Overview">
<t>
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 synchronization between hosts using the same router. This specification is REQUIRED for LoWPAN operation, but MAY also coexist with <xref target="RFC4861"/>, <xref target="RFC3122"/> or other future ND mechanisms. Any use of <xref target="RFC4944"/> without this specification is NOT RECOMMENDED.
</t>
<t>
The following features are defined by 6LoWPAN-ND (see Section <xref target="protocol"/> for details):
<list style="hanging">
<t hangText="Node Registration:">Method in which nodes in the LoWPAN register with Routers, creating state about nodes attached to that router (binding table).</t>
<t hangText="Next-hop Determination:">The specification defines a simple next-hop determination rule.</t>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="Context Dissemination:">The dissemination of LoWPAN context as used by <xref target="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.</t>
</list>
</t>
<t>
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:
<list style="hanging">
<t hangText="Node Registration (NR):">Sent by a node to a Router to register a binding.</t>
<t hangText="Node Confirmation (NC):">The response sent by a Router back to the registering node.</t>
</list>
</t>
<section anchor='overviewtop' title="Topology">
<t>
6LoWPAN-ND makes little assumption about synchronization between nodes in a LoWPAN except between a node and the routers it has registered with. 6LoWPAN-ND is designed to work also with Ad-hoc topologies. The case of Ad-hoc LoWPAN operation is described in <xref target="adhoc"/>.
</t>
<t>
6LoWPAN-ND is compatible with the use of link-layer mesh or <xref target="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 <xref target="roperation"/>. 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 be possible to combine IP routing and mesh link-layers within a LoWPAN.
</t>
</section>
<section anchor='overviewbs' title="Bootstrapping">
<t>
1. A node (host or router) first forms an Interface Identifier (IID) from its EUI-64 or other appropriate MAC address, and goes on to form a link-local unicast address as in <xref target="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 on-link routers (see <xref target="figmessrsra"/>). If a valid prefix is advertised in the RA, the host may also autoconfigure a global address. At this point the node has also chosen one or more default routers based on RAs.
</t>
<t>
2. Next the node will attempt to perform initial Node Registration. Registration is always performed with a link-local Router by sending a unicast Node Registration (NR) message to it. This message exchange is illustrated in <xref target="figmessbasic"/>. The NR includes the addresses the node wants to register, and it is possible to request the router to assign an address.
</t>
<t>
3. After processing the addresses and performing DAD if necessary, the Router replies with a Node Confirmation (NC). This confirmation includes the set of addresses now confirmed by this router. The Host is now capable of using the LoWPAN.
</t>
<figure anchor='figmessrsra'
title="Basic RS/RA exchange between a node and any on-link router (LoWPAN Router or Edge Router)">
<artwork><![CDATA[
Node Router
| |
| ---------- Router Solicitation --------> |
| |
| <-------- Router Advertisement --------- |
| |
]]></artwork>
</figure>
<figure anchor='figmessbasic'
title="Basic ND registration exchange">
<artwork><![CDATA[
Node Router
| |
| ---------- Node Registration --------> |
| |
| <--------- Node Confirmation --------- |
| |
]]></artwork>
</figure>
</section>
<section anchor='overviewbo' title="Operation">
<t>
The node may now send packets to any IPv6 address inside or outside the LoWPAN. Next-hop determination assumes destinations are off-link (and thus forwarded to a default router) except for link-local scope addresses which are always on-link. 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.
</t>
<t>
The LoWPAN Router binding table is soft, and thus must be renewed periodically as indicated by 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. If the host moves to a different LoWPAN (thus with a different subnet prefix), the bootstrapping process is initiated again. See <xref target="node"/> for details on node operation.
</t>
<t>
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 <xref target="roperation"/> for detailed router operation.
</t>
</section>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='mess' title="Message Formats">
<t>
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.
</t>
<t>The following new ICMPv6 message types are defined:
<list style="symbols">
<t>Node Registration (NR)</t>
<t>Node Confirmation (NC)</t>
</list>
</t>
<t>In addition, the following new ICMPv6 options are defined:
<list style="symbols">
<t>6LoWPAN Address Option (6AO)</t>
<t>6LoWPAN Information Option (6IO)</t>
<t>6LoWPAN Summary Option (6SO)</t>
<t>Owner Interface Identifier Option (OIIO)</t>
</list>
</t>
<t>The following <xref target="RFC4861"/> messages are used as specified in this section:
<list style="symbols">
<t>Router Solicitation (RS)</t>
<t>Router Advertisement (RA)</t>
</list>
</t>
<section anchor='bumess' title="Node Registration/Confirmation Message">
<t>
The Node Registration (NR) and Node Confirmation
(NC) messages are used by a node to register with a
Router. 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 on-link Router.
</t>
<t>
When registering the first time the (which then
still has optimistic addresses)
source address of the Node Registration must be the IPv6 unspecified address
to comply with oDAD. In subsequent registrations, the IPv6 source address is then the link-local IPv6 address of the sender. A registration is periodically refreshed by sending a new NR message more frequently than the Binding Lifetime indicated by the node during registraion.
</t>
<!-- ZS: Should it be defined that bindings can be also refreshed by other means. For example if routers periodically exchange routing protocol signalling between themselves, this can serve to refresh a binding? Makes sense for ROLL if you are not piggybacking on NR/NC messages. -->
<t>
Address Options are included in the NR message for each IPv6 address to be
registered, and included in the corresponding NC to indicate success.
</t>
<figure anchor='bsfig' title="Node Registration/Confirmation message format">
<artwork>
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Owner Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Owner Interface Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration option(s)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
<list style="hanging">
<t hangText="IP Fields:">
<list style="hanging">
<t hangText="Source Address:">
The IPv6 address of the source. This address MUST be
the IPv6 unspecified address for initial registration.
</t>
<t hangText="Destination Address:">
The link-local unicast IPv6 address of a on-link router when sent by a node.
</t>
<t hangText="Hop Limit:">
255
</t>
</list>
</t>
<t hangText="ICMP Fields:">
<list style="hanging">
<t hangText="Type:">
TBD1 for Node Registration, TBD2 for Node Confirmation.
</t>
<t hangText="Status:">
4-bit unsigned integer. Sent only in NC messages, ignored in NR messages. Values 0-7 are reserved for success codes:
<list>
<t>0 is unqualified success.</t>
</list>
Values 8-15 are reserved for error codes:
<list>
<t>8 is send to indicate that the router is saturated and an alternative router should be used.</t>
</list>
</t>
<t hangText="Code:">
4-bit unsigned integer.
<list>
<t>0 indicates this NR is a request sent directly from the originating host, or this NC is a corresponding response.</t>
<t>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. (For future use)</t>
<t>2 indicates this NC is a request for the node to re-register.</t>
<t>4-15 are reserved for future use.</t>
</list>
</t>
<t hangText="Checksum:">
The ICMP checksum.
</t>
<t hangText="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 on-link 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.
</t>
<t hangText="P:">
1-bit Primary flag. Not yet used by this specification, always set to 1.
</t>
<t hangText="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.
</t>
<t hangText="Binding Lifetime:">
16-bit unsigned integer. The amount of time in
10 second intervals 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. A value of 0xFFFF indicates
an idefinite lifetime. (The 16-bit field covers up to slightly more than
a week of Binding Lifetime.)
</t>
<t hangText="Reserved:">
This field is unused. It MUST be initialized to
zero by the sender and MUST be ignored by the
receiver.
</t>
<t hangText="Owner Interface Identifier (OII):">
A globally unique identifier for the requesting
host's interface. Typically the EUI-64 derived IID.
</t>
<t hangText="Owner Nonce:">
A 32-bit Nonce generated randomly by the node upon booting, and generated again each time the node re-boots. This Nonce may be used to detect duplicate OIIs.
</t>
</list>
</t>
<t hangText="Possible Options:">
<list style="hanging">
<t hangText="6LoWPAN Address Option(s):">
An Address Option is included for each address the host wants to bind for this
interface.
</t>
<t hangText="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.
</t>
</list>
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.
</t>
</list>
</t>
</section>
<section anchor='rsmess' title="Router Solicitation Message">
<t>
The RS message format for 6LoWPAN is identical to the classic
<xref target="RFC4861"/> RS message. The following clarifications are made regarding the use of RS in LoWPANs.
</t>
<t>
If a node has only optimistic addresses, not yet confirmed by a 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.
</t>
<t>
The Code field of the Router Solicitation message is used to inidicate whether a node wants to receive the full set of 6IOs in the RA response, or just the 6SO. An RS with Code = 0 is used to request just the 6LoWPAN Summary Option, and Code = 1 is used to request the full set of 6IOs.
</t>
</section>
<section anchor='ramess' title="Router Advertisement Message">
<t>
The RA message format for 6LoWPAN is identical to the classic
<xref target="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.
</t>
<t>
<list style="hanging">
<t hangText="Updated Flag Definitions:">
<list style="hanging">
<t hangText="Prf:">
2-bit signed integer. Default Router Preference as defined in <xref target="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.
</t>
</list>
</t>
<t hangText="Options:">
<list style="hanging">
<t hangText="6LoWPAN Information Option:">
This option includes information about the prefixes of the
LoWPAN along with other context information.
</t>
<t hangText="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 when a change has occured, or when requested with an RS Code = 1.
</t>
<t hangText="Prefix Information Option:">
If needed for backward compatibility, an RA may
also be sent using the classic <xref target="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.
</t>
</list>
The MTU and SLLAO options defined in <xref target="RFC4861"/> are not used by this specification.
</t>
<t>
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.
</t>
</list>
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='opt' title="Message Options">
<t>This section defines the new 6LoWPAN-ND message options.</t>
<section anchor='addropt' title="6LoWPAN Address Option">
<t>
The 6LoWPAN Address Option (6AO) is used to indicate the address which a node
wants to register, 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 use, or for an address to be removed.
</t>
<figure anchor='addrfig' title="6LoWPAN Address Option format">
<artwork>
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|O| Reserved | IPv6 Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
<list style="hanging">
<t hangText="Type:">
TBD3
</t>
<t hangText="Length:">
8-bit unsigned integer. The length of the option
(including the type and length fields) in units
of 8 octets.
</t>
<t hangText="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.
</t>
<t hangText="D:">
1-bit Duplicate flag. When set, indicates that
duplicates are allowed for this address (to
support anycast) in a request.
</t>
<t hangText="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.
</t>
<t hangText="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).
</t>
<t hangText="O:">
1-bit Optimistic flag. When set, indicates that
this particular address is optimistic and has not yet been checked for duplicates.
</t>
<t hangText="P:">
5-bit unsigned integer. Identifies prefix
compression or type, if any.
<list style="hanging">
<t hangText="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.
</t>
<t hangText="16:">
Prefix is carried inline.
</t>
<t hangText="17:">
Prefix compressed; upon decompression, the
link-local prefix (fe80::) is inserted.
</t>
<t hangText="18-31:">
Reserved.
</t>
</list>
</t>
<t hangText="S:">
3-bit unsigned integer. Identifies suffix
compression or type, if any.
<list style="hanging">
<t hangText="0:">
Suffix carried inline.
</t>
<t hangText="1:">
Suffix compressed and assumes the same value
as the Owner Interface Identifier field in the
NR/NC message header.
</t>
<t hangText="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 <xref target="RFC4944"/>.
</t>
<t hangText="3-7:">
Reserved.
</t>
</list>
</t>
<t hangText="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.
</t>
</list>
</t>
</section>
<section anchor='sixpreopt' title="6LoWPAN Information Option">
<t>
This option carries prefix information for LoWPANs, and is similar
in use to the Prefix Information Option of <xref target="RFC4861"/>.
However this option allows for the dissemination of multiple contexts
identified by a Context Identifier (CID) for use in 6LoWPAN address
compression.
</t>
<figure anchor='sixlpprefixfig' title="6LoWPAN Information Option format">
<artwork>
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 .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
<list style="hanging">
<t hangText="Type:">
TBD4
</t>
<t hangText="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.
</t>
<t hangText="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.
</t>
<t hangText="L:">
1-bit on-link flag, similar to the L flag in <xref target="RFC4861"/>. This flag MUST be unset for Route Over
LoWPANs and Extended LoWPANs, and MAY be set for
Mesh Under Simple LoWPANs.
</t>
<t hangText="A:">
1-bit autonomous address-configuration flag.
When set indicates that this prefix can be used
for stateless address configuration as specified
in <xref target="RFC4861"/>.
</t>
<t hangText="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.
</t>
<t hangText="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.
</t>
<t hangText="CID:">
4-bit Context Identifier for this prefix information. CID is used
by context based header compression specified in <xref target="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.
</t>
<!-- There is no R field any longer, but it will be back:
<t hangText="R:">
Reserved. This field is unused. It MUST be initialized to
zero by the sender and MUST be ignored by the
receiver.
</t>
-->
<t hangText="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 on-link
determination. A value of all one bits
(0xffffffff) represents infinity.
</t>
<t hangText="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.
</t>
</list>
</t>
</section>
<section anchor='psopt' title="6LoWPAN Summary Option">
<t>
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.
</t>
<figure anchor='psfig' title="6LoWPAN Summary Option">
<artwork>
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
<list style="hanging">
<t hangText="Type:">
TBD5
</t>
<t hangText="Length:">
1
</t>
<t hangText="Sequence Number:">
16-bit signed integer. Indicates the freshness of
the information advertised by the RA.
</t>
<t hangText="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.
</t>
<t hangText="V:">
1-bit flag. Indicates if the sequence number is
valid and the router is advertising information
obtained from another router.
</t>
<t hangText="Reserved:">
This field is unused. It MUST be initialized to
zero by the sender and MUST be ignored by the
receiver.
</t>
</list>
</t>
</section>
<section anchor='oiiopt' title="Owner Interface Identifier Option">
<t>
This option is used together with Router Solicitation messages
when a node has only optimistic addresses before initial
registration.
</t>
<figure anchor='hiifig' title="Owner Interface Identifier Option">
<artwork>
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 +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
<list style="hanging">
<t hangText="Type:">
TBD6
</t>
<t hangText="Length:">
2
</t>
<t hangText="TID:">
8-bit unsigned integer. This field is set to the last TID value used for
sending an NR message.
</t>
<t hangText="Reserved:">
This field is unused. It MUST be initialized to
zero by the sender and MUST be ignored by the
receiver.
</t>
<t hangText="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 to detect duplicate OIIs.
</t>
<t hangText="Owner Interface Identifier:">
A globally unique identifier for the host's interface. This is typically
the EUI-64 derived IID of the interface.
</t>
</list>
</t>
</section>
</section>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='protocol' title="Protocol Specification">
<t>
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.
</t>
<section anchor='protocol_init' title="Interface initialization">
<t>
A LoWPAN node forms a 64-bit Interface Identifier (IID) as specified in Section 6 of <xref target="RFC4944"/>. This may be based on the EUI-64 identifier, an assigned 16-bit short address, or any other appropriate MAC address. All nodes MUST configure at least one address, a link-local address, by concatenating its IID with the prefix FE80::/64 as specified in Section 7 of <xref target="RFC4944"/>. As a result, knowledge of the IID of another LoWPAN Node is enough
to derive its link-local address and reach it on the same link. If derived from an EUI-64 or an equivalent the link-local address is presumably unique on the LoWPAN, which enables the use of Optimistic Duplicate Address Detection (oDAD) <xref target="RFC4429"/>. The address SHOULD be created as optimistic before it has been confirmed by Node Registration (Section <xref target="protocol_nr"/>). This document assumes that addresses are formed in a uniform manner in a LoWPAN. Appropriate steps SHOULD be taken to ensure that only correctly configured devices participate in the LoWPAN, e.g. using L2 security mechanisms.
</t>
<t>
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.
</t>
<t>
Nodes MAY learn the address of routers using
traditional means such as L2 configuration or Router Advertisement
messages as in <xref target="RFC4861"/>. When sending a Router Solicitation it MUST not have the SLLAO Option, but instead MUST include the OII Option.
<!-- ZS: Hmmm. We don't otherwise need the OII for anything else right now. Can we get awat without it, or do we need it for just this purpose? -->
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 <xref target="RFC4429"/>.
</t>
<t>
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 following the general description in Section 5.5 of <xref target="RFC4862"/>. This address is marked optimistic until confirmed by the Node Registration process. If the LoWPAN is operating in ad-hoc mode, then the prefix is a Unique on-link IPv6 Address (ULA) prefix <xref target="RFC4193"/> as specified in <xref target="adhoc"/> (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.
</t>
</section>
<section anchor='protocol_nr' title="Node Registration">
<t>
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 optimistic as long as the binding is not confirmed a router.
The LoWPAN Node sends a unicast Node Registration to an on-link Router to perform the binding. 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 on-link Edge Routers 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 rank routers.
</t>
<t>
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 <xref target="RFC4944"/>. A randomly generated 32-bit Owner Nonce is formed each time a node boots or reboots. This is included in the NR and may be used to detect duplicate OIIs. While cryptographic randomness <xref target="RFC4086"/> is not strictly required, the randomness SHOULD be derived using a mechanism of similar quality.
</t>
<t>
The NR message includes an Address Option for each address to be registered. Thus the message is structured as follows:
</t>
<t>ICMPv6 (Node Registration (Address Option[0], Address Option[1], Address Option[n]))</t>
<t>
This registration method includes a way of requesting a unique address by setting the 'A' flag in an Address Option during registration. This is useful for receiving a unique short link-layer address. How a router assigns such an address is out of scope for this document.
</t>
<t>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 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. A node that has not heard a valid Node Confirmation for 16 Node Registration messages in a row restarts with a on-link next TID of zero (the node MAY, but need not, generate a new Owner Nonce). </t>
<t>
The acknowledgment to a Node Registration is a unicast Node Confirmation
message that contains the status of the bindings. The source of the packet
is the link-local address of the on-link 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 to preferred.
See <xref target="messex" /> for message examples.
</t>
<t>
Node bindings have timeouts associated with them, therefore nodes must periodically send a new Node Registration message to renew the binding. The period between Request NR messages SHOULD be less than BindingLifetime. If a node no longer receives Node Confirmation messages from any router in the current subnet, the registration process starts over.
</t>
<section title="Processing a Node Registration Message">
<t>
When a router receives a Node Registration message
from a node, it first checks for correctness of the message fields
and options. In the case of an existing node, the message is used to refresh the corresponding entries in the router's binding table.
</t>
<t>
In the case of a new node, then a binding table entry is made for each 6AO in the message. The router SHOULD perform Duplicate Address Detection on each optimistic address (O flag set), see <xref target="protocol_dad"/> for further information on the DAD procedure. If a 6AO option with an A flag is received, then the router should aquire a suitable address for the node. How this is done is out of scope. Depending on the link-layer and network it may be possible to generate a random address (DAD MUST be performed in this case), aquire an address from a link-layer coordinator, or perform DHCPv6 in a managed network to name a few.
</t>
<t>
After processing all 6AO options, a unicast Node Confirmation message is sent back to the node with an appropriate NC Status code and success codes
for each 6AO option in the same order as received.
</t>
</section>
<section title="Processing a Node Confirmation Message">
<t>
When a router receives a Node Registration message
from a node, it first checks for correctness of the message fields
and options.
</t>
<t>
If a NC is recieved with a success status (0-7), then the node goes on to process 6LoWPAN Address Options. If a successful NC is received with a code of 2, this indicates that the node should re-register with that router.
</t>
<t>
6LoWPAN Address Options are processed one at a time. A success status (0-127) indicates that the address was successfully bound with the router. If the address is marked optimistic, it is now updated to preferred. A failure code (128-) indicates that the binding failed. See <xref target="addropt"/> for an explanation of 6AO codes. A binding failure may indicate that a duplicate address (and thus a duplicate IID) already exists. In this case the node SHOULD attempt to form a new IID and restart the registration process. If this is not possible, the node MUST not participate in the LoWPAN.
</t>
<t>
If a NC is received with an error status (8 or greater), then the registration has failed. See <xref target="bumess" /> for an explanation of NR/NC codes. If no successful Node Confirmation is received within the timeout (RegistrationTimeout) and number of retries (RegistrationRetries), then registration should be performed with another router in the default router list.
</t>
</section>
</section>
<section anchor='protocol_dad' title="Duplicate Address Detection">
<t>
It is important for proper network operation that duplicate addresses are not used in a LoWPAN as described in <xref target="RFC4862">"IPv6 Stateless Address Autoconfiguration"</xref>. Furthermore, as LoWPANs are made up of links with undetermined connectivity, it is important that address uniqueness is ensured thoughout the routing domain as discussed in <xref target="I-D.ietf-autoconf-adhoc-addr-model"/>. LoWPAN Hosts may be very simple, and thus are not expected to have the capability of performing a duplicate address detection (DAD) algorithm themselves. Therefore the handling of DAD is considered a function of LoWPAN Routers. This document does not perform DAD as defined in <xref target="RFC4862"/>, but instead makes use of alternative techniques appropriate for LoWPANs. It is assumed that all routers in a LoWPAN are configured to perform DAD in a uniform way. If there is only a single router in the LoWPAN, as occurs in mesh-under or star topologies, then a router automatically detects duplicates by checking its own binding table during registration, thus no additional mechanism is needed.
</t>
<t>
If a router receives a Node Registration 6AO with the Optimistic Flag (O) set, it SHOULD perform DAD on this address. If the router generates or assigns an address for a node in response to a 6AO with the A flag set, it SHOULD perform DAD on that address. DAD MAY be disabled if the address has been generated or assigned in such a way that there is high confidence of no duplicates (WARNING IN LARGE PRINT). Examples include the use of an EUI-64 to form an IID or DHCPv6 performed through a single server uniformly by all nodes in the LoWPAN (as per the homogeneous LoWPAN assumption).
</t>
<t>
A router can be configured to perform DAD using one of the following techniques, the details of which are out of the scope of this document:
</t>
<t>
<list style="hanging">
<t hangText="Extended LoWPAN:">
The Extended LoWPAN technique defined in (draft tbd) provides DAD during its ER registration.
</t>
<t hangText="Routing protocol:">
If supported, a routing protocol mechanism could be used to check for the existance of an address in the LoWPAN, assuming that it is covered by a single routing domain.
</t>
</list>
</t>
<!-- ZS: What is the point of having multiple DAD techniques if DAD is optional?? DHCPv6 is not considered to be DAD above, but a way to ensure uniquely assigned addresses in very control situations. Why don't we just point to the Extended LoWPAN mechanism in the case DAD needs to be performed? The routing protocol thing is stretching it a bit, and is not even specified anywhere. -->
</section>
<section anchor='protocol_nexthop' title="Next-hop Determination">
<t>
The IP address of the next-hop for a destination is determined as follows. Destinations to the link-local prefix (FE80::) are always sent on the link to that destination. All other prefixes are assumed to be off-link as recommended in <xref target="I-D.ietf-autoconf-adhoc-addr-model"/>. They are therefore sent to the IP address of a router chosen from the Default Router List.
</t>
<t>
Multicast addresses are considered to be on-link and are resolved as specified in <xref target="RFC4944"/> or relative future documents. A LoWPAN Node is not required to maintain a minimum of one buffer per neighbor as specified in <xref target="RFC4861"/>, as address lookup is not performed as part of next-hop determination. Anycast addresses are always considered to be off-link.
</t>
</section>
<section anchor='protocol_ar' title="Address Resolution">
<t>
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 off-link, resolution between hosts is not needed.
</t>
<t>
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 on-link/global
bit being inverted).
</t>
</section>
<section anchor='protocol_nud' title="Unreachability Detection">
<t>
Unreachability between a node and router is determined based on NR/NC and RS/RA exchanges and other unicast L3 data messages. Host-host unreachability detection is out of scope.
</t>
<t>
In order to detect unreachable destinations, nodes SHOULD support type 1 ICMPv6 destination unreachable messages <xref target="RFC4443"/>. LoWPAN Routers or Edge Routers make use of ICMPv6 destination unreachable to indicate that delivery to that destination is not possible.
</t>
</section>
<section anchor='protocol_context' title="Context Dissemination">
<t>
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.
</t>
<t>
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.
</t>
<t>
Conversely, to avoid that nodes send packets making use
of previous values of contexts, resulting in
ambiguity when receiving a packet 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.
</t>
<t>
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.
</t>
<t>
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
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, the router SHOULD include all 6LoWPAN
Information Options in the RA. A node may use an RS with Code set to 1 in order
to get the whole prefix information set in case it misses the RA sent when
the sequence number changes. An RS with Code set to 0 is responded to with an RA with the 6SO.
</t>
</section>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='node' title="LoWPAN Node Specification">
<t>
This section specifies the conceptual data structures and variables of a LoWPAN Node.
</t>
<section anchor='node_structures' title="Conceptual structures">
<t>
LoWPAN Nodes make use of the following conceptual data structures:
<list style="hanging">
<t hangText="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 <xref target="RFC4861"/>, these prefixes are always assumed to be off-link.</t>
<t hangText="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.</t>
<t hangText="Default Router List"> - As in <xref target="RFC4861"/>. For networks
where address resolution needs to be performed, this list also contains link-layer information about each router.</t>
</list>
</t>
<t>
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.
</t>
</section>
<section anchor='node_variables' title="Conceptual variables">
<t>
The following variables are kept for each interface on a node, and default values are overridden by information in Router Advertisements:
</t>
<t>
<list style="hanging" hangIndent="20">
<t hangText="CurHopLimit"> The default hop limit to be used
when sending IP packets.</t>
<t hangText="CurTID"> The current Transaction ID (TID) value for use in NR messages.</t>
<t hangText="BindingLifetime"> The binding lifetime sent in
Node Registration messages. </t>
<t hangText="RegistrationTimeout"> The time to wait for a
Node Confirmation after sending a Node Registration. SHOULD
be at least MIN_NR_TIMEOUT.</t>
<t hangText="RegistrationRetries"> The number of times
to try to send a Node Registration, which SHOULD be less
than MAX_NR_RETRIES.</t>
</list>
</t>
</section>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='roperation' title="LoWPAN Router Specification">
<t>
LoWPAN Routers are used in a route over configuration
where the network is composed of overlapping link-local
scopes. LoWPAN Edge Routers are implement LoWPAN Router functionality. As a result, we extend classic ND as specified in <xref target="RFC4861"/> to operate over such non-transitive LoWPAN links. This section describes ND for 6LoWPAN router operations. Note that this section
does not entirely apply to pure Mesh Under LoWPANs where the are no LoWPAN Routers, although they do have LoWPAN Edge Routers.
</t>
<section title="Router Configuration Variables">
<t>
A router MUST allow the configuration of conceptual variables as defined in
Section 6.2.1 of <xref target="RFC4861"/>. AdvReachableTime
and AdvRetransTimer are not used.
</t>
</section>
<section title="Becoming an Advertising Interface">
<t>
An interface may become an advertising interface as
specified in Section 6.2.2 of <xref target="RFC4861"/>.
</t>
<t>
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.
</t>
</section>
<section title="Router Advertisement Message Content">
<t>
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.
</t>
<t>
<list>
<t>
- 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.
</t>
<t>
- In the M and O flags: the current value of
AdvManagedFlag and AdvOtherConfigFlag, respectively.
</t>
<t>
- In the Preference flag: this flag is set to 00 to indicate
that the sender is a LoWPAN Router.
</t>
<t>
- In the Cur Hop Limit field: the current value of
CurHopLimit.
</t>
<t>
- In the Reachable Time field: not used, set to zero.
</t>
<t>
- In the Retrans Timer field: not used, set to zero.
</t>
<t>
- In the options:
<list>
<t>
- 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:
<list>
<t>
- In the "valid" flag: the current value of
AdvInformationValid.
</t>
<t>
- In the Sequence Number field: the current
value of AdvInformationSequence.
</t>
<t>
- The ER Metric field is used by a routing algorithm
to indicate the cost of reaching an ER through this router.
</t>
</list>
</t>
<t>
- 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:
<list>
<t>
- In the "on-link" flag: the entry's
AdvOnLinkFlag.
</t>
<t>
- In the "Autonomous address configuration"
flag: the entry's AdvAutonomousFlag.
</t>
<t>
- In the Valid Lifetime field: the entry's
AdvValidLifetime.
</t>
</list>
</t>
</list>
</t>
</list>
</t>
</section>
<section title="Sending Unsolicited Router Advertisements">
<t>As specified in Section 6.2.4 of <xref target="RFC4861"/>.</t>
</section>
<section title="Ceasing To Be an Advertising Interface">
<t>As specified in Section 6.2.5 of <xref target="RFC4861"/>.</t>
</section>
<section title="Processing Router Solicitations">
<t>As specified in Section 6.2.6 of <xref target="RFC4861"/>.</t>
</section>
<section title="Binding Table">
<t>
Routers maintain an set of information about nodes that are
currently registered through it called the binding table.
</t>
<t>
The binding table contains an entry with information such as
the registered node's OII, link-local IPv6 address and the binding lifetime from the last NR. If address resolution is required,
the table will also include corresponding link-layer address information.
</t>
</section>
</section>
<section anchor='adhoc' title="Ad-hoc LoWPAN">
<t>
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.</t>
<t>
A LoWPAN Router in the Ad-hoc LoWPAN is configured to implement basic Edge Router functionality (initiating RA dissemination) and generates a prefix based on Unique on-link IPv6 Unicast Addresses (ULAs) as defined in <xref target="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 <xref target="RFC4193"/> or something appropriate to the Edge Router's capabilities. There SHOULD be only one Edge Router in an Ad-hoc LoWPAN (just as in a Simple LoWPAN) to keep prefix consistency.
</t>
<t>
In the case that an Edge Router on a Simple LoWPAN does not have a prefix available from its IPv6 address, it SHOULD advertise a ULA prefix in a similar manner.
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='constants' title="Protocol Constants">
<t>
This section defines the protocol constants used in this document based
on a subset of <xref target="RFC4861"/> constants. (*) indicates constants
modified from <xref target="RFC4861"/> and (+) indicates new constants.
</t>
<t>
Additional protocol constants are defined in Section <xref target="mess"/>.
</t>
<t> Edge Router Constants:
<list style="hanging" hangIndent="40">
<t hangText="MIN_CONTEXT_CHANGE_DELAY+">60 seconds</t>
</list>
</t>
<t> Router Constants:
<list style="hanging" hangIndent="40">
<t hangText="MAX_INITIAL_RTR_ADVERT_INTERVAL*">60 seconds</t>
<t hangText="MAX_INITIAL_RTR_ADVERTISEMENTS">3 transmissions</t>
<t hangText="MAX_FINAL_RTR_ADVERTISEMENTS">3 transmissions</t>
<t hangText="MIN_DELAY_BETWEEN_RAS*">10 seconds</t>
<t hangText="MAX_RA_DELAY_TIME*">2 seconds</t>
</list>
</t>
<t> Host Constants:
<list style="hanging" hangIndent="40">
<t hangText="MAX_RTR_SOLICITATION_DELAY*">2 second</t>
<t hangText="RTR_SOLICITATION_INTERVAL*">10 seconds</t>
<t hangText="MAX_RTR_SOLICITATIONS">3 transmissions</t>
</list>
</t>
<t> Node Constants:
<list style="hanging" hangIndent="40">
<t hangText="MAX_NR_RETRIES+">3 transmissions</t>
<t hangText="MIN_NR_TIMEOUT+">5 seconds</t>
</list>
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='adapt' title="Use of 6LoWPAN-ND under RFC4861-only stacks">
<t>
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.
</t>
<t>
There are several ways to implement 6LoWPAN-ND in combination with an IPv6 stack:
<list style="symbols">
<t>6LoWPAN-ND is integrated with the IPv6 stack and its tools. This is common for LoWPAN nodes.</t>
<t>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.</t>
<t>6LoWPAN-ND is implemented as part of the interface, and it performs adaptation for RFC4861 mechanisms running on the IPv6 stack. The binding table is used to answer RFC4861 messages, and appropriate options added to RA messages.</t>
</list>
</t>
<t>
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.
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='messex' title="Message Examples">
<t>
This section provides basic examples of messages and options from
this document.
</t>
<section title="NR/NC message exchange">
<t>When a host wanting to register to a router, 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.</t>
<t>First the Host sends an NR message to the link-local address of the router. In this example the host includes a 600 second binding lifetime 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.</t>
<figure anchor='fig-ex1nr' title="Basic NR request.">
<artwork>
IPv6 Source: Unspecified address
IPv6 Destination: Router'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 = 60 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Owner Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Owner Interface Identifier = +
| Modified EUI-64 of the interface |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<figure anchor='fig-ex1ao1' title="NR Address Option 1, for the SAA address.">
<artwork>
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|1| Reserved | Padding = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<figure anchor='fig-ex1ao2' title="NR Address Option 2, for the requested address.">
<artwork>
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|0| Reserved | Padding = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<figure anchor='fig-ex1nc' title="Corresponding NC message.">
<artwork>
IPv6 Source: Router's link-local address
IPv6 Destination: Host's link-local address
The base NC message is identical to the base NR message above.
</artwork>
</figure>
<figure anchor='fig-ex1ncao1' title="NC Address Option 1, for the SAA address.">
<artwork>
Address Option 1 is identical to Address Option 1 in the NR.
</artwork>
</figure>
<figure anchor='fig-ex1ncao2' title="NC Address Option 2, for the requested address.">
<artwork>
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|0| Reserved | Generated 16-bit address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</section>
<section title="Router advertisement">
<t>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.</t>
<t>In the example the Preference flag is 01 (router),
and a 1200s Router Lifetime is advertised. A 6LoWPAN Prefix
Information Option is included.</t>
<figure align="center"
title="RA message example."
anchor="fig-ex3ra">
<artwork align="center">
<![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<figure anchor='fig-ex3pio' title="6LoWPAN Information Option example.">
<artwork>
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 .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</section>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section title="Security Considerations">
<t>
The security considerations of IPv6 Neighbor Discovery <xref target="RFC4861"/>
apply. Additional considerations can be found in <xref target="RFC3756"/>.
</t>
<t>
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 <xref target="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.
</t>
<t>
The use of EUI-64 for forming the Interface ID in the link on-link
address prevents the usage of Secure ND (<xref target="RFC3971"/> and <xref target="RFC3972"/>) and
address privacy techniques. Considering the envisioned deployments
and the MAC layer security applied, this is not considered an issue
at this time.
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section title="IANA Considerations">
<t>
This document requires two new ICMPv6 message types:
<list style="symbols">
<t>Node Registration (TBD1)</t>
<t>Node Confirmation (TBD2)</t>
</list>
The document also requires four new ND option types under the
subregistry "IPv6 Neighbor Discovery Option Formats":
<list style="symbols">
<t>6LoWPAN Address Option (TBD3)</t>
<t>6LoWPAN Information Option (TBD4)</t>
<t>6LoWPAN Summary Option (TBD5)</t>
<t>Owner Interface Identifier Option (TBD6)</t>
</list>
</t>
<t>
[TO BE REMOVED: This registration should take place at the following location:
http://www.iana.org/assignments/icmpv6-parameters]
</t>
</section>
<!--==================================================-->
<!-- SECTION: ACKNOWLEDGMENTS -->
<!--==================================================-->
<section title="Acknowledgments">
<t>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.</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section title="Changelog">
<t>Changes from -07 to -08:
<list>
<t>o Removed Extended LoWPAN and Whiteboard related sections.</t>
<t>o Included reference to the autoconf addressing model.</t>
<t>o Added Optimistic Flag to 6AO.</t>
<t>o Added guidelines on routers performing DAD.</t>
<t>o Removed the NR/NC Advertising Interval.</t>
<t>o Added assumption of uniform IID formation and DAD throughout a LoWPAN.</t>
</list>
</t>
<t>Changes from -06 to -07:
<list>
<t>o Updated addressing and address resolution (#60).</t>
<t>o Changed the Address Option to 6LoWPAN Address Option, fixed S values (#61).</t>
<t>o Added support for classic RFC4861 RA Prefix Information messages to be processed (#62).</t>
<t>o Added a section on using 6LoWPAN-ND under a hard-wired RFC4861 stack (#63).</t>
<t>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).</t>
<t>o Made co-existence with other ND mechanisms clear (#59).</t>
<t>o Added a new Protocol Specification section with all mechanisms specified there (#59).</t>
<t>o Removed dependencies and conflicts with RFC4861 wherever possible (#59).</t>
<t>o Some editorial cleanup.</t>
</list>
</t>
<t>Changes from -05 to -06:
<list>
<t>o Fixed the Prf codes (#52).</t>
<t>o Corrected the OIIO TID field to 8-bits. Changed the Nonce/OII order in both the OIIO and the NR/NC. (#53)</t>
<t>o Corrected an error in Table 1 (#54).</t>
<t>o Fixed asymmetric and a misplaced transient in the 6LoWPAN terminology section.</t>
<t>o Added Updates RFC4861 to header</t>
</list>
</t>
<t>Changes from -04 to -05:
<list>
<t>o Meaning of the RA's M-bit changed to original <xref target="RFC4861"/> meaning (#46).</t>
<t>o Terms "on-link" and "off-link" used in place of "on-link" and "off-link".</t>
<t>o Next-hop determination text simplified (#49).</t>
<t>o Neighbor cache and destination cache removed.</t>
<t>o IID to link-layer address requirement relaxed. </t>
<t>o NR/NC changes to enable on-link refresh with routers (#48).</t>
<t>o Modified 6LoWPAN Information Option (#47).</t>
<t>o Added a Protocol Constants section (#24)</t>
<t>o Added the NR processing table (#51)</t>
<t>o Considered the use of SeND on backbone NS/NA messages (#50)</t>
</list>
</t>
<t>Changes from -03 to -04:
<list>
<t>o Moved Ad-hoc LoWPAN operation to Section 7 and made ULA prefix generation a features useful also in Simple and Extended LoWPANs. (#41)</t>
<t>o Added a 32-bit Owner Nonce to the NR/NC messages and the Whiteboard, removed the TID history. (#39)</t>
<t>o Improved the duplicate OII detection algorithm using the Owner Nonce. (#39)</t>
<t>o Clarified the use of Source and Target link-layer options in NR/NC. (#43)</t>
<t>o Included text on the use of alternative methods to acquire addresses. (#38)</t>
<t>o Removed S=2 from Address Option (not needed). (#36)</t>
<t>o Added a section on router dissemination consistency. (#44)</t>
<t>o Small improvements and extensive editing. (#42, #37, #35)</t>
</list>
</t>
<t>Changes from -02 to -03:
<list>
<t>o Updated terminology, with RFC4861 non-transitive link model.</t>
<t>o 6LoWPAN and ND terminology separated.</t>
<t>o Protocol overview explains RFC4861 diff in detail.</t>
<t>o RR/RC is now Node Registration/Confirmation (NR/NC).</t>
<t>o Added NR failure codes.</t>
<t>o ER Metric now included in 6LoWPAN Summary Option for use in default router determination by hosts.</t>
<t>o Examples of host data structures, and the Whiteboard given.</t>
<t>o Whiteboard is supported by all Edge Routers for option simplicity.</t>
<t>o Edge Router Specification chapter re-structured, clarifying optional Extended LoWPAN operation.</t>
<t>o NS/NA now completely optional for nodes. No address resolution or NS/NA NUD required.</t>
<t>o link-local operation now compatible with oDAD (was broken).</t>
<t>o Exception to hop limit = 255 for NR/NC messages.</t>
<t>o Security considerations improved.</t>
<t>o ICMPv6 destination unreachable supported.</t>
</list>
</t>
<t>Changes from -01 to -02:
<list>
<t>o Fixed 16 != 0xff bug (ticket closed).</t>
<t>o Specified use of ULAs in ad-hoc LoWPAN section 9 (ticket closed).</t>
<t>o Terminology cleanup based on Alex's comments.</t>
<t>o General editing improvements.</t>
</list>
</t>
<t>Changes from -00 to -01:
<list>
<t>o Specified the duplicate owner interface identifier procedures. A TID lollipop algorithm was sufficient (nonce unnecessary).</t>
<t>o Defined fault tolerance using secondary bindings.</t>
<t>o Defined ad-hoc network operation.</t>
<t>o Removed the E flag from RA and the X flag from RR/RC.</t>
<t>o Completed message examples.</t>
<t>o Lots of improvements in text quality and consistency were made. </t>
</list>
</t>
</section>
</middle>
<back>
<references title='Normative References'>
&I-D.ietf-autoconf-adhoc-addr-model;
&RFC2119;
&RFC2491;
&RFC4191;
&RFC4193;
&RFC4291;
&RFC4429;
&RFC4443;
&RFC4861;
&RFC4862;
&RFC4944;
</references>
<references title='Informative References'>
&RFC2022;
&RFC3122;
&RFC3756;
&RFC3971;
&RFC3972;
&RFC4086;
&RFC4903;
&RFC4919;
&I-D.ietf-6lowpan-hc;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:00:26 |