Subject: [6lowpan] Fwd: New Version Notification for draft-ietf-6lowpan-nd-08

From: Zach Shelby <[email-masked]>
Date: Tue, 2 Feb 2010 00:17:22 +0200

Hi everyone,

Thanks to an active discussion among the ND authors, and a bunch of helpful reviews (thanks Richard, Anders and Colin), I finally managed to post 6lowpan-nd-08, in its new slim form (think biggest loser). After Hiroshima we reached good WG consensus to split the ND work into the basic mechanism (which is now this document) and a separate Extended LoWPAN draft (to be started), furthermore we agreed to deal with the DAD issue. This document hopefully moves us very close to that goal. This also includes the new RS feature suggested by Anders.

http://www.ietf.org/id/draft-ietf-6lowpan-nd-08.txt

As always with major changes (this needed lots of hacking and major editing), there are surely tons of bugs and loose-ends left. Help to find those appreciated.

   Changes from -07 to -08:

      o Removed Extended LoWPAN and Whiteboard related sections.

      o Included reference to the autoconf addressing model.

      o Added Optimistic Flag to 6AO.

      o Added guidelines on routers performing DAD.

      o Removed the NR/NC Advertising Interval.

      o Added assumption of uniform IID formation and DAD throughout a
      LoWPAN.

The major open issue we have is how to develop the DAD text in Section 5.3 in such a way that it works for most people, yet produces reliable and safe LoWPANs, and is yet acceptable to the IPv6 crowd and especially the IESG ;-) We are trying to find a balance to keep the WG happy, yet having a chance to actually become an RFC.... 

It would also be nice to reduce the complexity of NR/NC and especially 6AO message processing. Writing the spec, I am at least not totally happy with the amount of explaining needed.... Is there a sleeker way to deal with the addresses?

Zach

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: February 1, 2010 23:59:40 GMT+02:00
> To: [email-masked]
> Cc: [email-masked],[email-masked],[email-masked],[email-masked],[email-masked]
> Subject: New Version Notification for draft-ietf-6lowpan-nd-08 
> 
> 
> A new version of I-D, draft-ietf-6lowpan-nd-08.txt has been successfuly submitted by Zach Shelby and posted to the IETF repository.
> 
> Filename:	 draft-ietf-6lowpan-nd
> Revision:	 08
> Title:		 6LoWPAN Neighbor Discovery
> Creation_date:	 2010-02-01
> WG ID:		 6lowpan
> Number_of_pages: 46
> 
> Abstract:
> This document specifies a new Neighbor Discovery mechanism suitable
> for LoWPANs.  The 6LoWPAN format allows IPv6 to be used over energy
> and bandwidth constrained wireless networks often making use of
> multihop topologies.  However, the use of classic IPv6 Neighbor
> Discovery with 6LoWPAN has several problems.  Classic Neighbor
> Discovery was not designed for non-transitive wireless links, and the
> traditional IPv6 link concept and heavy use of multicast makes it
> unpractical.  This document specifies a simple Neighbor Discovery
> mechanism both sufficient yet minimal for LoWPAN operation.
> 
> 
> 
> The IETF Secretariat.
> 
> 

-- 
http://www.sensinode.com
http://zachshelby.org - My blog "On the Internet of Things"
http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof.

---

From: Robert Cragie <[email-masked]>
Date: Tue, 09 Feb 2010 22:53:54 +0000

Hi Zach,

I have been through the document and made some corrections (in yellow) 
and some comments (in cyan) - see attachment.

The main things I found were:

    * Inconsistent terminology. Bar the actual definitions, the terms,
      'host', 'node', 'router' and 'Edge Router' should be used
      throughout, not a 'LoWPAN' variant of them.
    * Some hangovers re. whiteboard and Extended LoWPAN
    * DAD not covered - as mentioned below
    * Propagation of RS/RA not covered
    * Hints at relaying NR/NC but not covered
    * Assumption that IID will use EUI-64 whereas it could be formed
      from alternate link-layer address.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com <http://www.gridmerge.com/>

