One document matched: draft-chakrabarti-6lowpan-ipv6-nd-simple-00.xml

<?xml version="1.0"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [

<!ENTITY % RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119" >

]>

<?rfc toc="yes"?>

<?rfc compact='yes'?>

<!-- <?rfc sortrefs="yes"?> -->

<?rfc symrefs="no"?>

<rfc ipr="trust200902" docName="draft-chakrabarti-6lowpan-ipv6-nd-simple-00.txt">
	
	<front>
		<title abbrev="6LoWPAN-ND-SIMPLE">
		IPv6 LoWPAN Neighbor Discovery and Addressing Choices
</title>

<author initials="S" surname="Chakrabarti" fullname="Samita Chakrabarti">
  <organization>IP Infusion</organization>
  <address>
    <postal>
	<street> 1188 Arquest Street</street>
	<city>Sunnyvale, CA</city>
        <country>USA</country>
    </postal>
    <email>samitac@ipinfusion.com</email>
  </address>
</author>

<author initials="E" surname="Nordmark" fullname="Erik Nordmark">
  <organization>Oracle, Inc.</organization>
  <address>
    <postal>
    <street>17 Network Circle</street>
    <city>Menlo Park, CA 94025</city>
    <country>USA</country>
    </postal>
    <email>Erik.Nordmark@Sun.COM</email>
  </address>
</author>


<date month="March" year="2010"/>
<workgroup>6LoWPAN WG</workgroup>
<keyword>6LoWPAN</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>IPv6</keyword>
<keyword>lowpan</keyword>
<keyword>Neighbor</keyword>
<keyword>Discovery</keyword>

<abstract>
	<t> 		
		IETF 6LoWPAN working group defines IPv6 over low-power personal area network (IEEE 802.15.4). IEEE 802.15.4 and other low-power wireless networks have limited or no usage of broadcast or multicast signaling due to energy conservation. Besides the wireless nodes may not strictly follow traditional concept of IP subnet and IP-links while connecting nodes and routers. This document describes simple optimizations to IPv6 Neighbor Discovery protocol(RFC4861), and addressing mechanisms that are useful for small scale 6LoWPAN networks in star and mesh topologies.
</t>
<t>
The optimizations include reducing the amount of Neighbor Discovery multicast
traffic and allowing for a single subnet to span multiple routers in a
"route-over" topology.
</t>
</abstract>
</front>

<middle>

<section title="Introduction and Overview">
	<t>
The IPv6-over-IEEE 802.15.4 <xref target="LOWPAN"/> document specifies
IPv6 headers carried over IEEE 802.15.4 network with the help of an 
adaptation layer which sits between the MAC layer and the IP network layer. The 
LoWPAN network is characterized by low-powered, low bit-rate, short ranged, 
low cost nodes. Thus, all-node multicast defined in Neighbor Discovery 
<xref target="ND"/> may be unsuitable in the LoWPAN network which does not have direct multicast support at the link-layer.
Broadcast messages could be used in some cases to represent all-node multicast
messages, but periodic broadcast messages should be minimized in the LoWPAN network in order to conserve energy.
</t>

<t>
This document provides an overview of IPv6 Neighbor Discovery options and describes a base mechanism for optimized 6LoWPAN neighbor discovery mechanism.
</t>

<t>
The optimizations include reducing the amount of Neighbor Discovery multicast
traffic and allowing for a single subnet to span multiple routers in a
"route-over" topology.
</t>

<section title="IPv6 Neighbor Discovery shortcomings in low-power wireless network">
    <t>
    IPv6 ND <xref target="ND"/> is based on multicast signaling messages on the local link in order to avoid broadcast messages. Following power-on and initialization of the network in IPv6 Ethernet networks, a node joins the solicited-node multicast address on the interface and then performs duplicate address detection (DAD) for the acquired link-local address by sending a solicited-node multicast message to the link. After that it sends multicast router solicitation (RS) messages to the all-router address to solicit router advertisements. Once the host receives a valid router advertisement (RA) with the "A" flag, it autoconfigures the IPv6 address with the advertised prefix in the router advertisement (RA). Besides this, the IPv6 routers usually send router advertisements periodically on the network. RAs are sent to the all-node multicast address. Nodes send Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages to resolve the IPv6 address of the destination on the link. These NS/NA messages are also often multicast messages and it is assumed that the node is on the same link and relies on the fact that the destination node is always powered and generally available. 
    </t> 

  <t>
