One document matched: draft-shelby-6lowpan-nd-00.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 RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2460 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml">
<!ENTITY RFC3775 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3775.xml">
<!ENTITY RFC3963 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3963.xml">
<!ENTITY RFC3971 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3971.xml">
<!ENTITY RFC3972 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3972.xml">
<!ENTITY RFC4291 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4291.xml">
<!ENTITY RFC4389 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4389.xml">
<!ENTITY RFC4429 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4429.xml">
<!ENTITY RFC4443 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4443.xml">
<!ENTITY RFC4861 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861.xml">
<!ENTITY RFC4862 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4862.xml">
<!ENTITY RFC4919 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4919.xml">
<!ENTITY RFC4944 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4944.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="full3978" docName="draft-shelby-6lowpan-nd-00">
<?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="2008" />
<area>Internet</area>
<workgroup>6LoWPAN</workgroup>
<abstract>
<t>
The 6LoWPAN format allows IPv6 to be used over very low-power, low-bandwidth wireless networks often making use of extended multihop topologies. However, the use of standard IPv6 Neighbor Discovery over 6LoWPAN networks has several problems. Standard ND was not designed for wireless links, the standard IPv6 link concept and heavy use of multicast makes it inefficient. This paper specifies Neighbor Discovery optimized for 6LoWPAN.
</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 network with
the help of an adaptation header which comes before the IP header.
A LoWPAN network is characterized as a low-power, low bit-rate, short
range, low cost network. Thus, all-node multicast defined in IPv6 Neighbor
Discovery <xref target="RFC4861"/> is not often desirable in a wireless
low-power, lossy network. In addition IEEE 802.15.4 and similar wireless
technologies do not have multicast support, but supports broadcast. Broadcast messages could be used in some cases to represent all-node multicast messages,
but periodic broadcast messages should be minimized in LoWPANs in order to
conserve energy. Moreover, LoWPAN nodes are transient in nature; they are
not always considered to be in a fixed network nor they are bounded by
our standard definition of a wired-link. The link is often defined by
reachability and radio strength. The standard IPv6 neighbor discovery
<xref target="RFC4861"/> control messages and their default frequency
also attribute to unnecessary loss of power in the 6lowpan network.</t>
<t>The goal of this document is to minimize/remove periodic multicast signals
used by IPv6 Neighbor Discovery <xref target="RFC4861"/> while enabling
the LoWPAN to work as efficiently and optimally as possible and reducing the
complexity of LoWPAN node implementations. </t>
<t>Neighbor discovery for 6LoWPAN provides for basic bootstrapping, and network
operation, along with advanced features such as address assignment and ND Proxy,
while avoiding the use of multicast and providing both mesh under
and route over support. Unlike standard IPv6 ND <xref target="RFC4861"/>, this
document takes the lossy characteristics of wireless networks into account.</t>
<t>The concept of a LoWPAN Whiteboard located at Edge Routers is introduced,
which allows for duplicate address detection and address assignment for the
entire LoWPAN. Address resolution simplifications are made to make LoWPAN
operation efficient and reduce LoWPAN Nodes complexity. A new
registration/confirmation message sequence is specified, allowing nodes to
register their IPv6 addresses with an Edge Router, and to request global unique
address assignment. </t>
<t> The ND for 6LoWPAN whiteboard makes use of soft bindings, thus nodes send periodic registration messages in order to maintain their binding and address assignments. Changes in network topology, and mobility between ERs and subnets
are supported. The dissemination of RA information throughout multihop route
over networks is also discussed.</t>
<t>This paper also specifies an extension to ND Proxy and its use by Edge Routers,
allowing for the seamless integration of an extended LoWPAN and multiple Edge
Routers on a shared backbone link (e.g. Ethernet) to form a single IPv6 subnet.
This allows hosts to keep the same IPv6 address throughout a large network,
and allows for easy communications with backbone link IPv6 hosts.
</t>
<t>This paper defines two new ICMPv6 message sets: Router Registration/Confirmation and Relay RR/RC messages. In addition a new 6LOWPAN_ER anycast address is introduced, allowing for nodes to send register without knowing the
specific Edge Router's or Router's unicast address.</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 prefix and 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 address assignment.</t>
</list>
</t>
<t>Assumptions:
<list>
<t>o Either <xref target="RFC4944"/> or [draft-ietf-6lowpan-hc-01] 6LoWPAN header compression.</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 covers all the LoWPANs and their backbone link with the same
IPv6 global or local 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 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. Besides often these low-powered
nodes conserve energy by using sleep schedules; waking them up to receive IPv6
signaling messages such as multicast messages for NS, and periodic RA is not
practical. Nor they are capable of processing address-resolution for its
neighbors effectively. Besides due to radio strength of its neighboring
router or its own strength, a node may often move between one subnet to
another without physically moving from one place to another. Considering
the above characteristics in a LoWPAN, and IPv6 Neighbor Discovery <xref target="RFC4861"/> base protocol requirements, it was concluded that
standard Neighbor Discovery is not suitable as it is and a 6lowpan-specific
ND protocol would be useful and efficient for wide deployment of IPv6
over low-powered wireless networks of embedded devices.</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. Multihop 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 2 or more Edge Routers.
It is expected to be deployed as a high speed backbone in order to
federate a potentially large set of LoWPANS.
</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 Subnet"></t>
<t>A subnet including a LoWPAN or Extended LoWPAN, together with the backbone link sharing the same prefix.
</t>
<t hangText="Binding"></t>
<t>The association of the LoWPAN node IPv6 address and Interface ID
with associated whiteboard and proxy 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"/> supporting 6LoWPAN low-power wireless stub networks. Basic bootstrapping and network maintenenace mechanisms are provided, and the use of multicast for ND messages is avoided. Duplicate address detection and global address assignment are supported as part of bootstrapping. This is achieved using a whiteboard located on the 6LoWPAN Edge Routers of the LoWPAN network. </t>
<t>Multihop route-over networks are supported by relaying ND messages. Finally, advanced features include ND Proxy extensions, and secondary Edge Router registrations. ND for 6LoWPAN is designed to work with many network topologies, including isolated ad-hoc networks, single ER networks, and networks with multiple ERs interconnected by a backbone link. The use
of both IEEE 802.15.4 and other suitable 6LoWPAN link-layer technologies
is considered. Both the use of mesh under forwarding and route over routing are supported.
</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. The implication of this on ND for 6LoWPAN, is that it can always be assumed that the ER and hosts are on the same link. Multicast with mesh under technologies most often induces flooding, and therefore it is avoided.</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 those nodes reachable over
a single radio transmission. The implication for ND for 6LoWPAN is that
if the ER is out of radio range of a host, the ND messages require
relaying by intermediate Routers. Multicast may also involve flooding
in such networks, and is avoided.</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, and assigns
addresses. The Edge Router terminates 6LoWPAN framing from the LoWPAN,
and forwards packets. Multiple such networks may also overlap to
form an Extended LoWPAN.</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
]]></artwork>
</figure>
<t>
In the backbone link topology, a backbone link federates multiple
LoWPANs as a single IP link, the Extended LoWPAN. Each LoWPAN is
anchored at one or more Edge Router. The Edge Routers interconnect
the LoWPANs over the backbone link. A node can move freely from a
LoWPAN anchored at an Edge Router to a LoWPAN anchored at another
Edge Router on the same backbone link and conserve its link local
and any other IPv6 address it has formed. If ND Proxy is used, a
standard IPv6 Host on the backbone link can communicate with any
host in the Extended LoWPAN and vice versa.
</t>
<t>
The following sections explain the basics of how ND for 6LoWPAN works, starting with bootrapping on the network, maintenance of the network, and finally optional features such as ND Proxy.
</t>
<section anchor='overviewbs' title="Bootstrapping">
<t>
A Host first performs stateless autoconfiguration of its link-local address for each 6LoWPAN 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 global prefix is included 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, and a possible request for a global assigned address. An RR message is structured as follows, with nested Address Options inside an Identity Request Option.
</t>
<t>ICMP (Router Registration (Identity Request Option (Address Options))) </t>
<t>
The Edge Router replies either directly with a Router Confirmation (RC), or through a Router. This Confirmation includes the set of addresses now bound to the whiteboard of the ER, including assigned addresses. The RC may also include other network configuration information. The Host is now capable of using the LoWPAN, and the ER forwards on its behalf.
</t>
<figure anchor='figmessbasic'
title="Basic ND registration exchange.">
<artwork><![CDATA[
Node Edge Router
| |
| ---------- Router Registration --------> |
| |
| <--------- Router Confirmation --------- |
| |
]]></artwork>
</figure>
<figure anchor='figmessrelay'
title="Relay ND registration exchange.">
<artwork><![CDATA[
Node Router (relay) Edge Router
| | |
| ---- RR ---> | ---- Relay RR ---> |
| | |
| <---- RC ---- | <---- Relay RC ---- |
| | |
]]></artwork>
</figure>
</section>
<section anchor='overviewbo' title="Basic operation">
<t>
The whiteboard address binding and assignment are soft, and thus must
be renewed periodically as indicated by the lifetime of the identity.
This is achieved by periodically sending a new RR to the ER. If a
host moves, or the network topology changes, and the current ER is
no longer available, the host then starts the registration process
with another ER. If the host is still in the same Extended LoWPAN,
its IPv6 addresses remain the same. If the host moves to a
different LoWPAN, with a different global prefix, the bootstrapping
process is initiated again. In route over networks, Routers that act as relays must disseminate RAs to their neighbors. The Edge Router disseminates RAs, and this information is included in the RAs of each Router.
</t>
</section>
<section anchor='overviewof' title="Optional features">
<t>
ND Proxy is specified in <xref target="RFC4389"/>, and allows for two segments to be merged into a single IPv6 link. This specification extends ND Proxy for use with Extended LoWPAN networks with multiple ERs on a backbone link. This optional feature allows for the entire Extended LoWPAN and backbone links to appear as a single IPv6 link. The extended ND Proxy includes an option to uniquely identify the LoWPAN Host on the backbone, and override the claim on an address on behalf of a LoWPAN Host. Thus a Host can keep the same address, and appears the same to other Hosts on the backbone link, regardless of moving its binding from one ER to another. Forwarding is automatic regardless of which ER the host is proxied by.
</t>
</section>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='mess' title="6LoWPAN ND messages">
<t>
This section introduces message formats for all messages
used in this specification. The new messages are all ICMPv6
messages and extend the capabilities
of <xref target="RFC4861">"The IPv6 Neighbor Discovery
Protocol"</xref>.
</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.
</t>
<figure anchor='bsfig' title="Router Registration/Confirmation message format (16 octets)">
<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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Host Interface Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option(s)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
<list style="hanging">
<t hangText="IP Fields:">
<list style="hanging">
<t hangText="Source Address:">
A Link-local IPv6 address. This address may be
an optimistic address.
</t>
<t hangText="Destination Address:">
A link-local IPv6 address of an Edge Router or
Edge Router Relay.
</t>
<t hangText="Hop Limit:">
255
</t>
</list>
</t>
<t hangText="ICMP Fields:">
<list style="hanging">
<t hangText="Type:">
TBD by IANA.
</t>
<t hangText="Code:">
0
</t>
<t hangText="Checksum:">
The ICMP checksum.
</t>
<t hangText="TID:">
A unique Transaction ID assigned by the host
to match 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="Host Interface Identifier:">
A globally unique identifier for the requesting
host's interface.
</t>
</list>
</t>
<t hangText="Possible Options:">
<list style="hanging">
<t hangText="Identity Request Option">
</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='relaymess' title="Relay RR/RC message">
<t>
The Relay Router Registration/Confirmation message is used between
Routers and Edge Routers in order to relay the content of RR/RC messages
from nodes multiple IP hops from the ER. When a Host sends an RR message
to a Router, the Router copies the RR message TID, HII and options to
this Relay RR message format. When the ER Relay is sending a
confirmation message back to the Host, it is converted to a standard
RC message format.
</t>
<figure anchor='relayfig' title="Relay RR/RC message format (24 octets)">
<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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Host Interface Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Host Link-Local Address Interface Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. 6LoWPAN ND Options (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
<list style="hanging">
<t hangText="IP Fields:">
<list style="hanging">
<t hangText="Source Address:">
The IPv6 address of the Edge Router or Router that
is originating this message.
</t>
<t hangText="Destination Address:">
The IPv6 address of the Edge Router or Router that is
consuming this message.
</t>
<t hangText="Hop Limit:">
255
</t>
</list>
</t>
<t hangText="ICMP Fields:">
<list style="hanging">
<t hangText="Type:">
TBD by IANA.
</t>
<t hangText="Code:">
0
</t>
<t hangText="Checksum:">
The ICMP checksum.
</t>
<t hangText="TID:">
A unique Transaction ID assigned by the
requesting host to match 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="Host Interface Identifier:">
A globally unique identifier for the requesting
host's interface.
</t>
<t hangText="Host Link-Local Address Interface Identifier:">
The interface identifier of the requesting
hosts's link-local address used by the relay
to communicate replies to the requesting
client.
</t>
</list>
</t>
<t hangText="Possible Options:">
<list style="hanging">
<t hangText="Identity Request Option">
</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 based on the
<xref target="RFC4861"/> RA message with the addition
of a new flag "E". In addition new options are identified.
</t>
<figure align="center"
title="Router Advertisement Message Format (16 octets)"
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|S|E| rsv | 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 address assignment mechanism specified in this paper, not DHCPv6 as in <xref target="RFC4861"/>.
</t>
<t hangText="O:">
As specified in <xref target="RFC4861"/>.
</t>
<t hangText="S:">
1-bit "Router Solicitation" flag. When set, it
indicates that the router is requesting
neighboring routers to generate Router
Advertisement messages.
</t>
<t hangText="E:">
1-bit "Edge Router" flag. When set, it indicates
that the router is an Edge Router.
</t>
<t hangText="Reserved:">
A 3-bit unused field. It MUST be initialized
to zero by the sender and MUST be ignored by
the receiver.
</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">
</t>
<t hangText="Multihop Information Option">
</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="Neighbor Solicitation message">
<t>
NS message employed between ERs on the backbone link when
ND proxy is used. A unique identifier needs to be added
to the message as an option to uniquely identify a
host's interface. The NS message is used in this
document is as in <xref target="RFC4861"/> with the
addition of the Host Interface Identifier Option.
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='opt' title="6LoWPAN ND Message Options">
<t>This section defines the common ND for 6LoWPAN message options.</t>
<section anchor='ireqopt' title="Identity Request Option">
<figure anchor='identreqfig' title="Identity Request 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 |G|P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option(s)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
<list style="hanging">
<t hangText="Type:">
TBD.
</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="G:">
1-bit Global Address Request flag. Set to
indicate that the client is requesting global
addresses.
</t>
<t hangText="P:">
1-bit Primary flag. Set to indicate that the router
is primary and MAY proxy for the node if Proxy ND
is used on the backbone link. If the flag is not
set then the router MUST not proxy for the node.
</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="Lifetime:">
32-bit unsigned integer. The amout of time in
units of seconds remaining before the binding
MUST be considered expired. A value of zero
indicates that the Binding Cache entry for the
registered node MUST be deleted.
</t>
<t hangText="Possible Options:">
<list style="hanging">
<t hangText="Address Option">
</t>
<t hangText="6LoWPAN Address Option">
</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='irepopt' title="Identity Reply Option">
<figure anchor='identrepfig' title="Identity Reply 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 |G|P|X| rsv | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option(s)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
<list style="hanging">
<t hangText="Type:">
TBD.
</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="G:">
1-bit Global Address Request flag. Set to
indicate that the client is requesting global
addresses.
</t>
<t hangText="P:">
1-bit Primary flag. Set to indicate that the router
is primary and MAY proxy for the node if Proxy ND
is used on the backbone link. If the flag is not
set then the router MUST not proxy for the node.
</t>
<t hangText="X:">
1-bit Proxy Flag. Indicates that the router
actually proxies for all of the addresses in the
options field that are being assigned to the
node. This can only happen if the P flag is set
as well.
</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
MUST be considered expired. A value of zero
indicates that the Binding Cache entry for the
registered node MUST be deleted.
</t>
<t hangText="Possible Options:">
<list style="hanging">
<t hangText="Address Option">
</t>
<t hangText="6LoWPAN Address Option">
</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='addropt' title="Address Option">
<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 | P | S |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. IPv6 Address (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
<list style="hanging">
<t hangText="Type:">
TBD.
</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="P:">
8-bit unsigned integer. Identifies prefix
compression in use, 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-255:">
Reserved.
</t>
</list>
</t>
<t hangText="S:">
8-bit unsigned integer. Identifies suffix
compression in use, if any.
<list style="hanging">
<t hangText="0:">
Suffix carried inline.
</t>
<t hangText="1:">
Suffix compressed and assumes the same value
as the Host Interface Identifier field in the
RR/RC message header.
</t>
<t hangText="2:">
Suffix compressed and is derived from the 6LoWPAN PAN
ID/SHORT address option as defined in RFC 4944.
</t>
<t hangText="3-255:">
Reserved.
</t>
</list>
</t>
<t hangText="D:">
1-bit Duplicate flag. When set, indicates that
duplicates are allowed for this address (to
support anycast).
</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="IPv6 Address:">
</t>
</list>
</t>
</section>
<section anchor='6addropt' title="6LoWPAN Address Option">
<figure anchor='6lpaddrfig' title="6LoWPAN Address Option format">
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PAN ID | Short Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
<list style="hanging">
<t hangText="Type:">
TBD.
</t>
<t hangText="Length:">
1
</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="PAN ID:">
PAN ID of the client node. When included in a reply, the PAN
ID MUST be echoed from the request.
</t>
<t hangText="Short Address:">
Short address of the client node. A value of 0xffff
indicates an unspecified short address.
</t>
</list>
</t>
</section>
<section anchor='6preopt' title="6LoWPAN Prefix Information Option">
<t>Note: Context Identifier field to be added in rsv for use with HC. </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:">
TBD.
</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
[ADDRCONF], for which there may be more
restrictions on the prefix length.
</t>
<t hangText="L:">
1-bit on-link flag. When set, indicates that
this prefix can be used for on-link
determination. When not set the advertisement
makes no statement about on-link or off-link
properties of the prefix. In other words, if the
L flag is not set a host MUST NOT conclude that
an address derived from the prefix is off-link.
That is, it MUST NOT update a previous indication
that the address is on-link.
</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 [ADDRCONF].
</t>
<t hangText="CID:">
4-bit Context Identifier for this prefix information. This
is used as defined in [draft-ietf-6lowpan-hc-01].
</t>
<t hangText="Prefix:">
IPv6 Prefix.
</t>
</list>
</t>
</section>
<section anchor='miopt' title="Multihop Information Option">
<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:">
TBD.
</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>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='6sub' title="LoWPAN Subnet">
<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. As a result,
a link does not define the proper set of nodes to perform ND operations such as Duplicate Address Detection and Neighbor lookup. So in ND for
6LoWPAN, those operations are performed over a subnet. A subnet is a
collection of LoWPAN links interconnected by routers that may share one
or more global prefixes. In particular, DAD is performed over a subnet
for all types of addresses, inclucing link local.</t>
<t>In the backhaul model, an Edge Router and all the LoWPAN Nodes registered to
that Edge Router form a subnet. In that model, the Edge Router serves all the
prefixes that are defined on its subnet and can be connected to an IP routed
infrastructure. </t>
<t>In the backbone model, a Backbone Link federates multiple LoWPANs into a
single IP subnet. Each LoWPAN is a collection of links anchored at an Edge Router.
The Edge Routers interconnect the LoWPANs over the Backbone Link. A node can move
freely from a LoWPAN anchored at an Edge Router to a LoWPAN anchored at another
Edge Router in the same subnet and conserve its link local and any other IPv6
address it has formed.
</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 perform ND proxy on a backbone link,
creating an extended LoWPAN sharing the same subnet prefix. ND proxy allows
nodes to change their point of attachment without changing its IPv6 addresses. This specification simplifies address resolution compared
to standard IPv6 ND. Global address assignment is also specified as
part of the binding process, avoiding the need for additional
mechanisms such as DHCPv6.
</t>
<section anchor='sdoperationfa' title="Forming addresses">
<t>
All nodes are required to autoconfigure at least one address, a link-local
address that is derived from the IEEE 64-bit extended MAC
address that is globally unique to the device as in <xref target="RFC4944"/>. Link-local addresses are
described in section 2.5.6 of <xref target="RFC4291"/>. Appendix A of
that specification explains how the node builds an interface-ID based on
the IEEE 64-bit extended MAC address by inverting the "u" (universal/local) bit.
</t>
<t>
As a result, knowledge of the 64-bit address of another node on the same
extended LoWPAN is enough to derive its link-local address and reach it
over IP. Another consequence is that the link local address is presumably
unique on the Extended LoWPAN, which enables the use of Optimistic Duplicate Address Detection (oDAD) <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 ER and MAY
keep using the 6LOWPAN_ER anycast address for all its registrations.
</t>
<t>
The node might also form Unique Local and Global Unicast addresses, for
instance if it needs to be reachable from the outside of the Extended LoWPAN. If a Global Prefix is available from an RA ('A' flag is set), then a Global Unicast address can be derived from the IEEE-64-bit extended MAC address using SAA. This address is marked optimistic until confirmed by the ER.
</t>
<t>
This specification includes a method for requesting a unique assigned Global Unicast address from the Edge Router by setting the 'G' flag of the Identity Request Option during registration. This is useful in the case of e.g. short addresses and avoids the need for a separate mechanism such as DHCPv6.
</t>
<t>
To simplify address resolution it is assumed that LoWPAN nodes
are assigned addresses in a homogeneous so that the unicast IPv6 addresses IID resolve directly to a corresponding link-layer address. Thus
avoiding address resolution when possible.
</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. The source address is the link local address of the node. A unique Host Interface
Indentifier is included in the Router Registration so the binding can be identified throughout the subnet. This is usually the EUI-64 identifier of the sending node. The
RR message includes an Identity Request Option. If the node would like to be assigned a Global Unique address the Global Flag 'G' is set. For each address to be bound
an Address Option is included in the Identity Request Option. Thus the message
is structured as follows.
</t>
<t>ICMP (Router Registration (Identity Request Option (Address Options))) </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 in the Identity Reply Option. Upon successful
completion in the Router Confirmation message, the LoWPAN Node sets the address
from optimistic or tentative to preferred.
</t>
<t>
The 'X' flag in the Router Confirmation Indentity Reply Option indicates that the
Edge Router has completed DAD and now owns the Binding Address over the Transit Link.
</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 over a same or different LoWPANs. The 'P' flag in the Router
Registration Indentity Request Option indicates whether the binding is primary.
</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 ER in the current subnet (with the same
network prefix), 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. Global and Local
prefix are assumed to be off-link as the LoWPAN subnet with that prefix may
be much larger than the link in route over topologies, unless the
destination address exists in the neighbor cache. Link-layer information should be used to maintain the neighbor cahce whenever
possible rather than using ND traffic. The ERs and Routers used for registration are kept in the Default Router List. Multihop addresses
resolve to a broadcast as specified in <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 ND protocol <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 must extend ND as specified in
<xref target="RFC4861"/> to operate over an entire subnet, specifically
the subnet controlled by Edge Routers, rather than a
single IP link.
</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 that indicates that the information contained in the
Router Advertisement is valid. The option also includes a
sequence number to ensure that all nodes converge on the
same settings.
</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 the following conceptual variables
to be configured by system management. The specific
variable names are used for demonstration purposes only,
and an implementation is not required to have them, so
long as its external behavior is consistent with that
described in this document. The meaning of these
variables are as defined in Section 6.2.1 of [RFC
4861]. Default values are specified to simplify
configuration in common cases.
</t>
<t>
<list>
<t>- IsRouter</t>
<t>- MaxRtrAdvInterval</t>
<t>- MinRtrAdvInterval</t>
<t>- AdvDefaultLifetime</t>
</list>
</t>
<t>
A router MUST allow the following conceptual variables
to be configured by information received in Router
Advertisement messages. The specific variable names are
used for demonstration purposes only, and an
implementation is not required to have them, so long as
its external behavior is consistent with that described
in this document. The meaning of these variables are as
defined in Section 6.2.1 of [RFC 4861]. However, default
values are not relevant as a router should not be
advertising such values until they have been received
from other neighboring routers.
</t>
<t>
<list style="hanging">
<t>- AdvManagedFlag</t>
<t>- AdvOtherConfigFlag</t>
<t>- AdvReachableTime</t>
<t>- AdvRetransTimer</t>
<t>- AdvCurHopLimit</t>
<t>- AdvPrefixList</t>
</list>
</t>
</section>
<section title="Becoming an Advertising Interface">
<t>
An interface may become an advertising interace as
specified in Section 6.2.2 of [RFC 4861].
</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
[ramess].
</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>
- The E flag is not set.
</t>
<t>
- In the S flag: One if the router is soliciting
Router Advertisements from neighboring nodes. Zero
if the router is not soliciting Router
Advertisements from neighboring nodes.
</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>
- Prefix Information options: one Prefix
Information option for each prefix listed in
AdvPrefixList with the option fields set from
the information in the AdvPrefxList entry as
follows:
<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 [RFC 4861].</t>
</section>
<section title="Ceasing To Be an Advertising Interface">
<t>As specified in Section 6.2.5 of [RFC 4861].</t>
</section>
<section title="Processing Router Solicitations">
<t>As specified in Section 6.2.6 of [RFC 4861].</t>
</section>
<section title="Router Advertisement Consistency">
<t>TBD</t>
</section>
<section title="Relaying a Router Registration Message">
<t>
When a router receives a Router Registration message
from a LoWPAN Node, the router copies the information from
the Router Registration message into the Relay Router
Registration message. The Host Link-Local Address
Interface Identifier is the only differing field from
the Router Registration message, and the router copies
the value from the IID of the Router Registration's IP
Source Address.
</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.
</t>
</section>
<section title="Relaying a Router Confirmation Message">
<t>
When the router receives a Relay Router Confirmation
message from an Edge Router, the router copies the
information from the Relay message into a Router
Confirmation message. The Host Link-Local Address
Interface Identifier is used to form the IPv6
Destination Address for the Router Confirmation
message. The Hop Limit of the Router Confirmation
message is set to 255.
</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 subnet that
may cover hundreds or thousands of nodes.
</t>
<t>
Instead of multicasting ND messages, a LoWPAN Node performs unicast
exchanges to its Edge Router to claim and lookup addresses using unicast
and anycast addresses, and the Edge Router proxies the ND requests over
the Backbone Link when necessary.
</t>
<t>
This specification documents the extensions to IPv6 Neighbor
Discovery that enables a LoWPAN Node to claim and lookup addresses
using a Edge Router as an intermediate proxy. The draft also
documents the use of EUI-64 based link-local addresses and the way
they are claimed by the Edge Routers over the Backbone link.
</t>
<t>
For the purpose of Neighbor Discovery proxying, this specification
documents the LoWPAN registration table, 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 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 renumber. To enable this, the ND proxy operation upon a Router Registration/Confirmation flow wins the address ownership over a
ND proxy operation that is done asynchronously, on behalf of the same
LoWPAN Node, upon a prior registration. So an Edge Router that would
happen to have a binding for that same address for the same LoWPAN Node
identified by its EUI-64 address will yield and deprecate its binding.
</t>
<t>
A new option in NS/NA messages that carries the node EUI-64 address
enables to differentiate an address collision from a movement of
a node from one Edge Router to the next. Upon a registration flow,
a node doing DAD SHOULD ignore NA without the the override (O) bit,
and set the override (O) bit in its own NA messages. Asynchronously
to the registration, a node SHOULD NOT set the override (O) bit in
its NA messages and should yield to an NA message with the override
(O) bit set.
</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 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.
</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. The ER responds to Relay RR messages with a Relay RC message, where the destination address is the address of the Router which sent the Relay RR message.
</t>
<t>
If the Edge Router is primary for a registration as indicated by the
'P' flag in the Identity Request Option and it is connected to a
Backbone, then it SHOULD perform proxy ND operations on the backbone and
indicate so in the Router Confirmation message using the 'X' flag of the
Identity Reply Option. In particular the Egde Router SHOULD reject the
registration if DAD fails on the backbone. When oDAD is used over the
backbone the Edge Router MAY issue the Router Confirmation right away
with a positive code, but if a collision is finally detected, it cancels
the registration with an asynchronous Router Confirmation and a negative
completion code on the same TID.
</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 operation in place for that medium. Edge Routers also perform ND
proxying for the LoWPAN Nodes that are proactively registered to them.
That way, a lookup over the backbone is not propagated over the LoWPANs,
but answered by the proxy that has the registration for the target, if any.
</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. It uses the same link local address
for the Backbone Link and for all the associated LoWPAN(s) connected
to that Edge Router.
</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.
</t>
<t>
A new (E) bit in the RA indicates the Edge Router capability. In this
way a node can learn the PAN-ID and the 16-bit short address for the
Edge Router if it was not already acquired from another process that
is not covered by this specification.
</t>
<t>
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. 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='eroperationfault' title="Fault tolerance">
<t>TBD : to be provided in the next revision.</t>
</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>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section title="IANA Considerations">
<t>
This specification requires four new ICMP types for binding registration.
The is also a need for a new link local anycast address, 6LOWPAN_ER
for the Edge Routers and Routers; used as a functional address.
</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;
&RFC3775;
&RFC4291;
&RFC4429;
&RFC4443;
&RFC4861;
&RFC4862;
&RFC4944;
</references>
<references title='Informative References'>
&RFC3963;
&RFC3971;
&RFC3972;
&RFC4389;
&RFC4919;
&I-D.van-beijnum-multi-mtu;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:47:01 |