Robert Cragie wrote:
> Hi Zach,
>
> I have been through the document and made some corrections (in yellow) 
> and some comments (in cyan) - see attachment.
>
> The main things I found were:
>
>     * Inconsistent terminology. Bar the actual definitions, the terms,
>       'host', 'node', 'router' and 'Edge Router' should be used
>       throughout, not a 'LoWPAN' variant of them.
>     * Some hangovers re. whiteboard and Extended LoWPAN
>     * DAD not covered - as mentioned below
>     * Propagation of RS/RA not covered
>     * Hints at relaying NS/NC but not covered
>     * Assumption that IID will use EUI-64 whereas it could be formed
>       from alternate link-layer address.
>
> Robert 
>
> Robert Cragie (Pacific Gas & Electric)
>
> Gridmerge Ltd.
> 89 Greenfield Crescent,
> Wakefield, WF4 4WA, UK
> +44 (0) 1924 910888
> http://www.gridmerge.com <http://www.gridmerge.com/>
>
>
>
> Zach Shelby wrote:
>> Hi everyone,
>>
> ------------------------------------------------------------------------
>
>
> [Docs <../html/>] [txt 
> <http://tools.ietf.org/id/draft-ietf-6lowpan-nd-08.txt>] [pdf 
> </pdf/draft-ietf-6lowpan-nd-08.txt>] [WG <../wg/6lowpan>] [Email 
> <mailto:[email-masked]?subject=draft-ietf-6lowpan-nd%20>] 
> [Diff1 </rfcdiff?difftype=--hwdiff&url2=draft-ietf-6lowpan-nd-08.txt>] 
> [Diff2 </rfcdiff?url2=draft-ietf-6lowpan-nd-08.txt>] [Nits 
> </idnits?url=http://tools.ietf.org/id/draft-ietf-6lowpan-nd-08.txt>]
>
> Versions: (draft-hui-6lowpan-nd <./draft-hui-6lowpan-nd>) 00 
> <./draft-ietf-6lowpan-nd-00> 01 <./draft-ietf-6lowpan-nd-01> 02 
> <./draft-ietf-6lowpan-nd-02> 03 <./draft-ietf-6lowpan-nd-03>
> 04 <./draft-ietf-6lowpan-nd-04> 05 <./draft-ietf-6lowpan-nd-05> 06 
> <./draft-ietf-6lowpan-nd-06> 07 <./draft-ietf-6lowpan-nd-07> 08 
> <./draft-ietf-6lowpan-nd-08>
>
>  
> 6lowpan Working Group                                     Z. Shelby, Ed.
> Internet-Draft                                                 Sensinode
> Updates: 4944 <./rfc4944> (if approved)                                   P. Thubert
> Intended status: Standards Track                                   Cisco
> Expires: August 5, 2010                                           J. Hui
>                                                                Arch Rock
>                                                           S. Chakrabarti
>                                                              IP Infusion
>                                                               C. Bormann
>                                                  Universitaet Bremen TZI
>                                                              E. Nordmark
>                                                                      Sun
>                                                         February 1, 2010
>  
>  
>                        6LoWPAN Neighbor Discovery
>                         draft-ietf-6lowpan-nd-08 <./draft-ietf-6lowpan-nd-08> 
>  
> Abstract
>  
> Status of this Memo
>    This Internet-Draft is submitted to IETF in full conformance with the
>    provisions of BCP 78 <./bcp78> and BCP 79 <./bcp79>.
>  
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF), its areas, and its working groups.  Note that
>    other groups may also distribute working documents as Internet-
>    Drafts.
>  
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time.  It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
>  
>    The list of current Internet-Drafts can be accessed at
>    http://www.ietf.org/ietf/1id-abstracts.txt.
>  
>  
>  
>  
> Shelby, et al.           Expires August 5, 2010                 [Page 1] 
>   
>   <#page-2> 
> Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
>  
>  
>    The list of Internet-Draft Shadow Directories can be accessed at 
>    http://www.ietf.org/shadow.html. 
>  
>    This Internet-Draft will expire on August 5, 2010.
>  
> Copyright Notice
>  
>    Copyright (c) 2010 IETF Trust and the persons identified as the
>    document authors.  All rights reserved.
>  
>    This document is subject to BCP 78 <./bcp78> and the IETF Trust's Legal
>    Provisions Relating to IETF Documents
>    (http://trustee.ietf.org/license-info) in effect on the date of
>    publication of this document.  Please review these documents
>    carefully, as they describe your rights and restrictions with respect
>    to this document.  Code Components extracted from this document must
>    include Simplified BSD License text as described in Section 4 <#section-4>.e of
>    the Trust Legal Provisions and are provided without warranty as
>    described in the BSD License.
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
> Shelby, et al.           Expires August 5, 2010                 [Page 2] 
>   
>   <#page-3> 
> Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
>  
>  
> Table of Contents
>  
>    1 <#section-1>.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4 <#page-4> 
>      1.1 <#section-1.1>.  Goals, Assumptions, and Guesses  . . . . . . . . . . . . .  5 <#page-5> 
>      1.2 <#section-1.2>.  Why not classic IPv6 ND? . . . . . . . . . . . . . . . . .  5 <#page-5> 
>    2 <#section-2>.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6 <#page-6> 
>      2.1 <#section-2.1>.  6LoWPAN Terminology  . . . . . . . . . . . . . . . . . . .  7 <#page-7> 
>      2.2 <#section-2.2>.  ND Terminology . . . . . . . . . . . . . . . . . . . . . .  9 <#page-9> 
>    3 <#section-3>.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . . 10 <#page-10> 
>      3.1 <#section-3.1>.  Topology . . . . . . . . . . . . . . . . . . . . . . . . . 11 <#page-11> 
>      3.2 <#section-3.2>.  Bootstrapping  . . . . . . . . . . . . . . . . . . . . . . 12 <#page-12> 
>      3.3 <#section-3.3>.  Operation  . . . . . . . . . . . . . . . . . . . . . . . . 13 <#page-13> 
>    4 <#section-4>.  Message Formats  . . . . . . . . . . . . . . . . . . . . . . . 13 <#page-13> 
>      4.1 <#section-4.1>.  Node Registration/Confirmation Message . . . . . . . . . . 14 <#page-14> 
>      4.2 <#section-4.2>.  Router Solicitation Message  . . . . . . . . . . . . . . . 16 <#page-16> 
>      4.3 <#section-4.3>.  Router Advertisement Message . . . . . . . . . . . . . . . 17 <#page-17> 
>      4.4 <#section-4.4>.  Message Options  . . . . . . . . . . . . . . . . . . . . . 18 <#page-18> 
>        4.4.1 <#section-4.4.1>.  6LoWPAN Address Option . . . . . . . . . . . . . . . . 18 <#page-18> 
>        4.4.2 <#section-4.4.2>.  6LoWPAN Information Option . . . . . . . . . . . . . . 19 <#page-19> 
>        4.4.3 <#section-4.4.3>.  6LoWPAN Summary Option . . . . . . . . . . . . . . . . 21 <#page-21> 
>        4.4.4 <#section-4.4.4>.  Owner Interface Identifier Option  . . . . . . . . . . 22 <#page-22> 
>    5 <#section-5>.  Protocol Specification . . . . . . . . . . . . . . . . . . . . 23 <#page-23> 
>      5.1 <#section-5.1>.  Interface initialization . . . . . . . . . . . . . . . . . 23 <#page-23> 
>      5.2 <#section-5.2>.  Node Registration  . . . . . . . . . . . . . . . . . . . . 24 <#page-24> 
>        5.2.1 <#section-5.2.1>.  Processing a Node Registration Message . . . . . . . . 25 <#page-25> 
>        5.2.2 <#section-5.2.2>.  Processing a Node Confirmation Message . . . . . . . . 25 <#page-25> 
>      5.3 <#section-5.3>.  Duplicate Address Detection  . . . . . . . . . . . . . . . 26 <#page-26> 
>      5.4 <#section-5.4>.  Next-hop Determination . . . . . . . . . . . . . . . . . . 27 <#page-27> 
>      5.5 <#section-5.5>.  Address Resolution . . . . . . . . . . . . . . . . . . . . 27 <#page-27> 
>      5.6 <#section-5.6>.  Unreachability Detection . . . . . . . . . . . . . . . . . 28 <#page-28> 
>      5.7 <#section-5.7>.  Context Dissemination  . . . . . . . . . . . . . . . . . . 28 <#page-28> 
>    6 <#section-6>.  Node Specification  . . . . . . . . . . . . . . . . . . 29 <#page-29> 
>      6.1 <#section-6.1>.  Conceptual structures  . . . . . . . . . . . . . . . . . . 29 <#page-29> 
>      6.2 <#section-6.2>.  Conceptual variables . . . . . . . . . . . . . . . . . . . 30 <#page-30> 
>    7 <#section-7>.  Router Specification  . . . . . . . . . . . . . . . . . 30 <#page-30> 
>      7.1 <#section-7.1>.  Router Configuration Variables . . . . . . . . . . . . . . 30 <#page-30> 
>      7.2 <#section-7.2>.  Becoming an Advertising Interface  . . . . . . . . . . . . 30 <#page-30> 
>      7.3 <#section-7.3>.  Router Advertisement Message Content . . . . . . . . . . . 31 <#page-31> 
>      7.4 <#section-7.4>.  Sending Unsolicited Router Advertisements  . . . . . . . . 32 <#page-32> 
>      7.5 <#section-7.5>.  Ceasing To Be an Advertising Interface . . . . . . . . . . 32 <#page-32> 
>      7.6 <#section-7.6>.  Processing Router Solicitations  . . . . . . . . . . . . . 32 <#page-32> 
>      7.7 <#section-7.7>.  Binding Table  . . . . . . . . . . . . . . . . . . . . . . 32 <#page-32> 
>    8 <#section-8>.  Ad-hoc LoWPAN  . . . . . . . . . . . . . . . . . . . . . . . . 32 <#page-32> 
>    9 <#section-9>.  Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 33 <#page-33> 
>    10 <#section-10>. Use of 6LoWPAN-ND under RFC4861 <./rfc4861>-only stacks  . . . . . . . . . 34 <#page-34> 
>    11 <#section-11>. Message Examples . . . . . . . . . . . . . . . . . . . . . . . 34 <#page-34> 
>      11.1 <#section-11.1>. NR/NC message exchange . . . . . . . . . . . . . . . . . . 34 <#page-34> 
>      11.2 <#section-11.2>. Router advertisement . . . . . . . . . . . . . . . . . . . 36 <#page-36> 
>  
>  
>  
> Shelby, et al.           Expires August 5, 2010                 [Page 3] 
>   
>   <#page-4> 
> Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
>  
>  
>    12 <#section-12>. Security Considerations  . . . . . . . . . . . . . . . . . . . 37 <#page-37> 
>    13 <#section-13>. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 38 <#page-38> 
>    14 <#section-14>. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 38 <#page-38> 
>    15 <#section-15>. Changelog  . . . . . . . . . . . . . . . . . . . . . . . . . . 38 <#page-38> 
>    16 <#section-16>. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 <#page-42> 
>      16.1 <#section-16.1>. Normative References . . . . . . . . . . . . . . . . . . . 42 <#page-42> 
>      16.2 <#section-16.2>. Informative References . . . . . . . . . . . . . . . . . . 43 <#page-43> 
>    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 <#page-44> 
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
> Shelby, et al.           Expires August 5, 2010                 [Page 4] 
>   
>   <#page-5> 
> Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
>  
>  
> 1.  Introduction 
>  
>    The IPv6 over IEEE 802.15.4 [RFC4944 <./rfc4944>] document has specified how to
>    carry IPv6 packets over IEEE 802.15.4 and similar networks (6LoWPANs
>    or LoWPANs for short) with the help of an adaptation header which
>    comes before the IP header.  A link in such a 6LoWPAN is
>    characterized as lossy, low-power, low bit-rate, short range, with
>    many nodes saving energy with long deep sleep periods.  Multicast as
>    used in classic IPv6 Neighbor Discovery [RFC4861 <./rfc4861>] is not desirable in
>    such a wireless low-power, lossy network.
>  
>    Moreover, LoWPAN links are asymmetric and non-transient in nature;
>    they are not always considered to be in a fixed network nor are they
>    bounded by our traditional definition of a wired-link.  A LoWPAN is
>    potentially composed of a large amount of overlapping radio ranges,
>    eventually federated by a backbone or a backhaul link.  Although a
>    given radio range has broadcast capabilities, the aggregation of
>    these is a complex Non-Broadcast MultiAccess (NBMA, [RFC2491 <./rfc2491>])
>    structure with (generally) no LoWPAN-wide multicast capabilities.
>    link-local scope is in reality defined by reachability and radio
>    strength.  Thus we can consider a LoWPAN to be made up of links with
>    undetermined connectivity properties as defined in
>    [I-D.ietf-autoconf-adhoc-addr-model <#ref-I-D.ietf-autoconf-adhoc-addr-model>], along with the corresponding
>    assumptions defined therein.  The classic IPv6 Neighbor Discovery
>    [RFC4861 <./rfc4861>] control messages, the use of multicast and their default
>    frequency also attribute to unnecessary waste of energy in LoWPANs.
>  
>    This specification introduces a new mechanism called Node
>    Registration, used to optimize the interface between hosts and
>    routers in a LoWPAN.  That registration mechanism provides a service
>    somewhat similar to the Multicast Address Resolution Server (MARS)
>    [RFC2022 <./rfc2022>] for a limited purpose, and in a much simpler and less
>    generic fashion.  The use of Router Advertisements to disseminate
>    prefix and header compression context throughout the LoWPAN is also
>    specified.  The solution supports the use of both link-layer- or
>    LoWPAN-level mesh (Mesh Under) and IP routing (Route Over) solutions
>    for multihop forwarding.  This specification is both sufficient and
>    required for LoWPAN operation.  The 6LoWPAN-ND mechanism could also
>    coexist with [RFC4861 <./rfc4861>], [RFC3122 <./rfc3122>] or other future ND mechanisms
>    (although the motivation or detailed specification of such
>    coexistence is out of scope for the present document).
>  
>    The document defines two new ICMPv6 messages: Node Registration and
>    Node Confirmation.
>  
>  
>  
>  
>  
>  
>  
> Shelby, et al.           Expires August 5, 2010                 [Page 5] 
>   
>   <#page-6> 
> Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
>  
>  
> 1.1.  Goals, Assumptions, and Guesses 
>  
>    This document has the following main goals and assumptions, as well
>    as two guesses that may or may not be true in a specific LoWPAN but
>    still have shaped the optimizations.
>  
>    Goals:
>  
>    o  Optimize ND with a mechanism that is minimal yet sufficient for
>       LoWPAN operation in both mesh-under and route-over configurations.
>  
>    o  Minimize signalling by avoiding the use of multicast flooding and
>       reducing the frequency of link scope multicast messages inside the
>       LoWPANs.
>  
>    o  Disseminate context information throughout the LoWPAN used by
>       [I-D.ietf-6lowpan-hc <#ref-I-D.ietf-6lowpan-hc>].
>  
>    o  Minimize the complexity of nodes.
>  
>    o  Optimize the interfaces between nodes and their default routers.
>  
>    Assumptions:
>  
>    o  A subnet includes all the nodes sharing the same IPv6
>       prefix.
>  
>    o  A single LoWPAN is configured in a homogeneous way, i.e., IIDs are
>       formed by nodes in a uniform matter and DAD is performed by
>       routers in a uniform way.
>  
>    o  Link layer technology is e.g.  IEEE 802.15.4 as in [RFC4944 <./rfc4944>], or
>       any other link-layer exhibiting non-transitivity or a similar
>       topology.
>  
> 1.2.  Why not classic IPv6 ND? 
>  
>    IPv6 Neighbor Discovery [RFC4861 <./rfc4861>] provides several important
>    functions such as Router Discovery, Address Resolution, Duplicate
>    Address Detection, Redirect, Prefix and Parameter Discovery.
>  
>    Following power-on and initialization of the network in IPv6 Ethernet
>    networks, a node joins the solicited-node multicast address on the
>    interface and then performs duplicate address detection (DAD) for the
>    acquired link-local address by sending a solicited-node multicast
>    message to the link.  After that it sends multicast messages to the
>    all-router address to solicit router advertisements.  Once the host
>    receives a valid router advertisement with the "A" flag, it
>  
>  
>  
> Shelby, et al.           Expires August 5, 2010                 [Page 6] 
>   
>   <#page-7> 
> Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
>  
>  
>    autoconfigures the IPv6 address with the advertised prefix in the
>    router advertisement (RA).  Besides this, the IPv6 routers usually
>    send router advertisements periodically on the network.  RAs are sent
>    to the all-node multicast address.  Nodes send Neighbor Solicitation/
>    Neighbor Advertisement messages to resolve the IPv6 address of the
>    destination on the link.  These NS/NA messages are also often
>    multicast messages and it is assumed that the node is on the same
>    link and relies on the fact that the destination node is always
>    powered and generally reliable.
>  
>    A LoWPAN network typically uses two types of L2 addresses -- for
>    example 16-bit short addresses and 64-bit unique addresses as defined
>    in [RFC4944 <./rfc4944>].  Moreover, the available L2 payload size on the order
>    of less than 100 bytes where we often might need to use header
>    compression and use a minimum payload.  The network is lossy and low-
>    powered, and it does not provide multicast capability at the link-
>    layer, thus simulating multicast behavior by both using broadcast or
>    sending a number of unicast messages, both expensive for the low-
>    powered network and the low-processing capable nodes.  Often these
>    low-powered nodes conserve energy by using sleep schedules; waking
>    them up to receive IPv6 signaling messages such as multicast messages
>    for NS or periodic RAs is not practical.  Also they are not capable
>    of processing address-resolution for their neighbors effectively.
>    Due to the radio strength of its neighboring router or its own
>    strength, a node may often move from one router to another without
>    physically moving from one place to another.  Considering the above
>    characteristics in a LoWPAN, and the IPv6 Neighbor Discovery
>    [RFC4861 <./rfc4861>] base protocol requirements, it was concluded that classic
>    Neighbor Discovery is not suitable as it is and a 6LoWPAN-specific ND
>    definition would be useful and efficient for the wide deployment of
>    IPv6 over low-powered wireless networks of embedded devices.
>  
>  
> 2.  Terminology 
>  
>    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 [RFC2119 <./rfc2119>].
>  
>    This specification requires readers to be familiar with all the terms
>    and concepts that are discussed in "IPv6 Stateless Address
>    Autoconfiguration" [RFC4862 <./rfc4862>], "IPv6 over Low-Power Wireless Personal
>    Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement,
>    and Goals" [RFC4919 <./rfc4919>], "Transmission of IPv6 Packets over IEEE
>    802.15.4 Networks" [RFC4944 <./rfc4944>] and "IP Addressing Model in Ad Hoc
>    Networks" [I-D.ietf-autoconf-adhoc-addr-model <#ref-I-D.ietf-autoconf-adhoc-addr-model>].
>  
>    Readers would benefit from reading "Optimistic Duplicate Address
>  
>  
>  
> Shelby, et al.           Expires August 5, 2010                 [Page 7] 
>   
>   <#page-8> 
> Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
>  
>  
>    Detection" [RFC4429 <./rfc4429>] ("oDAD") prior to this specification.
>  
>    This specification makes extensive use of the same terminology
>    defined in [RFC4861 <./rfc4861>] unless otherwise redefined below.
>  
> 2.1.  6LoWPAN Terminology 
>  
>    This section defines additional general terms related to the 6LoWPAN
>    architecture used in this specification:
>  
>    IP Routing
>  
>       The forwarding of datagrams at the IP layer between arbitrary
>       source-destination pairs, during which the IPv6 hop limit is
>       decremented.  In the LoWPAN context, IP routing is performed by
>       routers on a single interface within the same subnet.
>       Exact match search is performed on the destination address of the
>       IP packet to find the next-hop to the destination.  Referred to as
>       routing in this document.
>  
>    Link
>  
>       The link is a communication facility or medium over which nodes
>       can communicate at the link-layer, i.e., the layer directly below
>       IP ([RFC4861 <./rfc4861>]). 6LoWPAN assumes the use of low-power and lossy
>       wireless links such as IEEE 802.15.4, which is a special type of
>       link as described in [RFC4861 <./rfc4861>] exhibiting severe asymmetric
>       reachability with both asymmetric (A can reach B, but B can't
>       reach A) and non-transitive (A can reach B, and B can reach C, but
>       A can't reach C) qualities.  The use of link-layer mesh technology
>       (see Mesh Under) emulates transitivity across the link but still
>       has problems with asymmetricity.  Multicast on a link-layer mesh,
>       if available, is often implemented as an expensive broadcast
>       flood.  Due to their nature, these are considered links with
>       undetermined connectivity properties as defined in
>       [I-D.ietf-autoconf-adhoc-addr-model <#ref-I-D.ietf-autoconf-adhoc-addr-model>].
>  
>    Link-local
>  
>       Standard IPv6 link-local scope is defined in [RFC4291 <./rfc4291>] and
>       [RFC4861 <./rfc4861>].  Link-local scope is achieved by setting the hop limit
>       to 1, using a link-local prefix (FE80::) or link-local multicast
>       scope (FFx2::).  If a link is non-transitive then link-local scope
>       may include only a subset of nodes on the link (the set of nodes
>       within symmetric radio range of a node).  Nodes in the link-local
>       scope of a node are its neighbors, and this link-local scope may
>       differ from the perspective of each node.  Therefore, link-local
>       addresses are of limited value as discussed in
>  
>  
>  
> Shelby, et al.           Expires August 5, 2010                 [Page 8] 
>   
>   <#page-9> 
> Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
>  
>  
>       [I-D.ietf-autoconf-adhoc-addr-model <#ref-I-D.ietf-autoconf-adhoc-addr-model>].
>  
>    LoWPAN Host
>  
>       A node that only sources or sinks IPv6 datagrams.  Referred to as
>       a host in this document.
>  
>    LoWPAN Node
>  
>       A node that composes a LoWPAN, referring to both hosts and
>       routers.  Simply called a node in this document.
>  
>    LoWPAN Router
>  
>       A LoWPAN node that forwards datagrams between arbitrary source-
>       destination pairs using a single 6LoWPAN interface performing IP
>       routing on that interface.  Referred to as a router in this document.
>  
>    LoWPAN Mesh node
>  
>       A LoWPAN node that forwards data between arbitrary source-
>       destination pairs using link addresses (and thus only exists in
>       Mesh Under LoWPANs).
>  
>    Mesh Under
>  
>       A term referring to a configuration where the link-local scope is
>       defined by the boundaries of the LoWPAN (or a sizable part of it,
>       if Mesh Under is combined with Route Over) and includes all the
>       6LoWPAN interfaces within it.  There are forwarding and multihop
>       routing functions at L2 to achieve transitivity on the link.  In
>       this configuration the link may still exhibit lossy, asymmetric,
>       NBMA (non-availability of mesh-wide multicast) behavior.
>  
>    Route Over
>  
>       A term referring to a configuration where the LoWPAN is made up of
>       several partially overlapping links and link-local scope reaches
>       only a subset of the nodes.  IP routing is performed by
>       routers to provide connectivity across the LoWPAN.  A
>       LoWPAN with this configuration may consist of both routers and
>       hosts.  Route Over and Mesh Under are not mutually exclusive, and
>       IP routing may be used between links that perform Mesh Under.
>  
>    Subnet
>  
>  
>  
>  
>  
>  
> Shelby, et al.           Expires August 5, 2010                 [Page 9] 
>   
>   <#page-10> 
> Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
>  
>  
>       A subnet is the collection of interfaces having the same IPv6
>       subnet prefix on a link, as defined in [RFC4291 <./rfc4291>].  A LoWPAN is
>       made up of the interfaces of nodes and Edge Routers sharing
>       the same subnet prefix.  This Route Over configuration exhibits a
>       multi-hop subnet feature with regard to hop limit as discussed in
>       [RFC4903 <./rfc4903>], and thus 6LoWPAN applications should be careful when
>       making assumptions about the hop limit as it may be decremented in
>       a LoWPAN.
>  
> 2.2.  ND Terminology 
>  
>    This section defines Neighbor Discovery specific terminology used in
>    this specification:
>  
>    Simple LoWPAN
>  
>       A Simple LoWPAN consists of a single Edge Router and the set of
>       nodes on the same LoWPAN Subnet, shown in Figure 1.
>  
>    Ad-hoc LoWPAN
>  
>       An isolated LoWPAN, not connected to any other IP networks.  Ad-
>       Hoc LoWPANs make use of Unique on-link IPv6 Unicast Addresses
>       (ULAs) [RFC4193 <./rfc4193>].
>  
>    Backbone Link
>  
>       This is an IPv6 link that interconnects two or more Edge Routers
>       in an Extended LoWPAN topology.  It is expected to be deployed as
>       a high speed backbone in order to federate a potentially large set
>       of LoWPANs.
>  
>    LoWPAN Edge Router
>  
>       An IPv6 router that interconnects the LoWPAN to another IP
>       network.  Referred to as an Edge Router in this document.
>  
>    Registration
>  
>       The process during which a LoWPAN node sends a Node Registration
>       message to a router creating a binding for the node.
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
> Shelby, et al.           Expires August 5, 2010                [Page 10] 
>   
>   <#page-11> 
> Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
>  
>  
>           Infrastructure Cloud
>                    |
>                    |
>                    |
>                 +-----+
>                 |     | Edge
>                 |     | Router
>                 +-----+
>                   o  o
>                o   o    o
>              o  o   o  o o        o: Node
>               o   o  o  o
>                 o   o o
>  
>              Simple LoWPAN
>  
>  
>                     Figure 1: A simple LoWPAN topology
>  
>  
> 3.  Protocol Overview 
>  
>    6LoWPAN Neighbor Discovery (6LoWPAN-ND) optimizes IPv6 ND with a
>    mechanism which is on its own minimal yet sufficient for LoWPAN IPv6
>    operation. 6LoWPAN-ND defines a node registration mechanism
>    optimizing the node-router interface.  This mechanism requires no
>    flooding and reduces link-local multicast frequency. 6LoWPAN-ND
>    supports non-transitive links, the use of both mesh-under and route-
>    over techniques and makes no assumptions about synchronization
>    between hosts using the same router.  This specification is REQUIRED
>    for LoWPAN operation, but MAY also coexist with [RFC4861 <./rfc4861>], [RFC3122 <./rfc3122>]
>    or other future ND mechanisms.  Any use of [RFC4944 <./rfc4944>] without this
>    specification is NOT RECOMMENDED.
>  
>    The following features are defined by 6LoWPAN-ND (see Section
>    Section 5 <#section-5> for details):
>  
>    Node Registration:  Method in which nodes in the LoWPAN register with
>       routers, creating state about nodes attached to that router
>       (binding table).
>  
>    Next-hop Determination:  The specification defines a simple next-hop
>       determination rule.
>  
>    Address Resolution:  The Node Registration mechanism provides
>       sufficient a priori state in nodes and routers to resolve an IPv6
>       address to its associated link-layer address on the node-router
>       interface.  Host-host resolution is out of scope of this
>  
>  
>  
> Shelby, et al.           Expires August 5, 2010                [Page 11] 
>   
>   <#page-12> 
> Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
>  
>  
>       specification.
>  
>    Unreachability Detection:  Unreachability between a node and router
>       is determined based on link-layer acknowledgements to node
>       registration and unicast data messages.  Host-host unreachability
>       detection is out of scope.  Destination unreachability detection
>       is performed using ICMPv6 destination unreachable messages.
>  
>    Context Dissemination:  The dissemination of LoWPAN context as used
>       by [I-D.ietf-6lowpan-hc <#ref-I-D.ietf-6lowpan-hc>] is defined as an ICMPv6 option, along
>       with an associated summary option to reduce message size when many
>       contexts are advertised.
>  
>    This specification makes use of RS/RA message exchanges similar to
>    classic ND, which in 6LoWPAN-ND may also carry additional options for
>    context dissemination (6LoWPAN Information Option, 6IO) and reducing
>    RA message size (6LoWPAN Summary Option, 6SO).  In addition
>    6LoWPAN-ND defines two new ICMP packet types:
>  
>    Node Registration (NR):  Sent by a node to a router to register a
>       binding.
>  
>    Node Confirmation (NC):  The response sent by a router back to the
>       registering node.
>  
> 3.1.  Topology 
>  
>    6LoWPAN-ND makes little assumption about synchronization between
>    nodes in a LoWPAN except between a node and the routers it has
>    registered with. 6LoWPAN-ND is designed to work also with Ad-hoc
>    topologies.  The case of Ad-hoc LoWPAN operation is described in
>    Section 8 <#section-8>.
>  
>    6LoWPAN-ND is compatible with the use of link-layer mesh or [RFC4944 <./rfc4944>]
>    mesh techniques, which alleviate the otherwise non-transitive nature
>    of wireless links.  If used throughout the LoWPAN, this so-called
>    Mesh Under topology thus makes the entire link appear to the IP layer
>    as having a link-local scope covering all the 6LoWPAN interfaces in
>    the LoWPAN.  This kind of LoWPAN is made up of hosts and Edge
>    Routers.  This link still exhibits lossy, low-rate, asymmetric
>    behavior along with sleep cycles.  The non-transitive nature of the
>    link can also be overcome using IP routing within the LoWPAN, also
>    called a Route Over topology.  Routers are used in the LoWPAN
>    to provide routing between all nodes in the LoWPAN.  Router
>    operations are specified in Section 7 <#section-7>. Link-local scope includes the
>    neighbors of each node within symmetric wireless range.  Mesh Under
>    and Route Over techniques are not mutually exclusive, and it may be
>    possible to combine IP routing and mesh link-layers within a LoWPAN.
>  
>  
>  
> Shelby, et al.           Expires August 5, 2010                [Page 12] 
>   
>   <#page-13> 
> Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
>  
>  
> 3.2.  Bootstrapping 
>  
>    1.  A node (host or router) first forms an Interface Identifier (IID)
>    from its EUI-64 or other appropriate MAC address, and goes on to form
>    a link-local unicast address as in [RFC4944 <./rfc4944>].  When a node
>    wants to join a LoWPAN, it does so by listening for Router
>    Advertisements, or by broadcasting a Router Solicitation (RS) and
>    receiving RA responses from on-link routers (see Figure 2).  If a
>    valid prefix is advertised in the RA, the host may also autoconfigure
>    a global address.  At this point the node has also chosen one or more
>    default routers based on RAs.
>  
>    2.  Next the node will attempt to perform initial Node Registration.
>    Registration is always performed with a link-local router by sending
>    a unicast Node Registration (NR) message to it.  This message
>    exchange is illustrated in Figure 3.  The NR includes the addresses
>    the node wants to register, and it is possible to request the router
>    to assign an address.
>  
>    3.  After processing the addresses and performing DAD if necessary,
>    the router replies with a Node Confirmation (NC).  This confirmation
>    includes the set of addresses now confirmed by this router.  The Host
>    is now capable of using the LoWPAN.
>  
>  
>    Node                                                     Router
>     |                                                          |
>     |       ---------- Router Solicitation -------->           |
>     |                                                          |
>     |       <-------- Router Advertisement ---------           |
>     |                                                          |
>  
>  
>    Figure 2: Basic RS/RA exchange between a node and any on-link router
>                       (or Edge Router)
>  
>  
>  
>    Node                                                      Router
>     |                                                          |
>     |       ---------- Node Registration -------->             |
>     |                                                          |
>     |       <--------- Node Confirmation ---------             |
>     |                                                          |
>  
>  
>                  Figure 3: Basic ND registration exchange
>  
>  
>  
>  
> Shelby, et al.           Expires August 5, 2010                [Page 13] 
>   
>   <#page-14> 
> Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
>  
>  
> 3.3.  Operation 
>  
>    The node may now send packets to any IPv6 address inside or outside
>    the LoWPAN.  Next-hop determination assumes destinations are off-link
>    (and thus forwarded to a default router) except for link-local scope
>    addresses which are always on-link.  The information needed for
>    resolving the link-layer address of default routers or registered
>    nodes is known a priori as a result of node registration.
>  
>    The router binding table is soft, and thus must be renewed
>    periodically as indicated by the lifetime of the binding.  This is
>    achieved by periodically sending a new NR message.  If a host moves,
>    or the network topology changes, and the current routers are no
>    longer available, the host then starts the registration process with
>    another router.  If the host is still in the same LoWPAN (same subnet
>    prefix), its IPv6 addresses remain the same.  If the host moves to a
>    different LoWPAN (thus with a different subnet prefix), the
>    bootstrapping process is initiated again.  See Section 6 <#section-6> for details
>    on node operation.
>  
>    Routers periodically send RAs to their neighbors.  The Edge
>    Router initiates the first RAs, and information from these RAs is
>    included in the RAs of each further router, causing the information
>    to be disseminated throughout the LoWPAN.  RA periods should be
>    optimized to reduce signalling.  See Section 7 <#section-7> for detailed router
>    operation.
>  
>  
> 4.  Message Formats 
>  
>    This section defines the message and option formats used in this
>    document.  The new messages are all ICMPv6 messages.  In addition,
>    new options for ICMPv6 messages are defined.
>  
>    The following new ICMPv6 message types are defined:
>  
>    o  Node Registration (NR)
>  
>    o  Node Confirmation (NC)
>  
>    In addition, the following new ICMPv6 options are defined:
>  
>    o  6LoWPAN Address Option (6AO)
>  
>    o  6LoWPAN Information Option (6IO)
>  
>    o  6LoWPAN Summary Option (6SO)
>  
>  
>  
>  
> Shelby, et al.           Expires August 5, 2010                [Page 14] 
>   
>   <#page-15> 
> Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
>  
>  
>    o  Owner Interface Identifier Option (OIIO)
>  
>    The following [RFC4861 <./rfc4861>] messages are used as specified in this
>    section:
>  
>    o  Router Solicitation (RS)
>  
>    o  Router Advertisement (RA)
>  
> 4.1.  Node Registration/Confirmation Message 
>  
>    The Node Registration (NR) and Node Confirmation (NC) messages are
>    used by a node to register with a router.  Any option that is not
>    recognized MUST be skipped silently.  The Node Registration message
>    is sent by the node to the link-local unicast IPv6 address of
>    a on-link router.
>  
>    When registering for the first time, the node still has
>    optimistic addresses therefore the source address
>    of the Node Registration must be the IPv6 unspecified address to
>    comply with oDAD.  In subsequent registrations, the IPv6 source
>    address is then the link-local IPv6 address of the sender.  A
>    registration is periodically refreshed by sending a new NR message
>    more frequently than the Binding Lifetime indicated by the node
>    during registration.
>  
>    Address Options are included in the NR message for each IPv6 address
>    to be registered, and included in the corresponding NC to indicate
>    success.
>  
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |     Type      |Status | Code  |           Checksum            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |      TID      |P|R|                Reserved                   |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |        Binding Lifetime       |            Reserved           |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                         Owner Nonce                           |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                                                               |
>    +                  Owner Interface Identifier                   +
>    |                                                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |   Registration option(s)...
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+
>  
>           Figure 4: Node Registration/Confirmation message format
>  
>  
>  
> Shelby, et al.           Expires August 5, 2010                [Page 15] 
>   
>   <#page-16> 
> Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
>  
>  
>    IP Fields:
>  
>       Source Address:  The IPv6 address of the source.  This address
>          MUST be the IPv6 unspecified address for initial registration.
>  
>       Destination Address:  The link-local unicast IPv6 address of a on-
>          link router when sent by a node.
>  
>       Hop Limit:  255
>  
>    ICMP Fields:
>  
>       Type:  TBD1 for Node Registration, TBD2 for Node Confirmation.
>  
>       Status:  4-bit unsigned integer.  Sent only in NC messages,
>          ignored in NR messages.  Values 0-7 are reserved for success
>          codes:
>  
>             0 is unqualified success.
>  
>          Values 8-15 are reserved for error codes:
>  
>             8 is send to indicate that the router is saturated and an
>             alternative router should be used.
>  
>       Code:  4-bit unsigned integer.
>  
>             0 indicates this NR is a request sent directly from the
>             originating host, or this NC is a corresponding response.
>  
>             1 indicates that the NR message has been relayed by a
>             router, or that the NC is to be relayed by the router
>             indicated as the destination.  (For future use)
>  
>             2 indicates this NC is a request <#> for the node to re-
>             register.
>  
>             4-15 are reserved for future use.
>  
>       Checksum:  The ICMP checksum.
>  
>       TID:  8-bit unsigned integer.  A unique Transaction ID assigned by
>          the host and used to match replies.  A lollipop mechanism is
>          used to increment the TID upon each new registration.  The TID
>          is not incremented upon a on-link refresh.  In a Node
>          Confirmation, the TID is that of the corresponding NR.  TID is set
>          to 0 upon booting, and is incremented with each NR message.
>          After reaching 0xFF, the value loops to 16 (0x10) and is
>  
>  
>  
> Shelby, et al.           Expires August 5, 2010                [Page 16] 
>   
>   <#page-17> 
> Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
>  
>  
>          incremented from there.  Thus the values between 0-15 MUST only
>          used after a boot or reboot.
>  
>       P: 1-bit Primary flag.  Not yet used by this specification, always
>          set to 1.
>  
>       R: 1-bit Router flag.  Used to indicate the role of node sending
>          the NR message.  Set to 0 by hosts and to 1 by routers.
>  
>       Binding Lifetime:  16-bit unsigned integer.  The amount of time in
>          10 second intervals remaining before the binding of this owner
>          interface identifier, and all associated address options and
>          configuration options, MUST be considered expired.  A value of
>          zero indicates that the Binding Cache entries for the
>          registered owner interface identifier MUST be deleted.  A value
>          of 0xFFFF indicates an idefinite lifetime.  (The 16-bit field
>          covers up to slightly more than a week of Binding Lifetime.)
>  
>       Reserved:  This field is unused.  It MUST be initialized to zero
>          by the sender and MUST be ignored by the receiver.
>  
>       Owner Interface Identifier (OII):  A globally unique identifier
>          for the requesting host's interface.  Typically the EUI-64
>          derived IID.
>  
>       Owner Nonce:  A 32-bit Nonce generated randomly by the node upon
>          booting, and generated again each time the node re-boots.  This
>          Nonce may be used to detect duplicate OIIs.
>  
>    Possible Options:
>  
>       6LoWPAN Address Option(s):  An Address Option is included for each
>          address the host wants to bind for this interface.
>  
>       6LoWPAN Information Option:  This option includes information
>          about the prefixes of the LoWPAN along with other context
>          information.  Although normally carried in RA messages, a 6IO
>          option MAY also be carried in NC messages.
>  
>       Future versions of this protocol may define new option types.
>       Receivers MUST silently ignore any options they do not recognize
>       and continue processing the message.
>  
> 4.2.  Router Solicitation Message 
>  
>    The RS message format for 6LoWPAN is identical to the classic
>    [RFC4861 <./rfc4861>] RS message.  The following clarifications are made
>    regarding the use of RS in LoWPANs.
>  
>  
>  
> Shelby, et al.           Expires August 5, 2010                [Page 17] 
>   
>   <#page-18> 
> Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
>  
>  
>    If a node has only optimistic addresses not yet confirmed by a
>    Router, then the IPv6 source address in the RS MUST be the IPv6
>    unspecified address.  The Source Link-Layer Address Option MUST NOT
>    be included in the RS at any time.  Instead the Owner Interface
>    Identifier specified in this document MUST be included in the RS.
>  
>    The Code field of the Router Solicitation message is used to
>    indicate whether a node wants to receive the full set of 6IOs in the
>    RA response, or just the 6SO.  An RS with Code = 0 is used to request
>    just the 6LoWPAN Summary Option, and Code = 1 is used to request the
>    full set of 6IOs.
>  
> 4.3.  Router Advertisement Message 
>  
>    The RA message format for 6LoWPAN is identical to the classic
>    [RFC4861 <./rfc4861>] RA message.  The use of flags is however defined in the
>    6LoWPAN context, and additional new options are identified.  RA
>    messages are sent either to link-local all-nodes multicast, or to a
>    link-local unicast address as a response to an RS.
>  
>    Updated Flag Definitions:
>  
>       Prf:  2-bit signed integer.  Default Router Preference as defined
>          in [RFC4191 <./rfc4191>].  Indicates whether to prefer this router over
>          other default routers.  Routers with no Edge Router available
>          MUST set Prf to (11) for low preference, routers with Edge Router
>          availability <#> MUST set Prf to (00) for normal preference, and
>          Edge Routers MUST set Prf to (01) for high preference.
>  
>    Options:
>  
>       6LoWPAN Information Option:  This option includes information
>          about the prefixes of the LoWPAN along with other context
>          information.
>  
>       6LoWPAN Summary Option:  This option provides a sequence number
>          associated with the current prefix options.  It allows the
>          prefix options themselves to be sent only when a change has
>          occured, or when requested with an RS Code = 1.
>  
>       Prefix Information Option:  If needed for backward compatibility,
>          an RA may also be sent using the classic [RFC4861 <./rfc4861>] Prefix
>          Information Option which all LoWPAN nodes MUST be able to
>          parse.  If possible, routers in the LoWPAN SHOULD make use of
>          6IO and 6SO options instead of PIO.
>  
>       The MTU and SLLAO options defined in [RFC4861 <./rfc4861>] are not used by
>       this specification.
>  
>  
>  
> Shelby, et al.           Expires August 5, 2010                [Page 18] 
>   
>   <#page-19> 
> Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
>  
>  
>       Future versions of this protocol may define new option types.
>       Receivers MUST silently ignore any options they do not recognize
>       and continue processing the message.
>  
> 4.4.  Message Options 
>  
>    This section defines the new 6LoWPAN-ND message options.
>  
> 4.4.1.  6LoWPAN Address Option 
>  
>    The 6LoWPAN Address Option (6AO) is used to indicate the address
>    which a node wants to register, and to indicate the success or
>    failure of that binding in an NC.  Multiple Address Options can be
>    included in a message.  In order to be as compact as possible, fields
>    are used to indicate the compression of the IPv6 address.  The 6AO
>    also allows for duplicate addresses (e.g. anycasts), the request of a
>    generated address for claim and defend use, or for an address to be
>    removed.
>  
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |     Type      |    Length     |    Status     |  S  |    P    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |D|A|R|O|      Reserved         |         IPv6 Address        ...
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  
>  
>                   Figure 5: 6LoWPAN Address Option format
>  
>    Type:  TBD3
>  
>    Length:  8-bit unsigned integer.  The length of the option (including
>       the type and length fields) in units of 8 octets.
>  
>    Status:  8-bit unsigned integer. 0 means unqualified success.  Any
>       value below 128 is a positive status that means that the binding
>       for this address was created or is being created optimistically.
>       Only used in a confirmation.
>  
>    D: 1-bit Duplicate flag.  When set, indicates that duplicates are
>       allowed for this address (to support anycast) in a request.
>  
>    A: 1-bit Address Generation flag.  Set to indicate that the host is
>       requesting a generated address for claim and defend addressing.
>       In a request when A is set the IPv6 address length is 0.  Set to
>       indicate that an address has been assigned in a confirmation.  P
>       and S are set to indicate the type of address requested and
>  
>  
>  
> Shelby, et al.           Expires August 5, 2010                [Page 19] 
>   
>   <#page-20> 
> Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
>  
>  
>       assigned when A is set.  Otherwise must be 0.
>  
>    R: 1-bit Removal flag.  When set, indicates that this particular
>       address binding MUST be removed from a whiteboard (in a request)
>       or MUST not be used any longer (in a confirmation) <#>.
>  
>    O: 1-bit Optimistic flag.  When set, indicates that this particular
>       address is optimistic and has not yet been checked for duplicates.
>  
>    P: 5-bit unsigned integer.  Identifies prefix compression or type, if
>       any.
>  
>       0-15:  Prefix compressed; upon decompression, the prefix given by
>          the compression context with the same numerical CID as the P
>          field given is inserted.
>  
>       16:  Prefix is carried inline.
>  
>       17:  Prefix compressed; upon decompression, the link-local prefix
>          (fe80::) is inserted.
>  
>       18-31:  Reserved.
>  
>    S: 3-bit unsigned integer.  Identifies suffix compression or type, if
>       any.
>  
>       0: Suffix carried inline.
>  
>       1: Suffix compressed and assumes the same value as the Owner
>          Interface Identifier field in the NR/NC message header.
>  
>       2: Suffix compressed for an IID formed from an IEEE 802.15.4 16-
>          bit short addresses.  Only the 16-bit short-address is carried
>          in-line.  The IID is formed from this address as specified in
>          [RFC4944 <./rfc4944>].
>  
>       3-7:  Reserved.
>  
>    IPv6 Address:  The IPv6 address to be registered with the router, or
>       confirmed by the router.  Parts of the address may be elided as per
>       the P and S fields.
>  
> 4.4.2.  6LoWPAN Information Option 
>  
>    This option carries prefix information for LoWPANs, and is similar in
>    use to the Prefix Information Option of [RFC4861 <./rfc4861>].  However this
>    option allows for the dissemination of multiple contexts identified
>    by a Context Identifier (CID) for use in 6LoWPAN address compression.
>  
>  
>  
> Shelby, et al.           Expires August 5, 2010                [Page 20] 
>   
>   <#page-21> 
> Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
>  
>  
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |     Type      |     Length    |  Info Length  |L|A|C|V|  CID  |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                        Valid Lifetime                         |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    .                                                               .
>    .                 Prefix or Address Information                 .
>    .                                                               .
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  
>                 Figure 6: 6LoWPAN Information Option format
>  
>    Type:  TBD4
>  
>    Length:  8-bit unsigned integer.  The length of the option (including
>       the type and length fields) in units of 8 octets.  May be 1, 2 or
>       3 depending on the length of the Information field.
>  
>    Info Length:  8-bit unsigned integer.  The number of leading bits in
>       the Information field that are valid.  The value ranges from 0 to
>       128.  The info length field provides necessary information for on-
>       link determination (when combined with the L flag in the prefix
>       information option).  It also assists with address
>       autoconfiguration as specified in [RFC4862 <./rfc4862>], for which there may
>       be more restrictions on the info length.
>  
>    L: 1-bit on-link flag, similar to the L flag in [RFC4861 <./rfc4861>].  This flag
>       MUST be unset for Route Over LoWPANs and Extended LoWPANs, and MAY
>       be set for Mesh Under Simple LoWPANs <#>.
>  
>    A: 1-bit autonomous address-configuration flag.  When set indicates
>       that this prefix can be used for stateless address configuration
>       as specified in [RFC4861 <./rfc4861>].
>  
>    C: 1-bit context flag.  This flag indicates that this information
>       option also serves as a context on the LoWPAN, which is identified
>       by the CID field.
>  
>    V: 1-bit context validity flag.  This flag indicates if the context
>       is valid, and is used only in combination with the C flag.  A
>       context that is not valid MUST not be used for compression, but
>       MAY be used in decompression in case another compressor still
>       considers the context as valid.
>  
>  
>  
>  
>  
>  
> Shelby, et al.           Expires August 5, 2010                [Page 21] 
>   
>   <#page-22> 
> Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
>  
>  
>    CID:  4-bit Context Identifier for this prefix information.  CID is
>       used by context based header compression specified in
>       [I-D.ietf-6lowpan-hc <#ref-I-D.ietf-6lowpan-hc>].  The list of CIDs for a LoWPAN is
>       configured on Edge Routers, who distribute the prefix list to all
>       nodes in the LoWPAN.
>  
>    Valid Lifetime:  32-bit unsigned integer.  The length of time in
>       seconds (relative to the time the packet is sent) that the prefix
>       is valid for the purpose of on-link determination.  A value of all
>       one bits (0xffffffff) represents infinity.
>  
>    Information:  The IPv6 prefix or context information indicated.  This
>       may be a partial prefix, a partial context or even an entire IPv6
>       address for use as a context for compression.
>  
> 4.4.3.  6LoWPAN Summary Option 
>  
>    This option identifies the set of prefix information options by a
>    sequence number.  This allows for the full set of prefix information
>    options to be sent only periodically in unsolicited RAs.  If a host
>    detects a difference in the sequence number of this option, then the
>    prefix information has likely changed, and is then requested with an
>    RS.  An RA sent in response to a unicast RS always includes the full
>    set of prefix information.
>  
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |     Type      |     Length    |       Sequence Number         |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |V|          Reserved           |           ER Metric           |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  
>                      Figure 7: 6LoWPAN Summary Option
>  
>    Type:  TBD5
>  
>    Length:  1
>  
>    Sequence Number:  16-bit signed integer.  Indicates the freshness of
>       the information advertised by the RA.
>  
>    ER Metric:  16-bit unsigned integer.  The ER Metric gives an
>       indication of the cost (in routing metric terms) of reaching nodes
>       outside the LoWPAN via an Edge Router through this router.  The metric
>       SHOULD be derived in a well-defined way from the routing protocol
>       used in the LoWPAN (possibly by structuring the 16 bits available
>       e.g. into a major and a minor metric), and has a mid-range default
>  
>  
>  
> Shelby, et al.           Expires August 5, 2010                [Page 22] 
>   
>   <#page-23> 
> Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
>  
>  
>       value of 0x8000.  Edge Routers most likely set this field to 0.  A
>       host SHOULD take this metric into account when choosing default
>       routers by making a scalar comparison, preferring routers with
>       numerically lower ER Metric values.
>  
>    V: 1-bit flag.  Indicates if the sequence number is valid and the
>       router is advertising information obtained from another router.
>  
>    Reserved:  This field is unused.  It MUST be initialized to zero by
>       the sender and MUST be ignored by the receiver.
>  
> 4.4.4.  Owner Interface Identifier Option 
>  
>    This option is used together with Router Solicitation messages when a
>    node has only optimistic addresses before initial registration.
>  
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |     Type      |     Length    |      TID      |    Reserved   |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                         Owner Nonce                           |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                                                               |
>     +                  Owner Interface Identifier                   +
>     |                                                               |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  
>                 Figure 8: Owner Interface Identifier Option
>  
>    Type:  TBD6
>  
>    Length:  2
>  
>    TID:  8-bit unsigned integer.  This field is set to the last TID
>       value used for sending an NR message.
>  
>    Reserved:  This field is unused.  It MUST be initialized to zero by
>       the sender and MUST be ignored by the receiver.
>  
>    Owner Nonce:  A 32-bit Owner Nonce generated randomly by the node
>       upon booting, and generated again each time the node re-boots.
>       This Owner Nonce is used to detect duplicate OIIs.
>  
>    Owner Interface Identifier:  A globally unique identifier for the
>       host's interface.  This is typically the EUI-64 derived IID of the
>       interface.
>  
>  
>  
>  
> Shelby, et al.           Expires August 5, 2010                [Page 23] 
>   
>   <#page-24> 
> Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
>  
>  
> 5.  Protocol Specification 
>  
>    This section specifies the functions defined by this specification,
>    along with pointers to needed procedures from other specifications.
>    These basic procedures are sufficient and required for LoWPAN
>    operation.
>  
> 5.1.  Interface initialization 
>  
>    A LoWPAN node forms a 64-bit Interface Identifier (IID) as specified
>    in Section 6 of [RFC4944] <./rfc4944#section-6>.  This may be based on the EUI-64
>    identifier, an assigned 16-bit short address, or any other
>    appropriate MAC address.  All nodes MUST configure at least one
>    address, a link-local address, by concatenating its IID with the
>    prefix FE80::/64 as specified in Section 7 of [RFC4944] <./rfc4944#section-7>.  As a
>    result, knowledge of the IID of another node is enough to
>    derive its link-local address and reach it on the same link.  If
>    derived from an EUI-64 or an equivalent the link-local address is
>    presumably unique on the LoWPAN, which enables the use of Optimistic
>    Duplicate Address Detection (oDAD) [RFC4429 <./rfc4429>].  The address SHOULD be
>    created as optimistic before it has been confirmed by Node
>    Registration (Section Section 5.2 <#section-5.2>).  This document assumes that
>    addresses are formed in a uniform manner in a LoWPAN.  Appropriate
>    steps SHOULD be taken to ensure that only correctly configured
>    devices participate in the LoWPAN, e.g. using L2 security mechanisms.
>  
>    A node MUST join the all-nodes multicast address, which is used for
>    receiving RAs from routers.  A router MUST also join the all-routers
>    multicast address.  A node MAY join other multicast addresses such as
>    the solicited-node multicast address if its link-layer includes
>    multicast support, but that is not required by this specification.
>  
>    Nodes MAY learn the address of routers using traditional means such
>    as L2 configuration or Router Advertisement messages as in [RFC4861 <./rfc4861>].
>    When sending a Router Solicitation it MUST not have the SLLAO Option,
>    but instead MUST include the OII Option.  If the sender of the RS has
>    only optimistic addresses, it MUST not use them as the IPv6 source
>    address for the RS, but instead uses the IPv6 unspecified address.
>    This procedure is to comply with the use of optimistic addresses as
>    per oDAD [RFC4429 <./rfc4429>].
>  
>    The node SHOULD also form a global unicast address for routing inside
>    the LoWPAN and reachability from outside the LoWPAN.  If a valid
>    prefix is available from an RA ('A' flag is set), then a global
>    unicast address MAY be derived following the general description in
>    Section 5.5 of [RFC4862] <./rfc4862#section-5.5>.  This address is marked optimistic until
>    confirmed by the Node Registration process.  If the LoWPAN is
>    operating in ad-hoc mode, then the prefix is a Unique on-link IPv6
>  
>  
>  
> Shelby, et al.           Expires August 5, 2010                [Page 24] 
>   
>   <#page-25> 
> Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
>  
>  
>    Address (ULA) prefix [RFC4193 <./rfc4193>] as specified in Section 8 <#section-8> (use of a
>    ULA prefix requires no changes to node operation).  A node MAY
>    alternatively acquire a global unicast address using other suitable
>    means, e.g.  DHCPv6, L2 assignment or manual configuration.
>  
> 5.2.  Node Registration 
>  
>    The node registration process is very similar to that of a MIPv6
>    mobile node, though the messages used are new Node Registration/Confirmation ICMP
>    messages.  A node address is optimistic as long as the binding is
>    not confirmed by a router.  The node sends a unicast Node
>    Registration to an on-link router to perform the binding.  While a
>    node's addresses are still optimistic (first registration in a
>    LoWPAN), the IPv6 unspecified address must be used as the source.
>    Registration SHOULD be preferred with on-link Edge Routers rather
>    than routers if available.  The Preference Flag of the RA is
>    used to differentiate between Edge Routers (Prf=01) and routers
>    (Prf=00).  Routers with Prf=11 SHOULD NOT be used for
>    registration.  Furthermore the ER Metric in the 6LoWPAN Summary
>    Option SHOULD be used to rank routers.
>  
>    A unique Owner Interface Identifier (OII) is included in the Node
>    Registration so the binding can be identified throughout the LoWPAN.
>    The OII SHOULD be formed from the EUI-64 of the interface <#> in the same
>    way as the node's link-local address IID as defined in [RFC4944 <./rfc4944>].  A
>    randomly generated 32-bit Owner Nonce is formed each time a node
>    boots or reboots.  This is included in the NR and may be used to
>    detect duplicate OIIs.  While cryptographic randomness [RFC4086 <./rfc4086>] is
>    not strictly required, the randomness SHOULD be derived using a
>    mechanism of similar quality.
>  
>    The NR message includes an Address Option for each address to be
>    registered.  Thus the message is structured as follows:
>  
>    ICMPv6 (Node Registration (Address Option[0], Address Option[1],
>    Address Option[n]))
>  
>    This registration method includes a way of requesting a unique
>    address by setting the 'A' flag in an Address Option during
>    registration.  This is useful for receiving a unique short link-layer
>    address.  How a router assigns such an address is out of scope for
>    this document.
>  
>    A unique Transaction ID (TID) is included by the host in the NR
>    message and used to match replies.  A lollipop mechanism is used.
>    TID is set to 0 upon booting, and is incremented with each Request NR
>    message.  The TID MUST NOT be incremented when sending a Refresh NR
>    message.  After reaching 0xFF, the value loops to 16 (0x10) and is
>  
>  
>  
> Shelby, et al.           Expires August 5, 2010                [Page 25] 
>   
>   <#page-26> 
> Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
>  
>  
>    incremented from there.  Thus the values between 0-15 MUST only used
>    after a boot or reboot while not yet registered.  A node that has not
>    heard a valid Node Confirmation for 16 Node Registration messages in
>    a row restarts with a on-link next TID of zero (the node MAY, but
>    need not, generate a new Owner Nonce).
>  
>    The acknowledgment to a Node Registration is a unicast Node
>    Confirmation message that contains the status of the bindings.  The
>    source of the packet is the link-local address of the on-link router.
>    The destination address is the link-local address of the node.  An
>    Address Option for each confirmed or assigned address is included.
>    Upon successful completion in the Node Confirmation message, the
>    node sets the address from optimistic to preferred.  See
>    Section 11 <#section-11> for message examples.
>  
>    Node bindings have timeouts associated with them, therefore nodes
>    must periodically send a new Node Registration message to renew the
>    binding.  The period between Request NR messages SHOULD be less than
>    BindingLifetime.  If a node no longer receives Node Confirmation
>    messages from any router in the current subnet, the registration
>    process starts over.
>  
> 5.2.1.  Processing a Node Registration Message 
>  
>    When a router receives a Node Registration message from a node, it
>    first checks for correctness of the message fields and options.  In
>    the case of an existing node, the message is used to refresh the
>    corresponding entries in the router's binding table.
>  
>    In the case of a new node, then a binding table entry is made for
>    each 6AO in the message.  The router SHOULD perform Duplicate Address
>    Detection on each optimistic address (O flag set), see Section 5.3 <#section-5.3> 
>    for further information on the DAD procedure.  If a 6AO option with
>    an A flag is received, then the router should acquire a suitable
>    address for the node.  How this is done is out of scope.  Depending
>    on the link-layer and network it may be possible to generate a random
>    address (DAD MUST be performed in this case), acquire an address from
>    a link-layer coordinator, or perform DHCPv6 in a managed network to
>    name a few.
>  
>    After processing all 6AO options, a unicast Node Confirmation message
>    is sent back to the node with an appropriate NC Status code and
>    success codes for each 6AO option in the same order as received.
>  
> 5.2.2.  Processing a Node Confirmation Message 
>  
>    When a node receives a Node Confirmation message from a router, it
>    first checks for correctness of the message fields and options.
>  
>  
>  
> Shelby, et al.           Expires August 5, 2010                [Page 26] 
>   
>   <#page-27> 
> Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
>  
>  
>    If a NC is received with a success status (0-7), then the node goes
>    on to process 6LoWPAN Address Options.  If a successful NC is
>    received with a code of 2, this indicates that the node should re-
>    register with that router.
>  
>    6LoWPAN Address Options are processed one at a time.  A success
>    status (0-127) indicates that the address was successfully bound with
>    the router.  If the address is marked optimistic, it is now updated
>    to preferred.  A failure code (128-) indicates that the binding
>    failed.  See Section 4.4.1 <#section-4.4.1> for an explanation of 6AO codes.  A
>    binding failure may indicate that a duplicate address (and thus a
>    duplicate IID) already exists.  In this case the node SHOULD attempt
>    to form a new IID and restart the registration process.  If this is
>    not possible, the node MUST not participate in the LoWPAN.
>  
>    If a NC is received with an error status (8 or greater), then the
>    registration has failed.  See Section 4.1 <#section-4.1> for an explanation of NR/NC
>    codes.  If no successful Node Confirmation is received within the
>    timeout (RegistrationTimeout) and number of retries
>    (RegistrationRetries), then registration should be performed with
>    another router in the default router list.
>  
> 5.3.  Duplicate Address Detection <#> 
>  
>    It is important for proper network operation that duplicate addresses
>    are not used in a LoWPAN as described in "IPv6 Stateless Address
>    Autoconfiguration" [RFC4862 <./rfc4862>].  Furthermore, as LoWPANs are made up of
>    links with undetermined connectivity, it is important that address
>    uniqueness is ensured thoughout the routing domain as discussed in
>    [I-D.ietf-autoconf-adhoc-addr-model <#ref-I-D.ietf-autoconf-adhoc-addr-model>].  Hosts may be very
>    simple, and thus are not expected to have the capability of
>    performing a duplicate address detection (DAD) algorithm themselves.
>    Therefore the handling of DAD is considered a function of routers.
>    This document does not perform DAD as defined in [RFC4862 <./rfc4862>],
>    but instead makes use of alternative techniques appropriate for
>    LoWPANs.  It is assumed that all routers in a LoWPAN are configured
>    to perform DAD in a uniform way.  If there is only a single router in
>    the LoWPAN, as occurs in mesh-under or star topologies, then a router
>    automatically detects duplicates by checking its own binding table
>    during registration, thus no additional mechanism is needed.
>  
>    If a router receives a Node Registration 6AO with the Optimistic Flag
>    (O) set, it SHOULD perform DAD on this address.  If the router
>    generates or assigns an address for a node in response to a 6AO with
>    the A flag set, it SHOULD perform DAD on that address.  DAD MAY be
>    disabled if the address has been generated or assigned in such a way
>    that there is high confidence of no duplicates (WARNING IN LARGE
>    PRINT).  Examples include the use of an EUI-64 to form an IID or
>  
>  
>  
> Shelby, et al.           Expires August 5, 2010                [Page 27] 
>   
>   <#page-28> 
> Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
>  
>  
>    DHCPv6 performed through a single server uniformly by all nodes in
>    the LoWPAN (as per the homogeneous LoWPAN assumption).
>  
>    A router can be configured to perform DAD using one of the following
>    techniques, the details of which are out of the scope of this
>    document:
>  
>    Extended LoWPAN <#>:  The Extended LoWPAN technique defined in (draft
>       tbd) provides DAD during its ER registration.
>  
>    Routing protocol:  If supported, a routing protocol mechanism could
>       be used to check for the existance of an address in the LoWPAN,
>       assuming that it is covered by a single routing domain.
>  
> 5.4.  Next-hop Determination 
>  
>    The IP address of the next-hop for a destination is determined as
>    follows.  Destinations to the link-local prefix (FE80::) are always
>    sent on the link to that destination.  All other prefixes are assumed
>    to be off-link as recommended in
>    [I-D.ietf-autoconf-adhoc-addr-model <#ref-I-D.ietf-autoconf-adhoc-addr-model>].  They are therefore sent to the
>    IP address of a router chosen from the Default Router List.
>  
>    Multicast addresses are considered to be on-link and are resolved as
>    specified in [RFC4944 <./rfc4944>] or relative future documents <#>.  A node
>    is not required to maintain a minimum of one buffer per neighbor as
>    specified in [RFC4861 <./rfc4861>], as address lookup is not performed as part of
>    next-hop determination.  Anycast addresses are always considered to
>    be off-link.
>  
> 5.5.  Address Resolution 
>  
>    The node registration mechanism provides sufficient a priori state in
>    nodes and routers to resolve an IPv6 address to its associated link-
>    layer address on the node-router interface.  As prefixes are always
>    assumed to be off-link, resolution between hosts is not needed.
>  
>    Information about link-layer addresses is stored by nodes about
>    routers in its default router list, and by routers about nodes in its
>    binding table.  This information is stored during the node
>    registration process.  In order to achieve LoWPAN compression, most
>    global addresses are also formed using a link-layer address.  A node
>    can minimize memory usage by making use of an educated guess and
>    storing link-layer address information only if it differs from the
>    link-layer address corresponding to the IID of the IPv6 address
>    (i.e., differs in more than the on-link/global bit being inverted).
>  
>  
>  
>  
>  
> Shelby, et al.           Expires August 5, 2010                [Page 28] 
>   
>   <#page-29> 
> Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
>  
>  
> 5.6.  Unreachability Detection 
>  
>    Unreachability between a node and router is determined based on NR/NC
>    and RS/RA exchanges and other unicast L3 data messages.  Host-host
>    unreachability detection is out of scope.
>  
>    In order to detect unreachable destinations, nodes SHOULD support
>    type 1 ICMPv6 destination unreachable messages [RFC4443 <./rfc4443>].  LoWPAN
>    Routers or Edge Routers make use of ICMPv6 destination unreachable to
>    indicate that delivery to that destination is not possible.
>  
> 5.7.  Context Dissemination 
>  
>    Network configuration parameters carried in Router Advertisements
>    originate at Edge Routers and must disseminate to all routers and
>    hosts within the LoWPAN <#>.  RAs include either 6LoWPAN Information
>    Options (one for each context) and a 6LoWPAN Summary Option, or just
>    a 6LoWPAN Summary Option.
>  
>    For the dissemination of context information using the 6IO, a strict
>    lifecycle SHOULD be used in order to ensure the context information
>    stays synchronized throughout the LoWPAN.  New context information
>    SHOULD be introduced into the LoWPAN with C=1 and V=0, to ensure it
>    is known by all nodes that may have to decompress based on this
>    context information.  Only when it is reasonable to assume that this
>    information was successfully disseminated SHOULD an option with C=1
>    and V=1 be sent, enabling the actual use of the context information
>    for compression.
>  
>    Conversely, to avoid that nodes send packets making use of previous
>    values of contexts, resulting in ambiguity when receiving a packet
>    that uses a recently changed context, old values of a context SHOULD
>    be taken out of use for a while before new values are assigned to
>    this specific context.  That is, in preparation for a change of
>    context information, its dissemination SHOULD continue for at least
>    MIN_CONTEXT_CHANGE_DELAY with C=1 and V=0.  Only when it is
>    reasonable to assume that the fact that the context is now invalid
>    was successfully disseminated, should the context ID be taken out of
>    dissemination or reused with a different Information field.  In the
>    latter case, dissemination of the new value again SHOULD start with
>    C=1 and V=0, as above.
>  
>    The 6LoWPAN Summary Option is used to support information
>    dissemination from one or more Edge Routers to all other nodes in the
>    LoWPAN.  The option includes a "V" flag which indicates that the
>    information contained in the Router Advertisement is valid.  The
>    option also includes a sequence number to ensure that all nodes
>    converge on the same settings.  The sequence number is incremented by
>  
>  
>  
> Shelby, et al.           Expires August 5, 2010                [Page 29] 
>   
>   <#page-30> 
> Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
>  
>  
>    the originating Edge Router each time the set of prefix information
>    changes.
>  
>    As the number of prefixes or addresses included for context
>    compression in an RA may be large (up to 16), it is beneficial to
>    avoid the need to always include all options in every RA.  Therefore
>    routers SHOULD only include the 6LoWPAN Summary Option in unsolicited
>    RAs, unless a set of prefix information with a new sequence number is
>    being disseminated.  In the case of a new sequence number, the router
>    SHOULD include all 6LoWPAN Information Options in the RA.  A node may
>    use an RS with Code set to 1 in order to get the whole prefix
>    information set in case it misses the RA sent when the sequence
>    number changes.  An RS with Code set to 0 is responded to with an RA
>    with the 6SO.
>  
>  
> 6.  Node Specification 
>  
>    This section specifies the conceptual data structures and variables
>    of a LoWPAN Node.
>  
> 6.1.  Conceptual structures 
>  
>    Nodes make use of the following conceptual data structures:
>  
>    Prefix List  - The list of prefixes which are advertised in Router
>       Advertisements, along with an associated invalidation timer.  Each
>       entry is associated with the sequence number last advertised in
>       the 6LoWPAN Summary Option.  Unlike in [RFC4861 <./rfc4861>], these prefixes
>       are always assumed to be off-link.
>  
>    Context List  - The list of contexts and their associated CID which
>       are advertised in Router Advertisements, along with an associated
>       invalidation timer.  Each entry is associated with the sequence
>       number last advertised in the 6LoWPAN Summary Option.  This list
>       may be realized together with the Prefix List.
>  
>    Default Router List  - As in [RFC4861 <./rfc4861>].  For networks where address
>       resolution needs to be performed, this list also contains link-
>       layer information about each router.
>  
>    These conceptual data structures may be realized in many ways.  As
>    nodes have very limited memory the number of cache entries
>    should be limited, duplicate entries between caches referenced, and
>    full IPv6 addresses represented in a compressed format where
>    possible.
>  
>  
>  
>  
>  
> Shelby, et al.           Expires August 5, 2010                [Page 30] 
>   
>   <#page-31> 
> Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
>  
>  
> 6.2.  Conceptual variables 
>  
>    The following variables are kept for each interface on a node, and
>    default values are overridden by information in Router
>    Advertisements:
>  
>    CurHopLimit         The default hop limit to be used when sending IP
>                        packets.
>  
>    CurTID              The current Transaction ID (TID) value for use in
>                        NR messages.
>  
>    BindingLifetime     The binding lifetime sent in Node Registration
>                        messages.
>  
>    RegistrationTimeout The time to wait for a Node Confirmation after
>                        sending a Node Registration.  SHOULD be at least
>                        MIN_NR_TIMEOUT.
>  
>    RegistrationRetries <#> The number of times to try to send a Node
>                        Registration, which SHOULD be less than
>                        MAX_NR_RETRIES.
>  
>  
> 7.  Router Specification 
>  
>    Routers are used in a route-over configuration where the
>    network is composed of overlapping link-local scopes.  Edge
>    Routers implement router functionality.  As a result, we
>    extend classic ND as specified in [RFC4861 <./rfc4861>] to operate over such non-
>    transitive LoWPAN links.  This section describes ND for 
>    router operations in a LoWPAN.  Note that this section does not entirely apply to
>    pure Mesh Under LoWPANs where the are no routers, although
>    they do have Edge Routers.
>  
> 7.1.  Router Configuration Variables 
>  
>    A router MUST allow the configuration of conceptual variables as
>    defined in Section 6.2.1 of [RFC4861] <./rfc4861#section-6.2.1>.  AdvReachableTime and
>    AdvRetransTimer are not used.
>  
> 7.2.  Becoming an Advertising Interface 
>  
>    An interface may become an advertising interface as specified in
>    Section 6.2.2 of [RFC4861] <./rfc4861#section-6.2.2>.
>  
>    A router's interface MAY become an advertising interface
>    before all of its router variables have been initialized.  The router
>  
>  
>  
> Shelby, et al.           Expires August 5, 2010                [Page 31] 
>   
>   <#page-32> 
> Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
>  
>  
>    MUST learn these variables (e.g.  AdvCurHopLimit, prefix and context
>    information, etc.) from neighboring routers.  While the variables are
>    not initialized, the router MAY send Router Advertisement with the
>    "Solicit" flag set to solicit Router Advertisements from neighboring
>    routers.  However, the router MUST set the Router Lifetime field to
>    zero while one or more of its variables are uninitialized.
>  
> 7.3.  Router Advertisement Message Content 
>  
>    A router sends periodic as well as solicited Router Advertisements
>    out its advertising interface.  Outgoing Router Advertisements are
>    filled with the following values consistent with the message format
>    given in this document.
>  
>       - 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.
>  
>       - In the M and O flags: the current value of AdvManagedFlag and
>       AdvOtherConfigFlag, respectively.
>  
>       - In the Preference flag: this flag is set to 00 to indicate that
>       the sender is a router <#>.
>  
>       - In the Cur Hop Limit field: the current value of CurHopLimit.
>  
>       - In the Reachable Time field: not used, set to zero.
>  
>       - In the Retrans Timer field: not used, set to zero.
>  
>       - In the options:
>  
>          - 6LoWPAN Summary Option: to indicate if the information
>          contained in the Router Advertisement is valid and, if so, the
>          freshness of the information contained in the Router
>          Advertisement message.  The option fields are set as follows:
>  
>             - In the "valid" flag: the current value of
>             AdvInformationValid.
>  
>             - In the Sequence Number field: the current value of
>             AdvInformationSequence.
>  
>             - The ER Metric field is used by a routing algorithm to
>             indicate the cost of reaching an Edge Router through this
>             router.
>  
>  
>  
>  
>  
>  
> Shelby, et al.           Expires August 5, 2010                [Page 32] 
>   
>   <#page-33> 
> Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
>  
>  
>          - 6LoWPAN Information options: one 6LoWPAN Information option
>          for each prefix listed in AdvPrefixList with the option fields
>          set from the information in the AdvPrefxList entry as follows:
>  
>             - In the "on-link" flag: the entry's AdvOnLinkFlag.
>  
>             - In the "Autonomous address configuration" flag: the
>             entry's AdvAutonomousFlag.
>  
>             - In the Valid Lifetime field: the entry's AdvValidLifetime.
>  
> 7.4.  Sending Unsolicited Router Advertisements 
>  
>    As specified in Section 6.2.4 of [RFC4861] <./rfc4861#section-6.2.4>.
>  
> 7.5.  Ceasing To Be an Advertising Interface 
>  
>    As specified in Section 6.2.5 of [RFC4861] <./rfc4861#section-6.2.5>.
>  
> 7.6.  Processing Router Solicitations 
>  
>    As specified in Section 6.2.6 of [RFC4861] <./rfc4861#section-6.2.6>.
>  
> 7.7.  Binding Table 
>  
>    Routers maintain an set of information about nodes that are currently
>    registered through it called the binding table.
>  
>    The binding table contains an entry with information such as the
>    registered node's OII, link-local IPv6 address and the binding
>    lifetime from the last NR.  If address resolution is required, the
>    table will also include corresponding link-layer address information.
>  
>  
> 8.  Ad-hoc LoWPAN 
>  
>    LoWPAN networks by nature may often work in an ad-hoc fashion,
>    without an infrastructure or connectivity to the global Internet.
>    6LoWPAN-ND may still be applied in such networks.
>  
>    A specific router in the Ad-hoc LoWPAN is nominated as Edge Router
>    and <#> configured to implement basic Edge Router functionality
>    (initiating RA dissemination) and generates a prefix based on Unique
>    on-link IPv6 Unicast Addresses (ULAs) as defined in [RFC4193 <./rfc4193>].  A
>    ULA is made up of the prefix fc00::/7, a global ID and a subnet ID.
>    The global ID is randomly generated, and the subnet ID is not used.
>    The Edge Router is responsible for the generation of the ULA prefix 
>    to be advertised to the LoWPAN and used by all nodes.  ULA generation
>    may use the algorithm suggested Section
>  
>  
>  
> Shelby, et al.           Expires August 5, 2010                [Page 33] 
>   
>   <#page-34> 
> Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
>  
>  
>    3.2.2 of [RFC4193 <./rfc4193>] or something appropriate to the Edge Router's
>    capabilities.  There SHOULD be only one Edge Router in an Ad-hoc
>    LoWPAN (just as in a Simple LoWPAN) to keep prefix consistency.
>  
>    In the case that an Edge Router on a Simple LoWPAN does not have a
>    prefix available from its IPv6 address, it SHOULD advertise a ULA
>    prefix in a similar manner.
>  
>  
> 9.  Protocol Constants 
>  
>    This section defines the protocol constants used in this document
>    based on a subset of [RFC4861 <./rfc4861>] constants. (*) indicates constants
>    modified from [RFC4861 <./rfc4861>] and (+) indicates new constants.
>  
>    Additional protocol constants are defined in Section Section 4 <#section-4>.
>  
>    Edge Router Constants:
>  
>    MIN_CONTEXT_CHANGE_DELAY+               60 seconds
>  
>    Router Constants:
>  
>    MAX_INITIAL_RTR_ADVERT_INTERVAL*        60 seconds
>  
>    MAX_INITIAL_RTR_ADVERTISEMENTS          3 transmissions
>  
>    MAX_FINAL_RTR_ADVERTISEMENTS            3 transmissions
>  
>    MIN_DELAY_BETWEEN_RAS*                  10 seconds
>  
>    MAX_RA_DELAY_TIME*                      2 seconds
>  
>    Host Constants:
>  
>    MAX_RTR_SOLICITATION_DELAY*             2 second
>  
>    RTR_SOLICITATION_INTERVAL*              10 seconds
>  
>    MAX_RTR_SOLICITATIONS                   3 transmissions
>  
>    Node Constants:
>  
>    MAX_NR_RETRIES+                         3 transmissions
>  
>  
>  
>  
>  
>  
>  
> Shelby, et al.           Expires August 5, 2010                [Page 34] 
>   
>   <#page-35> 
> Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
>  
>  
>    MIN_NR_TIMEOUT+                         5 seconds
>  
>  
> 10.  Use of 6LoWPAN-ND under RFC4861 <./rfc4861>-only stacks 
>  
>    Some IPv6 stacks (e.g. on PCs) and tools (e.g. radvd) hard-wire the
>    mechanisms of RFC4861 <./rfc4861> for all links.  This section explains the
>    adaptation needed in order to use a 6LoWPAN interface under such an
>    RFC4861 <./rfc4861>-only implementation.
>  
>    There are several ways to implement 6LoWPAN-ND in combination with an
>    IPv6 stack:
>  
>    o  6LoWPAN-ND is integrated with the IPv6 stack and its tools.  This
>       is common for LoWPAN nodes.
>  
>    o  6LoWPAN-ND is implemented as part of the interface, configuration
>       is used to turn off RFC4861 <./rfc4861> mechanisms in the IPv6 stack.  For
>       example, Proxy-ND interfaces can be used in Linux to disable most
>       built-in ND mechanisms.  This model is common for Edge Routers
>       running on a standard operating system.
>  
>    o  6LoWPAN-ND is implemented as part of the interface, and it
>       performs adaptation for RFC4861 <./rfc4861> mechanisms running on the IPv6
>       stack.  The binding table is used to answer RFC4861 <./rfc4861> messages, and
>       appropriate options added to RA messages.
>  
>    Classic RS/RA messages can be used with a LoWPAN, thus allowing e.g.
>    for an unmodified radvd (with appropriate configuration) to be run on
>    an Edge Router as long as context dissemination is not needed.  It is
>    however recommended that 6IO and 6SO options be used if possible,
>    which is easily achieved by patching existing RA tools or performing
>    adaptation.
>  
>  
> 11.  Message Examples 
>  
>    This section provides basic examples of messages and options from
>    this document.
>  
> 11.1.  NR/NC message exchange 
>  
>    When a host wants to register to a router, a simple NR/NC request
>    message exchange occurs.  In this example, a host wants to register
>    its address generated with Stateless Address Autoconfiguration (SAA) <#>,
>    and in addition requests a generated short address.
>  
>    First the Host sends an NR message to the link-local address of the
>  
>  
>  
> Shelby, et al.           Expires August 5, 2010                [Page 35] 
>   
>   <#page-36> 
> Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
>  
>  
>    router.  In this example the host includes a 600 second binding
>    lifetime and its modified EUI-64 as the Owner Interface Identifier.
>    The message has two Address Options.  The host has just booted,
>    therefore the TID starts with 0.  This example assumes that the
>    LoWPAN prefix has been assigned CID 0.
>  
>    IPv6 Source: Unspecified address
>    IPv6 Destination: Router's link-local address
>  
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |  Type = TBD   |   0   |   0   |           Checksum            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |   TID = 0     |1|0|                 Reserved                  |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |    Binding Lifetime = 60      |            Reserved           |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                         Owner Nonce                           |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                                                               |
>    +                  Owner Interface Identifier =                 +
>    |                Modified EUI-64 of the interface               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  
>  
>                         Figure 9: Basic NR request.
>  
>  
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |  Type = TBD   |   Length = 1  |  Status = 0   | S=1 |  P=0    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |0|0|0|1|      Reserved         |         Padding  = 0          |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  
>  
>            Figure 10: NR Address Option 1, for the SAA address.
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
> Shelby, et al.           Expires August 5, 2010                [Page 36] 
>   
>   <#page-37> 
> Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
>  
>  
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |  Type = TBD   |   Length = 1  |  Status = 0   | S=2 |  P=0    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |0|1|0|0|      Reserved         |         Padding = 0           |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  
>  
>         Figure 11: NR Address Option 2, for the requested address.
>  
>  
>    IPv6 Source: Router's link-local address
>    IPv6 Destination: Host's link-local address
>  
>    The base NC message is identical to the base NR message above.
>  
>  
>                    Figure 12: Corresponding NC message <#>.
>  
>  
>  
>    Address Option 1 is identical to Address Option 1 in the NR.
>  
>  
>            Figure 13: NC Address Option 1, for the SAA address. <#>
>  
>  
>    Address Option 2 now includes the generated address.
>  
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |  Type = TBD   |   Length = 1  |  Status = 0   | S=2 |  P=0    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |0|1|0|0|      Reserved         |   Generated 16-bit address    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  
>  
>         Figure 14: NC Address Option 2, for the requested address.
>  
> 11.2.  Router advertisement 
>  
>    Routers and Edge Routers in LoWPAN networks periodically send RA
>    messages.  The following example is of an RA message sent by a
>    router.  If the message is sent by an Edge Router, the only difference
>    is that the Preference flag is set to 10.
>  
>  
>  
>  
> Shelby, et al.           Expires August 5, 2010                [Page 37] 
>   
>   <#page-38> 
> Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
>  
>  
>    In the example the Preference flag is 01 (router), and a 1200s Router
>    Lifetime is advertised.  A 6LoWPAN Prefix Information Option is
>    included.
>  
>  
>      IPv6 Source: Router's link-local address
>      IPv6 Destination: All-nodes multicast address
>  
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |  Type = 134   |   Code = 0    |          Checksum             |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      | Cur Hop Limit |0|0|0|0 0|Rsrvd|    Router Lifetime = 1200     |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                       Reachable Time = 0                      |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                       Retrans Timer = 0                       |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  
>  
>                       Figure 15: RA message example.
>  
>  
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |  Type = TBD   |  Length = 2   |     PL = 64   |0|1|1|1| CID=0 |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                     Valid Lifetime = 3000                     |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    .                                                               .
>    .                    Prefix = 2001:DB8::/64                     .
>    .                                                               .
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  
>               Figure 16: 6LoWPAN Information Option example.
>  
>  
> 12.  Security Considerations 
>  
>    The security considerations of IPv6 Neighbor Discovery [RFC4861 <./rfc4861>]
>    apply.  Additional considerations can be found in [RFC3756 <./rfc3756>].
>  
>    This specification expects that the link layer is sufficiently
>    protected, either by means of physical or IP security for the
>    backbone link or MAC sublayer cryptography.  In other words, model 1
>    from [RFC3756 <./rfc3756>] applies.  In particular, it is expected that the
>  
>  
>  
> Shelby, et al.           Expires August 5, 2010                [Page 38] 
>   
>   <#page-39> 
> Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
>  
>  
>    LoWPAN MAC provides secure unicast to/from Routers and secure
>    broadcast from the Routers in a way that prevents tampering with or
>    replaying the RA messages.  However, any future 6LoWPAN security
>    protocol that applies to Neighbor Discovery for 6LoWPAN protocol, is
>    out of scope of this document.
>  
>    The use of EUI-64 for forming the Interface ID <#> in the link on-link
>    address prevents the usage of Secure ND ([RFC3971 <./rfc3971>] and [RFC3972 <./rfc3972>]) and
>    address privacy techniques.  Considering the envisioned deployments
>    and the MAC layer security applied, this is not considered an issue
>    at this time.
>  
>  
> 13.  IANA Considerations 
>  
>    This document requires two new ICMPv6 message types:
>  
>    o  Node Registration (TBD1)
>  
>    o  Node Confirmation (TBD2)
>  
>    The document also requires four new ND option types under the
>    subregistry "IPv6 Neighbor Discovery Option Formats":
>  
>    o  6LoWPAN Address Option (TBD3)
>  
>    o  6LoWPAN Information Option (TBD4)
>  
>    o  6LoWPAN Summary Option (TBD5)
>  
>    o  Owner Interface Identifier Option (TBD6)
>  
>    [TO BE REMOVED: This registration should take place at the following
>    location: http://www.iana.org/assignments/icmpv6-parameters]
>  
>  
> 14.  Acknowledgments 
>  
>    The authors thank Richard Kelsey, Geoff Mulligan, Julien Abeille,
>    Alexandru Petrescu, Peter Siklosi, Pieter De Mil, Fred Baker, Anthony
>    Schoofs, Phil Roberts and Joakim Eriksson for useful discussions and
>    comments that have helped shaped and improve this document.
>  
>  
> 15.  Changelog 
>  
>    Changes from -07 to -08:
>  
>  
>  
>  
> Shelby, et al.           Expires August 5, 2010                [Page 39] 
>   
>   <#page-40> 
> Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
>  
>  
>    Changes from -06 to -07:
>       o Updated addressing and address resolution (#60).
>  
>       o Changed the Address Option to 6LoWPAN Address Option, fixed S
>       values (#61).
>  
>       o Added support for classic RFC4861 <./rfc4861> RA Prefix Information messages
>       to be processed (#62).
>  
>       o Added a section on using 6LoWPAN-ND under a hard-wired RFC4861 <./rfc4861> 
>       stack (#63).
>  
>       o Updated the NR/NC message with a new Router flag, combined the
>       Code and Status fields into one byte, and added the capability to
>       carry 6IOs (#64).
>  
>       o Made co-existence with other ND mechanisms clear (#59).
>  
>       o Added a new Protocol Specification section with all mechanisms
>       specified there (#59).
>  
>       o Removed dependencies and conflicts with RFC4861 <./rfc4861> wherever
>       possible (#59).
>  
>       o Some editorial cleanup.
>  
>    Changes from -05 to -06:
>  
>       o Fixed the Prf codes (#52).
>  
>       o Corrected the OIIO TID field to 8-bits.  Changed the Nonce/OII
>       order in both the OIIO and the NR/NC. (#53)
>  
>  
>  
>  
>  
> Shelby, et al.           Expires August 5, 2010                [Page 40] 
>   
>   <#page-41> 
> Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
>  
>  
>       o Corrected an error in Table 1 (#54).
>  
>       o Fixed asymmetric and a misplaced transient in the 6LoWPAN
>       terminology section.
>  
>       o Added Updates RFC4861 <./rfc4861> to header
>  
>    Changes from -04 to -05:
>  
>       o Meaning of the RA's M-bit changed to original [RFC4861 <./rfc4861>] meaning
>       (#46).
>  
>       o Terms "on-link" and "off-link" used in place of "on-link" and
>       "off-link".
>  
>       o Next-hop determination text simplified (#49).
>  
>       o Neighbor cache and destination cache removed.
>  
>       o IID to link-layer address requirement relaxed.
>  
>       o NR/NC changes to enable on-link refresh with routers (#48).
>  
>       o Modified 6LoWPAN Information Option (#47).
>  
>       o Added a Protocol Constants section (#24)
>  
>       o Added the NR processing table (#51)
>  
>       o Considered the use of SeND on backbone NS/NA messages (#50)
>  
>    Changes from -03 to -04:
>  
>       o Moved Ad-hoc LoWPAN operation to Section 7 <#section-7> and made ULA prefix
>       generation a features useful also in Simple and Extended LoWPANs.
>       (#41)
>  
>       o Added a 32-bit Owner Nonce to the NR/NC messages and the
>       Whiteboard, removed the TID history. (#39)
>  
>       o Improved the duplicate OII detection algorithm using the Owner
>       Nonce. (#39)
>  
>       o Clarified the use of Source and Target link-layer options in
>       NR/NC. (#43)
>  
>       o Included text on the use of alternative methods to acquire
>       addresses. (#38)
>  
>  
>  
> Shelby, et al.           Expires August 5, 2010                [Page 41] 
>   
>   <#page-42> 
> Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
>  
>  
>       o Removed S=2 from Address Option (not needed). (#36)
>  
>       o Added a section on router dissemination consistency. (#44)
>  
>       o Small improvements and extensive editing. (#42, #37, #35)
>  
>    Changes from -02 to -03:
>  
>       o Updated terminology, with RFC4861 <./rfc4861> non-transitive link model.
>  
>       o 6LoWPAN and ND terminology separated.
>  
>       o Protocol overview explains RFC4861 <./rfc4861> diff in detail.
>  
>       o RR/RC is now Node Registration/Confirmation (NR/NC).
>  
>       o Added NR failure codes.
>  
>       o ER Metric now included in 6LoWPAN Summary Option for use in
>       default router determination by hosts.
>  
>       o Examples of host data structures, and the Whiteboard given.
>  
>       o Whiteboard is supported by all Edge Routers for option
>       simplicity.
>  
>       o Edge Router Specification chapter re-structured, clarifying
>       optional Extended LoWPAN operation.
>  
>       o NS/NA now completely optional for nodes.  No address resolution
>       or NS/NA NUD required.
>  
>       o link-local operation now compatible with oDAD (was broken).
>  
>       o Exception to hop limit = 255 for NR/NC messages.
>  
>       o Security considerations improved.
>  
>       o ICMPv6 destination unreachable supported.
>  
>    Changes from -01 to -02:
>  
>       o Fixed 16 != 0xff bug (ticket closed).
>  
>       o Specified use of ULAs in ad-hoc LoWPAN section 9 <#section-9> (ticket
>       closed).
>  
>  
>  
>  
>  
> Shelby, et al.           Expires August 5, 2010                [Page 42] 
>   
>   <#page-43> 
> Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
>  
>  
>       o Terminology cleanup based on Alex's comments.
>  
>       o General editing improvements.
>  
>    Changes from -00 to -01:
>  
>       o Specified the duplicate owner interface identifier procedures.
>       A TID lollipop algorithm was sufficient (nonce unnecessary).
>  
>       o Defined fault tolerance using secondary bindings.
>  
>       o Defined ad-hoc network operation.
>  
>       o Removed the E flag from RA and the X flag from RR/RC.
>  
>       o Completed message examples.
>  
>       o Lots of improvements in text quality and consistency were made.
>  
>  
> 16.  References 
>  
> 16.1.  Normative References 
>  
>    [I-D.ietf-autoconf-adhoc-addr-model]
>               Baccelli, E. and M. Townsley, "IP Addressing Model in Ad
>               Hoc Networks", draft-ietf-autoconf-adhoc-addr-model-02 <./draft-ietf-autoconf-adhoc-addr-model-02> 
>               (work in progress), January 2010.
>  
>    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>               Requirement Levels", BCP 14 <./bcp14>, RFC 2119 <./rfc2119>, March 1997.
>  
>    [RFC2491]  Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6
>               over Non-Broadcast Multiple Access (NBMA) networks",
>               RFC 2491 <./rfc2491>, January 1999.
>  
>    [RFC4191]  Draves, R. and D. Thaler, "Default Router Preferences and
>               More-Specific Routes", RFC 4191 <./rfc4191>, November 2005.
>  
>    [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
>               Addresses", RFC 4193 <./rfc4193>, October 2005.
>  
>    [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
>               Architecture", RFC 4291 <./rfc4291>, February 2006.
>  
>    [RFC4429]  Moore, N., "Optimistic Duplicate Address Detection (DAD)
>               for IPv6", RFC 4429 <./rfc4429>, April 2006.
>  
>  
>  
>  
> Shelby, et al.           Expires August 5, 2010                [Page 43] 
>   
>   <#page-44> 
> Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
>  
>  
>    [RFC4443]  Conta, A., Deering, S., and M. Gupta, "Internet Control
>               Message Protocol (ICMPv6) for the Internet Protocol
>               Version 6 (IPv6) Specification", RFC 4443 <./rfc4443>, March 2006.
>  
>    [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
>               "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861 <./rfc4861>,
>               September 2007.
>  
>    [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
>               Address Autoconfiguration", RFC 4862 <./rfc4862>, September 2007.
>  
>    [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
>               "Transmission of IPv6 Packets over IEEE 802.15.4
>               Networks", RFC 4944 <./rfc4944>, September 2007.
>  
> 16.2.  Informative References 
>  
>    [I-D.ietf-6lowpan-hc]
>               Hui, J. and P. Thubert, "Compression Format for IPv6
>               Datagrams in 6LoWPAN Networks", draft-ietf-6lowpan-hc-06 <./draft-ietf-6lowpan-hc-06> 
>               (work in progress), October 2009.
>  
>    [RFC2022]  Armitage, G., "Support for Multicast over UNI 3.0/3.1
>               based ATM Networks", RFC 2022 <./rfc2022>, November 1996.
>  
>    [RFC3122]  Conta, A., "Extensions to IPv6 Neighbor Discovery for
>               Inverse Discovery Specification", RFC 3122 <./rfc3122>, June 2001.
>  
>    [RFC3756]  Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
>               Discovery (ND) Trust Models and Threats", RFC 3756 <./rfc3756>,
>               May 2004.
>  
>    [RFC3971]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
>               Neighbor Discovery (SEND)", RFC 3971 <./rfc3971>, March 2005.
>  
>    [RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
>               RFC 3972 <./rfc3972>, March 2005.
>  
>    [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
>               Requirements for Security", BCP 106 <./bcp106>, RFC 4086 <./rfc4086>, June 2005.
>  
>    [RFC4903]  Thaler, D., "Multi-Link Subnet Issues", RFC 4903 <./rfc4903>,
>               June 2007.
>  
>    [RFC4919]  Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
>               over Low-Power Wireless Personal Area Networks (6LoWPANs):
>               Overview, Assumptions, Problem Statement, and Goals",
>               RFC 4919 <./rfc4919>, August 2007.
>  
>  
>  
> Shelby, et al.           Expires August 5, 2010                [Page 44] 
>   
>   <#page-45> 
> Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
>  
>  
> Authors' Addresses
>  
>    Zach Shelby (editor)
>    Sensinode
>    Hallituskatu 13-17D
>    Oulu  90100
>    FINLAND
>  
>    Phone: +358407796297
>    Email: [email-masked]
>  
>  
>    Pascal Thubert
>    Cisco Systems
>    Village d'Entreprises Green Side
>    400, Avenue de Roumanille
>    Batiment T3
>    Biot - Sophia Antipolis  06410
>    FRANCE
>  
>    Phone: +33 4 97 23 26 34
>    Email: [email-masked]
>  
>  
>    Jonathan W. Hui
>    Arch Rock Corporation
>    501 2nd St. Ste. 410
>    San Francisco, California  94107
>    USA
>  
>    Phone: +415 692 0828
>    Email: [email-masked]
>  
>  
>    Samita Chakrabarti
>    IP Infusion
>    1188 Arquest Street
>    Sunnyvale, California
>    USA
>  
>    Phone:
>    Email: [email-masked]
>  
>  
>  
>  
>  
>  
>  
>  
>  
> Shelby, et al.           Expires August 5, 2010                [Page 45] 
>   
>   <#page-46> 
> Internet-Draft         6LoWPAN Neighbor Discovery          February 2010 
>  
>  
>    Carsten Bormann
>    Universitaet Bremen TZI
>    Postfach 330440
>    Bremen  D-28359
>    Germany
>  
>    Phone: +49-421-218-63921
>    Fax:   +49-421-218-7000
>    Email: [email-masked]
>  
>  
>    Erik Nordmark
>    Sun Microsystems
>    17 Network Circle
>    Menlo Park, California  94025
>    USA
>  
>    Phone:
>    Email: [email-masked]
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
> Shelby, et al.           Expires August 5, 2010                [Page 46]
>   
>  
>  
>   
>
> Html markup produced by rfcmarkup 1.86, available from 
> http://tools.ietf.org/tools/rfcmarkup/ 
[Docs] [txt] [pdf] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-hui-6lowpan-nd) 00 01 02 03
04 05 06 07 08

6lowpan Working Group Z. Shelby, Ed.
Internet-Draft Sensinode
Updates: 4944 (if approved) P. Thubert
Intended status: Standards Track Cisco
Expires: August 5, 2010 J. Hui
Arch Rock
S. Chakrabarti
IP Infusion
C. Bormann
Universitaet Bremen TZI
E. Nordmark
Sun
February 1, 2010

6LoWPAN Neighbor Discovery
draft-ietf-6lowpan-nd-08

Abstract

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

Shelby, et al. Expires August 5, 2010 [Page 1]

Internet-Draft 6LoWPAN Neighbor Discovery February 2010

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on August 5, 2010.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.

Shelby, et al. Expires August 5, 2010 [Page 2]

Internet-Draft 6LoWPAN Neighbor Discovery February 2010

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Goals, Assumptions, and Guesses . . . . . . . . . . . . . 5
1.2. Why not classic IPv6 ND? . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. 6LoWPAN Terminology . . . . . . . . . . . . . . . . . . . 7
2.2. ND Terminology . . . . . . . . . . . . . . . . . . . . . . 9
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Topology . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 12
3.3. Operation . . . . . . . . . . . . . . . . . . . . . . . . 13
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Node Registration/Confirmation Message . . . . . . . . . . 14
4.2. Router Solicitation Message . . . . . . . . . . . . . . . 16
4.3. Router Advertisement Message . . . . . . . . . . . . . . . 17
4.4. Message Options . . . . . . . . . . . . . . . . . . . . . 18
4.4.1. 6LoWPAN Address Option . . . . . . . . . . . . . . . . 18
4.4.2. 6LoWPAN Information Option . . . . . . . . . . . . . . 19
4.4.3. 6LoWPAN Summary Option . . . . . . . . . . . . . . . . 21
4.4.4. Owner Interface Identifier Option . . . . . . . . . . 22
5. Protocol Specification . . . . . . . . . . . . . . . . . . . . 23
5.1. Interface initialization . . . . . . . . . . . . . . . . . 23
5.2. Node Registration . . . . . . . . . . . . . . . . . . . . 24
5.2.1. Processing a Node Registration Message . . . . . . . . 25
5.2.2. Processing a Node Confirmation Message . . . . . . . . 25
5.3. Duplicate Address Detection . . . . . . . . . . . . . . . 26
5.4. Next-hop Determination . . . . . . . . . . . . . . . . . . 27
5.5. Address Resolution . . . . . . . . . . . . . . . . . . . . 27
5.6. Unreachability Detection . . . . . . . . . . . . . . . . . 28
5.7. Context Dissemination . . . . . . . . . . . . . . . . . . 28
6. Node Specification . . . . . . . . . . . . . . . . . . 29
6.1. Conceptual structures . . . . . . . . . . . . . . . . . . 29
6.2. Conceptual variables . . . . . . . . . . . . . . . . . . . 30
7. Router Specification . . . . . . . . . . . . . . . . . 30
7.1. Router Configuration Variables . . . . . . . . . . . . . . 30
7.2. Becoming an Advertising Interface . . . . . . . . . . . . 30
7.3. Router Advertisement Message Content . . . . . . . . . . . 31
7.4. Sending Unsolicited Router Advertisements . . . . . . . . 32
7.5. Ceasing To Be an Advertising Interface . . . . . . . . . . 32
7.6. Processing Router Solicitations . . . . . . . . . . . . . 32
7.7. Binding Table . . . . . . . . . . . . . . . . . . . . . . 32
8. Ad-hoc LoWPAN . . . . . . . . . . . . . . . . . . . . . . . . 32
9. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 33
10. Use of 6LoWPAN-ND under RFC4861-only stacks . . . . . . . . . 34
11. Message Examples . . . . . . . . . . . . . . . . . . . . . . . 34
11.1. NR/NC message exchange . . . . . . . . . . . . . . . . . . 34
11.2. Router advertisement . . . . . . . . . . . . . . . . . . . 36

Shelby, et al. Expires August 5, 2010 [Page 3]

Internet-Draft 6LoWPAN Neighbor Discovery February 2010

12. Security Considerations . . . . . . . . . . . . . . . . . . . 37
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38
15. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 38
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
16.1. Normative References . . . . . . . . . . . . . . . . . . . 42
16.2. Informative References . . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44

Shelby, et al. Expires August 5, 2010 [Page 4]

Internet-Draft 6LoWPAN Neighbor Discovery February 2010

1. Introduction

The IPv6 over IEEE 802.15.4 [RFC4944] document has specified how to
carry IPv6 packets over IEEE 802.15.4 and similar networks (6LoWPANs
or LoWPANs for short) with the help of an adaptation header which
comes before the IP header. A link in such a 6LoWPAN is
characterized as lossy, low-power, low bit-rate, short range, with
many nodes saving energy with long deep sleep periods. Multicast as
used in classic IPv6 Neighbor Discovery [RFC4861] is not desirable in
such a wireless low-power, lossy network.

Moreover, LoWPAN links are asymmetric and non-transient in nature;
they are not always considered to be in a fixed network nor are they
bounded by our traditional definition of a wired-link. A LoWPAN is
potentially composed of a large amount of overlapping radio ranges,
eventually federated by a backbone or a backhaul link. Although a
given radio range has broadcast capabilities, the aggregation of
these is a complex Non-Broadcast MultiAccess (NBMA, [RFC2491])
structure with (generally) no LoWPAN-wide multicast capabilities.
link-local scope is in reality defined by reachability and radio
strength. Thus we can consider a LoWPAN to be made up of links with
undetermined connectivity properties as defined in
[I-D.ietf-autoconf-adhoc-addr-model], along with the corresponding
assumptions defined therein. The classic IPv6 Neighbor Discovery
[RFC4861] control messages, the use of multicast and their default
frequency also attribute to unnecessary waste of energy in LoWPANs.

This specification introduces a new mechanism called Node
Registration, used to optimize the interface between hosts and
routers in a LoWPAN. That registration mechanism provides a service
somewhat similar to the Multicast Address Resolution Server (MARS)
[RFC2022] for a limited purpose, and in a much simpler and less
generic fashion. The use of Router Advertisements to disseminate
prefix and header compression context throughout the LoWPAN is also
specified. The solution supports the use of both link-layer- or
LoWPAN-level mesh (Mesh Under) and IP routing (Route Over) solutions
for multihop forwarding. This specification is both sufficient and
required for LoWPAN operation. The 6LoWPAN-ND mechanism could also
coexist with [RFC4861], [RFC3122] or other future ND mechanisms
(although the motivation or detailed specification of such
coexistence is out of scope for the present document).

The document defines two new ICMPv6 messages: Node Registration and
Node Confirmation.

Shelby, et al. Expires August 5, 2010 [Page 5]

Internet-Draft 6LoWPAN Neighbor Discovery February 2010

1.1. Goals, Assumptions, and Guesses

This document has the following main goals and assumptions, as well
as two guesses that may or may not be true in a specific LoWPAN but
still have shaped the optimizations.

Goals:

o Optimize ND with a mechanism that is minimal yet sufficient for
LoWPAN operation in both mesh-under and route-over configurations.

o Minimize signalling by avoiding the use of multicast flooding and
reducing the frequency of link scope multicast messages inside the
LoWPANs.

o Disseminate context information throughout the LoWPAN used by
[I-D.ietf-6lowpan-hc].

o Minimize the complexity of nodes.

o Optimize the interfaces between nodes and their default routers.

Assumptions:

o A subnet includes all the nodes sharing the same IPv6
prefix.

o A single LoWPAN is configured in a homogeneous way, i.e., IIDs are
formed by nodes in a uniform matter and DAD is performed by
routers in a uniform way.

o Link layer technology is e.g. IEEE 802.15.4 as in [RFC4944], or
any other link-layer exhibiting non-transitivity or a similar
topology.

1.2. Why not classic IPv6 ND?

IPv6 Neighbor Discovery [RFC4861] provides several important
functions such as Router Discovery, Address Resolution, Duplicate
Address Detection, Redirect, Prefix and Parameter Discovery.

Following power-on and initialization of the network in IPv6 Ethernet
networks, a node joins the solicited-node multicast address on the
interface and then performs duplicate address detection (DAD) for the
acquired link-local address by sending a solicited-node multicast
message to the link. After that it sends multicast messages to the
all-router address to solicit router advertisements. Once the host
receives a valid router advertisement with the "A" flag, it

Shelby, et al. Expires August 5, 2010 [Page 6]

Internet-Draft 6LoWPAN Neighbor Discovery February 2010

autoconfigures the IPv6 address with the advertised prefix in the
router advertisement (RA). Besides this, the IPv6 routers usually
send router advertisements periodically on the network. RAs are sent
to the all-node multicast address. Nodes send Neighbor Solicitation/
Neighbor Advertisement messages to resolve the IPv6 address of the
destination on the link. These NS/NA messages are also often
multicast messages and it is assumed that the node is on the same
link and relies on the fact that the destination node is always
powered and generally reliable.

A LoWPAN network typically uses two types of L2 addresses -- for
example 16-bit short addresses and 64-bit unique addresses as defined
in [RFC4944]. Moreover, the available L2 payload size on the order
of less than 100 bytes where we often might need to use header
compression and use a minimum payload. The network is lossy and low-
powered, and it does not provide multicast capability at the link-
layer, thus simulating multicast behavior by both using broadcast or
sending a number of unicast messages, both expensive for the low-
powered network and the low-processing capable nodes. Often these
low-powered nodes conserve energy by using sleep schedules; waking
them up to receive IPv6 signaling messages such as multicast messages
for NS or periodic RAs is not practical. Also they are not capable
of processing address-resolution for their neighbors effectively.
Due to the radio strength of its neighboring router or its own
strength, a node may often move from one router to another without
physically moving from one place to another. Considering the above
characteristics in a LoWPAN, and the IPv6 Neighbor Discovery
[RFC4861] base protocol requirements, it was concluded that classic
Neighbor Discovery is not suitable as it is and a 6LoWPAN-specific ND
definition would be useful and efficient for the wide deployment of
IPv6 over low-powered wireless networks of embedded devices.

2. Terminology

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 [RFC2119].

This specification requires readers to be familiar with all the terms
and concepts that are discussed in "IPv6 Stateless Address
Autoconfiguration" [RFC4862], "IPv6 over Low-Power Wireless Personal
Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement,
and Goals" [RFC4919], "Transmission of IPv6 Packets over IEEE
802.15.4 Networks" [RFC4944] and "IP Addressing Model in Ad Hoc
Networks" [I-D.ietf-autoconf-adhoc-addr-model].

Readers would benefit from reading "Optimistic Duplicate Address

Shelby, et al. Expires August 5, 2010 [Page 7]

Internet-Draft 6LoWPAN Neighbor Discovery February 2010

Detection" [RFC4429] ("oDAD") prior to this specification.

This specification makes extensive use of the same terminology
defined in [RFC4861] unless otherwise redefined below.

2.1. 6LoWPAN Terminology

This section defines additional general terms related to the 6LoWPAN
architecture used in this specification:

IP Routing

The forwarding of datagrams at the IP layer between arbitrary
source-destination pairs, during which the IPv6 hop limit is
decremented. In the LoWPAN context, IP routing is performed by
routers on a single interface within the same subnet.
Exact match search is performed on the destination address of the
IP packet to find the next-hop to the destination. Referred to as
routing in this document.

Link

The link is a communication facility or medium over which nodes
can communicate at the link-layer, i.e., the layer directly below
IP ([RFC4861]). 6LoWPAN assumes the use of low-power and lossy
wireless links such as IEEE 802.15.4, which is a special type of
link as described in [RFC4861] exhibiting severe asymmetric
reachability with both asymmetric (A can reach B, but B can't
reach A) and non-transitive (A can reach B, and B can reach C, but
A can't reach C) qualities. The use of link-layer mesh technology
(see Mesh Under) emulates transitivity across the link but still
has problems with asymmetricity. Multicast on a link-layer mesh,
if available, is often implemented as an expensive broadcast
flood. Due to their nature, these are considered links with
undetermined connectivity properties as defined in
[I-D.ietf-autoconf-adhoc-addr-model].

Link-local

Standard IPv6 link-local scope is defined in [RFC4291] and
[RFC4861]. Link-local scope is achieved by setting the hop limit
to 1, using a link-local prefix (FE80::) or link-local multicast
scope (FFx2::). If a link is non-transitive then link-local scope
may include only a subset of nodes on the link (the set of nodes
within symmetric radio range of a node). Nodes in the link-local
scope of a node are its neighbors, and this link-local scope may
differ from the perspective of each node. Therefore, link-local
addresses are of limited value as discussed in

Shelby, et al. Expires August 5, 2010 [Page 8]

Internet-Draft 6LoWPAN Neighbor Discovery February 2010

[I-D.ietf-autoconf-adhoc-addr-model].

LoWPAN Host

A node that only sources or sinks IPv6 datagrams. Referred to as
a host in this document.

LoWPAN Node

A node that composes a LoWPAN, referring to both hosts and
routers. Simply called a node in this document.

LoWPAN Router

A LoWPAN node that forwards datagrams between arbitrary source-
destination pairs using a single 6LoWPAN interface performing IP
routing on that interface. Referred to as a router in this document.

LoWPAN Mesh node

A LoWPAN node that forwards data between arbitrary source-
destination pairs using link addresses (and thus only exists in
Mesh Under LoWPANs).

Mesh Under

A term referring to a configuration where the link-local scope is
defined by the boundaries of the LoWPAN (or a sizable part of it,
if Mesh Under is combined with Route Over) and includes all the
6LoWPAN interfaces within it. There are forwarding and multihop
routing functions at L2 to achieve transitivity on the link. In
this configuration the link may still exhibit lossy, asymmetric,
NBMA (non-availability of mesh-wide multicast) behavior.

Route Over

A term referring to a configuration where the LoWPAN is made up of
several partially overlapping links and link-local scope reaches
only a subset of the nodes. IP routing is performed by
routers to provide connectivity across the LoWPAN. A
LoWPAN with this configuration may consist of both routers and
hosts. Route Over and Mesh Under are not mutually exclusive, and
IP routing may be used between links that perform Mesh Under.

Subnet

Shelby, et al. Expires August 5, 2010 [Page 9]

Internet-Draft 6LoWPAN Neighbor Discovery February 2010

A subnet is the collection of interfaces having the same IPv6
subnet prefix on a link, as defined in [RFC4291]. A LoWPAN is
made up of the interfaces of nodes and Edge Routers sharing
the same subnet prefix. This Route Over configuration exhibits a
multi-hop subnet feature with regard to hop limit as discussed in
[RFC4903], and thus 6LoWPAN applications should be careful when
making assumptions about the hop limit as it may be decremented in
a LoWPAN.

2.2. ND Terminology

This section defines Neighbor Discovery specific terminology used in
this specification:

Simple LoWPAN

A Simple LoWPAN consists of a single Edge Router and the set of
nodes on the same LoWPAN Subnet, shown in Figure 1.

Ad-hoc LoWPAN

An isolated LoWPAN, not connected to any other IP networks. Ad-
Hoc LoWPANs make use of Unique on-link IPv6 Unicast Addresses
(ULAs) [RFC4193].

Backbone Link

This is an IPv6 link that interconnects two or more Edge Routers
in an Extended LoWPAN topology. It is expected to be deployed as
a high speed backbone in order to federate a potentially large set
of LoWPANs.

LoWPAN Edge Router

An IPv6 router that interconnects the LoWPAN to another IP
network. Referred to as an Edge Router in this document.

Registration

The process during which a LoWPAN node sends a Node Registration
message to a router creating a binding for the node.

Shelby, et al. Expires August 5, 2010 [Page 10]

Internet-Draft 6LoWPAN Neighbor Discovery February 2010

Infrastructure Cloud
|
|
|
+-----+
| | Edge
| | Router
+-----+
o o
o o o
o o o o o o: Node
o o o o
o o o

Simple LoWPAN

Figure 1: A simple LoWPAN topology

3. Protocol Overview

6LoWPAN Neighbor Discovery (6LoWPAN-ND) optimizes IPv6 ND with a
mechanism which is on its own minimal yet sufficient for LoWPAN IPv6
operation. 6LoWPAN-ND defines a node registration mechanism
optimizing the node-router interface. This mechanism requires no
flooding and reduces link-local multicast frequency. 6LoWPAN-ND
supports non-transitive links, the use of both mesh-under and route-
over techniques and makes no assumptions about synchronization
between hosts using the same router. This specification is REQUIRED
for LoWPAN operation, but MAY also coexist with [RFC4861], [RFC3122]
or other future ND mechanisms. Any use of [RFC4944] without this
specification is NOT RECOMMENDED.

The following features are defined by 6LoWPAN-ND (see Section
Section 5 for details):

Node Registration: Method in which nodes in the LoWPAN register with
routers, creating state about nodes attached to that router
(binding table).

Next-hop Determination: The specification defines a simple next-hop
determination rule.

Address Resolution: The Node Registration mechanism provides
sufficient a priori state in nodes and routers to resolve an IPv6
address to its associated link-layer address on the node-router
interface. Host-host resolution is out of scope of this

Shelby, et al. Expires August 5, 2010 [Page 11]

Internet-Draft 6LoWPAN Neighbor Discovery February 2010

specification.

Unreachability Detection: Unreachability between a node and router
is determined based on link-layer acknowledgements to node
registration and unicast data messages. Host-host unreachability
detection is out of scope. Destination unreachability detection
is performed using ICMPv6 destination unreachable messages.

Context Dissemination: The dissemination of LoWPAN context as used
by [I-D.ietf-6lowpan-hc] is defined as an ICMPv6 option, along
with an associated summary option to reduce message size when many
contexts are advertised.

This specification makes use of RS/RA message exchanges similar to
classic ND, which in 6LoWPAN-ND may also carry additional options for
context dissemination (6LoWPAN Information Option, 6IO) and reducing
RA message size (6LoWPAN Summary Option, 6SO). In addition
6LoWPAN-ND defines two new ICMP packet types:

Node Registration (NR): Sent by a node to a router to register a
binding.

Node Confirmation (NC): The response sent by a router back to the
registering node.

3.1. Topology

6LoWPAN-ND makes little assumption about synchronization between
nodes in a LoWPAN except between a node and the routers it has
registered with. 6LoWPAN-ND is designed to work also with Ad-hoc
topologies. The case of Ad-hoc LoWPAN operation is described in
Section 8.

6LoWPAN-ND is compatible with the use of link-layer mesh or [RFC4944]
mesh techniques, which alleviate the otherwise non-transitive nature
of wireless links. If used throughout the LoWPAN, this so-called
Mesh Under topology thus makes the entire link appear to the IP layer
as having a link-local scope covering all the 6LoWPAN interfaces in
the LoWPAN. This kind of LoWPAN is made up of hosts and Edge
Routers. This link still exhibits lossy, low-rate, asymmetric
behavior along with sleep cycles. The non-transitive nature of the
link can also be overcome using IP routing within the LoWPAN, also
called a Route Over topology. Routers are used in the LoWPAN
to provide routing between all nodes in the LoWPAN. Router
operations are specified in Section 7. Link-local scope includes the
neighbors of each node within symmetric wireless range. Mesh Under
and Route Over techniques are not mutually exclusive, and it may be
possible to combine IP routing and mesh link-layers within a LoWPAN.

Shelby, et al. Expires August 5, 2010 [Page 12]

Internet-Draft 6LoWPAN Neighbor Discovery February 2010

3.2. Bootstrapping

1. A node (host or router) first forms an Interface Identifier (IID)
from its EUI-64 or other appropriate MAC address, and goes on to form
a link-local unicast address as in [RFC4944]. When a node
wants to join a LoWPAN, it does so by listening for Router
Advertisements, or by broadcasting a Router Solicitation (RS) and
receiving RA responses from on-link routers (see Figure 2). If a
valid prefix is advertised in the RA, the host may also autoconfigure
a global address. At this point the node has also chosen one or more
default routers based on RAs.

2. Next the node will attempt to perform initial Node Registration.
Registration is always performed with a link-local router by sending
a unicast Node Registration (NR) message to it. This message
exchange is illustrated in Figure 3. The NR includes the addresses
the node wants to register, and it is possible to request the router
to assign an address.

3. After processing the addresses and performing DAD if necessary,
the router replies with a Node Confirmation (NC). This confirmation
includes the set of addresses now confirmed by this router. The Host
is now capable of using the LoWPAN.

Node Router
| |
| ---------- Router Solicitation --------> |
| |
| <-------- Router Advertisement --------- |
| |

Figure 2: Basic RS/RA exchange between a node and any on-link router
(or Edge Router)

Node Router
| |
| ---------- Node Registration --------> |
| |
| <--------- Node Confirmation --------- |
| |

Figure 3: Basic ND registration exchange

Shelby, et al. Expires August 5, 2010 [Page 13]

Internet-Draft 6LoWPAN Neighbor Discovery February 2010

3.3. Operation

The node may now send packets to any IPv6 address inside or outside
the LoWPAN. Next-hop determination assumes destinations are off-link
(and thus forwarded to a default router) except for link-local scope
addresses which are always on-link. The information needed for
resolving the link-layer address of default routers or registered
nodes is known a priori as a result of node registration.

The router binding table is soft, and thus must be renewed
periodically as indicated by the lifetime of the binding. This is
achieved by periodically sending a new NR message. If a host moves,
or the network topology changes, and the current routers are no
longer available, the host then starts the registration process with
another router. If the host is still in the same LoWPAN (same subnet
prefix), its IPv6 addresses remain the same. If the host moves to a
different LoWPAN (thus with a different subnet prefix), the
bootstrapping process is initiated again. See Section 6 for details
on node operation.

Routers periodically send RAs to their neighbors. The Edge
Router initiates the first RAs, and information from these RAs is
included in the RAs of each further router, causing the information
to be disseminated throughout the LoWPAN. RA periods should be
optimized to reduce signalling. See Section 7 for detailed router
operation.

4. Message Formats

This section defines the message and option formats used in this
document. The new messages are all ICMPv6 messages. In addition,
new options for ICMPv6 messages are defined.

The following new ICMPv6 message types are defined:

o Node Registration (NR)

o Node Confirmation (NC)

In addition, the following new ICMPv6 options are defined:

o 6LoWPAN Address Option (6AO)

o 6LoWPAN Information Option (6IO)

o 6LoWPAN Summary Option (6SO)

Shelby, et al. Expires August 5, 2010 [Page 14]

Internet-Draft 6LoWPAN Neighbor Discovery February 2010

o Owner Interface Identifier Option (OIIO)

The following [RFC4861] messages are used as specified in this
section:

o Router Solicitation (RS)

o Router Advertisement (RA)

4.1. Node Registration/Confirmation Message

The Node Registration (NR) and Node Confirmation (NC) messages are
used by a node to register with a router. Any option that is not
recognized MUST be skipped silently. The Node Registration message
is sent by the node to the link-local unicast IPv6 address of
a on-link router.

When registering for the first time, the node still has
optimistic addresses therefore the source address
of the Node Registration must be the IPv6 unspecified address to
comply with oDAD. In subsequent registrations, the IPv6 source
address is then the link-local IPv6 address of the sender. A
registration is periodically refreshed by sending a new NR message
more frequently than the Binding Lifetime indicated by the node
during registration.

Address Options are included in the NR message for each IPv6 address
to be registered, and included in the corresponding NC to indicate
success.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |Status | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TID |P|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding Lifetime | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Owner Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Owner Interface Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration option(s)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4: Node Registration/Confirmation message format

Shelby, et al. Expires August 5, 2010 [Page 15]

Internet-Draft 6LoWPAN Neighbor Discovery February 2010

IP Fields:

Source Address: The IPv6 address of the source. This address
MUST be the IPv6 unspecified address for initial registration.

Destination Address: The link-local unicast IPv6 address of a on-
link router when sent by a node.

Hop Limit: 255

ICMP Fields:

Type: TBD1 for Node Registration, TBD2 for Node Confirmation.

Status: 4-bit unsigned integer. Sent only in NC messages,
ignored in NR messages. Values 0-7 are reserved for success
codes:

0 is unqualified success.

Values 8-15 are reserved for error codes:

8 is send to indicate that the router is saturated and an
alternative router should be used.

Code: 4-bit unsigned integer.

0 indicates this NR is a request sent directly from the
originating host, or this NC is a corresponding response.

1 indicates that the NR message has been relayed by a
router, or that the NC is to be relayed by the router
indicated as the destination. (For future use)

2 indicates this NC is a request for the node to re-
register.

4-15 are reserved for future use.

Checksum: The ICMP checksum.

TID: 8-bit unsigned integer. A unique Transaction ID assigned by
the host and used to match replies. A lollipop mechanism is
used to increment the TID upon each new registration. The TID
is not incremented upon a on-link refresh. In a Node
Confirmation, the TID is that of the corresponding NR. TID is set
to 0 upon booting, and is incremented with each NR message.
After reaching 0xFF, the value loops to 16 (0x10) and is

Shelby, et al. Expires August 5, 2010 [Page 16]

Internet-Draft 6LoWPAN Neighbor Discovery February 2010

incremented from there. Thus the values between 0-15 MUST only
used after a boot or reboot.

P: 1-bit Primary flag. Not yet used by this specification, always
set to 1.

R: 1-bit Router flag. Used to indicate the role of node sending
the NR message. Set to 0 by hosts and to 1 by routers.

Binding Lifetime: 16-bit unsigned integer. The amount of time in
10 second intervals remaining before the binding of this owner
interface identifier, and all associated address options and
configuration options, MUST be considered expired. A value of
zero indicates that the Binding Cache entries for the
registered owner interface identifier MUST be deleted. A value
of 0xFFFF indicates an idefinite lifetime. (The 16-bit field
covers up to slightly more than a week of Binding Lifetime.)

Reserved: This field is unused. It MUST be initialized to zero
by the sender and MUST be ignored by the receiver.

Owner Interface Identifier (OII): A globally unique identifier
for the requesting host's interface. Typically the EUI-64
derived IID.

Owner Nonce: A 32-bit Nonce generated randomly by the node upon
booting, and generated again each time the node re-boots. This
Nonce may be used to detect duplicate OIIs.

Possible Options:

6LoWPAN Address Option(s): An Address Option is included for each
address the host wants to bind for this interface.

6LoWPAN Information Option: This option includes information
about the prefixes of the LoWPAN along with other context
information. Although normally carried in RA messages, a 6IO
option MAY also be carried in NC messages.

Future versions of this protocol may define new option types.
Receivers MUST silently ignore any options they do not recognize
and continue processing the message.

4.2. Router Solicitation Message

The RS message format for 6LoWPAN is identical to the classic
[RFC4861] RS message. The following clarifications are made
regarding the use of RS in LoWPANs.

Shelby, et al. Expires August 5, 2010 [Page 17]

Internet-Draft 6LoWPAN Neighbor Discovery February 2010

If a node has only optimistic addresses not yet confirmed by a
Router, then the IPv6 source address in the RS MUST be the IPv6
unspecified address. The Source Link-Layer Address Option MUST NOT
be included in the RS at any time. Instead the Owner Interface
Identifier specified in this document MUST be included in the RS.

The Code field of the Router Solicitation message is used to
indicate whether a node wants to receive the full set of 6IOs in the
RA response, or just the 6SO. An RS with Code = 0 is used to request
just the 6LoWPAN Summary Option, and Code = 1 is used to request the
full set of 6IOs.

4.3. Router Advertisement Message

The RA message format for 6LoWPAN is identical to the classic
[RFC4861] RA message. The use of flags is however defined in the
6LoWPAN context, and additional new options are identified. RA
messages are sent either to link-local all-nodes multicast, or to a
link-local unicast address as a response to an RS.

Updated Flag Definitions:

Prf: 2-bit signed integer. Default Router Preference as defined
in [RFC4191]. Indicates whether to prefer this router over
other default routers. Routers with no Edge Router available
MUST set Prf to (11) for low preference, routers with Edge Router
availability MUST set Prf to (00) for normal preference, and
Edge Routers MUST set Prf to (01) for high preference.

Options:

6LoWPAN Information Option: This option includes information
about the prefixes of the LoWPAN along with other context
information.

6LoWPAN Summary Option: This option provides a sequence number
associated with the current prefix options. It allows the
prefix options themselves to be sent only when a change has
occured, or when requested with an RS Code = 1.

Prefix Information Option: If needed for backward compatibility,
an RA may also be sent using the classic [RFC4861] Prefix
Information Option which all LoWPAN nodes MUST be able to
parse. If possible, routers in the LoWPAN SHOULD make use of
6IO and 6SO options instead of PIO.

The MTU and SLLAO options defined in [RFC4861] are not used by
this specification.

Shelby, et al. Expires August 5, 2010 [Page 18]

Internet-Draft 6LoWPAN Neighbor Discovery February 2010

Future versions of this protocol may define new option types.
Receivers MUST silently ignore any options they do not recognize
and continue processing the message.

4.4. Message Options

This section defines the new 6LoWPAN-ND message options.

4.4.1. 6LoWPAN Address Option

The 6LoWPAN Address Option (6AO) is used to indicate the address
which a node wants to register, and to indicate the success or
failure of that binding in an NC. Multiple Address Options can be
included in a message. In order to be as compact as possible, fields
are used to indicate the compression of the IPv6 address. The 6AO
also allows for duplicate addresses (e.g. anycasts), the request of a
generated address for claim and defend use, or for an address to be
removed.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Status | S | P |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|A|R|O| Reserved | IPv6 Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 5: 6LoWPAN Address Option format

Type: TBD3

Length: 8-bit unsigned integer. The length of the option (including
the type and length fields) in units of 8 octets.

Status: 8-bit unsigned integer. 0 means unqualified success. Any
value below 128 is a positive status that means that the binding
for this address was created or is being created optimistically.
Only used in a confirmation.

D: 1-bit Duplicate flag. When set, indicates that duplicates are
allowed for this address (to support anycast) in a request.

A: 1-bit Address Generation flag. Set to indicate that the host is
requesting a generated address for claim and defend addressing.
In a request when A is set the IPv6 address length is 0. Set to
indicate that an address has been assigned in a confirmation. P
and S are set to indicate the type of address requested and

Shelby, et al. Expires August 5, 2010 [Page 19]

Internet-Draft 6LoWPAN Neighbor Discovery February 2010

assigned when A is set. Otherwise must be 0.

R: 1-bit Removal flag. When set, indicates that this particular
address binding MUST be removed from a whiteboard (in a request)
or MUST not be used any longer (in a confirmation).

O: 1-bit Optimistic flag. When set, indicates that this particular
address is optimistic and has not yet been checked for duplicates.

P: 5-bit unsigned integer. Identifies prefix compression or type, if
any.

0-15: Prefix compressed; upon decompression, the prefix given by
the compression context with the same numerical CID as the P
field given is inserted.

16: Prefix is carried inline.

17: Prefix compressed; upon decompression, the link-local prefix
(fe80::) is inserted.

18-31: Reserved.

S: 3-bit unsigned integer. Identifies suffix compression or type, if
any.

0: Suffix carried inline.

1: Suffix compressed and assumes the same value as the Owner
Interface Identifier field in the NR/NC message header.

2: Suffix compressed for an IID formed from an IEEE 802.15.4 16-
bit short addresses. Only the 16-bit short-address is carried
in-line. The IID is formed from this address as specified in
[RFC4944].

3-7: Reserved.

IPv6 Address: The IPv6 address to be registered with the router, or
confirmed by the router. Parts of the address may be elided as per
the P and S fields.

4.4.2. 6LoWPAN Information Option

This option carries prefix information for LoWPANs, and is similar in
use to the Prefix Information Option of [RFC4861]. However this
option allows for the dissemination of multiple contexts identified
by a Context Identifier (CID) for use in 6LoWPAN address compression.

Shelby, et al. Expires August 5, 2010 [Page 20]

Internet-Draft 6LoWPAN Neighbor Discovery February 2010

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Info Length |L|A|C|V| CID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Prefix or Address Information .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 6: 6LoWPAN Information Option format

Type: TBD4

Length: 8-bit unsigned integer. The length of the option (including
the type and length fields) in units of 8 octets. May be 1, 2 or
3 depending on the length of the Information field.

Info Length: 8-bit unsigned integer. The number of leading bits in
the Information field that are valid. The value ranges from 0 to
128. The info length field provides necessary information for on-
link determination (when combined with the L flag in the prefix
information option). It also assists with address
autoconfiguration as specified in [RFC4862], for which there may
be more restrictions on the info length.

L: 1-bit on-link flag, similar to the L flag in [RFC4861]. This flag
MUST be unset for Route Over LoWPANs and Extended LoWPANs, and MAY
be set for Mesh Under Simple LoWPANs.

A: 1-bit autonomous address-configuration flag. When set indicates
that this prefix can be used for stateless address configuration
as specified in [RFC4861].

C: 1-bit context flag. This flag indicates that this information
option also serves as a context on the LoWPAN, which is identified
by the CID field.

V: 1-bit context validity flag. This flag indicates if the context
is valid, and is used only in combination with the C flag. A
context that is not valid MUST not be used for compression, but
MAY be used in decompression in case another compressor still
considers the context as valid.

Shelby, et al. Expires August 5, 2010 [Page 21]

Internet-Draft 6LoWPAN Neighbor Discovery February 2010

CID: 4-bit Context Identifier for this prefix information. CID is
used by context based header compression specified in
[I-D.ietf-6lowpan-hc]. The list of CIDs for a LoWPAN is
configured on Edge Routers, who distribute the prefix list to all
nodes in the LoWPAN.

Valid Lifetime: 32-bit unsigned integer. The length of time in
seconds (relative to the time the packet is sent) that the prefix
is valid for the purpose of on-link determination. A value of all
one bits (0xffffffff) represents infinity.

Information: The IPv6 prefix or context information indicated. This
may be a partial prefix, a partial context or even an entire IPv6
address for use as a context for compression.

4.4.3. 6LoWPAN Summary Option

This option identifies the set of prefix information options by a
sequence number. This allows for the full set of prefix information
options to be sent only periodically in unsolicited RAs. If a host
detects a difference in the sequence number of this option, then the
prefix information has likely changed, and is then requested with an
RS. An RA sent in response to a unicast RS always includes the full
set of prefix information.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V| Reserved | ER Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 7: 6LoWPAN Summary Option

Type: TBD5

Length: 1

Sequence Number: 16-bit signed integer. Indicates the freshness of
the information advertised by the RA.

ER Metric: 16-bit unsigned integer. The ER Metric gives an
indication of the cost (in routing metric terms) of reaching nodes
outside the LoWPAN via an Edge Router through this router. The metric
SHOULD be derived in a well-defined way from the routing protocol
used in the LoWPAN (possibly by structuring the 16 bits available
e.g. into a major and a minor metric), and has a mid-range default

Shelby, et al. Expires August 5, 2010 [Page 22]

Internet-Draft 6LoWPAN Neighbor Discovery February 2010

value of 0x8000. Edge Routers most likely set this field to 0. A
host SHOULD take this metric into account when choosing default
routers by making a scalar comparison, preferring routers with
numerically lower ER Metric values.

V: 1-bit flag. Indicates if the sequence number is valid and the
router is advertising information obtained from another router.

Reserved: This field is unused. It MUST be initialized to zero by
the sender and MUST be ignored by the receiver.

4.4.4. Owner Interface Identifier Option

This option is used together with Router Solicitation messages when a
node has only optimistic addresses before initial registration.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | TID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Owner Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Owner Interface Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 8: Owner Interface Identifier Option

Type: TBD6

Length: 2

TID: 8-bit unsigned integer. This field is set to the last TID
value used for sending an NR message.

Reserved: This field is unused. It MUST be initialized to zero by
the sender and MUST be ignored by the receiver.

Owner Nonce: A 32-bit Owner Nonce generated randomly by the node
upon booting, and generated again each time the node re-boots.
This Owner Nonce is used to detect duplicate OIIs.

Owner Interface Identifier: A globally unique identifier for the
host's interface. This is typically the EUI-64 derived IID of the
interface.

Shelby, et al. Expires August 5, 2010 [Page 23]

Internet-Draft 6LoWPAN Neighbor Discovery February 2010

5. Protocol Specification

This section specifies the functions defined by this specification,
along with pointers to needed procedures from other specifications.
These basic procedures are sufficient and required for LoWPAN
operation.

5.1. Interface initialization

A LoWPAN node forms a 64-bit Interface Identifier (IID) as specified
in Section 6 of [RFC4944]. This may be based on the EUI-64
identifier, an assigned 16-bit short address, or any other
appropriate MAC address. All nodes MUST configure at least one
address, a link-local address, by concatenating its IID with the
prefix FE80::/64 as specified in Section 7 of [RFC4944]. As a
result, knowledge of the IID of another node is enough to
derive its link-local address and reach it on the same link. If
derived from an EUI-64 or an equivalent the link-local address is
presumably unique on the LoWPAN, which enables the use of Optimistic
Duplicate Address Detection (oDAD) [RFC4429]. The address SHOULD be
created as optimistic before it has been confirmed by Node
Registration (Section Section 5.2). This document assumes that
addresses are formed in a uniform manner in a LoWPAN. Appropriate
steps SHOULD be taken to ensure that only correctly configured
devices participate in the LoWPAN, e.g. using L2 security mechanisms.

A node MUST join the all-nodes multicast address, which is used for
receiving RAs from routers. A router MUST also join the all-routers
multicast address. A node MAY join other multicast addresses such as
the solicited-node multicast address if its link-layer includes
multicast support, but that is not required by this specification.

Nodes MAY learn the address of routers using traditional means such
as L2 configuration or Router Advertisement messages as in [RFC4861].
When sending a Router Solicitation it MUST not have the SLLAO Option,
but instead MUST include the OII Option. If the sender of the RS has
only optimistic addresses, it MUST not use them as the IPv6 source
address for the RS, but instead uses the IPv6 unspecified address.
This procedure is to comply with the use of optimistic addresses as
per oDAD [RFC4429].

The node SHOULD also form a global unicast address for routing inside
the LoWPAN and reachability from outside the LoWPAN. If a valid
prefix is available from an RA ('A' flag is set), then a global
unicast address MAY be derived following the general description in
Section 5.5 of [RFC4862]. This address is marked optimistic until
confirmed by the Node Registration process. If the LoWPAN is
operating in ad-hoc mode, then the prefix is a Unique on-link IPv6

Shelby, et al. Expires August 5, 2010 [Page 24]

Internet-Draft 6LoWPAN Neighbor Discovery February 2010

Address (ULA) prefix [RFC4193] as specified in Section 8 (use of a
ULA prefix requires no changes to node operation). A node MAY
alternatively acquire a global unicast address using other suitable
means, e.g. DHCPv6, L2 assignment or manual configuration.

5.2. Node Registration

The node registration process is very similar to that of a MIPv6
mobile node, though the messages used are new Node Registration/Confirmation ICMP
messages. A node address is optimistic as long as the binding is
not confirmed by a router. The node sends a unicast Node
Registration to an on-link router to perform the binding. While a
node's addresses are still optimistic (first registration in a
LoWPAN), the IPv6 unspecified address must be used as the source.
Registration SHOULD be preferred with on-link Edge Routers rather
than routers if available. The Preference Flag of the RA is
used to differentiate between Edge Routers (Prf=01) and routers
(Prf=00). Routers with Prf=11 SHOULD NOT be used for
registration. Furthermore the ER Metric in the 6LoWPAN Summary
Option SHOULD be used to rank routers.

A unique Owner Interface Identifier (OII) is included in the Node
Registration so the binding can be identified throughout the LoWPAN.
The OII SHOULD be formed from the EUI-64 of the interface in the same
way as the node's link-local address IID as defined in [RFC4944]. A
randomly generated 32-bit Owner Nonce is formed each time a node
boots or reboots. This is included in the NR and may be used to
detect duplicate OIIs. While cryptographic randomness [RFC4086] is
not strictly required, the randomness SHOULD be derived using a
mechanism of similar quality.

The NR message includes an Address Option for each address to be
registered. Thus the message is structured as follows:

ICMPv6 (Node Registration (Address Option[0], Address Option[1],
Address Option[n]))

This registration method includes a way of requesting a unique
address by setting the 'A' flag in an Address Option during
registration. This is useful for receiving a unique short link-layer
address. How a router assigns such an address is out of scope for
this document.

A unique Transaction ID (TID) is included by the host in the NR
message and used to match replies. A lollipop mechanism is used.
TID is set to 0 upon booting, and is incremented with each Request NR
message. The TID MUST NOT be incremented when sending a Refresh NR
message. After reaching 0xFF, the value loops to 16 (0x10) and is

Shelby, et al. Expires August 5, 2010 [Page 25]

Internet-Draft 6LoWPAN Neighbor Discovery February 2010

incremented from there. Thus the values between 0-15 MUST only used
after a boot or reboot while not yet registered. A node that has not
heard a valid Node Confirmation for 16 Node Registration messages in
a row restarts with a on-link next TID of zero (the node MAY, but
need not, generate a new Owner Nonce).

The acknowledgment to a Node Registration is a unicast Node
Confirmation message that contains the status of the bindings. The
source of the packet is the link-local address of the on-link router.
The destination address is the link-local address of the node. An
Address Option for each confirmed or assigned address is included.
Upon successful completion in the Node Confirmation message, the
node sets the address from optimistic to preferred. See
Section 11 for message examples.

Node bindings have timeouts associated with them, therefore nodes
must periodically send a new Node Registration message to renew the
binding. The period between Request NR messages SHOULD be less than
BindingLifetime. If a node no longer receives Node Confirmation
messages from any router in the current subnet, the registration
process starts over.

5.2.1. Processing a Node Registration Message

When a router receives a Node Registration message from a node, it
first checks for correctness of the message fields and options. In
the case of an existing node, the message is used to refresh the
corresponding entries in the router's binding table.

In the case of a new node, then a binding table entry is made for
each 6AO in the message. The router SHOULD perform Duplicate Address
Detection on each optimistic address (O flag set), see Section 5.3
for further information on the DAD procedure. If a 6AO option with
an A flag is received, then the router should acquire a suitable
address for the node. How this is done is out of scope. Depending
on the link-layer and network it may be possible to generate a random
address (DAD MUST be performed in this case), acquire an address from
a link-layer coordinator, or perform DHCPv6 in a managed network to
name a few.

After processing all 6AO options, a unicast Node Confirmation message
is sent back to the node with an appropriate NC Status code and
success codes for each 6AO option in the same order as received.

5.2.2. Processing a Node Confirmation Message

When a node receives a Node Confirmation message from a router, it
first checks for correctness of the message fields and options.

Shelby, et al. Expires August 5, 2010 [Page 26]

Internet-Draft 6LoWPAN Neighbor Discovery February 2010

If a NC is received with a success status (0-7), then the node goes
on to process 6LoWPAN Address Options. If a successful NC is
received with a code of 2, this indicates that the node should re-
register with that router.

6LoWPAN Address Options are processed one at a time. A success
status (0-127) indicates that the address was successfully bound with
the router. If the address is marked optimistic, it is now updated
to preferred. A failure code (128-) indicates that the binding
failed. See Section 4.4.1 for an explanation of 6AO codes. A
binding failure may indicate that a duplicate address (and thus a
duplicate IID) already exists. In this case the node SHOULD attempt
to form a new IID and restart the registration process. If this is
not possible, the node MUST not participate in the LoWPAN.

If a NC is received with an error status (8 or greater), then the
registration has failed. See Section 4.1 for an explanation of NR/NC
codes. If no successful Node Confirmation is received within the
timeout (RegistrationTimeout) and number of retries
(RegistrationRetries), then registration should be performed with
another router in the default router list.

5.3. Duplicate Address Detection

It is important for proper network operation that duplicate addresses
are not used in a LoWPAN as described in "IPv6 Stateless Address
Autoconfiguration" [RFC4862]. Furthermore, as LoWPANs are made up of
links with undetermined connectivity, it is important that address
uniqueness is ensured thoughout the routing domain as discussed in
[I-D.ietf-autoconf-adhoc-addr-model]. Hosts may be very
simple, and thus are not expected to have the capability of
performing a duplicate address detection (DAD) algorithm themselves.
Therefore the handling of DAD is considered a function of routers.
This document does not perform DAD as defined in [RFC4862],
but instead makes use of alternative techniques appropriate for
LoWPANs. It is assumed that all routers in a LoWPAN are configured
to perform DAD in a uniform way. If there is only a single router in
the LoWPAN, as occurs in mesh-under or star topologies, then a router
automatically detects duplicates by checking its own binding table
during registration, thus no additional mechanism is needed.

If a router receives a Node Registration 6AO with the Optimistic Flag
(O) set, it SHOULD perform DAD on this address. If the router
generates or assigns an address for a node in response to a 6AO with
the A flag set, it SHOULD perform DAD on that address. DAD MAY be
disabled if the address has been generated or assigned in such a way
that there is high confidence of no duplicates (WARNING IN LARGE
PRINT). Examples include the use of an EUI-64 to form an IID or

Shelby, et al. Expires August 5, 2010 [Page 27]

Internet-Draft 6LoWPAN Neighbor Discovery February 2010

DHCPv6 performed through a single server uniformly by all nodes in
the LoWPAN (as per the homogeneous LoWPAN assumption).

A router can be configured to perform DAD using one of the following
techniques, the details of which are out of the scope of this
document:

Extended LoWPAN: The Extended LoWPAN technique defined in (draft
tbd) provides DAD during its ER registration.

Routing protocol: If supported, a routing protocol mechanism could
be used to check for the existance of an address in the LoWPAN,
assuming that it is covered by a single routing domain.

5.4. Next-hop Determination

The IP address of the next-hop for a destination is determined as
follows. Destinations to the link-local prefix (FE80::) are always
sent on the link to that destination. All other prefixes are assumed
to be off-link as recommended in
[I-D.ietf-autoconf-adhoc-addr-model]. They are therefore sent to the
IP address of a router chosen from the Default Router List.

Multicast addresses are considered to be on-link and are resolved as
specified in [RFC4944] or relative future documents. A node
is not required to maintain a minimum of one buffer per neighbor as
specified in [RFC4861], as address lookup is not performed as part of
next-hop determination. Anycast addresses are always considered to
be off-link.

5.5. Address Resolution

The node registration mechanism provides sufficient a priori state in
nodes and routers to resolve an IPv6 address to its associated link-
layer address on the node-router interface. As prefixes are always
assumed to be off-link, resolution between hosts is not needed.

Information about link-layer addresses is stored by nodes about
routers in its default router list, and by routers about nodes in its
binding table. This information is stored during the node
registration process. In order to achieve LoWPAN compression, most
global addresses are also formed using a link-layer address. A node
can minimize memory usage by making use of an educated guess and
storing link-layer address information only if it differs from the
link-layer address corresponding to the IID of the IPv6 address
(i.e., differs in more than the on-link/global bit being inverted).

Shelby, et al. Expires August 5, 2010 [Page 28]

Internet-Draft 6LoWPAN Neighbor Discovery February 2010

5.6. Unreachability Detection

Unreachability between a node and router is determined based on NR/NC
and RS/RA exchanges and other unicast L3 data messages. Host-host
unreachability detection is out of scope.

In order to detect unreachable destinations, nodes SHOULD support
type 1 ICMPv6 destination unreachable messages [RFC4443]. LoWPAN
Routers or Edge Routers make use of ICMPv6 destination unreachable to
indicate that delivery to that destination is not possible.

5.7. Context Dissemination

Network configuration parameters carried in Router Advertisements
originate at Edge Routers and must disseminate to all routers and
hosts within the LoWPAN. RAs include either 6LoWPAN Information
Options (one for each context) and a 6LoWPAN Summary Option, or just
a 6LoWPAN Summary Option.

For the dissemination of context information using the 6IO, a strict
lifecycle SHOULD be used in order to ensure the context information
stays synchronized throughout the LoWPAN. New context information
SHOULD be introduced into the LoWPAN with C=1 and V=0, to ensure it
is known by all nodes that may have to decompress based on this
context information. Only when it is reasonable to assume that this
information was successfully disseminated SHOULD an option with C=1
and V=1 be sent, enabling the actual use of the context information
for compression.

Conversely, to avoid that nodes send packets making use of previous
values of contexts, resulting in ambiguity when receiving a packet
that uses a recently changed context, old values of a context SHOULD
be taken out of use for a while before new values are assigned to
this specific context. That is, in preparation for a change of
context information, its dissemination SHOULD continue for at least
MIN_CONTEXT_CHANGE_DELAY with C=1 and V=0. Only when it is
reasonable to assume that the fact that the context is now invalid
was successfully disseminated, should the context ID be taken out of
dissemination or reused with a different Information field. In the
latter case, dissemination of the new value again SHOULD start with
C=1 and V=0, as above.

The 6LoWPAN Summary Option is used to support information
dissemination from one or more Edge Routers to all other nodes in the
LoWPAN. The option includes a "V" flag which indicates that the
information contained in the Router Advertisement is valid. The
option also includes a sequence number to ensure that all nodes
converge on the same settings. The sequence number is incremented by

Shelby, et al. Expires August 5, 2010 [Page 29]

Internet-Draft 6LoWPAN Neighbor Discovery February 2010

the originating Edge Router each time the set of prefix information
changes.

As the number of prefixes or addresses included for context
compression in an RA may be large (up to 16), it is beneficial to
avoid the need to always include all options in every RA. Therefore
routers SHOULD only include the 6LoWPAN Summary Option in unsolicited
RAs, unless a set of prefix information with a new sequence number is
being disseminated. In the case of a new sequence number, the router
SHOULD include all 6LoWPAN Information Options in the RA. A node may
use an RS with Code set to 1 in order to get the whole prefix
information set in case it misses the RA sent when the sequence
number changes. An RS with Code set to 0 is responded to with an RA
with the 6SO.

6. Node Specification

This section specifies the conceptual data structures and variables
of a LoWPAN Node.

6.1. Conceptual structures

Nodes make use of the following conceptual data structures:

Prefix List - The list of prefixes which are advertised in Router
Advertisements, along with an associated invalidation timer. Each
entry is associated with the sequence number last advertised in
the 6LoWPAN Summary Option. Unlike in [RFC4861], these prefixes
are always assumed to be off-link.

Context List - The list of contexts and their associated CID which
are advertised in Router Advertisements, along with an associated
invalidation timer. Each entry is associated with the sequence
number last advertised in the 6LoWPAN Summary Option. This list
may be realized together with the Prefix List.

Default Router List - As in [RFC4861]. For networks where address
resolution needs to be performed, this list also contains link-
layer information about each router.

These conceptual data structures may be realized in many ways. As
nodes have very limited memory the number of cache entries
should be limited, duplicate entries between caches referenced, and
full IPv6 addresses represented in a compressed format where
possible.

Shelby, et al. Expires August 5, 2010 [Page 30]

Internet-Draft 6LoWPAN Neighbor Discovery February 2010

6.2. Conceptual variables

The following variables are kept for each interface on a node, and
default values are overridden by information in Router
Advertisements:

CurHopLimit The default hop limit to be used when sending IP
packets.

CurTID The current Transaction ID (TID) value for use in
NR messages.

BindingLifetime The binding lifetime sent in Node Registration
messages.

RegistrationTimeout The time to wait for a Node Confirmation after
sending a Node Registration. SHOULD be at least
MIN_NR_TIMEOUT.

RegistrationRetries The number of times to try to send a Node
Registration, which SHOULD be less than
MAX_NR_RETRIES.

7. Router Specification

Routers are used in a route-over configuration where the
network is composed of overlapping link-local scopes. Edge
Routers implement router functionality. As a result, we
extend classic ND as specified in [RFC4861] to operate over such non-
transitive LoWPAN links. This section describes ND for
router operations in a LoWPAN. Note that this section does not entirely apply to
pure Mesh Under LoWPANs where the are no routers, although
they do have Edge Routers.

7.1. Router Configuration Variables

A router MUST allow the configuration of conceptual variables as
defined in Section 6.2.1 of [RFC4861]. AdvReachableTime and
AdvRetransTimer are not used.

7.2. Becoming an Advertising Interface

An interface may become an advertising interface as specified in
Section 6.2.2 of [RFC4861].

A router's interface MAY become an advertising interface
before all of its router variables have been initialized. The router

Shelby, et al. Expires August 5, 2010 [Page 31]

Internet-Draft 6LoWPAN Neighbor Discovery February 2010

MUST learn these variables (e.g. AdvCurHopLimit, prefix and context
information, etc.) from neighboring routers. While the variables are
not initialized, the router MAY send Router Advertisement with the
"Solicit" flag set to solicit Router Advertisements from neighboring
routers. However, the router MUST set the Router Lifetime field to
zero while one or more of its variables are uninitialized.

7.3. Router Advertisement Message Content

A router sends periodic as well as solicited Router Advertisements
out its advertising interface. Outgoing Router Advertisements are
filled with the following values consistent with the message format
given in this document.

- 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.

- In the M and O flags: the current value of AdvManagedFlag and
AdvOtherConfigFlag, respectively.

- In the Preference flag: this flag is set to 00 to indicate that
the sender is a router.

- In the Cur Hop Limit field: the current value of CurHopLimit.

- In the Reachable Time field: not used, set to zero.

- In the Retrans Timer field: not used, set to zero.

- In the options:

- 6LoWPAN Summary Option: to indicate if the information
contained in the Router Advertisement is valid and, if so, the
freshness of the information contained in the Router
Advertisement message. The option fields are set as follows:

- In the "valid" flag: the current value of
AdvInformationValid.

- In the Sequence Number field: the current value of
AdvInformationSequence.

- The ER Metric field is used by a routing algorithm to
indicate the cost of reaching an Edge Router through this
router.

Shelby, et al. Expires August 5, 2010 [Page 32]

Internet-Draft 6LoWPAN Neighbor Discovery February 2010

- 6LoWPAN Information options: one 6LoWPAN Information option
for each prefix listed in AdvPrefixList with the option fields
set from the information in the AdvPrefxList entry as follows:

- In the "on-link" flag: the entry's AdvOnLinkFlag.

- In the "Autonomous address configuration" flag: the
entry's AdvAutonomousFlag.

- In the Valid Lifetime field: the entry's AdvValidLifetime.

7.4. Sending Unsolicited Router Advertisements

As specified in Section 6.2.4 of [RFC4861].

7.5. Ceasing To Be an Advertising Interface

As specified in Section 6.2.5 of [RFC4861].

7.6. Processing Router Solicitations

As specified in Section 6.2.6 of [RFC4861].

7.7. Binding Table

Routers maintain an set of information about nodes that are currently
registered through it called the binding table.

The binding table contains an entry with information such as the
registered node's OII, link-local IPv6 address and the binding
lifetime from the last NR. If address resolution is required, the
table will also include corresponding link-layer address information.

8. Ad-hoc LoWPAN

LoWPAN networks by nature may often work in an ad-hoc fashion,
without an infrastructure or connectivity to the global Internet.
6LoWPAN-ND may still be applied in such networks.

A specific router in the Ad-hoc LoWPAN is nominated as Edge Router
and configured to implement basic Edge Router functionality
(initiating RA dissemination) and generates a prefix based on Unique
on-link IPv6 Unicast Addresses (ULAs) as defined in [RFC4193]. A
ULA is made up of the prefix fc00::/7, a global ID and a subnet ID.
The global ID is randomly generated, and the subnet ID is not used.
The Edge Router is responsible for the generation of the ULA prefix
to be advertised to the LoWPAN and used by all nodes. ULA generation
may use the algorithm suggested Section

Shelby, et al. Expires August 5, 2010 [Page 33]

Internet-Draft 6LoWPAN Neighbor Discovery February 2010

3.2.2 of [RFC4193] or something appropriate to the Edge Router's
capabilities. There SHOULD be only one Edge Router in an Ad-hoc
LoWPAN (just as in a Simple LoWPAN) to keep prefix consistency.

In the case that an Edge Router on a Simple LoWPAN does not have a
prefix available from its IPv6 address, it SHOULD advertise a ULA
prefix in a similar manner.

9. Protocol Constants

This section defines the protocol constants used in this document
based on a subset of [RFC4861] constants. (*) indicates constants
modified from [RFC4861] and (+) indicates new constants.

Additional protocol constants are defined in Section Section 4.

Edge Router Constants:

MIN_CONTEXT_CHANGE_DELAY+ 60 seconds

Router Constants:

MAX_INITIAL_RTR_ADVERT_INTERVAL* 60 seconds

MAX_INITIAL_RTR_ADVERTISEMENTS 3 transmissions

MAX_FINAL_RTR_ADVERTISEMENTS 3 transmissions

MIN_DELAY_BETWEEN_RAS* 10 seconds

MAX_RA_DELAY_TIME* 2 seconds

Host Constants:

MAX_RTR_SOLICITATION_DELAY* 2 second

RTR_SOLICITATION_INTERVAL* 10 seconds

MAX_RTR_SOLICITATIONS 3 transmissions

Node Constants:

MAX_NR_RETRIES+ 3 transmissions

Shelby, et al. Expires August 5, 2010 [Page 34]

Internet-Draft 6LoWPAN Neighbor Discovery February 2010

MIN_NR_TIMEOUT+ 5 seconds

10. Use of 6LoWPAN-ND under RFC4861-only stacks

Some IPv6 stacks (e.g. on PCs) and tools (e.g. radvd) hard-wire the
mechanisms of RFC4861 for all links. This section explains the
adaptation needed in order to use a 6LoWPAN interface under such an
RFC4861-only implementation.

There are several ways to implement 6LoWPAN-ND in combination with an
IPv6 stack:

o 6LoWPAN-ND is integrated with the IPv6 stack and its tools. This
is common for LoWPAN nodes.

o 6LoWPAN-ND is implemented as part of the interface, configuration
is used to turn off RFC4861 mechanisms in the IPv6 stack. For
example, Proxy-ND interfaces can be used in Linux to disable most
built-in ND mechanisms. This model is common for Edge Routers
running on a standard operating system.

o 6LoWPAN-ND is implemented as part of the interface, and it
performs adaptation for RFC4861 mechanisms running on the IPv6
stack. The binding table is used to answer RFC4861 messages, and
appropriate options added to RA messages.

Classic RS/RA messages can be used with a LoWPAN, thus allowing e.g.
for an unmodified radvd (with appropriate configuration) to be run on
an Edge Router as long as context dissemination is not needed. It is
however recommended that 6IO and 6SO options be used if possible,
which is easily achieved by patching existing RA tools or performing
adaptation.

11. Message Examples

This section provides basic examples of messages and options from
this document.

11.1. NR/NC message exchange

When a host wants to register to a router, a simple NR/NC request
message exchange occurs. In this example, a host wants to register
its address generated with Stateless Address Autoconfiguration (SAA),
and in addition requests a generated short address.

First the Host sends an NR message to the link-local address of the

Shelby, et al. Expires August 5, 2010 [Page 35]

Internet-Draft 6LoWPAN Neighbor Discovery February 2010

router. In this example the host includes a 600 second binding
lifetime and its modified EUI-64 as the Owner Interface Identifier.
The message has two Address Options. The host has just booted,
therefore the TID starts with 0. This example assumes that the
LoWPAN prefix has been assigned CID 0.

IPv6 Source: Unspecified address
IPv6 Destination: Router's link-local address

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | 0 | 0 | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TID = 0 |1|0| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding Lifetime = 60 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Owner Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Owner Interface Identifier = +
| Modified EUI-64 of the interface |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 9: Basic NR request.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Length = 1 | Status = 0 | S=1 | P=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|1| Reserved | Padding = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 10: NR Address Option 1, for the SAA address.

Shelby, et al. Expires August 5, 2010 [Page 36]

Internet-Draft 6LoWPAN Neighbor Discovery February 2010

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Length = 1 | Status = 0 | S=2 | P=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1|0|0| Reserved | Padding = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 11: NR Address Option 2, for the requested address.

IPv6 Source: Router's link-local address
IPv6 Destination: Host's link-local address

The base NC message is identical to the base NR message above.

Figure 12: Corresponding NC message.

Address Option 1 is identical to Address Option 1 in the NR.

Figure 13: NC Address Option 1, for the SAA address.

Address Option 2 now includes the generated address.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Length = 1 | Status = 0 | S=2 | P=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1|0|0| Reserved | Generated 16-bit address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 14: NC Address Option 2, for the requested address.

11.2. Router advertisement

Routers and Edge Routers in LoWPAN networks periodically send RA
messages. The following example is of an RA message sent by a
router. If the message is sent by an Edge Router, the only difference
is that the Preference flag is set to 10.

Shelby, et al. Expires August 5, 2010 [Page 37]

Internet-Draft 6LoWPAN Neighbor Discovery February 2010

In the example the Preference flag is 01 (router), and a 1200s Router
Lifetime is advertised. A 6LoWPAN Prefix Information Option is
included.

IPv6 Source: Router's link-local address
IPv6 Destination: All-nodes multicast address

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 134 | Code = 0 | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |0|0|0|0 0|Rsrvd| Router Lifetime = 1200 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 15: RA message example.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Length = 2 | PL = 64 |0|1|1|1| CID=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime = 3000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Prefix = 2001:DB8::/64 .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 16: 6LoWPAN Information Option example.

12. Security Considerations

The security considerations of IPv6 Neighbor Discovery [RFC4861]
apply. Additional considerations can be found in [RFC3756].

This specification expects that the link layer is sufficiently
protected, either by means of physical or IP security for the
backbone link or MAC sublayer cryptography. In other words, model 1
from [RFC3756] applies. In particular, it is expected that the

Shelby, et al. Expires August 5, 2010 [Page 38]

Internet-Draft 6LoWPAN Neighbor Discovery February 2010

LoWPAN MAC provides secure unicast to/from Routers and secure
broadcast from the Routers in a way that prevents tampering with or
replaying the RA messages. However, any future 6LoWPAN security
protocol that applies to Neighbor Discovery for 6LoWPAN protocol, is
out of scope of this document.

The use of EUI-64 for forming the Interface ID in the link on-link
address prevents the usage of Secure ND ([RFC3971] and [RFC3972]) and
address privacy techniques. Considering the envisioned deployments
and the MAC layer security applied, this is not considered an issue
at this time.

13. IANA Considerations

This document requires two new ICMPv6 message types:

o Node Registration (TBD1)

o Node Confirmation (TBD2)

The document also requires four new ND option types under the
subregistry "IPv6 Neighbor Discovery Option Formats":

o 6LoWPAN Address Option (TBD3)

o 6LoWPAN Information Option (TBD4)

o 6LoWPAN Summary Option (TBD5)

o Owner Interface Identifier Option (TBD6)

[TO BE REMOVED: This registration should take place at the following
location: http://www.iana.org/assignments/icmpv6-parameters]

14. Acknowledgments

The authors thank Richard Kelsey, Geoff Mulligan, Julien Abeille,
Alexandru Petrescu, Peter Siklosi, Pieter De Mil, Fred Baker, Anthony
Schoofs, Phil Roberts and Joakim Eriksson for useful discussions and
comments that have helped shaped and improve this document.

15. Changelog

Changes from -07 to -08:

Shelby, et al. Expires August 5, 2010 [Page 39]

Internet-Draft 6LoWPAN Neighbor Discovery February 2010

Changes from -06 to -07:

o Updated addressing and address resolution (#60).

o Changed the Address Option to 6LoWPAN Address Option, fixed S
values (#61).

o Added support for classic RFC4861 RA Prefix Information messages
to be processed (#62).

o Added a section on using 6LoWPAN-ND under a hard-wired RFC4861
stack (#63).

o Updated the NR/NC message with a new Router flag, combined the
Code and Status fields into one byte, and added the capability to
carry 6IOs (#64).

o Made co-existence with other ND mechanisms clear (#59).

o Added a new Protocol Specification section with all mechanisms
specified there (#59).

o Removed dependencies and conflicts with RFC4861 wherever
possible (#59).

o Some editorial cleanup.

Changes from -05 to -06:

o Fixed the Prf codes (#52).

o Corrected the OIIO TID field to 8-bits. Changed the Nonce/OII
order in both the OIIO and the NR/NC. (#53)

Shelby, et al. Expires August 5, 2010 [Page 40]

Internet-Draft 6LoWPAN Neighbor Discovery February 2010

o Corrected an error in Table 1 (#54).

o Fixed asymmetric and a misplaced transient in the 6LoWPAN
terminology section.

o Added Updates RFC4861 to header

Changes from -04 to -05:

o Meaning of the RA's M-bit changed to original [RFC4861] meaning
(#46).

o Terms "on-link" and "off-link" used in place of "on-link" and
"off-link".

o Next-hop determination text simplified (#49).

o Neighbor cache and destination cache removed.

o IID to link-layer address requirement relaxed.

o NR/NC changes to enable on-link refresh with routers (#48).

o Modified 6LoWPAN Information Option (#47).

o Added a Protocol Constants section (#24)

o Added the NR processing table (#51)

o Considered the use of SeND on backbone NS/NA messages (#50)

Changes from -03 to -04:

o Moved Ad-hoc LoWPAN operation to Section 7 and made ULA prefix
generation a features useful also in Simple and Extended LoWPANs.
(#41)

o Added a 32-bit Owner Nonce to the NR/NC messages and the
Whiteboard, removed the TID history. (#39)

o Improved the duplicate OII detection algorithm using the Owner
Nonce. (#39)

o Clarified the use of Source and Target link-layer options in
NR/NC. (#43)

o Included text on the use of alternative methods to acquire
addresses. (#38)

Shelby, et al. Expires August 5, 2010 [Page 41]

Internet-Draft 6LoWPAN Neighbor Discovery February 2010

o Removed S=2 from Address Option (not needed). (#36)

o Added a section on router dissemination consistency. (#44)

o Small improvements and extensive editing. (#42, #37, #35)

Changes from -02 to -03:

o Updated terminology, with RFC4861 non-transitive link model.

o 6LoWPAN and ND terminology separated.

o Protocol overview explains RFC4861 diff in detail.

o RR/RC is now Node Registration/Confirmation (NR/NC).

o Added NR failure codes.

o ER Metric now included in 6LoWPAN Summary Option for use in
default router determination by hosts.

o Examples of host data structures, and the Whiteboard given.

o Whiteboard is supported by all Edge Routers for option
simplicity.

o Edge Router Specification chapter re-structured, clarifying
optional Extended LoWPAN operation.

o NS/NA now completely optional for nodes. No address resolution
or NS/NA NUD required.

o link-local operation now compatible with oDAD (was broken).

o Exception to hop limit = 255 for NR/NC messages.

o Security considerations improved.

o ICMPv6 destination unreachable supported.

Changes from -01 to -02:

o Fixed 16 != 0xff bug (ticket closed).

o Specified use of ULAs in ad-hoc LoWPAN section 9 (ticket
closed).

Shelby, et al. Expires August 5, 2010 [Page 42]

Internet-Draft 6LoWPAN Neighbor Discovery February 2010

o Terminology cleanup based on Alex's comments.

o General editing improvements.

Changes from -00 to -01:

o Specified the duplicate owner interface identifier procedures.
A TID lollipop algorithm was sufficient (nonce unnecessary).

o Defined fault tolerance using secondary bindings.

o Defined ad-hoc network operation.

o Removed the E flag from RA and the X flag from RR/RC.

o Completed message examples.

o Lots of improvements in text quality and consistency were made.

16. References

16.1. Normative References

[I-D.ietf-autoconf-adhoc-addr-model]
Baccelli, E. and M. Townsley, "IP Addressing Model in Ad
Hoc Networks", draft-ietf-autoconf-adhoc-addr-model-02
(work in progress), January 2010.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6
over Non-Broadcast Multiple Access (NBMA) networks",
RFC 2491, January 1999.

[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005.

[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.

[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.

[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD)
for IPv6", RFC 4429, April 2006.

Shelby, et al. Expires August 5, 2010 [Page 43]

Internet-Draft 6LoWPAN Neighbor Discovery February 2010

[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006.

[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.

[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.

[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007.

16.2. Informative References

[I-D.ietf-6lowpan-hc]
Hui, J. and P. Thubert, "Compression Format for IPv6
Datagrams in 6LoWPAN Networks", draft-ietf-6lowpan-hc-06
(work in progress), October 2009.

[RFC2022] Armitage, G., "Support for Multicast over UNI 3.0/3.1
based ATM Networks", RFC 2022, November 1996.

[RFC3122] Conta, A., "Extensions to IPv6 Neighbor Discovery for
Inverse Discovery Specification", RFC 3122, June 2001.

[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756,
May 2004.

[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.

[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.

[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.

[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903,
June 2007.

[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals",
RFC 4919, August 2007.

Shelby, et al. Expires August 5, 2010 [Page 44]

Internet-Draft 6LoWPAN Neighbor Discovery February 2010

Authors' Addresses

Zach Shelby (editor)
Sensinode
Hallituskatu 13-17D
Oulu 90100
FINLAND

Phone: +358407796297
Email: [email-masked]

Pascal Thubert
Cisco Systems
Village d'Entreprises Green Side
400, Avenue de Roumanille
Batiment T3
Biot - Sophia Antipolis 06410
FRANCE

Phone: +33 4 97 23 26 34
Email: [email-masked]

Jonathan W. Hui
Arch Rock Corporation
501 2nd St. Ste. 410
San Francisco, California 94107
USA

Phone: +415 692 0828
Email: [email-masked]

Samita Chakrabarti
IP Infusion
1188 Arquest Street
Sunnyvale, California
USA

Phone:
Email: [email-masked]

Shelby, et al. Expires August 5, 2010 [Page 45]

Internet-Draft 6LoWPAN Neighbor Discovery February 2010

Carsten Bormann
Universitaet Bremen TZI
Postfach 330440
Bremen D-28359
Germany

Phone: +49-421-218-63921
Fax: +49-421-218-7000
Email: [email-masked]

Erik Nordmark
Sun Microsystems
17 Network Circle
Menlo Park, California 94025
USA

Phone:
Email: [email-masked]

Shelby, et al. Expires August 5, 2010 [Page 46]

Html markup produced by rfcmarkup 1.86, available from
http://tools.ietf.org/tools/rfcmarkup/

---

From: Zach Shelby <[email-masked]>
Date: Mon, 15 Feb 2010 12:28:58 +0200

Robert,

Thanks for all the comments, very helpful. I am not sure I could see all of them though with the HTML embedded in your mail. Could you send me that again directly as an attachment? Thanks. See some comments below based on what I could see:

On Feb 10, 2010, at 0:53 , Robert Cragie wrote:

> Hi Zach,
> 
> I have been through the document and made some corrections (in yellow) and some comments (in cyan) - see attachment.
> 
> 	• Inconsistent terminology. Bar the actual definitions, the terms, 'host', 'node', 'router' and 'Edge Router' should be used throughout, not a 'LoWPAN' variant of them.

Yep, will fix.

> 	• Some hangovers re. whiteboard and Extended LoWPAN

Thanks for catching those.

> 	• DAD not covered - as mentioned below

Correct, how you do DAD is basically out of scope right now in the draft. The hard part is actually the text defining *when* you SHOULD or MUST perform DAD... Let's get back to this when I see your full comments. 

> 	• Propagation of RS/RA not covered

Hmmm.. It is covered in Section 5.7 with regard to Context. Maybe a new section in Chapter 7 could be added to deal with this more explicitly? 

> 	• Hints at relaying NR/NC but not covered

Right. This would be used by a separate Extended LoWPAN draft. This draft just needs to define the relay code and fields in NR/NC. Maybe a mention of why that code is there could help?

> 	• Assumption that IID will use EUI-64 whereas it could be formed from alternate link-layer address.

From Section 5.1:

"  A LoWPAN node forms a 64-bit Interface Identifier (IID) as specified in 
Section 6 of [RFC4944]. This may be based on the EUI-64 identifier, an assigned 16-bit short address, or any other appropriate MAC address."

Isn't this OK? 

Cheers,
Zach

> http://www.gridmerge.com
>> I have been through the document and made some corrections (in yellow) and some comments (in cyan) - see attachment.
>> 
>> 	• Inconsistent terminology. Bar the actual definitions, the terms, 'host', 'node', 'router' and 'Edge Router' should be used throughout, not a 'LoWPAN' variant of them.
>> 	• Some hangovers re. whiteboard and Extended LoWPAN
>> 	• DAD not covered - as mentioned below
>> 	• Propagation of RS/RA not covered
>> 	• Hints at relaying NS/NC but not covered
>> 	• Assumption that IID will use EUI-64 whereas it could be formed from alternate link-layer address.
>> Robert 
>> http://www.gridmerge.com
>>>> To: 
>>>> [email-masked]
>>>> Cc: 
>>>> [email-masked],[email-masked],[email-masked],[email-masked],[email-masked]
>>>> 

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

---

From: Robert Cragie <[email-masked]>
Date: Mon, 15 Feb 2010 17:23:00 +0000

Hi Zach,

Comments inline, bracketed by <RCC></RCC>

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

> Hmmm.. It is covered in Section 5.7 with regard to Context. Maybe a new section in Chapter 7 could be added to deal with this more explicitly? 
<RCC>
With regard to RS, this can only apply on on-link routers as it is 
indistinguishable from the RFC4861 RS. Therefore there is no guarantee 
that an on-link router will have valid information disseminated to it. I 
guess the V flag indicates this to some extent but there does seem to be 
some implicit assumption that the correct LoWPAN information will 
percolate to the edges somehow.

With regard to RA, It is implicitly covered to some extent by the 
content of 6IO and 6SO and how that is disseminated from the Edge Router 
out into the LoWPAN but the synchronisation mechanism doesn't seem very 
clear. There is no explicit section on processing RAs that contain 
6IO/6SO. Maybe it's not strictly necessary but I think there may be some 
gaps from a specification point of view.
</RCC>
> Right. This would be used by a separate Extended LoWPAN draft. This draft just needs to define the relay code and fields in NR/NC. Maybe a mention of why that code is there could help?
<RCC>Is this just in extended LoWPANs? In 07 draft, NC would be relayed 
to the Edge Router and fundamentally made sense in conjunction with the 
Whiteboard for DAD. Now it only goes to an on-link router, so I guess I 
don't quite see the point of it anymore unless some specific DAD 
mechanism is described.</RCC>
> Section 6 of [RFC4944]. This may be based on the EUI-64 identifier, an assigned 16-bit short address, or any other appropriate MAC address."
<RCC>There are references throughout which suggest the IID is only 
formed from the EUI-64. This gives subsequent addresses formed from it 
different properties wrt. optimism of uniqueness than an IID using 
16-bit  short addresses, say, it its formation.</RCC>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 17 Feb 2010 18:33:20 +0100

A side note on this draft.  First - please don't overeact, I know, I
should discuss this on tlp-interest - ok, I will.

I wanted to publicly let the group know that I don't agree with the
conditions in the preamble (boilerplate) of this draft.

In the past I may have commented technically on this draft.

Right now I must say I don't agree with its licensing.

That's all, thanks for ignoring this message.  I just want it to be here
if any use for later.

Yours,

Alex
(I am trying to do the same about all drafts I've been commented on
  recently because I just discovered the new IETF Trust licensing
  scheme in the boilerplate.)

Le 01/02/2010 23:17, Zach Shelby a écrit :
> Hi everyone,
>
> Thanks to an active discussion among the ND authors, and a bunch of
> helpful reviews (thanks Richard, Anders and Colin), I finally managed
> to post 6lowpan-nd-08, in its new slim form (think biggest loser).
> After Hiroshima we reached good WG consensus to split the ND work
> into the basic mechanism (which is now this document) and a separate
> Extended LoWPAN draft (to be started), furthermore we agreed to deal
> with the DAD issue. This document hopefully moves us very close to
> that goal. This also includes the new RS feature suggested by
> Anders.
>
> As always with major changes (this needed lots of hacking and major
> editing), there are surely tons of bugs and loose-ends left. Help to
>  find those appreciated.
>
> Changes from -07 to -08:
>
> The major open issue we have is how to develop the DAD text in
> Section 5.3 in such a way that it works for most people, yet produces
> reliable and safe LoWPANs, and is yet acceptable to the IPv6 crowd
> and especially the IESG ;-) We are trying to find a balance to keep
> the WG happy, yet having a chance to actually become an RFC....
>
> It would also be nice to reduce the complexity of NR/NC and
> especially 6AO message processing. Writing the spec, I am at least
> not totally happy with the amount of explaining needed.... Is there a
> sleeker way to deal with the addresses?
>
> Zach
>
> Begin forwarded message:
>
>> From: IETF I-D Submission Tool<[email-masked]> Date:
>> February 1, 2010 23:59:40 GMT+02:00 To: [email-masked] Cc:
>>
>>
>> A new version of I-D, draft-ietf-6lowpan-nd-08.txt has been
>> successfuly submitted by Zach Shelby and posted to the IETF
>> repository.
>>
>> Filename:	 draft-ietf-6lowpan-nd Revision:	 08 Title:		 6LoWPAN
>> Neighbor Discovery Creation_date:	 2010-02-01 WG ID:		 6lowpan
>> Number_of_pages: 46
>>
>> Abstract: This document specifies a new Neighbor Discovery
>> mechanism suitable for LoWPANs.  The 6LoWPAN format allows IPv6 to
>>  be used over energy and bandwidth constrained wireless networks
>> often making use of multihop topologies.  However, the use of
>> classic IPv6 Neighbor Discovery with 6LoWPAN has several problems.
>>  Classic Neighbor Discovery was not designed for non-transitive
>> wireless links, and the traditional IPv6 link concept and heavy use
>> of multicast makes it unpractical.  This document specifies a
>> simple Neighbor Discovery mechanism both sufficient yet minimal for
>> LoWPAN operation.
>>
>>
>>
>> The IETF Secretariat.
>>
>>
>