In 6LoWPAN 802.15.4 network, primarily two types of configurations are used - 1) Star network and 2) Mesh network. A star network is similar to regular IPv6 subnet with a router and a set of nodes connected to it via the same link. But in low-power mesh networks, the nodes are capable of routing and forwarding packets but due to lossy nature of wireless communication, the IPv6-link node sets may change due to external physical factors and thus the link and connection becomes unreliable. 
 </t>
<t>
Thus optimizing the regular IPv6 Neighbor Discovery <xref target="ND"/> to minimize total number of related signaling messages without loosing
generality of Neighbor Discovery and autoconfiguration and making host and router communication reliable, is desirable in 6LoWPAN mesh configuration.
</t>

  </section>

<section title="Address Allocation Options in 6LoWPAN">
 <t>
 As 6LoWPAN and IEEE 802.15.4 technologies are evolving we can anticipate that regular IPv6 ND <xref target="ND"/> might be used in some configuration where the physical medium and hardware support higher bandwidth and processing power with low-power consumption. 

 </t>
<t>
Thus the following options of address allocations are envisioned in a 6LoWPAN network depending on the configuration and network capacity.
</t>
<t>
<list style="symbols">
  <t>
   Address allocation through multicast IPv6 Neighbor Discovery <xref target="ND"/> and IPv6 Autoconfiguration <xref target="AUTOCONF"/> with tuned parameters for 6LoWPAN usage. The Neighbor Discovery and autoconfiguration parameters are configurable on the basis of deployment requirement(example: when all 6LoWPAN nodes are one-hop away from the IPv6 router).
   </t>

  <t>
  A simplified DHCPv6 method for IPv6 address allocation in a 6LoWPAN network. This is useful for a star network and mesh network where all the nodes are in reachable range of the DHCPv6 server. DHCPv6 services SHOULD be used for assigning IPv6-addresses using 16-bit short MAC addresses described in IEEE 802.15.4 <xref target="IEEE"/> in order to ensure uniqueness of IPv6 addresses.
   </t> 

  <t>
  An optimized 6LoWPAN Neighbor Discovery is recommended for efficiency and power savings for the low-power and lossy wireless mesh networks. The simple optimization of IPv6 Neighbor Discovery<xref target="ND"/> for low-power network in this document. This mechanism SHOULD be used for efficient handling of signaling messages in the 6LoWPAN mesh and star networks using nodes with EUI-64 MAC addresses. 
  </t>
 </list>
</t>

<t>
It is noted that all the above address allocation methods MUST follow the 
address allocation principles described in <xref target="AUTOADHOC"/>.
</t>

 </section>

 <section title="Mesh-under and Route-over Concept and Behavior">
<t>
In  6LoWPAN network context, often the link-layer mesh routing mechanism for carrying IP packets as a data message is referred as "mesh-under" while routing/forwarding packets using IP-layer addresses are referred as "route-over". The difference between mesh-under and route-over networks is similar to a bridged-network and IP-routing network in the Ethernet. Thus, in a mesh-under network all nodes are considered part of an IPv6 subnet when a 6LoWPAN network is considered as one IPv6 subnet served by one or more 6LoWPAN border routers (6LBR). The 6LBR could also be a gateway to the legacy IPv4 or IPv6 network. 
</t>
<t>
In a route-over network, there are multiple IPv6 subnets connecting to each other in a 6LoWPAN network. However, unlike fixed IP networks, these subnet members may be changing due to the nature of the low-power and lossy behavior of wireless LoWPANs. Thus a route-over network is almost always a flexible set of mesh networks. The design considerations are based on the above properties. The optimized 6LoWPAN neighbor discovery are applicable to both "mesh-under" and "route-over" implementations. However, in "route-over" networks, we like to define two types of routers - 6LoWPAN border Routers(6LBR) and 6LoWPAN-routers(6LR). 6LoWPAN border Routers sit at the boundary of the 6LoWPAN and the backbone network while 6LoWPAN-routers are inside the 6LoWPAN network and they can not communicate to a different network routers directly. The 6LoWPAN-routers are assumed to be running a routing protocol. In "route-over" configuration, the hosts are unable to take part in routing and forwarding packets and they are acting as simple IPv6 hosts.
</t>
<t>
These neighbor discovery optimizations for "mesh-under" configuration where the 6LBR is acting as the IPv6 router where all the hosts in 6LoWPAN are part of one subnet and they are only one IP hop away and no 6LR concept exist in "mesh-under" topology. Thus, the IPv6 packet is carried as the data via a link-layer mesh routing protocol.
</t>
<t>
When "route-over" configuration is used, the IPv6 Neighbor Discovery operation takes place between the requesting node and the 6LRs or 6LBRs. The 6LR nodes are able to send and receive Router Advertisements, Router Solicitations as well as forward and route IPv6 packets. The packet forwarding happens at the routing layer.
</t> 
<t>
With "route-over" there is a need to allow a host to attach to different 6LRs
over time (e.g., to handle changes in the radio conditions) while the host
keeps the same IPv6 addresses. Thus one (or more) subnet prefixes (see 
<xref target="AUTOADHOC"/>) should be assigned to the 6LoWPAN. This implies
that a 6LRs need to reliably know which IP addresses are directly reachable 
from that particular 6LR; 
this information will be used by the routing protocol that is used by the 6LRs
and 6LBRs.
</t>

