One document matched: draft-ietf-6lowpan-nd-01.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 "bibxml/reference.RFC.2022.xml">
<!ENTITY RFC2119 SYSTEM "bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2460 SYSTEM "bibxml/reference.RFC.2460.xml">
<!ENTITY RFC2491 SYSTEM "bibxml/reference.RFC.2491.xml">
<!ENTITY RFC3971 SYSTEM "bibxml/reference.RFC.3971.xml">
<!ENTITY RFC3972 SYSTEM "bibxml/reference.RFC.3972.xml">
<!ENTITY RFC3775 SYSTEM "bibxml/reference.RFC.3775.xml">
<!ENTITY RFC4191 SYSTEM "bibxml/reference.RFC.4191.xml">
<!ENTITY RFC4291 SYSTEM "bibxml/reference.RFC.4291.xml">
<!ENTITY RFC4389 SYSTEM "bibxml/reference.RFC.4389.xml">
<!ENTITY RFC4429 SYSTEM "bibxml/reference.RFC.4429.xml">
<!ENTITY RFC4861 SYSTEM "bibxml/reference.RFC.4861.xml">
<!ENTITY RFC4862 SYSTEM "bibxml/reference.RFC.4862.xml">
<!ENTITY RFC4903 SYSTEM "bibxml/reference.RFC.4903.xml">
<!ENTITY RFC4919 SYSTEM "bibxml/reference.RFC.4919.xml">
<!ENTITY RFC4944 SYSTEM "bibxml/reference.RFC.4944.xml">
<!ENTITY I-D.ietf-6lowpan-hc SYSTEM "bibxml/reference.I-D.ietf-6lowpan-hc.xml">
<!ENTITY I-D.van-beijnum-multi-mtu SYSTEM "bibxml/reference.I-D.van-beijnum-multi-mtu.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="trust200811" docName="draft-ietf-6lowpan-nd-01">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title>Neighbor Discovery for 6LoWPAN</title>
<author initials="Z" surname="Shelby" fullname="Zach Shelby" role="editor">
<organization>
Sensinode
</organization>
<address>
<postal>
<street>Kidekuja 2</street>
<city>Vuokatti</city>
<code>88600</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, Inc.</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 very constrained wireless
networks often making use of extended multihop
topologies. However, the use of standard IPv6 Neighbor Discovery over
6LoWPAN networks has several problems. Standard Neighbor Discovery was not designed
for wireless links, and the standard IPv6 link concept and heavy use of
multicast makes it inefficient. This document spefies a new mechanism
allowing efficient Duplicate Address Detection over entire 6LoWPAN
networks. In addition it specifies context dissemination for
use with router advertisements, claim and defend addressing,
and the support of extended LoWPANs over backbone links.
</t>
</abstract>
</front>
<middle>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='introduction' title="Introduction">
<t>The IPv6 over IEEE 802.15.4 <xref target="RFC4944"/> document has
specified IPv6 headers carried over an IEEE 802.15.4 and similar network with
the help of an adaptation header which comes before the IP header.
A LoWPAN link is characterized as lossy, low-power, low bit-rate, short
range, 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 transient in nature; they are
not always considered to be in a fixed network nor they are bounded by
our standard definition of a wired-link. The link is in reality defined by
reachability and radio strength. The standard IPv6 Neighbor Discovery
<xref target="RFC4861"/> control messages and their default frequency
also attribute to unnecessary loss of power in 6LoWPAN networks.</t>
<t>Neighbor discovery for 6LoWPAN provides for basic bootstrapping and network
operation, along with advanced features such as claim and defend addressing and
extended LoWPANs over backbone links, while avoiding the use of multicast
and providing both mesh under and route over support. Unlike standard IPv6
ND <xref target="RFC4861"/>, this document takes the characteristics of
low-power, lossy wireless networks and links into account.</t>
<t>A LoWPAN network is composed of a potentially large amount of radio links,
eventually federated by a backbone or a backhaul link. Although a given link
has broadcast capabilities, the aggregation of links is a complex Non-Broadcast
MultiAccess (NBMA, <xref target="RFC2491"/>) structure with no multicast
capabilities. 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 MARS (<xref target="RFC2022"/>) for the limited purpose
of ND NS/NA, and in a lot simpler and less generic fashion. For those link scope
multicast that could not be avoided, such as ND RAs, Trickle 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 is introduced,
which allows for duplicate address detection and claim and defend addressing for the
entire LoWPAN. Address resolution simplifications are included to make LoWPAN
operation efficient and reduce LoWPAN Node complexity. A new
registration/confirmation message sequence is specified, allowing nodes to
register their IPv6 addresses with an Edge Router whiteboard. </t>
<t> The ER 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 subnets are supported. The dissemination of
RA information throughout multihop route over networks is also discussed.</t>
<t>This document also specifies the seamless integration of an extended LoWPAN and
multiple Edge Routers on a shared backbone link (e.g. Ethernet) to form a
single IPv6 subnet. This allows nodes to keep the same IPv6 address throughout
a large network, and allows for easy communications with backbone link IPv6 hosts.
</t>
<t>The document defines two new ICMPv6 messages: Router Registration and Router Confirmation. In addition a new 6LOWPAN_ER anycast address is introduced, allowing
for nodes to send register without knowing the specific Edge Router's or Router's
unicast address.</t>
<section anchor='goals+assumptions' title="Goals & Assumptions">
<t>This document has the following main goals and makes several assumptions.</t>
<t>Goals:
<list>
<t>o Avoid the use of 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 Either <xref target="RFC4944"/> or <xref target="I-D.ietf-6lowpan-hc"/> 6LoWPAN header compression used.</t>
<t>o Link layer technology may be IEEE 802.15.4 as in <xref target="RFC4944"/>, or any other suitable link-layer.</t>
<t>o Link-local addresses are derived from an EUI-64 identifier.</t>
<t>o The use of optimistic DAD.</t>
<t>o Mesh-under nodes know the edge router link-layer addresses of their
mesh network from some L2 mechanism.</t>
<t>o A subnet includes all the LoWPAN nodes and their backbone link.</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 initialisation of the network in IPv6 ethernet
networks, a node joins the solicited-node multicast address on the interface
and then it performs duplicate address detection (DAD) for the acquired
link-local address by sending solicited-node multicast message to the link.
After that it sends multicast messages to all-router address to solicit
router advertisements. Once the host receives a valid router advertisement
with the "A" flag, it autoconfigures the IPv6 address with the advertised
prefix in the rotuer advertisement (RA). Besides this, the IPv6 routers
usually send router advertisements periodically on the network. It sends
the RA to all-node multicast address. Nodes send Neighbor Solicitation/Neighbor
Advertisement messages to resolve the IPv6 address of the destination
on the link. These NS/NA messages are also often multicast messages and
it assumes that the node is on the same link and relies on the fact
that the destination node is always powered and generally reliable.</t>
<t>A LoWPAN network typically uses two types of L2 addresses - 16-bit
short addresses and 64-bit unique addresses as defined in <xref target="RFC4944"/>. Moreover, the link bandwidth is often on the order of less than 100
bytes where we often
might need to use header compression and use a minimum payload. The network
is lossy and low-powered, and it does not provide multicast capability at
the link-layer, thus simulating multicast behavior by both using broadcast
or sending a number of unicast messages, both expensive for the low-powered
network and the low-processing capable nodes. Often these low-powered
nodes conserve energy by using sleep schedules; waking them up to receive IPv6
signaling messages such as multicast messages for NS, and periodic RA is not
practical. Nor they are capable of processing address-resolution for its
neighbors effectively. Due to 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 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 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>
Readers are expected to be familiar with all the terms and concepts that are discussed in <xref target="RFC4861">"Neighbor Discovery for IP version 6"</xref>, <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 document defines additional terms:
<list style="hanging">
<t hangText="LoWPAN Host"></t>
<t>A node that only sources or sinks IPv6
datagrams. Referred to as a host in this document. The term
node is used when the the differentiation between host and router
is not important.</t>
<t hangText="LoWPAN Edge Router"></t>
<t>An IPv6 router that interconnects the LoWPAN to another network. Referred to as an Edge Router in this document.
</t>
<t hangText="LoWPAN Router"></t>
<t>A node that forwards datagrams between
arbitrary source-destination pairs using a single
6LoWPAN/802.15.4 interface. A LoWPAN Router may also
serve as a LoWPAN Host - both sourcing and sinking IPv6
datagrams. Refered to as a router in this document. All LoWPAN Routers
perform ND message relay on behalf of other nodes.
</t>
<t hangText="Mesh Under"></t>
<t>A LoWPAN configuration where the link-local
scope is defined by the boundaries of the LoWPAN and
includes all nodes within. Forwarding is achieved at L2
between mesh nodes.
</t>
<t hangText="Route Over"></t>
<t>A LoWPAN configuration where the link-local
scope is defined by those nodes reachable over a single
radio transmission. Due to the time-varying
characteristics of wireless communication, the neighbor
set may change over time even when nodes maintain the
same physical locations. Multihop is achieved using IP routing.
</t>
<t hangText="Backbone Link"></t>
<t>This is an IPv6 link that interconnects two or more Edge Routers.
It is expected to be deployed as a high speed backbone in order to
federate a potentially large set of LoWPANS.
</t>
<t hangText="Backhaul Link"></t>
<t>This is an IPv6 link that connects a single Edge Router to another network.
</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.
</t>
<t hangText="LoWPAN Link"></t>
<t>In a LoWPAN, a link can be a very instable set of nodes, for
instance the set of nodes that can receive a packet that is broadcast
over the air. Such a set may vary from one packet to the next as the
node moves or as the radio propagation conditions change.
</t>
<t hangText="LoWPAN Subnet"></t>
<t>A subnet including a LoWPAN or Extended LoWPAN, together with the backbone link with the same subnet prefix and prefix length.
</t>
<t hangText="Binding"></t>
<t>The association of the LoWPAN node IPv6 address and Interface ID
with associated whiteboard and ND states including the remaining lifetime
of that association.
</t>
<t hangText="Registration"></t>
<t>The process during which a LoWPAN node sends a Router Registration ND message to an Edge Router causing a binding for the LoWPAN node to be registered.
</t>
</list>
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='overview' title="Protocol Overview">
<t>Neighbor discovery for 6LoWPAN provides additions and optimizations to IPv6 ND <xref target="RFC4861"/> specifically supporting 6LoWPAN networks. Basic bootstrapping and network maintenenace mechanisms are provided, and the use of multicast is avoided. Duplicate address detection and claim and defend addressing are supported as part of bootstrapping. This is achieved using a whiteboard located on the 6LoWPAN Edge Routers of the LoWPAN network. Extended LoWPANs over backbone links are optionally
supported.</t>
<t>Multihop route-over networks are supported by routers relaying ND messages. ND for 6LoWPAN is designed to work with many network topologies, including isolated ad-hoc networks, single ER networks, and networks with multiple ERs interconnected by a backbone link. The use of both IEEE 802.15.4 and other suitable 6LoWPAN link-layer
technologies is considered. Both the use of mesh under forwarding and route
over routing are supported.
</t>
<figure anchor='figmu'
title="A Mesh under LoWPAN.">
<artwork><![CDATA[
|
|
|
+-----+
| | Edge
| | router
+-----+
m m
m m
m m m m m: Mesh node
m m m m
m m m
LoWPAN
]]></artwork>
</figure>
<t>In a mesh under network, shown above, multihop forwarding is dealt with below layer 3. Thus the entire LoWPAN forms a link-layer mesh. This means that the IPv6 link-local scope includes all the nodes of the LoWPAN. Link-local scope stops however at the ER, and does not include any backbone link. The implication of this regarding ND for 6LoWPAN, is that it can always be assumed that the ER and hosts are on the same link. In these networks
only LoWPAN Node and Edge Router functionalities are needed. Multicast with mesh under technologies most often induces flooding, and therefore it is avoided.</t>
<figure anchor='figro'
title="A Route over LoWPAN.">
<artwork><![CDATA[
|
|
|
+-----+
| | Edge
| | router
+-----+
r h
r r r
h r h r h h: Host
h r r h r: Router
h h h
LoWPAN
]]></artwork>
</figure>
<t>A route over network performs multihop using standard layer 3 IP routing. The
link-local scope is defined by a LoWPAN link, which includes nodes reachable over
a single radio transmission at each instant. The implication for ND for 6LoWPAN is that
if the ER is out of radio range of a host, the ND messages require
relaying by intermediate routers. In these networks also LoWPAN Router
functionality needs to be implemented by all routers in the LoWPAN. Multicast
may also involve flooding in such networks and often does not work, and thus is avoided.</t>
<figure anchor='figbackhaul'
title="A LoWPAN connected to a backhaul link.">
<artwork><![CDATA[
Infrastructure
Cloud
z
z
z Backhaul link
z
z
+-----+
| | Edge
| | router
+-----+
o o
o o o
o o o o o o: Any node
o o o o
o o o
LoWPAN
]]></artwork>
</figure>
<t>The simplest topology is a LoWPAN connected by a single Edge Router to another
network, over a so-called backhaul link. The Edge Router
maintains a whiteboard of all hosts in the network. The Edge Router terminates
6LoWPAN framing from the LoWPAN, and forwards packets. The LoWPAN subnet covers
all the interfaces in the LoWPAN, which have the same prefix and prefix length.</t>
<figure anchor='figbackbone'
title="Backbone link and edge routers with a 6LoWPAN subnet">
<artwork><![CDATA[
Infrastucture Cloud
|
|
+-----+ +-----+
| | Gateway | | Host
| | | |
+-----+ +-----+
| |
| Backbone link |
+--------------------+------------------+
| | |
+-----+ +-----+ +-----+
| | Edge | | Edge | | Edge
| | router | | router | | router
+-----+ +-----+ +-----+
o o o o o o o o
o o o o o o o o o o o o o o o o o
o o o o o o o o o o o o o o o o
o o o o o o o o o o o o
o o o o o o o o o
Extended LoWPAN OII
]]></artwork>
</figure>
<t>
In the backbone link topology, a backbone link federates multiple
LoWPANs into a single LoWPAN Subnet, the Extended LoWPAN. Each LoWPAN is
anchored at one or more Edge Router. The Edge Routers interconnect
the LoWPANs over the backbone link. A node can move freely from a
LoWPAN anchored at an Edge Router to a LoWPAN anchored at another
Edge Router on the same backbone link and conserve all IPv6 address
it has formed.
</t>
<t>
The following sections summarizes how ND for 6LoWPAN works, starting with bootrapping on the network, maintenance of the network, and finally optional features.
</t>
<section anchor='overviewbs' title="Bootstrapping">
<t>
A Host first performs stateless autoconfiguration of its link-local unicast address for each LoWPAN interface from its EUI-64 as in <xref target="RFC4944"/>. When a LoWPAN Host wants to join a LoWPAN network, it does so by listening for Route Advertisements from Edge Routers or routers, or by broadcasting a Router Solicitations. If a valid prefix is advertised in the RA, the host may form an optimistic global unique address with stateless autoconfiguration.
</t>
<t>
Next the Host registers with an on-link Edge Router or router by sending a Router Registration (RR) message to it, either unicast or using the 6LOWPAN_ER anycast address. These message exchanges are illustrated below. The RR contains the addresses the node wants to register. If the network is configured to support whiteboard claim and defend, e.g., generating short addresses for nodes, this is indicated in the RA message with the M flag. In such networks a node may request an address to be generated on its behalf by including an Address Option with the A flag and an address of length 0 in the RR. Note that registration must be performed separately for each interface of a Host.
</t>
<t>
The Edge Router replies either directly with a Router Confirmation (RC), or through a router by relaying. Note that routers only exist in route over networks, and in
mesh under networks nodes are on the same link with Edge Routers. This confirmation includes the set of addresses now bound to the whiteboard of the ER. The Host is now capable of using the LoWPAN, and the ER forwards on its behalf.
</t>
<figure anchor='figmessbasic'
title="Basic ND registration exchange when the Node and Edge Router are on the same link.">
<artwork><![CDATA[
Node Edge Router
| |
| ---------- Router Registration --------> |
| |
| <--------- Router Confirmation --------- |
| |
]]></artwork>
</figure>
<figure anchor='figmessrelay'
title="Relay ND registration exchange in route over networks.">
<artwork><![CDATA[
Node Router (relay) Edge Router
| | |
| ---- RR ---> | ---- RR ---> |
| | |
| <---- RC ---- | <---- RC ---- |
| | |
]]></artwork>
</figure>
</section>
<section anchor='overviewbo' title="Basic operation">
<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 RR to the ER. If a
host moves, or the network topology changes, and the current ER is
no longer available, the host then starts the registration process
with another ER. If the host is still in the same Extended LoWPAN (same 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, with a different prefix, the bootstrapping process is initiated again. In route over networks, Routers that act as relays must disseminate RAs to their neighbors. The Edge Router initiates RAs, and this information is included in the RAs of each router.
</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 feature allows for DAD 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.
</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 the ICMPv6 Router Advertisement is
updated with new options.
</t>
<t>The following new ICMPv6 message types are defined:
<list>
<t>Router Registration</t>
<t>Router 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>Multihop Information Option</t>
<t>Owner Interface Identifier Option</t>
</list>
</t>
<section anchor='bumess' title="Router Registration/Confirmation Message">
<t>
The Router Registration (RR) and Router Confirmation
(RC) messages are used by a Host to register with an
ER, and for the ER to confirm the binding. Any option
that is not recognized MUST be skipped silently. The
Router Registration message is sent by the LoWPAN Node
to an on-link ER or router, and may be sent unicast or to the
6LOWPAN_ER anycast address. This same message format is also used
for relayed RR/RC messages, with an alternative code that is set
when the message has been relayed.
</t>
<figure anchor='bsfig' title="Router 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 +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding 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 may be
an optimistic address.
</t>
<t hangText="Destination Address:">
The destination IPv6 address of an on-link Edge Router or
Router. May be the 6LOWPAN_ER anycast address.
</t>
<t hangText="Hop Limit:">
255
</t>
</list>
</t>
<t hangText="ICMP Fields:">
<list style="hanging">
<t hangText="Type:">
TBD1 for Router Registration, TBD2 for Router Confirmation.
</t>
<t hangText="Code:">
0 indicates a message sent directly from the orginating host. 1 indicates that the message has been relayed by a router.
</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 lollypop mechanism is used to increment the TID at each new message. TID
is set to 0 upon booting, and is incremented with each RR message. After reaching
0xFFFF, the value loops to 16 (0xFF) and is incremented from there. Thus the
values between 0-16 MUST only used after a boot or reboot.
</t>
<t hangText="P:">
1-bit Primary flag. Set to indicate that the router
is primary and MAY represent the node if used in a backbone link setup.
If the flag is not set then the router MUST not represent the node on the backbone. 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 amout 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:">
A globally unique identifier for the requesting
host's interface. Typically the EUI-64 dervied IID.
</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 RR/RC messages. Such options are not defined in this
document.
</t>
<t hangText="Source link-layer address:">
Included in a Relay RR message in case the Owner Interface Identifier is not the
same as the link-layer address of the host interface. Format as defined in <xref target="RFC4861"/> and <xref target="RFC4944"/>. If the RR was relayed, then
this option MAY be added to the RC by the relaying router to indicate the identity of the ER for use by a host.
</t>
<t hangText="Target link-layer address:">
Included in a relayed RC message in case the Owner Interface Identifier is not the same as the link-layer address of the host interface. Format as defined in <xref target="RFC4861"/> and <xref target="RFC4944"/>. MAY be included in an
RR message from a host to a router to indicate the prefered Edge Router to relay
the message to.
</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='ramess' title="Router Advertisement Message">
<t>
The RA message for 6LoWPAN is identical to the
<xref target="RFC4861"/> RA message. The use of flags is defined in
the 6LoWPAN context, and additional new options
are identified.
</t>
<figure align="center"
title="Router Advertisement Message Format"
anchor="fig:router-advertisement">
<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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |M|O|H|Prf|P|R|R| Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<t>
<list style="hanging">
<t hangText="IP Fields:">
<list style="hanging">
<t hangText="Source Address:">
MUST be the link-local address assigned to the
interface from which this message is sent.
</t>
<t hangText="Destination Address:">
Typically the Source Address of an invoking
Router Solicitation or the all-nodes multicast
address.
</t>
<t hangText="Hop Limit:">
255
</t>
</list>
</t>
<t hangText="ICMP Fields:">
<list style="hanging">
<t hangText="Type:">
134
</t>
<t hangText="Code:">
0
</t>
<t hangText="Checksum:">
The ICMP checksum.
</t>
<t hangText="Cur Hop Limit:">
As specified in <xref target="RFC4861"/>.
</t>
<t hangText="M:">
As specified in <xref target="RFC4861"/> with the exception that managed mode here refers to the claim and defend address mechanism specified in this document, not DHCPv6 as in <xref target="RFC4861"/>.
</t>
<t hangText="O:">
As specified in <xref target="RFC4861"/>.
</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>
<t hangText="Router Lifetime:">
As specified in <xref target="RFC4861"/>.
</t>
<t hangText="Reachable Time:">
As specified in <xref target="RFC4861"/>.
</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="Multihop Information 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>
Neighbor Solicitation and Neighbor Advertisement messages are employed between ERs on the backbone link. 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 RR/RC messages
and associated with bindings.
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='opt' title="6LoWPAN ND Message Options">
<t>This section defines the new ND for 6LoWPAN 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 RR, and to indicate the success or failure
of that binding in an RC. 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:/10) is assumed.
</t>
<t hangText="2:">
Prefix compressed and the default prefix 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
RR/RC message header.
</t>
<t hangText="2:">
Suffix compressed and is derived from the 6LoWPAN short
address option as defined in RFC 4944.
</t>
<t hangText="3:">
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="4-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='6preopt' 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='6lpprefixfig' 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.
</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 for route over
LoWPANs and backbone link LoWPANs, and MAY be set for
mesh-under LoWPANs without a backbone.
</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. The use
of this Context Identifier is not specified in this document.
</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='miopt' title="Multihop Information 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.
</t>
<figure anchor='miofig' title="Multihop Information 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</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="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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Owner Interface Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</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 RR and used
to match RC 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.
</t>
</list>
</t>
</section>
</section>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='6sub' title="LoWPAN Subnet">
<t>In a LoWPAN, a link can be a very unstable set of nodes, for
instance the set of nodes that can receive a packet that is broadcast
over the air at that instant. Such a set may vary from one packet to the next as the
node moves or as the radio propagation conditions change. In addition, a LoWPAN is
an NBMA network. As a result, a link does not define the proper set of nodes to
perform ND operations such as Duplicate Address Detection and Address Resolution,
nor is it stable enough to be assigned a prefix usable for routing or address configuration. Therefore in ND for 6LoWPAN, those operations are performed over the
entire LoWPAN or Extended LoWPAN. In LoWPANs it is critical that IP routing,
homogeneous addressing across the LoWPAN, and the mobility of nodes are supported.
</t>
<t>
In this document, a LoWPAN subnet is defined to be a collection of LoWPAN links
interconnected by routers that have the same subnet prefix. In particular, DAD
is performed over a LoWPAN subnet for all types of addresses, inclucing link-local.
Thus a LoWPAN subnet differs from the IPv6 subnet defined in <xref target="RFC4291"/>
as the LoWPAN subnet is associated with a collection of links and is a multi-link
subnet. In a LoWPAN, setting the hop-limit to 1 limits a packet to the link, but hop
limit assumptions MUST NOT be made about the subnet. Multi-link subnet issues
are discussed in <xref target="RFC4903"/>. The issues pointed out in
<xref target="RFC4903"/> are not relevant in 6LoWPAN where existing applications
do not exist, and the network is a variation of NBMA.
</t>
<t>In the backhaul model, the Edge Router's interface and all the LoWPAN Node interfaces registered to that Edge Router form a subnet. In that model, the Edge Router serves all the
prefixes that are defined on the subnet and can be connected to an IP routed
infrastructure. With the backhaul model, in a mesh under network the link and subnet are equivalent as the link spans the entire LoWPAN. </t>
<t>In the backbone model, a Backbone Link federates multiple LoWPANs into a
single subnet. Each LoWPAN is a collection of links anchored at an Edge Router.
The Edge Routers interconnect the LoWPANs over the Backbone Link. A node can move
freely from a LoWPAN anchored at an Edge Router to a LoWPAN anchored at another
Edge Router in the same subnet and conserve its link-local and any other IPv6
address it has formed.
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='sdoperation' title="LoWPAN Node Specification">
<t>
Instead of relying on multicast ND messages for DAD and neighbor address
resolution, LoWPAN Nodes make use of an Edge Router in the LoWPAN
which keeps a whiteboard of all bound addresses from nodes attached
to the same ER. In addition, ERs may support a backbone link,
creating an extended LoWPAN sharing the same subnet prefix. This allows
a node to change its point of attachment without changing its IPv6 addresses. This specification simplifies address resolution compared
to standard IPv6 ND. Claim and defend addressing is also specified as
part of the binding process. This section specifies LoWPAN node operations.
</t>
<section anchor='sdoperationfa' title="Forming addresses">
<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 Transit Link and the LoWPAN. The address SHOULD be created as optimistic to enable its use in the binding process with the Edge Router.
</t>
<t>
Nodes MAY learn the address of Edge Routers or Routers using
traditional means such as L2 configuration or Router Advertisement
messages. This specification also introduces a new anycast address 6LOWPAN_ER
that the node can use to reach any Edge Router or router on
the link. This specification tolerates movement within the
LoWPAN so the node does not have to stick with a given router and MAY
keep using the 6LOWPAN_ER anycast address for all its registrations.
</t>
<t>
The node SHOULD also form a global unicast address, for
routing inside the LoWPAN and reachability from outside of the Extended LoWPAN.
If a valid prefix is available from an RA ('A' flag is set), then a global unicast
address can be derived using SAA. This address is marked optimistic until confirmed
by the ER.
</t>
<t>
This specification includes a method for requesting a unique stateless address from the Edge Router by setting the 'A' flag in an Address Option during registration. This is useful for receiving a unique short address and, and works in a claim and defend fasion.
The node can tell if address generation is available
if the 'M' flag of the RA from that router is set. Address generation using the RR/RC
mechanism is stateless. Although the address is generated by the ER and checked for
uniqueness across the subnet using DAD, it is just like any other address binding in the whiteboard of the ER after assignment. Thus in order to keep using the assigned address
the host must keep refreshing the address binding, including when moving to another
ER in the same subnet.
</t>
<t>
To simplify address resolution it is assumed that nodes within a LoWPAN
use addresses in a homogeneous way and that the unicast IPv6 address IIDs resolve directly to a corresponding link-layer address. Thus avoiding address resolution whenever possible.
</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 Edge Router.
</t>
<t>
The LoWPAN Node uses unicast Router Registrations to perform the binding.
The destination address is that of an on-link Edge Router or router, or
the 6LOWPAN_ER anycast address. Registration SHOULD be preferred with on-link ERs rather than Routers. The Preference Flag of the RA is used to differentiate between ERs and routers. The source address is the link local address of the node. A unique Owner
Interface Indentifier is included in the Router Registration so the
binding can be identified throughout the subnet. This is usually the EUI-64 identifier
of the interface. The RR message includes an Address Option for each address to be
bound. Thus the message is structured as follows.
</t>
<t>ICMPv6 (Router Registration (Address Option[0], Address Option[1], Address Option[n]))</t>
<t>A unique Transaction ID (TID) is included by the host in the RR message and
used to match replies. A lollypop mechanism is used. TID is set to 0 upon booting,
and is incremented with each RR message. After reaching 0xFFFF, the value loops to
16 (0xFF) and is incremented from there. Thus the values between 0-16 MUST only used
after a boot or reboot.</t>
<t>
The acknowledgment to a Router Registration is a unicast Router Confirmation
message that contains the status of the binding. The source of the packet
is the link-local address of the Edge Router or Router. The destination address
is the link-local address of the node. An Address Option for each confirmed or
assigned address is included. Upon successful completion in the Router 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 no Router Confirmation is received within an implementation specific
timeout and number of retries, then there may be no Edge Routers in the LoWPAN.
In this case the hosts and routers SHOULD continue to operate using the optimistic address
generated by SAA. 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 Router
Registration Indentity Request Option indicates whether the binding is primary.
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 Router Registration message to renew the bindings. If
a node no longer receives RCs 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 LoWPAN subnet with that prefix may
be larger than the link in route over topologies, unless the
destination address exists in the neighbor cache. Link-layer information
should be used to maintain the neighbor cahce whenever possible rather than
using ND traffic. The ERs and routers used for registration are kept in the
default router List. Multicast addresses resolve to a broadcast as
specified in <xref target="RFC4944"/>.
</t>
</section>
<section anchor='sdoperationqa' title="Address lookup">
<t>
A LoWPAN node does not use multicast for its Neighbor
Solicitation as prescribed by the IPv6 ND <xref target="RFC4861"/> and
oDAD <xref target="RFC4429"/>. When lookup is necessary, all NS
messages are sent in unicast to the Edge Router, that answers in unicast as well. The message is a standard Neighbor Solicitation but for the destination
is set to the Edge Router address or the well known 6LOWPAN_ER anycast
address as opposed to the solicited-node multicast address for the
destination address. A LoWPAN Node SHOULD retain a small queue for packets
to neighbors awaiting to be delivered while address lookup is being performed.
The size of the queue should be suitable to the available RAM of the node, and
is not required to be a minimum of one buffer per neighbor as in <xref target="RFC4861"/>.
</t>
<t>
The Target link-layer address in the response is either that of the
destination if a short cut is possible over the LoWPAN, or that of the
Edge Router if the destination is reachable over the Transit Link, in
which case the Edge Router will terminate 6LoWPAN and relay the packet.
</t>
<t>
A LoWPAN Node does not need to join the solicited-node multicast address
for its own addresses and SHOULD NOT have to answer a multicast
Neighbor Solicitation. It MAY be configured to answer a unicast NS
but that is not required by this specification.
</t>
<t>
Care must be used with the 6LOWPAN_ER and other anycast addresses, as
anycast resolution is normally performed with a multicast NS/NA exchange.
As nodes are not required to answer NS messages, the next hop determination
process SHOULD map the anycast address to the link layer address of a
neighbor using available L2 or other ND information.
</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 an entire
LoWPAN subnet, rather than a single IP link. This section describes
ND for 6LoWPAN router operations. Note that this section
does not apply to mesh under LoWPANs.
</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 Multihop Information Option is used to support
information dissemination from one or more Edge Routers to
all other nodes in the LoWPAN. The option includes a "V"
flag 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 Router Registration/Confirmation exchanges only
occur over link-local scope, such messages must be relayed
between hosts and Edge Routers when separated by multiple
IP hops. Every LoWPAN Router MUST also serve as a relay to
ensure that any neighboring node can successfully
participate in the LoWPAN.
</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 interace 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
initializes. The router MUST learn these variables
(e.g. AdvCurHopLimit, AdvReachableTime, prefix
information, etc.) from neighboring routers. While the
variables are not initialized, the router MAY send
Router Advertisement with the "Solicit" flag set to
solicit Router Advertisements from neighboring
routers. However, the router MUST set the Router
Lifetime field to zero while one or more of its
variables are uninitialized.
</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 constistent 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>
- Multihop Information option: to indicate if
the information contained in the Router
Advertisement is valid and, if so, the freshness
of the information contained in the Router
Advertisement message. The option fields are set
as follows:
<list>
<t>
- In the "valid" flag: the current value of
AdvInformationValid.
</t>
<t>
- In the Sequence Number field: the current
value of AdvInformationSequence.
</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">
<!-- Jonathan -->
<t>TBD</t>
</section>
<section title="Relaying a Router Registration Message">
<t>
When a router receives a Router 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.
</t>
<t>
By default, the router relays Router Registration
messages to the 6LOWPAN_ER anycast address. However, the
router MAY be configured to use a list of destination
addresses, which MAY include unicast addresses, the
6LOWPAN_ER anycast address, or other addresses selected
by the network administrator. If the RR includes a Target
link-layer address option, then that SHOULD be used to form the
desination address as it indicates the ER which the LoWPAN node
prefers.
</t>
</section>
<section title="Relaying a Router Confirmation Message">
<t>
When the router receives a Relay Router Confirmation
message from an Edge Router, the Code field is set to 1.
The Owner Interface Identifier is used to form the IPv6
Destination Address for the Router Confirmation
message. If a Target link-layer address option is included in the
message, then that is used to form the IPv6 destination address instead of the
Owner Interface Identifier. The IPv6 source address is set to that of the Router.
The Hop Limit of the Router Confirmation message is set to 255.
</t>
</section>
</section>
<!--**************************************************************** -->
<!--**************************************************************** -->
<!--**************************************************************** -->
<!--**************************************************************** -->
<section anchor='eroperation' title="LoWPAN Edge Router Specification">
<t> Edge Routers are introduced to scale the Neighbor Discovery Operations
by reducing the amount of costly multicast ND messages over a LoWPAN subnet that
may cover hundreds or thousands of nodes.
</t>
<t>
Instead of multicasting ND messages, a LoWPAN Node performs unicast
exchanges with an Edge Router to claim and lookup addresses using unicast
and anycast addresses, and the Edge Router performs ND operations on its behalf over
the Backbone Link when necessary, for example DAD.
</t>
<t>
This specification documents the extensions to IPv6 Neighbor
Discovery that enables a LoWPAN Node to claim and lookup addresses
using an Edge Router as an intermediate proxy. The draft also
documents the use of EUI-64 based link-local addresses and the way
they are claimed by the Edge Routers over the Backbone link.
</t>
<t>
This specification documents the LoWPAN whiteboard, a conceptual data
structure that is similar to the MIPv6 binding cache.
</t>
<t>
Another function of the Edge Router is to perform 6LoWPAN compression and
uncompression between the LoWPAN and the Backbone Link and ensure MTU
compatibility. Packets flow uncompressed over the Backbone Link and are
routed normally towards a Gateway or an Application sitting on the Backbone
link or on a different link that is reachable via IP.
</t>
<section anchor='eroperationbind' title="Registration process">
<t>
Upon a new registration for a link-local or global unicast address
based on an IEEE 64-bit extended MAC address, the Edge Router MAY use
Optimistic DAD on the Transit Link. A positive acknowledgement can be sent
to the 6LoWPAN node right away if oDAD is used on the Transit Link.
</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 Router 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
identified by its EUI-64 address will yield and deprecate its binding.
</t>
<t>
The new Owner Interface Identifier Option in NS/NA messages that carries
the node EUI-64 address and the lollypop mechanism on the TID
help differentiate an address collision over the backbone from a movement of
a node from one Edge Router to the next. More details on collision detection
and resolution are provided in <xref target="eroperationdad" />.
</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 transit 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>
The Edge Router responds to a Router Registration with a Router Confirmation. The
source address is a link-local address of the router and the destination is the
optimistic address of the node from which the RR was received. The ER responds
to relayed RR messages with an RC message, where the destination address
is the address of the Router which sent the relayed RR message.
</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 Egde Router SHOULD reject the
registration if DAD fails on the backbone. When oDAD is used over the
backbone the Edge Router MAY issue the Router Confirmation right away
with a positive code, but if a collision is finally detected, it cancels
the registration with an asynchronous Router Confirmation and a negative
completion code on the same TID.
</t>
<t>
If the RR message includes an Address Option with the 'A' flag set, this
indicated the request of stateless address generation. If the ER supports
managed address mode ('M' flag set in its RAs), then the ER aquires 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 RC with the 'A' flag set and the assigned IPv6 address formed from the generated link-layer address with the defualt prefix inline.
</t>
</section>
<section anchor='eroperationexp' title="Exposing the Edge Router">
<t>
The Backbone link is used as reference for Neighbor Discovery operations.
When an Edge Router does not have an entry in its registration
table for a target node, it looks it up over the backbone using
ND an operation in place for that medium. Edge Routers also represent
the LoWPAN Nodes that are proactively registered to them.
That way, a lookup over the backbone is not propagated over the LoWPANs,
but answered by the 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>
An Edge Router expects and answers unicast Neighbor Solicitations for all
nodes in its LoWPANs. It answers as a proxy for the real target. The target
link-layer address in the response is either that of the destination
if a short cut is possible over the LoWPAN, or that of the Backbone
Router if the destination is reachable over the Transit Link, in which
case the Backbone Router will terminate 6LoWPAN and relay the packet.
</t>
<t>
The Edge Router forms a link-local address in exactly the same way
as any other node on the LoWPAN.
</t>
<t>
The Edge Router configures the well known 6LOWPAN_ER anycast
address on the LoWPAN interfaces where it serves as Edge Router. Note that
the Edge Router will accept registration packets with a hop limit that is
lower than 255 on that specific address.
</t>
<t>
The Edge Router announces itself using Router Advertisement (RA)
messages that are broadcasted periodically over the LOWPAN and
the backbone link. The Edge Router MAY also announce any prefix that is configured on the
transit link, and serve as the default gateway for any node on the
Transit Link or on the attached LoWPANs.
</t>
<t>
The transit link Maximum Transmission Unit serves as base for Path MTU
discovery and Transport layer Maximum Segment Size negotiation (see
section 8.3 of <xref target="RFC2460"/>) for all nodes in the LoWPANs.
To achieve this, the Edge Router announces the MTU of the transit link
over the LoWPAN using the MTU option in the RA message as prescribed
in section "4.6.4. MTU" of <xref target="RFC4861"> IPv6 Neighbor
Discovery </xref>.
</t>
<t>
LoWPAN Nodes SHOULD form IPv6 packets that are smaller than that MTU.
As a result, those packets should not require any fragmentation over
the transit link though they might be intranet-fragmented over the
LoWPAN itself as prescribed by <xref target="RFC4944"/>.
</t>
<t>
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"/>.
</t>
</section>
<section anchor='eroperationforw' title="Forwarding packets">
<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 to another
LoWPAN Node or over the Backbone link. The hop limit is decremented upon
forwarding. Otherwise, the Edge Router MUST discard the packet. If the
packet is to be transmitted over the Transit link, then the 6LoWPAN sublayer
is terminated and the full IPv6 packet is reassembled and expanded.
</t>
<t>
When forwarding a packet from the Backbone Link towards a LoWPAN interface,
the Edge Router performs the 6LoWPAN sublayer operations of compression and
fragmentation and passes the packet to the lower layer for transmission.
</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, and additional collision resolution
mechanism takes place, 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
transit link using Duplicate Address Detection. The edge router in charge
of the resolution is the edge router that handles the registration.</t>
<t>The general principles are as follows:
<list>
<t>Mobility is included and welcome. A 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 router 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 Router Registration message based on
its own states for that registration and ND exchanges over the transit
link.
</t>
<t>A registration is identified by the (OII, IPv6 address) pair. A conflict occurs
when a Router 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> A conflict may also occur with a node that is already present on the transit
link when the registration occurs, or with a node appears on the transit 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 a Router 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 transit
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 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 Router Confirmation Message
to the node, and advertises the address on the transit link.
Since this happens asynchronously to the Router Registration, the edge router
SHOULD NOT set 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 a entry on the
whiteboard, sends a positive Router Confirmation Message to the node, and
advertises the address on the transit link. Since this happens synchronously
to the Router Registration, the edge router SHOULD set set Override (O) bit in the
NA message.
</t>
<t>If the address is already present on the transit 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>
<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 looses 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">
<!--
is section should deal with the behaviour 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>The TID is a sequential number that is used to control the normal operation
of a registration and detect a duplicate Owner Interface Identifier during
the Neighbor Discovery operations. The TID is set by a node in its Router
Registration message and echoed by the edge router in the Router Confirmation
message. 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 lollypop mechanism.
When a node starts or restarts, the TID is reset to zero. After that, it is
incremented with each Router Registration. When the TID reaches its maximum
value (0xFFFF) it wraps directly to its looping value at the base of the lollypop
that is 16. So a value in the straight part of the lollypop (between 0 and 0xFF)
is only used after a reboot and before the circular part of the lollypop is entered.
</t>
<t>
Upon a positive Registration Confirmation, if the current TID is less than 16,
then the node sets it to 16. So a TID in the straight part denotes a node that
just started/restarted and did not get registered yet.
</t>
<t>To compare TID1 and TID2, the following rules apply:
<list>
<t>If at least one of TID1 and TID2 is in the straight part of the lollipop
(smaller than 16) then they compare directly.
</t>
<t>If both TID1 and TID2 are in the circular part 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 preceeding one if it is a small increment
or decrement (more or less 16) from it. During normal operations, the TIDs saved in
the white board entry should be consistent. As long as a TID is consistent with
the previous one, it appears that the new message is coming from the same source as
the previous one and there is no OII collision.
If the TID is a small decrement then the registration messages crossed and that
message should be ignored, but still there's no collision.
</t>
<t> If the TID jumps to a low value in the lollypop 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 reported as a collision, but an actual collision will be detected and
filtered out next.
</t>
<t>Otherwise, if an inconsistent TID value is detected between the new TID and
the most recently accepted value, 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 it is rejected as a 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='adhoc' title="Ad-hoc LoWPAN Operation">
<t>
LoWPAN networks by nature may often work in an ad-hoc fasion. Neighbor
Discovery for 6LoWPAN may still be applied in such ad-hoc networks.
If a router in the LoWPAN implements the Edge Router whiteboard functionality,
then ND for 6LoWPAN can be applied in routers and nodes as specified in this
document. The election of such an edge router in an ad-hoc network is not
specified here. The Edge Router does not implement forwarding or backbone features,
and must generate a prefix to advertise.
</t>
<t>
If no Edge Router is available in the LoWPAN, then the whiteboard features
specified in this draft are unavailable. The nodes in the LoWPAN SHOULD however continue
to operate using SAA optimistic addresses after timing out on Router Registrations.
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='messex' title="Message Examples">
<t>
This section provides basic examples of messages and options from
this document.
</t>
<section title="Basic RR/RC message exchange">
<t>In the basic case, when a host wanting to register to the whiteboard is
on the same link with an Edge Router, a simple RR/RC message exchange occurs.
In this example a host wants to register its address generated with SAA, and
in addition requests a generated short address.</t>
<t>First the Host sends an RR message to the Edge Router or to the 6LOWPAN_ER
Anycast address. In this example the host wants to use the Edge Router as primary,
uses a 600s lifetime, and its EUI-64 as the Owner Interface Indentifier. The
message has two Address Options. The host has just booted, therefore the TID
starts with 0.</t>
<figure anchor='fig:ex1rr' title="Basic RR 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 = +
| EUI-64 of the interface |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</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=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1|0| Reserved | Padding = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</section>
<section title="Relayed RR/RCC message exchange">
<t>In case an Edge Router is not on-link, then the RR 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 Edge Router. 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 RR 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 = +
| EUI-64 of the interface |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</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 generated
addresses are available, 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::/60 .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</section>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section title="Security Considerations">
<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 particular, it is expected that
the LoWPAN MAC provides secure unicast to/from Routers and secure
broadcast from the Routers in a way that prevents tempering with or
replaying the RA messages. However, any future 6LoWPAN security protocol that applies to Neighbor Discovery for 6LoWPAN protocol, is out of scope of this document.
</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>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section title="IANA Considerations">
<t>
This document requires two new ICMPv6 message types:
<list>
<t>Router Registration (TBD1)</t>
<t>Router 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>Multihop Information 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>The authors thank Carsten Bormann, Geoff Mulligan and Julien Abeille for useful discussions and comments that have helped shaped and improve this document.</t>
</section>
</middle>
<back>
<references title='Normative References'>
&RFC2119;
&RFC2460;
&RFC2491;
&RFC3775;
&RFC4191;
&RFC4291;
&RFC4429;
&RFC4861;
&RFC4862;
&RFC4944;
</references>
<references title='Informative References'>
&RFC2022;
&RFC3971;
&RFC3972;
&RFC4389;
&RFC4903;
&RFC4919;
&I-D.ietf-6lowpan-hc;
&I-D.van-beijnum-multi-mtu;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:21:25 |