One document matched: draft-ietf-6lowpan-nd-04.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 RFC2460 SYSTEM "reference.RFC.2460.xml">
<!ENTITY RFC2491 SYSTEM "reference.RFC.2491.xml">
<!ENTITY RFC3971 SYSTEM "reference.RFC.3971.xml">
<!ENTITY RFC3972 SYSTEM "reference.RFC.3972.xml">
<!ENTITY RFC3756 SYSTEM "reference.RFC.3756.xml">
<!ENTITY RFC3775 SYSTEM "reference.RFC.3775.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 RFC4389 SYSTEM "reference.RFC.4389.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.van-beijnum-multi-mtu SYSTEM "reference.I-D.van-beijnum-multi-mtu.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" docName="draft-ietf-6lowpan-nd-04">
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<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 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="2009"/>
<area>Internet</area>
<workgroup>6lowpan Working Group</workgroup>
<abstract>
<t>
This document specifies Neighbor Discovery optimized 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 standard IPv6 Neighbor Discovery with
6LoWPAN has several problems. Standard Neighbor Discovery was not designed
for non-transitive wireless links, and the standard IPv6 link concept and
heavy use of multicast makes it inefficient. This document specifies a new ND mechanism
allowing for the efficient detection of duplicate addresses over entire LoWPANs, which
also optimizes other ND operations. In addition context dissemination, claim and
defend address generation, and the support of Extended LoWPANs over Backbone Links
are specified.
</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 with the
help of an adaptation header which comes before the IP header.
A link in 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
IPv6 Neighbor Discovery <xref target="RFC4861"/> is not desirable in
such a wireless low-power, lossy network. </t>
<t>Moreover, LoWPAN links are non-symmetric and transient in nature; they are
not always considered to be in a fixed network nor are they bounded by
our standard definition of a wired-link. A LoWPAN is potentially composed of a potentially 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 no multicast
capabilities. Link-local scope is in reality defined by
reachability and radio strength. The standard 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>Neighbor discovery for 6LoWPAN 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 mesh (Mesh Under) and IP routing (Route Over) multihop solutions. Unlike standard IPv6 ND <xref target="RFC4861"/>, this document specifically takes the characteristics of low-power, lossy wireless links into account.</t>
<t>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) <xref target="RFC2022"/> for a limited purpose, and in a lot 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.</t>
<t>The concept of a LoWPAN Whiteboard located at Edge Routers (ERs) is introduced,
which allows for Duplicate Address Detection and claim and defend addressing for the entire LoWPAN. Address resolution is not needed, and thus makes LoWPAN
operation power efficient and to reduces LoWPAN Node complexity. A new
registration/confirmation message sequence is specified, allowing nodes to
register their IPv6 addresses with an Edge Router. </t>
<t> 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.</t>
<t>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.
</t>
<t>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.</t>
<section anchor='goalsnassumptions' title="Goals & Assumptions">
<t>This document has the following main goals and makes several assumptions.</t>
<t>Goals:
<list>
<t>o Enable ND operations over an entire LoWPAN, even with
non-transitive links and over multihop IP hops.</t>
<t>o Minimize signalling by avoiding the use of multicast flooding and reducing the frequency of link scope multicast for ND messages inside the LoWPANs.</t>
<t>o Disseminate context information throughout the LoWPAN.</t>
<t>o Minimize the complexity of LoWPAN Nodes.</t>
<t>o Interconnect LoWPANs with backbone links seamlessly.</t>
<t>o Provide a mechanism for claim and defend addressing.</t>
</list>
</t>
<t>Assumptions:
<list>
<t>o Link layer technology may be e.g. IEEE 802.15.4 as in <xref target="RFC4944"/>, or any other suitable link-layer.</t>
<t>o Link-local IPv6 addresses are derived from a unique identifier (e.g. EUI-64).</t>
<t>o There is a direct mapping between the IPv6 address IID and the link-layer address (this is already an assumption by <xref target="RFC4944"/> used for header compression), thus address resolution is not required.</t>
<t>o A subnet includes all the LoWPAN Nodes, Edge Router(s) and optionally their backbone link sharing the same IPv6 prefix.</t>
</list>
</t>
</section>
<section anchor='why_not' title="Why not standard 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
standard 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> and <xref target="RFC4944"> "Transmission of IPv6 Packets over IEEE 802.15.4 Networks"</xref>.
</t>
<t>
Readers would benefit from reading <xref target="RFC3775"> "Mobility Support in IPv6" </xref>, <xref target="RFC4389"> "Neighbor Discovery Proxies (ND Proxy)" </xref> and <xref target="RFC4429">"Optimistic Duplicate Address Detection" </xref> prior to this specification for a clear understanding of state of the art in ND proxy and binding.
</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="Ad-hoc LoWPAN"></t>
<t>An isolated LoWPAN, not connected to any other IP networks. Ad-Hoc LoWPANs make use of Unique Local 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="Binding"></t>
<t>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.
</t>
<t hangText="Extended LoWPAN"></t>
<t>This is the aggregation of multiple LoWPANs as defined in
<xref target="RFC4919"/> interconnected by a backbone link via Edge Routers and forming a single subnet, shown in <xref target="figextended"/>.
</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="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"/>. If the Edge Router has a Whiteboard, all nodes belonging to its LoWPAN have a whiteboard entry.
</t>
<t hangText="Registration"></t>
<t>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.
</t>
<t hangText="Whiteboard"></t>
<t>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, Transaction ID history and a remaining lifetime of the binding.
</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>
<figure anchor='figextended'
title="Extended LoWPAN with a backbone link and edge routers ">
<artwork><![CDATA[
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
]]></artwork>
</figure>
</section>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='overview' title="Protocol Overview">
<t>
6LoWPAN Neighbor discovery (6LoWPAN-ND) provides additions and optimizations to IPv6 ND <xref target="RFC4861"/> specifically supporting 6LoWPAN. Basic Neighbor Discovery mechanisms are optimized, avoiding the use of multicast flooding and minimizing link-local multicast (broadcast) frequency. The detection of duplicate addresses is performed across the entire LoWPAN. This is achieved using a Whiteboard located on the Edge Routers of the LoWPAN network. An Extended LoWPAN topology over a shared backbone link is optionally supported.
</t>
<t>
The following list summarizes 6LoWPAN-ND operations and the differences with <xref target="RFC4861"/>:
<list style="hanging">
<t hangText="Router Discovery:">As in <xref target="RFC4861"/> with the addition of new 6LoWPAN specific options to Router Advertisements.</t>
<t hangText="Prefix Discovery:">The discovery of 6LoWPAN prefixes with context identifiers. Destinations are assumed to be off-link unless explicitly known to be a neighbor.</t>
<t hangText="Address Autoconfiguration:">Stateless address autoconfiguration is supported as in <xref target="RFC4861"/>. Additionally a claim and defend address generation method is supported using the Whiteboard.</t>
<t hangText="Address Resolution:">Not performed as there is a direct mapping between the IID and the link-layer address.</t>
<t hangText="Next-hop Determination:">Next-hop determination is performed considering LoWPAN routing and link specifics, and is simplified compared
to <xref target="RFC4861"/>.</t>
<t hangText="Neighbor Unreachability Detection:">An algorithm is specified that makes use of ND messages and link-layer reachability information, without the use of NS/NA exchanges. In addition, ICMP destination unreachable messages are supported.</t>
<t hangText="Duplicate Address Detection:">The detection of duplicate addresses is performed across the entire LoWPAN using a lookup on the Whiteboard using a new registration method. Edge routers in an Extended LoWPAN formation perform standard <xref target="RFC4861"/> DAD on the backbone link.</t>
<t hangText="Redirect:">Redirect messages are not required.</t>
<t hangText="Node Registration (new):">Method in which nodes in the LoWPAN register with Edge Routers, creating Whiteboard state about all IPv6 addresses in the LoWPAN.</t>
<t hangText="Whiteboard Conflict Resolution (new):">This method is used in the Extended LoWPAN topology, using the backbone link to resolve conflicts between the Whiteboards of Edge Routers.</t>
</list>
</t>
<t>
This specification makes use of RS/RA message exchanges along with standard NS/NA on the Backbone Link. The use of NS/NA message exchanges in the LoWPAN are not required by this document. In addition 6LoWPAN-ND defines two new ICMP packet types:
<list style="hanging">
<t hangText="Node Registration:">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 Edge Router on-link.</t>
<t hangText="Node Confirmation:">The response sent by an Edge Router or router back to the registering node. May be relayed by an intermediate router.</t>
</list>
</t>
<section anchor='overviewtop' title="Topology">
<t>
ND for 6LoWPAN 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 <xref target="adhoc"/>. Edge Router operation and Extended LoWPAN functionality are described in <xref target="eroperation"/>. 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).
</t>
</section>
<section anchor='overviewlink' title="Links">
<t>
The use of 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-symmetric, non-transitive nature of these links.
</t>
<t>
6LoWPAN-ND is agnostic to the use of link-layer mesh or <xref target="RFC4944"/> mesh techniques, which alleviate the otherwise non-transitive nature of wireless links. This so-called Mesh Under topology thus makes the entire link to 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.
</t>
<t>
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 is possible to combine IP routing and mesh link-layers within a LoWPAN.
</t>
</section>
<section anchor='overviewbs' title="Bootstrapping">
<t>
1. A Host first performs stateless address autoconfiguration of its link-local unicast address for each LoWPAN interface from its EUI-64 as in <xref target="RFC4944"/>. When a LoWPAN Node wants to join a LoWPAN, it does so by listening for Route Advertisements from Edge Routers or LoWPAN Routers, 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 will also form an optimistic global unique address with stateless address autoconfiguration (or any other suitable method). At this point the node has also chosen one or more default routers.
</t>
<t>
2. Next the node will attempt to perform initial registration with an Edge Router. Registration is always performed with a link-local
Edge Router or router by sending a unicast Node Registration (NR) message to it. Registering directly with an Edge Router is of course preferred as shown in <xref target="figmessbasic"/> (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 <xref target="figmessrelay"/>.
</t>
<t>
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.
</t>
<t>
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 always 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 fully, and the ER forwards on its behalf.
</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 when the Edge Router is on-link">
<artwork><![CDATA[
Node Edge Router
| |
| ---------- Node Registration --------> |
| |
| <--------- Node Confirmation --------- |
| |
]]></artwork>
</figure>
<figure anchor='figmessrelay'
title="Registration exchange relayed by a router (no on-link ER), the messages are ICMP relayed">
<artwork><![CDATA[
Node Router (ICMP relay) Edge Router
| | |
| ---- NR ---> | ---- NR ---> |
| | |
| <---- NC ---- | <---- NC ---- |
| | |
]]></artwork>
</figure>
</section>
<section anchor='overviewbo' title="Basic operation">
<t>
The node may now send packets to any IPv6 address inside or outside the LoWPAN. Destinations are assumed to be off-link unless known to be within link-local scope (valid entry in the neighbor cache). Address resolution is not performed with neighbors as in <xref target="RFC4861"/>, but instead the IID part of the IPv6 address directly corresponds to a MAC address. The support of NS/NA is optional for nodes.
</t>
<t>
The Whiteboard address bindings and assignments are soft, and thus must
be renewed periodically as indicated by the lifetime of the binding.
This is achieved by periodically sending a new NR to the ER. If a
host moves, or the network topology changes, and the current ER is
no longer available, the host then starts the registration process
with another ER. If the host is still in the same Extended LoWPAN (same subnet prefix), its IPv6 addresses remain the same. Claim and defend addresses generated 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 <xref target="sdoperation"/> for details on node operation.
</t>
<t>
LoWPAN Routers periodically send RAs to their neighbors. The Edge Router initiates the first RAs, and this information is included in the RAs of each router. RA periods can be optimized to reduce signalling. See <xref target="roperation"/> for detailed router operation.
</t>
</section>
<section anchor='overviewof' title="Optional features">
<t>
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 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 <xref target="eroperation"/> for a description of Extended LoWPAN operation. Extended LoWPAN operation does not require changes to node operation.
</t>
</section>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='mess' title="6LoWPAN-ND Messages">
<t>
This section introduces message formats for all messages
used in this document. The new messages are all ICMPv6
messages and extend the capabilities
of <xref target="RFC4861">"The IPv6 Neighbor Discovery
Protocol"</xref>. In addition, new options for the ICMPv6
Router Advertisement message are defined.
</t>
<t>The following <xref target="RFC4861"/> are used with modifications as specified in this section:
<list>
<t>Router Solicitation</t>
<t>Router Advertisement</t>
<t>Neighbor Solicitation (Extended LoWPAN only)</t>
<t>Neighbor Advertisement (Extended LoWPAN only)</t>
</list>
</t>
<t>The following new ICMPv6 message types are defined:
<list>
<t>Node Registration</t>
<t>Node Confirmation</t>
</list>
</t>
<t>In addition, the following new ICMPv6 options are defined:
<list>
<t>Address Option</t>
<t>6LoWPAN Prefix Information Option</t>
<t>6LoWPAN Prefix Summary Option</t>
<t>Owner Interface Identifier Option</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 an
ER, and for the ER to confirm the binding. 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 an on-link Edge Router
or LoWPAN Router. NR/NC messages may be sent over multiple
IP hops within the LoWPAN by relaying routers, 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.
</t>
<t>
When registering the first time (the node still has optimistic addresses) it
sends an NR to the link-local unicast address of an on-link
ER or LoWPAN Router. The source address must be the IPv6 unspecified address
to comply with oDAD.
</t>
<t>
Nodes send subsequent NR messages to an on-link ER or router, however the IPv6 source address is then the link-local IPv6 address of the sender.
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.
</t>
<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. When
NR/NC messages are sent through a relaying router Target link-layer and
Source link-layer address options are used to indicate the ER with which
registration occured (in an NC) or which ER should preferably be used
(in an NR).
</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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TID | Status |P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Owner Interface Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Owner Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 an on-link Edge Router or 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.
</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="Code:">
0 indicates a message sent directly from the originating host. 1 indicates that the message has been relayed by a router. Values 128-255 are reserved for error codes. 128 is sent in an NC response by a router to indicate that no ER is available. 129 is sent by a router or Edge Router to indicate that Whiteboard registration is not supported.
</t>
<t hangText="Checksum:">
The ICMP checksum.
</t>
<t hangText="TID:">
A unique Transaction ID assigned by the host and used to match replies.
A lollipop mechanism is used to increment the TID at each new message. TID
is set to 0 upon booting, and is incremented with each NR message. After reaching 0xFFFF, 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. 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.
</t>
<t hangText="Status:">
8-bit unsigned integer. Values TBD. 0 means
unqualified success. Any value below 128 is a
positive status that means that the binding was
created or is being created optimistically.
</t>
<t hangText="Lifetime:">
32-bit unsigned integer. The amount of time in
units of seconds 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.
</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 is used by ERs to detect duplicate OIIs <xref target="eroperationduplicate"/>.
</t>
</list>
</t>
<t hangText="Possible Options:">
<list style="hanging">
<t hangText="Address Option(s):">
An Address Option is included for each address the host wants to bind for this
interface.
</t>
<t hangText="Configuration options:">
Other configuration information requests and configuration settings may be
carried in options of NR/NC messages. Such options are not defined in this
document.
</t>
<t hangText="Source link-layer address:">
This option SHOULD be added to the NC by the relaying router to indicate the identity of the ER for use by a host. Format as defined in <xref target="RFC4861"/> and <xref target="RFC4944"/>.
</t>
<t hangText="Target link-layer address:">
This option MAY be included by a node in an NR to indicate the preferred ER to be used by a relaying router. Format as defined in <xref target="RFC4861"/> and <xref target="RFC4944"/>.
</t>
</list>
Future versions of this protocol may define new
option types. Receivers MUST silently ignore any
options they do not recognized and continue
processing the message.
</t>
</list>
</t>
</section>
<section anchor='rsmess' title="Router Solicitation Message">
<t>
The RS message format for 6LoWPAN is identical to the
<xref target="RFC4861"/> RS message. The following changes 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, as the MAC address is implicitly known. Instead the Owner Interface Identifier specified in this document MUST be included in the RS.
</t>
</section>
<section anchor='ramess' title="Router Advertisement Message">
<t>
The RA message format for 6LoWPAN is identical to the
<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="M:">
Managed mode here refers to the availability of an Edge Router through this router, not DHCPv6 as in <xref target="RFC4861"/>. MUST be set to 1 by
Edge Routers, and SHOULD be set to 1 by LoWPAN routers who are successfully
registered with and have a route to an Edge Router.
</t>
<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 SHOULD set the preference
to (00) for normal, and LoWPAN Edge Routers SHOULD set the preference
to (01) for high.
</t>
</list>
</t>
<t hangText="Possible Options:">
<list style="hanging">
<t hangText="6LoWPAN Prefix Information Option:">
This option includes information about the prefixes of the
LoWPAN along with other context information.
</t>
<t hangText="6LoWPAN Prefix 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.
</t>
</list>
Future versions of this protocol may define new
option types. Receivers MUST silently ignore any
options they do not recognized and continue
processing the message.
</t>
</list>
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='nsmess' title="NS/NA Messages">
<t>
NS/NA messages are also employed between ERs on the backbone link.
For this use a unique identifier is required in
the message as an option to uniquely identify a
host's interface. The standard NS/NA message is used in this
document is as per <xref target="RFC4861"/> with the
an additional Owner Interface Identifier Option defined in this document.
The Owner Interface Identifier is the same as that carried in NR/NC messages
and associated with bindings.
</t>
<t>
If NS/NA messages are sent on the LoWPAN link (which is not required by this specification), they do not carry link-layer address options, because of link non-transitivity and the Extended LoWPAN topologies do not preserve the MAC address. For the same reason redirect is not supported. Instead they MUST include the Owner Interface Identifier option to help resolve conflict.
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='opt' title="6LoWPAN-ND Message Options">
<t>This section defines the new 6LoWPAN-ND message options.</t>
<section anchor='addropt' title="Address Option">
<t>
The Address Option 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 Address Option also allows
for duplicate addresses (e.g. anycasts), the request of a generated address for claim and defend, or for an address to be removed.
</t>
<figure anchor='addrfig' title="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 | P | S |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|A|R| 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. Values TBD. 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="P:">
4-bit unsigned integer. Identifies prefix
compression or type, if any.
<list style="hanging">
<t hangText="0:">
Prefix is carried inline.
</t>
<t hangText="1:">
Prefix compressed and link-local (fe80::) is assumed.
</t>
<t hangText="2:">
Prefix compressed and the default prefix (CID=0) is assumed.
</t>
<t hangText="3-15:">
Reserved.
</t>
</list>
</t>
<t hangText="S:">
4-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 is a 6LoWPAN 16-bit short address as defined in RFC 4944 or
as appropriate for the link-layer of the LoWPAN.
</t>
<t hangText="3-15:">
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 Prefix 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 Prefix 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 | Prefix Length |L|A| CID | R |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Prefix .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</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 Prefix field.
</t>
<t hangText="Prefix Length:">
8-bit unsigned integer. The number of leading
bits in the Prefix that are valid. The value
ranges from 0 to 128. The prefix length field
provides necessary information for on-link
determination (when combined with the L flag in
the prefix information option). It also assists
with address autoconfiguration as specified in
<xref target="RFC4862"/>, for which there may be more
restrictions on the prefix length.
</t>
<t hangText="L:">
1-bit on-link flag. 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="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. CID = 0 identified the default prefix for the LoWPAN.
</t>
<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="Prefix:">
The IPv6 Prefix indicated for this context. This may be a partial
prefix, or even an entire IPv6 address for use as a context for
compression.
</t>
</list>
</t>
</section>
<section anchor='psopt' title="6LoWPAN Prefix 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 Prefix 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 for use with standard 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.
</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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Owner Interface Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Owner Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
<list style="hanging">
<t hangText="Type:">
TBD6
</t>
<t hangText="Length:">
2
</t>
<t hangText="TID:">
A unique Transaction ID assigned by the host in the associated NR and used
to match NC replies.
</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:">
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.
</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 by ERs to detect duplicate OIIs.
</t>
</list>
</t>
</section>
</section>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='sdoperation' title="LoWPAN Node Specification">
<t>
This section specifies LoWPAN node operations, and explains the differences to <xref target="RFC4861"/> node operation, while specifying the new Node Registration operation. Instead of relying on multicast ND messages for DAD and neighbor unreachability detection, LoWPAN Nodes send unicast messages to an Edge Router in the LoWPAN
which keeps a Whiteboard of all bound addresses from nodes attached
to that ER. Thus these functions are performed across the entire LoWPAN using the Whiteboard, which allows 6LoWPAN-ND to operate over asymmetric, non-transitive links and with sleeping nodes. Node complexity and energy consumption are reduced as address resolution and the support of redirect are not required, ND traffic is
reduced and nodes do not need to answer NS messages. In an Extended LoWPAN topology, ND functions are performed across the entire Extended LoWPAN, and a node may change its point of attachment within the LoWPAN without changing its IPv6 addresses. Extended LoWPAN operation is transparent for nodes.
</t>
<section anchor='sdoperationdata' title="Conceptual structures and variables">
<t>
LoWPAN Nodes make use of the same conceptual data structures as defined in <xref target="RFC4861"/> Section 5.1, with the following differences:
<list style="hanging">
<t hangText="Neighbor Cache"> - The neighbor unreachability detection entry is not kept in this cache, but instead MAY be used with destination cache entries.</t>
<t hangText="Destination Cache"> - The destination cache MAY include a neighbor unreachability detection entry, for destinations within the same LoWPAN.</t>
<t hangText="Prefix List"> - The list of prefixes and their associated CID which are advertised in Router Advertisements, along with an associated invalidation timer. Each entry is associated with the LoWPAN prefix (CID = 0) and the sequence number last advertised in the 6LoWPAN Prefix Summary Option. Unlike in <xref target="RFC4861"/>, these prefixes are always assumed to be off-link.</t>
<t hangText="Default Router List"> - As in <xref target="RFC4861"/>. </t>
<t hangText="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. Off-link ERs can be included in this list but this is not required as they can be reached using the 6LOWPAN_ER anycast address through a default router.</t>
</list>
</t>
<t>
These conceptual data structure 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>
<t>
The Neighbor Discovery variables defined in <xref target="RFC4861"/> Section 6.3.2 are valid for 6LoWPAN-ND, and default values are overridden by information in Router Advertisements. The LinkMTU variable is always 1280 octets for 6LoWPAN. ReachableTime and RetransTimer variables are used for neighbor unreachability detection using the Whiteboard.
</t>
</section>
<section anchor='sdoperationfa' title="Interface initialization">
<t>
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 <xref target="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 if 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) <xref target="RFC4429"/> over the backbone link and the LoWPAN. The address SHOULD be created as optimistic before it has been confirmed by an Edge Router.
Due to the way 6LoWPAN networks perform address compression <xref target="RFC4944"/> nodes within a LoWPAN use addresses in a homogeneous way and the unicast IPv6 address IID resolves directly to a corresponding link-layer address. As a result, address resolution within the LoWPAN is not required.
</t>
<t>
A node MUST join the all-nodes multicast address, which is used for receiving
RAs from routers. 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 Edge Routers or 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 SLLA 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 <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 using Stateless Address Autoconfiguration <xref target="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 <xref target="RFC4193"/> as specified in <xref target="adhoc" /> (use of a ULA prefix requires no changes to node operation). A node MAY alternatively aquire a global unicast address using other suitable means, e.g. DHCPv6, L2 assignment or manual configuration.
</t>
</section>
<section anchor='sdoperationbind' title="Registration process">
<t>
The binding process is very similar to that of a MIPv6 mobile node, though
the messages used are new Neighbor Discovery ICMP messages. A LoWPAN Node
address is tentative or optimistic as long as the binding is not confirmed by the ER.
</t>
<t>
The LoWPAN Node uses unicast Node Registrations with on-link ERs or LoWPAN Routers to perform the binding. The destination address is the link-local unicast address of an on-link 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 on-link 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). The M Flag of the RA indicates if an ER is available through a neighbor LoWPAN Router. If the M Flag is unset, that router SHOULD NOT be used for registration. Furthermore the ER Metric in the 6LoWPAN Prefix Summary Option SHOULD be used to choose a router to use for registration.
</t>
<t>
When performing Node Registration through a LoWPAN Router, the actual ER is transparent to the
node by default (the router chooses the best ER). In order to provide nodes the possibility to control which ER they register with, Target link-layer and Source link-layer address options are used with NR/NC messages. LoWPAN Routers include a Source link-layer address option when relaying an NC to a node, this indicates the IID of the ER. When sending an NR to a LoWPAN Router, a node may choose to include a Target link-layer address option with the IID of the ER
the node wants to register with. The router then attempts to make use of that ER if available.
</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 is used by ERs 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 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.
</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 NR message. After reaching 0xFFFF, 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). </t>
<t>
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 on-link 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 <xref target="messex" /> for detailed message examples.
</t>
<t>
If a Node Confirmation is received with an error code (128 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 an implementation specific timeout and number of retries, then there may be no Edge Routers in the LoWPAN. See <xref target="adhoc" /> for more information on ad-hoc network operation.
</t>
<t>
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 <xref target="eroperationfault" />.
</t>
<t>
ER bindings have a timeout associated with them, therefore nodes must
periodically send a new Node Registration message to renew the bindings. If
a node no longer receives Node Confirmation messages from any router in the current subnet, the
registration process begins from the beginning.
</t>
</section>
<section anchor='sdoperationnh' title="Next-hop determination">
<t>
Next-hop determination is performed as in Section 5.2 of
<xref target="RFC4861"/> with the following exceptions. All prefixes are assumed to be off-link as the subnet with that prefix may
be larger than the link (non-transitive property), unless the
destination address exists in the neighbor cache. Exact-match search is performed on the neighbor and destination caches. A node MAY attempt to transmit a packet to the link for destinations with the same LoWPAN prefix if no neighbor or destination cache entry is found before sending to a default router. Link-layer information and packet transmissions SHOULD be used to maintain the neighbor cache. 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 be 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.
</t>
<t>
Care must be used with anycast addresses, as anycast address resolution is normally performed with a multicast NS/NA exchange in <xref target="RFC4861"/>.
As LoWPAN Nodes are not required to perform address resolution, and do no need to answer NS messages, anycast addresses MUST be considered to be off-link. If a node does answer an NS with an NA, it MUST not include link-layer address options, but instead MUST include the OII Option.
</t>
</section>
<section anchor='sdoperationqa' title="Destination unreachability detection">
<t>
LoWPAN Nodes do not perform <xref target="RFC4861"/> address resolution, DAD or NUD. Therefore the implementation of NS/NA message support by a node is optional, and thus to minimize implementation size a node MAY choose not to support NS/NA messages.
</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>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<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. As a result, we extend 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 apply to pure Mesh Under LoWPANs where the are no LoWPAN Routers. In addition to the
operations described in this section, LoWPAN Routers also need
to implement the basic LoWPAN Node operations in <xref target="sdoperation"/>.
</t>
<t>
Network configuration parameters carried in Router
Advertisements originate at edge routers and must
disseminate to all routers and hosts within the
LoWPAN. The 6LoWPAN Prefix 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.
</t>
<t>
Because Node Registration/Confirmation exchanges between LoWPAN Nodes and LoWPAN Routers only occur over link-local scope, such
messages must be relayed
between nodes and ERs when separated by multiple
IP hops. Every LoWPAN Router MUST also serve as a relay to
ensure that any neighboring node can successfully
participate in the LoWPAN.
</t>
<section title="Router Configuration Variables">
<t>
A router MUST allow conceptual variables as defined in
Section 6.2.1 of <xref target="RFC4861"/>.
</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, AdvReachableTime, prefix
information, etc.) from neighboring routers. While the
variables are not initialized, the router MAY send
Router Advertisement with the "Solicit" flag set to
solicit Router Advertisements from neighboring
routers. However, the router MUST set the Router
Lifetime field to zero while one or more of its
variables are uninitialized.
</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: the current value of
AdvReachableTime.
</t>
<t>
- In the Retrans Timer field: the current value of
AdvRetransTimer.
</t>
<t>
- In the options:
<list>
<t>
- 6LoWPAN Prefix 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 Prefix Information options: one 6LoWPAN Prefix
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="Router Advertisement Consistency">
<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 Prefix Information
Options (one for each context) and a 6LoWPAN
Prefix Summary Option, or just a 6LoWPAN Prefix Summary
Option.
</t>
<t>
The 6LoWPAN Prefix 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 included
for context compression in an RA may be large (up to 16),
it is beneficial to avoid the need to always include all prefixes
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
Prefix 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.
</t>
</section>
<section title="Relaying a Node Registration Message">
<t>
When a router receives a Node Registration message
from a LoWPAN 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.
</t>
<t>
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.
</t>
<t>
As initial Node Registration messages are sent with an unspecified IPv6 source address, the router needs to keep state regarding the node's OII to link-layer address mapping while waiting for the Node Confirmation. This state is used to send the relayed NC to the correct MAC address for the node.
</t>
</section>
<section title="Relaying a Node Confirmation Message">
<t>
When the router receives a Relay Node Confirmation
message from an Edge Router, the Code field is set to 1.
The Owner Interface Identifier and relay state 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.
</t>
<t>
Upon relaying a successful NC message back to a node, the router SHOULD use the information about IPv6 addresses in the message to update its neighbor cache.
</t>
</section>
</section>
<!--**************************************************************** -->
<!--**************************************************************** -->
<!--**************************************************************** -->
<!--**************************************************************** -->
<section anchor='eroperation' title="LoWPAN Edge Router Specification">
<t>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:<list>
<t>
Edge Routers MUST implement LoWPAN Router features on their LoWPAN interfaces,
</t>
<t>
Edge Routers MUST support Whiteboard registration for LoWPAN Nodes within
their subnets.
</t>
<t>
Edge Routers MAY support the Extended LoWPAN modality
where a LoWPAN subnet is aggregated over a higher speed backbone link.
</t>
<t>Edge Routers supporting the extended LoWPAN modality MUST perform
ND proxy over the backbone on behalf of their registered LoWPAN Nodes.
</t>
</list>
</t>
<t>
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 <xref target="RFC4861">
IPv6 Neighbor Discovery Protocol </xref>
that enables a LoWPAN Node to locate an Edge Router
and then claim and register addresses using unicast exchanges with that
Edge Router.</t>
<t>
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.
</t>
<t> 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 for the LoWPAN Nodes.
</t>
<section anchor='eroperationwb' title="The Whiteboard">
<t> 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:
<list style="hanging">
<t hangText="IPv6 address:">
The IPv6 address being registered. This is an IPv6 unicast address of any scope.
</t>
<t hangText="Owner Interface Identifier:">
The 64-bit OII of the LoWPAN Node's interface (usually formed from an EUI-64) is used for <xref target='eroperationdad'>Address collision detection and resolution</xref>.
</t>
<t hangText="Owner Nonce:">
The 32-bit nonce generated by a node upon booting is used for <xref target='eroperationduplicate'>Duplicate OII detection</xref>.
</t>
<!-- <t hangText="Transaction Identifier History:">
The TID history of the last successful registrations for a LoWPAN Node is used for
<xref target='eroperationduplicate'>Duplicate OII detection</xref>.
</t> -->
<t hangText="Primary flag:">
Influences the proxy ND operation in the Extended LoWPAN case.
</t>
<t hangText="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.
</t>
</list>
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 LLA information in its Neighbor Cache. Otherwise, it will route packets towards the LoWPAN Nodes and thus will not need or use the LLA of the LoWPAN Node.
</t>
<t> 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.
</t>
<t> 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.
</t>
</section>
<section anchor='eroperationsimple' title="Simple LoWPAN">
<t>The support of the Simple LoWPAN modality is REQUIRED. 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 <xref target="figsimple"/>.
The ER may be connected to an IP infrastructure and may inject the prefixes for
its subnet in the routed infrastructure.</t>
<t>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.</t>
<t>The default prefix (CID = 0) 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 <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. </t>
<t>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.
</t>
</section>
<section anchor='eroperationexp' title="Extended LoWPAN">
<t>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 <xref target="figextended"/>. As a result,
all further reference to the Backbone Link and ND proxy operation over that link
is OPTIONAL but come as a whole.</t>
<t>
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 <xref target="RFC4861"/>;
Edge Routers represent themselves and 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.
</t>
<t>
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.
</t>
<t>
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 <xref target="RFC4861"/>. In the absence of a global IPv6 address, an IPv6 router can alternatively advertise a ULA prefix as defined in <xref target='eroperationsimple'/>.
</t>
<!-- This is not useful for LoWPANs?
The Backbone Link Maximum Transmission Unit serves as base for Path MTU
discovery and Transport layer Maximum Segment Size negotiation (see
section 8.3 of <xref target="RFC2460"/>) for all nodes in the LoWPANs.
To achieve this, the Edge Router announces the MTU of the Backbone Link
over the LoWPAN using the MTU option in the RA message as prescribed
in section "4.6.4. MTU" of <xref target="RFC4861"> IPv6 Neighbor
Discovery </xref>.
More information on the MTU issue with regard to ND-proxying can be
found in <xref target="RFC4389"> Neighbor Discovery Proxies </xref>
and <xref target="I-D.van-beijnum-multi-mtu"/>.
-->
</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>
If a LoWPAN Router in the Ad-hoc LoWPAN is configured to implement basic Edge Router Whiteboard functionality and generates a ULA prefix <xref target="RFC4193"/> (as described in <xref target='eroperationsimple'/>), 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 full Extended LoWPAN ER functionality.
</t>
</section>
<section anchor='eroperationbind' title="Registration process">
<t>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.
</t>
<t>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 provided in <xref target="eroperationdad" />.
</t>
<t>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.
</t>
<t>The remainder of this section deals with the case of an Extended LoWPAN
configuration. In that case:
</t>
<t>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
<xref target="RFC4429">Optimistic DAD</xref> on the Backbone Link.
A positive acknowledgement can be sent to the 6LoWPAN node right away if oDAD
is used on the Backbone Link.
</t>
<t>
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 depreciate its binding.
</t>
<t> 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.
</t>
<t>
So the Edge Router operation on the Backbone Link is similar to that of
a Home Agent as specified in <xref target="RFC3775">"Mobility Support for
IPv6"</xref> yet different. In particular, the Neighbor Advertisement
message is used as specified in section "10.4.1. Intercepting Packets
for a Mobile Node" with the exception that the override (O) bit is not
set, indicating that this Edge Router acts as a proxy for the LoWPAN and
will yield should another Edge Router claim that address on the Backbone Link.
</t>
<t>
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 <xref target="eroperationfault" />.
</t>
<t>
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.
</t>
<t>
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 assigned IPv6 address is formed from the generated link-layer address with the default prefix inline.
</t>
</section>
<section anchor='eroperationforw' title="Forwarding packets between a LoWPAN and an IPv6 infrastructure">
<t>
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.
</t>
<t> 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.
</t>
<t>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 on-link 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 on-link or via intermediate LoWPAN routers using the routing in place in the LoWPAN.
If the destination is not a registered LoWPAN node, then the ER acts as if the subnet was on-link 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 <xref target="RFC4443"/>.
</t>
</section>
<section anchor='eroperationdad' title="Address collision detection and resolution">
<t>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 <xref target="eroperationduplicate" />.
</t>
<t>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.</t>
<t>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.
</t>
<t>Additionally, the following principles apply to the resolution in the Extended LoWPAN modality:
<list>
<t>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.
</t>
<t>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.
</t>
<t>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.
</t>
<t> 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 standard Duplicate Address Detection
as prescribed by <xref target="RFC4862"/>.
</t>
</list>
</t>
<t>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.
</t>
<t>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.
</t>
<t>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
<xref target="eroperationduplicate"/>. 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 Override (O) bit in the
NA message.
</t>
<t>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.
</t>
<t> 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 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
<xref target="eroperationduplicate"/>. If there is no duplication then the NA is
ignored and the DAD timer keeps going.</t>
<t> 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.
</t>
<!-- XXX: The following is vague. -->
<t> 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.
</t>
</section>
<section anchor='eroperationduplicate' title="Duplicate OII detection">
<t>
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.
</t>
<!--
This section should deal with the behavior of the ERs in the following cases. 1. A node changes its primary registration from one ER to another (TID increases). 2. A node
reboots and registers again with the same or a new ER (TID resets). 3. A node enters a
network on accident or maliciously using an OII (EUI-64) which already is in use in the network. -->
<t>
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.
<!-- XXX: Why???
At least the 4 most recent values for a TID are also kept by the edge
router in the whiteboard entry for validation purpose. -->
</t>
<t>
The TID is maintained using the lollipop mechanism.
When a node starts or restarts, it sets its local next TID to
zero and its local Owner Nonce to a random value.
(While cryptographic randomness <xref target="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 Node
Registration, but keeps the Owner Nonce constant. When the
TID needs to be incremented beyond its maximum
value (0xFFFF), 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.
</t>
<t>
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.
</t>
<t>
To compare TID1 and TID2, the following rules apply:
<list>
<t>
If at least one of TID1 and TID2 is unacknowledged
(smaller than 16) then they compare directly.
</t>
<t>
If both TID1 and TID2 are acknowledged, then TID2 is greater than TID1 if
(TID2 - TID1) is smaller than (TID1 - TID2).
</t>
</list>
</t>
<t>
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.
<!-- During normal operations, the TIDs saved in
the white board entry should be consistent. -->
<!-- Two TIDs are strictly consistent if they are consistent and not the same. -->
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.
</t>
<t>
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.
</t>
<t>
If the TID in a new Node Registration message jumps back to
an unacknowledged value, this can be interpreted as
either a new node 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.
</t>
<t>
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,
<!-- XXX: ???
then the Edge Router compares with the
older TID values that are saved in the whiteboard entry for that registration.
This might occur for instance with an entry that was rendered non-operational
when the address was taken over by another Edge Router.
</t>
<t>
If the new value is consistent with a recent value then
it appears that 2
sources are competing for the same OII and an OII collision should be logged.
In that case the greater TID wins, that is if the new TID is greater than the
previous one it is accepted, otherwise it is reported as a collision.
</t>
<t>
If the new value is not consistent with a recent value saved in the whiteboard
entry
-->
then the Node Registration message is rejected as an OII collision.
</t>
</section>
<section anchor='eroperationfault' title="Fault tolerance">
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='messex' title="Message Examples">
<t>
This section provides basic examples of messages and options from
this document.
</t>
<section title="Basic NR/NC message exchange">
<t>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 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 ER. In this example the host wants to use the Edge Router as primary,
uses a 600s 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.</t>
<figure anchor='fig-ex1rr' title="Basic NR message.">
<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 | Code = 0 | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TID = 0 | Status = 0 |1| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime = 600 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Owner Interface Identifier = +
| Modified EUI-64 of the interface |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Owner Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<figure anchor='fig-ex1ao1' title="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 | P=2 | S=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0| Reserved | Padding = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<figure anchor='fig-ex1ao2' title="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 | P=2 | S=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1|0| Reserved | Padding = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</section>
<section title="Relaying an NR message">
<t>In case an ER is not on-link for initial node registration, then the NR message
from the previous example is sent to any on-link 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 or the 6LOWPAN_ER Anycast address and the source
IPv6 address that of the relaying router. The Address Options
are not modified.</t>
<figure anchor='fig-ex2rr' title="Relayed NR message.">
<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 | Code = 1 | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TID = 0 | Status = 0 |1| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime = 600 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Owner Interface Identifier = +
| Modified EUI-64 of the interface |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Owner Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</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 01 for high.</t>
<t>In the example the M flag is set to indicate that an ER is
available through this router, the Preference flag is 00 for normal,
and a 1200s Route 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[
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 |1|0|0|00 |Rsrvd| Router Lifetime = 1200 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<figure anchor='fig-ex3pio' title="6LoWPAN Prefix 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 = 60 |0|1| CID=0 | R |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 local
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>
<t>
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 <xref target="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.
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section title="IANA Considerations">
<t>
This document requires two new ICMPv6 message types:
<list>
<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>
<t>Address Option (TBD3)</t>
<t>6LoWPAN Prefix Information Option (TBD4)</t>
<t>6LoWPAN Prefix 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>
<t>
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.
</t>
<t>
[TO BE REMOVED: This registration should take place at the following location:
http://www.iana.org/assignments/ipv6-anycast-addresses]
</t>
</section>
<!--==================================================-->
<!-- SECTION: ACKNOWLEDGMENTS -->
<!--==================================================-->
<section title="Acknowledgments">
<t>
Special thanks to Carsten Bormann who has provided several important technical contributions, authored the security considerations section along with giving extensive comments on the document.
</t>
<t>The authors thank Geoff Mulligan, Julien Abeille, Alexandru Petrescu, Peter Siklosi, Pieter De Mil, Fred Baker, Anthony Schoofs and Phil Roberts for useful discussions and comments that have helped shaped and improve this document.</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section title="Changelog">
<t>Changes since -03:
<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 aquire 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 Prefix 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 lollypop 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'>
&RFC2119;
&RFC2460;
&RFC2491;
&RFC3775;
&RFC4191;
&RFC4193;
&RFC4291;
&RFC4429;
&RFC4443;
&RFC4861;
&RFC4862;
&RFC4944;
</references>
<references title='Informative References'>
&RFC2022;
&RFC3756;
&RFC3971;
&RFC3972;
&RFC4086;
&RFC4389;
&RFC4903;
&RFC4919;
&I-D.ietf-6lowpan-hc;
&I-D.van-beijnum-multi-mtu;
</references>
</back>
</rfc>
<!-- LocalWords: LoWPAN subnet IP IPv Unicast ULAs broadcasted lookup LoWPANs
-->
<!-- LocalWords: proxying ERs hoc anycast OII TID IEEE acknowledgement inline
-->
<!-- LocalWords: multihop lossy backhaul MultiAccess NBMA reachability ICMPv
-->
<!-- LocalWords: multicasts signalling IID autoconfigures RAs MIPv ICMP ADSL
-->
<!-- LocalWords: Autoconfiguration autoconfiguration asymmetricity EUI Prf TBD
-->
<!-- LocalWords: OIIs DHCPv anycasts CIDs unreachability LinkMTU ReachableTime
-->
<!-- LocalWords: RetransTimer autoconfigure SLLA AdvCurHopLimit AdvManagedFlag
-->
<!-- LocalWords: AdvReachableTime AdvDefaultLifetime AdvOtherConfigFlag MTU xF
-->
<!-- LocalWords: CurHopLimit Retrans AdvRetransTimer AdvInformationValid LLA
-->
<!-- LocalWords: AdvInformationSequence AdvPrefixList AdvPrefxList subnets SAA
-->
<!-- LocalWords: AdvOnLinkFlag AdvAutonomousFlag AdvValidLifetime TIDs xFFFF
-->
<!-- LocalWords: bicast subregistry
-->
| PAFTECH AB 2003-2026 | 2026-04-23 19:44:03 |