<t>
This document assumes that an implementation will have configuration knobs to determine whether it is running in "mesh-under" mode or "route-over" mode if the implementation supports both mechanisms.
</t>

</section>
</section>

<section title="Definition Of Terms">
		<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>
	    
	    <list style="hanging">


         <t hangText="6LoWPAN-link:"><vspace />
           It is a wireless link determined by single hop reachability of neighboring nodes.
                            </t>
	    
	    <t hangText="6LoWPAN-router (6LR):"><vspace />
                These are the intermediate routers in the 6LoWPAN network who can communicate with other 6LoWPAN-routers in the same 6LoWPAN network. These are also the immediate first-hop router for 6LoWPAN hosts. 6LoWPAN routers are present only in "route-over" topologies.
		            </t>

 <t hangText="6LoWPAN Border Router (6LBR):"><vspace />
                It is a border router located at the junction of separate 6LoWPAN networks or between a 6LoWPAN network and a non-6LoWPAN IP network.
There may be one or more 6LBR at the 6LoWPAN network border. 6LBR is the responsible authority for IPv6 Prefix propagation for the 6LoWPAN network it is serving. An isolated 6LoWPAN network also contains a 6LBR in the network, which provides the prefix(es) for the isolated network.
		            </t>

 <t hangText="Host:"><vspace />
           A host in 6LoWPAN network is considered a IPv6 node without routing and forwarding capability.                                
     </t>
	
        <t hangText="Mesh-under:"><vspace />
           It is a configuration topology where 6LoWPAN hosts are connected to the 6LBR through a mesh using Layer-2 forwarding. Thus in a "mesh-under" configuration all IPv6 hosts in a 6LoWPAN network are only one IP hop away from the 6LBR. This topology simulates the typical IP-subnet topology with one router with multiple nodes in the same subnet.
                            </t>
         <t hangText="Route-over:"><vspace />
           It is a configuration topology where 6LoWPAN hosts are connected to the 6LBR through the use of intermediate Layer-3 (IP) routing. Here hosts are typically multiple IP hops away from the 6LBR. The Route-over topology typically consists of a 6LBR, a set of 6LRs and possibly some hosts.
                            </t>




           </list>
           </t>
  </section>


<section title="Assumptions">
<t>
  <list style="symbols">

     <t>
     6LBRs are capable of routing/forwarding packets between 6LoWPAN networks and other networks. The 6LBRs are responsible for assigning one or more /64 IPv6 prefix to the 6LoWPAN network. It advertises this/these IPv6 prefixes to the 6LoWPAN network.
      </t>

    <t>
     The 6LR that are in range of 6LBR use the prefixes advertised by the the 6LBR. The 6LRs store these prefixes and use them for forming its own global autoconfigured addresses. When sending Router Advertisements, 6LRs advertise the same prefix(es). A 6LoWPAN-router SHOULD relay any prefix related options received from its parent router during Neighbor Discovery procedure.
     </t>

    <t>
    The 6LoWPAN hosts either autoconfigure their IPv6 address(es) based on the prefix(es) received in the Router Advertisement, or it uses DHCP service for address assignment. It can receive multiple Router Advertisements and should be able to configure multiple default routers as its immediate nexthop. The 6LoWPAN hosts always send their packets to the default router. If one default router becomes unavailable, it chooses the next available default router. This behavior is the same as standard IPv6 hosts behavior.
    </t>

    <t>
     In an isolated 6LoWPAN network an ULA prefix and address SHOULD be generated by the 6LBR. Thus in this topology, 6LBR prefix is formed according to <xref target="ULA"/>.
     </t>

<t>
The Prefix Options send by 6LBRs and 6LRs do not set the 'L' flag. This is 
necessary to get the hosts to send packets to (one of) their default router(s).
</t>

    <t>
     The local mobility or mobility within a 6LoWPAN is supported in this solution by using the same IPv6 prefix across the 6LoWPAN.
    </t>
    </list>
</t>
</section>



<section title="Applicability Statement">

<t>
This document aims to guide the implementors to choose an appropriate IPv6 neighbor discovery and Address configuration procedures suitable for a 6LoWPAN network. If the 6LoWPAN network does not have Multicast capability at the link-layer, then it SHOULD use the Optimized IPv6 Neighbor Discovery for the 6LoWPAN network.
</t>

<t>
This document does not specify a method for ensuring address uniqueness across
a LoWPAN. In general such a mechanism is needed for the IPv6 addresses
autoconfigured in the subnet prefix(es). In the general case of ND we use
multicast Neighbor Solicitation to perform Duplicate Address Detection (DAD)
<xref target="AUTOCONF"/>
but that is both undesirable in a 6LoWPAN due to the undesirability of
multicast packets, and insufficient in the case of "route-over" when the
subnet prefix spans several links and 6LRs.</t>

<t>The scope of this document is limited to addresses that are autoconfigured
based on EUI-64 based Interface-ids. For such addresses DAD is not required. 
Other IPv6 addresses, including those based on 16-bit IEEE 802.15.4 short 
addresses, are out of scope. Potentially DHCPv6 can be used to allocate
unique addresses for short addresses.
</t>
</section>

<section title="Autoconfiguration of 6LoWPAN Addresses">

<t>
The following discussion will include address auto-configuration procedure at the IP-layer.
 </t>

    <section title="Address Assignment in Star Networks">
      <t>
	 In a star network, all the nodes are one hop away from the IPv6-router and from each-other.
       Upon starting a node sends an IPv6 ND <xref target="ND"/> Router Solicitation (RS) to the All-Routers multicast address. The 6LBR sends unicast Router Advertisement (RA) and the node configures its IPv6 address using autoconfiguration <xref target="AUTOCONF"/>. If the nodes are using EUI-64 style MAC address, the Duplicate Address Detection SHOULD be skipped. The 6LBR is assumed to be the only router in the 6LoWPAN network - thus it should use a unique id, for example IEEE 802.15.4 PAN-ID as its subnet-id of the IPv6-address.
      </t>
    <t>
     If the node uses a short(16-bit) MAC addresses, address assignment through DHCP is advised.     </t>

     </section>

    <section title="Address Assignment in Mesh Network">

       <t>
In a "mesh-under" configuration, the nodes are considered one hop away. Thus address assignment/auto-configuration happens the same way as in Star Network configuration. However, 6LBR is acts as an Prefix authority and initial delegator of that prefix.
      </t>
     <t>
   In a "route-over" configuration, one or more 6LBR advertise the global prefix(es) along with a new IPv6 Router Advertisement option called Authoritative Router option. This option contains information about the 6LBR IP-address and a sequence number. The next-level 6LR receive the RA from 6LBR and store/auto-config with the advertised prefix. The received prefix from 6LBR and the new Authoritative Router option option are then propagated throughout the 6LoWPAN network hop by hop. The hosts use the address prefix to configure the address when they receive the Router Advertisements from their respective Neighborhood 6LR. 
     </t>

</section>

<section title="DHCPv6 Address and Resource Allocation">

<t>
DHCP address allocation procedure for 6LoWPAN is out of scope of this document.
</t>
</section>

</section>

<section title="New Neighbor Discovery options">

<t>
The optimized ND uses two new Neighbor Discovery options - Authoritative
Router option option and Node-lifetime option.
</t>

<section title="Authoritative Router option">
<t>
The Prefix Information options originate at the 6LBRs and are propagated
by the 6LRs. Thus 6LRs receive Prefix Information options from other 6LRs.
This implies that we can't just have the most recently received RA win. 
In order to be able to reliably remove prefixes from the 6LoWPAN we 
need to carry information from the authoritative 6LBR. 
We do that by introducing a sequence number which the 6LRs propagate as
they propagate the prefixes. When there are multiple 6LBRs they would have a 
separate sequence number spaces. Thus we need to carry the IP address of
the 6LBR that created the sequence number.
</t>

<t>
The Authoritative Router option is included in Router Advertisement
messages. It is required in "route-over" configurations.
</t>

<figure>
 <artwork><![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      |    Length = 3 |          Reserved             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Sequence Number                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                          6LBR Address                         +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                            Address[1] etc                     ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>Fields:
 <list style='hanging' hangIndent='15'>
  <t hangText="Type:"> TBD [To be allocated by the IANA.]</t>
  <t hangText="Length:"> 8-bit unsigned integer.
The length of the option in units of 8 octets. Always 3.</t>
  <t hangText="Reserved:"> 16-bits. This field is unused.
It MUST be initialized to zero by the sender and MUST be ignored by the
receiver.</t>
  <t hangText="Registration Period:"> 32-bit unsigned integer.
The amount of time in seconds between successive registration messages
for the same IP address.</t>
  <t hangText="6LBR Address:"> IP address of 6LBR that is authoritative
for the sequence number.</t>
 </list>
</t>

</section>


<section title="Node-lifetime option">

<t>
The 6LRs need to know the set of IP addresses that are directly reachable. This
needs to be maintained as the radio reachability changes. We introduce a 
Node-Lifetime option that is carried in the unicast NS and NA messages sent by
hosts. Thus it can be used on the unicast NS messages that that a host
sends as part of NUD to determine that it can still reach a default router.
This Node-Lifetime is used by the 6LR to reliably maintain its Neighbor
Cache.
</t>

<t>
The Node-lifetime is required for 6LoWPAN network for reliability and power saving to minimize frequent need for updating Neighbor status with the neighboring 6LR for liveliness. Thus the requested Node-lifetime provides flexibility to the requester to receive an address which should be usable (continue to be advertised by the 6LR in the routing protocol etc) during its intended of sleep schedule.
</t>


<figure>
 <artwork><![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      |   Length = 1  |          Reserved             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Registration Lifetime                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>Fields:
 <list style='hanging' hangIndent='15'>
  <t hangText="Type:"> TBD [To be allocated by the IANA.]</t>
  <t hangText="Length:"> 8-bit unsigned integer.
The length of the option in units of 8 octets. Always 1.</t>
  <t hangText="Reserved:"> 16-bits. This field is unused.
It MUST be initialized to zero by the sender and MUST be ignored by the
receiver.</t>
  <t hangText="Registration Lifetime:"> 32-bit unsigned integer.
The amount of time in seconds that the 6LR should retain the Neighbor Cache
entry for the sender of the NS/NA that includes this option.</t>
 </list>
</t>

</section>

</section>

<section title="Optimized Neighbor Discovery for 6LoWPANs">

<t>
The goal of having an optimized Neighbor Discovery is to basically use regular IPv6 Neighbor Discovery <xref target="ND"/> with some optimization for low-power networks. The main objective is to minimize the multicast messages and use unicast messages instead of multicast messages when possible. Note that IPv6 use multicast messages instead of broadcast messages. But layer-2 technologies that do not support multicast but provides broadcast support, usually map the IP multicast messages to L2 broadcast messages. IEEE 802.15.4 networks do this.
</t>

<section title="Operations Overview">

<t>
The mandatory part of the optimized Neighbor Discovery protocol is described here. Upon starting up, a node figures out whether it is configured as a router or a simple host. The procedure of determining this node behavior is local to the system and it is implementation specific.
</t>

<t>
The use of subnet and link-local address prefixes is specified in
<xref target="AUTOADHOC"/>). In this case, the link-local addresses can only
reach the set of nodes that are reachable from the sender at the time it
sends a packet. We can define that as 6LoWPAN-link. 
</t>

</section>

<section title="Existing Neighbor Discovery Messages">
<t>
IPv6 Neighbor Discovery <xref target="ND"/> protocol operates with Router Solicitation(RS), Router Advertisement(RA), Neighbor Solicitation(NS), Neighbor Advertisement (NA), and Redirect messages, link-layer address options, prefix options, MTU options etc., and a set of protocol constants. Moreover, duplicate address detection (DAD) is performed during address assignment.
</t>
<t>
The following sections describe optimizations (if any) of the above messages of IPv6 Neighbor Discovery Protocol<xref target="ND"/> for 6LoWPAN.
</t>
</section>

<section title="6LoWPAN Optimized Neighbor Discovery Messages">
<t>
<list style="numbers">
<t>
Router Advertisement(RA): Periodic RAs SHOULD be avoided. Only solicited RAs are recommended for the 6LBRs (on their 6LoWPAN interfaces) and 6LRs. An RA MUST contain the Source Link-layer Address option containing Router's link-layer address (this is optional in <xref target="ND"/>. An RA MUST carry Prefix information option with L bit being unset, so that hosts do not multicast any NS messages as part of address resolution. In addition to the Prefix option the RA should carry Authoritative Router option option generated by the 6LBR.
</t> 

<t>
Router Solicitation(RS): Upon system startup, the node sends a multicast or link broadcast (when multicast is not supported at the link-layer) RS to find out the available routers in the wireless link. An RS may be sent at other times as described in section 6.3.7 of RFC 4861. A Router Solicitation MUST carry Source Link-layer Address option.

Since no periodic RAs are allowed in a 6LoWPAN network, the host may restart 
sending multicast RS messages after NUD declares a default router unreachable.
</t> 

<t>
Default Router Selection: Same as in section 6.3.6 of RFC 4861.
</t>

<t>
Neighbor Solicitation (NS): Neighbor solicitation is used between the hosts and the default-router as part of NUD and registering the host's address(es). An NS messages MUST use the Node-lifetime option in order to accomplish the registration.
</t>

<t>
Neighbor Advertisement (NA): As defined in <xref target="ND"/>
</t>

<t>
Redirect Messages: A router in the 6LoWPAN network may send a Redirect message to a host. When to send the redirect message is implementation specific; a router may be overloaded or by some means it can determine the proximity of source and destination and decide that they should directly talk to each other. The host behavior is same as described in section 8.3 of RFC 4861 <xref target="ND"/>.
</t>

<t>
Message Validation: Same as in RFC 4861<xref target="ND"/>
</t>

<t>
MTU option: As per the RFC 4861.
</t>

<t>
Address Resolution: No multicast NS/NA are sent as the prefixes are treated as off-link. Thus no address resolution is performed at the hosts. The routers keep track of Neighbor Solicitations with Node-Lifetime options and create a neighbor cache of directly reachable addresses. The router also knows the nexthop link-local address and corresponding link-layer address when it wants to route a packet.
</t>

<t>
Neighbor Unreachability Detection(NUD): NUD is performed in "forward-progress" fashion as described in section 7.3.1 of <xref target="ND"/>. The unicast Neighbor Solicitation and Advertisement messages sent by a host as part of NUD include the Node-Lifetime option.
</t>
</list>
</t>
</section>

<section title="Host Behavior">

<t>
A 6LoWPAN host sends Router Solicitation at the system startup and also
when it suspects that one of its default routers have become unreachable
(after NUD fails). The latter part is a behavioral change from RFC 4861
<xref target="ND"/>, since RFC 4861 assumes that when NUD fails for a router there
will be some multicast RA messages that will make the host find out a
new set of working default routers. Here we avoid multicast RA messages
completely which implies that the host needs to send a RS after NUD fails,
just as it does in the case when the interface is reinitialized after a
temporary interface failure in section 6.3.7 in <xref target="ND"/>. Thus
in essence we treat a NUD failure for a default router the same way
as a temporary interface failure, which seems consistent with how 
<xref target="ND"/> operates on a wired network.
</t>

<t>
A host SHOULD be able to autoconfigure its IPv6 addresses and optionally it
can act as a simple DHCPv6 client.
</t>

<t>
A host always sends packets to (one of) its default router(s). This is 
accomplished by the 6LBRs and 6LRs never setting the 'L' flag in the Prefix
options. A router can control the host's selection of a default router
by sending Redirect messages, however care must be taken to ensure that
that router is indeed reachable from the host. Should this not be the case
then normal operation of NUD per RFC 4861 will end up deleting the redirect.
</t>

<t>
The host is unable to forward routes or participate in a routing protocol.
</t>

</section>
<section title="6LBR Behavior">

<t>
A 6LBR normally has multiple interfaces and connects the 6LoWPAN to other 6LoWPAN networks or to non-6LoWPAN network(s). The 6LBR is responsible for distributing one or more /64 prefixes to the 6LoWPAN nodes to identify a packet belonging to the particular 6LoWPAN network.
</t>

<t>
When the 6LBR sends a Router Advertisement it SHOULD include a Authoritative
Router option that includes its own address and a sequence number. (The 
Authoritative Router option is required in the "route-over" configuration.)
Each time 
the information in the RA changes (such as adding or deleting prefixes, or
changing the lifetime of the prefixes) the sequence number should be increased
by one. The 6LBR SHOULD keep the sequence number in stable storage or otherwise
ensure that after a reboot it will not reuse "old" sequence numbers.
</t>

<t>
A 6LBR keeps a cache for all the 6LoWPAN nodes' IP addresses, created from the routing protocol. The 6LBR may act as a DHCPv6 server for the 6LoWPAN network as well. It does not send unsolicited Router Advertisements on 6LoWPAN interfaces. 6LBR holds the authority of Prefix generation and initial Prefix allocation in the 6LoWPAN network.
</t>

</section>
<section title="6LR Behavior">

<t>
6LRs are only present in "Route-over" mesh topology. They participate in forwarding packets in from a host to another host or to the nexthop router. They may configure their own address based on the /64-bit prefix(es) they receive in RAs.
</t>

<t>
A 6LR keeps a cache of neighbor information collected from the Node-Lifetime options in Neighbor messages. This information is made available to the routing protocol. When receiving a packet the 6LR compares the destination against this neighbor cache. If present the host is directly connected to the 6LR and it can forward the packet to the host. Otherwise the packet is forwarded using the routing protocol. 
</t>

<t>
A 6LR receives Router Advertisements from 6LBRs and 6LRs and uses the received
Prefix options and Authoritative Router option to construct the Router 
Advertisements it sends. The 6LR MUST ignore any RA that does not contain an
Authoritative Router option. When a RA is received it compares the sequence
number and 6LBR Address against a cache of such information. If it has
information for the 6LBR Address and the received sequence number is less or 
equal to last sequence number, then it MUST ignore the received Prefix options.
Otherwise it updates the prefixes and the sequence number to what was received.
This mechanism needs to be able to handle different 6LBRs advertising different
prefixes. Among other things that implies that a RA sent by the 6LR can only
include prefixes (and the Authoritative Router option) originated
from one of the 6LBRs.
</t>

<t>
Unlike regular routers, 6LRs send multicast RS messages once upon startup to receive a RA message. After that they are not required to send RS messages, since they run a routing protocol.
</t>

</section>
</section>
 
<section title="Remaining Multicast messages">

<t>
With the optimizations specified above the only place where Neighbor Discovery
messages are multicast is Router Solicitations. Such messages must be 
conceptually multicast, both when a host is powered on and also when the NUD
indicates that a default router is unreachable, since the host needs to be 
able to find at least one new router at that point in time.
</t>

<t>
Potentially this could be further optimized if there is some L2 mechanism
to perform some form of anycast, since all that is needed is for the host to
reach at least one router. However, it isn't known to the authors whether
6LoWPAN has an L2 anycast address can be used to reach routers.
If such an address can be used, then the RS messages can be multicast at L3 
(sent to the "all-routers" IPv6 multicast address) while being anycast
at L2.
</t>

</section>
 
<section title="Security Considerations">

<t>These optimizations are not known to introduce any new threats
   against Neighbor Discovery beyond what is already documented for IPv6 [RFC 3756]. 
   However, the effect of a rogue router is more severe in Low-power wireless
   network than in the network of powered systems. The 6LoWPAN security analysis <xref
    target="6lowpan-threat"/>
   discusses possible threats. The security of 6LoWPAN Neighbor Discovery will be handled in a separate follow-up IETF publication.
</t>
</section>


<section title="IANA Considerations">

<t>If this document is approved then two Neighbor Discovery option types
need to be allocated.
</t>

</section>

<section title="Acknowledgements">

<t>
The primary idea and inspiration of this document to note different addressing mechanism and simple ND procedures are from Geoff Mulligan. </t>
<t>
Also thanks to the 6LoWPAN and 6man working group members to provide ideas on simplification. Part of the ideas are also discussed at the IETF mailing list as a summary of base 6LoWPAN-ND requirement.
</t>
</section>

</middle>

<back>
<references title="Normative References">
&RFC2119;

<reference anchor="ND"> 
<front>
	<title>Neighbor Discovery for IP version 6</title>
	<author initials="T" surname="Narten" fullname="Thomas Narten">
<organization/>
</author>
<author initials="E" surname="Nordmark" fullname="Erik Nordmark">
<organization/>
</author>
<author initials="W" surname="Simpson" fullname="W. Simpson">
<organization/>
</author>
<author initials="H" surname="Soliman" fullname="Hesham Soliman">
<organization/>
</author>
<date month="September" day="" year="2007"/>
</front>
<seriesInfo name="RFC" value="4861"/>
</reference>
<reference anchor="LOWPAN"> 
<front>
	<title>Transmission of IPv6 Packets over IEEE 802.15.4 networks</title>
	<author initials="G" surname="Montenegro" fullname="Gabriel Montenegro">
<organization/>
</author>
	<author initials="N" surname="Kushalnagar" fullname="Nandakishore Kushalnagar">
<organization/>
</author>
<date month="September" day="" year="2007"/>
</front>
<seriesInfo name="RFC" value="4944"/>
</reference>

<reference anchor="LOWPANG"> 
<front>
<title>6LoWPAN: Overview, Assumptions, Problem Statement and Goals</title>
	<author initials="N" surname="Kushalnagar" fullname="Nandakishore Kushalnagar">
<organization/>
</author>
	<author initials="G" surname="Montenegro" fullname="Gabriel Montenegro">
<organization/>
</author>
<date month="August" day="" year="2007"/>
</front>
<seriesInfo name="RFC" value="4919"/>
</reference>

</references>

<references title="Informative References">
	
<reference anchor="IPV6">
<front>
	<title>Internet Protocol, Version 6 (IPv6), Specification</title>
<author initials="S." surname="Deering" fullname="S. Deering">
<organization/>
</author>
<author initials="R." surname="Hinden" fullname="R. Hinden">
<organization/>
</author>
<date month="December" day="" year="1998"/>
</front>
<seriesInfo name="RFC" value="2460"/>
</reference>


<reference anchor="AUTOCONF">
<front>
	<title>IPv6 Stateless Autoconfiguration</title>
<author initials="S." surname="Thomson" fullname="S. Thomson">
<organization/>
</author>

<author initials="T." surname="Narten" fullname="T. Narten">
<organization/>
</author>
<author initials="T." surname="Jinmei" fullname="T. Jinmei">
<organization/>
</author>
<date month="September" day="" year="2007"/>
</front>
<seriesInfo name="RFC" value="4862"/>
</reference>

<reference anchor="SEND">
<front>
	<title>Secure Neighbor Discovery
	</title>
<author initials="J." surname="Arkko" fullname="J. Arkko">
<organization/>
</author>
<author initials="J." surname="Kempf" fullname="J. Kempf">
<organization/>
</author>
<author initials="B." surname="Zill" fullname="B. Zill">
<organization/>
</author>
<author initials="P." surname="Nikander" fullname="P. Nikander">
<organization/>
</author>
<date month="March" day="" year="2005"/>
</front>
<seriesInfo name="RFC" value="3971"/>
</reference>

<reference anchor="AUTOADHOC">
<front>
	<title>IP Addressing Model in Adhoc Networks
	</title>
<author initials="E." surname="Baccelli" fullname="E. Baccelli">
<organization/>
</author>

<author initials="M." surname="Townsley" fullname="M. Townsley">
<organization/>
</author>
<date month="December" day="" year="2009"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-autoconf-adhoc-addr-model-02.txt"/>
</reference>



<reference anchor="IEEE">
<front>
<title>IEEE Std. 802.15.4-2003</title>
<author initials="" surname="IEEE Computer Society" fullname="IEEE Computer Society">
<organization/>
</author>
<date month="October" day="" year="2003"/>
</front>
<seriesInfo name="" value=""/>
</reference>


<reference anchor="PD">
<front>
<title>Requirements for Prefix Delegation</title>
<author initials="S." surname="Miwakawya" fullname="">
<organization/>
</author>
<date month="June" day="" year="2004"/>
</front>
<seriesInfo name="RFC" value="3769"/>
</reference>

<reference anchor="ULA">
<front>
<title>Unique Local IPv6 Addresses</title>
<author initials="" surname="" fullname="">
<organization/>
</author>
<date month="" day="" year=""/>
</front>
<seriesInfo name="RFC" value="4193"/>
</reference>

<reference anchor="6lowpan-threat"> 
<front>
<title>IPv6 over Low Power WPAN Security Analysis</title>
	<author initials="D" surname="Park" fullname="Daniel Park">
<organization/>
</author>
  <author initials="K" surname="Kim" fullname="K. Kim">
<organization/>
</author>
      <author initials="E" surname="Seo" fullname="E. Seo">
<organization/>
</author>
   <author initials="S" surname="Chakrabarti" fullname="S. Chakrabarti">
<organization/>
</author>
     	
<date month="January"  year="2007"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-daniel-6lowpan-security-analysis-02.txt"/>
</reference>

</references>
</back>
</rfc>