[Docs] [txt|pdf|xml] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-shelby-6lowpan-nd) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 RFC 6775

6lowpan Working Group                                     Z. Shelby, Ed.
Internet-Draft                                                 Sensinode
Intended status: Standards Track                              P. Thubert
Expires: November 29, 2009                                         Cisco
                                                                  J. Hui
                                                               Arch Rock
                                                          S. Chakrabarti
                                                             IP Infusion
                                                             E. Nordmark
                                                                     Sun
                                                            May 28, 2009


                     Neighbor Discovery for 6LoWPAN
                        draft-ietf-6lowpan-nd-03

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.

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

   This Internet-Draft will expire on November 29, 2009.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights



Shelby, et al.          Expires November 29, 2009               [Page 1]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


   and restrictions with respect to this document.

Abstract

   This document specifies Neighbor Discovery optimized for 6LoWPAN.
   The 6LoWPAN format allows IPv6 to be used over energy and bandwidth
   constrained wireless networks often making use of multihop
   topologies.  However, the use of standard IPv6 Neighbor Discovery
   with 6LoWPAN has several problems.  Standard Neighbor Discovery was
   not designed for non-transitive wireless links, and the standard IPv6
   link concept and heavy use of multicast makes it inefficient.  This
   document specifies a new ND mechanism allowing for the efficient
   detection of duplicate addresses over entire LoWPANs while avoiding
   or simplifying other ND operations.  In addition it specifies context
   dissemination for use with router advertisements, claim and defend
   address generation, and the support of Extended LoWPANs over backbone
   links.


































Shelby, et al.          Expires November 29, 2009               [Page 2]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.1.  Goals & Assumptions  . . . . . . . . . . . . . . . . . . .  6
     1.2.  Why not standard IPv6 ND?  . . . . . . . . . . . . . . . .  7
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  8
     2.1.  6LoWPAN Terminology  . . . . . . . . . . . . . . . . . . .  8
     2.2.  ND Terminology . . . . . . . . . . . . . . . . . . . . . . 10
   3.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . . 13
     3.1.  Topology . . . . . . . . . . . . . . . . . . . . . . . . . 15
     3.2.  Links  . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     3.3.  Bootstrapping  . . . . . . . . . . . . . . . . . . . . . . 15
     3.4.  Basic operation  . . . . . . . . . . . . . . . . . . . . . 17
     3.5.  Optional features  . . . . . . . . . . . . . . . . . . . . 17
   4.  6LoWPAN ND Messages  . . . . . . . . . . . . . . . . . . . . . 18
     4.1.  Node Registration/Confirmation Message . . . . . . . . . . 19
     4.2.  Router Solicitation Message  . . . . . . . . . . . . . . . 21
     4.3.  Router Advertisement Message . . . . . . . . . . . . . . . 21
     4.4.  NS/NA Messages . . . . . . . . . . . . . . . . . . . . . . 22
     4.5.  6LoWPAN ND Message Options . . . . . . . . . . . . . . . . 23
       4.5.1.  Address Option . . . . . . . . . . . . . . . . . . . . 23
       4.5.2.  6LoWPAN Prefix Information Option  . . . . . . . . . . 24
       4.5.3.  6LoWPAN Prefix Summary Option  . . . . . . . . . . . . 26
       4.5.4.  Owner Interface Identifier Option  . . . . . . . . . . 27
   5.  LoWPAN Node Specification  . . . . . . . . . . . . . . . . . . 27
     5.1.  Conceptual structures and variables  . . . . . . . . . . . 28
     5.2.  Interface initialization . . . . . . . . . . . . . . . . . 29
     5.3.  Registration process . . . . . . . . . . . . . . . . . . . 30
     5.4.  Next-hop determination . . . . . . . . . . . . . . . . . . 31
     5.5.  Destination unreachability detection . . . . . . . . . . . 32
   6.  LoWPAN Router Specification  . . . . . . . . . . . . . . . . . 32
     6.1.  Router Configuration Variables . . . . . . . . . . . . . . 33
     6.2.  Becoming an Advertising Interface  . . . . . . . . . . . . 33
     6.3.  Router Advertisement Message Content . . . . . . . . . . . 33
     6.4.  Sending Unsolicited Router Advertisements  . . . . . . . . 34
     6.5.  Ceasing To Be an Advertising Interface . . . . . . . . . . 34
     6.6.  Processing Router Solicitations  . . . . . . . . . . . . . 34
     6.7.  Relaying a Node Registration Message . . . . . . . . . . . 34
     6.8.  Relaying a Node Confirmation Message . . . . . . . . . . . 35
   7.  LoWPAN Edge Router Specification . . . . . . . . . . . . . . . 35
     7.1.  The Whiteboard . . . . . . . . . . . . . . . . . . . . . . 36
     7.2.  Simple LoWPAN  . . . . . . . . . . . . . . . . . . . . . . 37
     7.3.  Extended LoWPAN  . . . . . . . . . . . . . . . . . . . . . 37
     7.4.  Registration process . . . . . . . . . . . . . . . . . . . 38
     7.5.  Forwarding packets between a LoWPAN and an IPv6
           infrastructure . . . . . . . . . . . . . . . . . . . . . . 40
     7.6.  Address collision detection and resolution . . . . . . . . 40
     7.7.  Duplicate OII detection  . . . . . . . . . . . . . . . . . 43



Shelby, et al.          Expires November 29, 2009               [Page 3]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


     7.8.  Fault tolerance  . . . . . . . . . . . . . . . . . . . . . 44
   8.  Ad-hoc LoWPAN Operation  . . . . . . . . . . . . . . . . . . . 44
   9.  Message Examples . . . . . . . . . . . . . . . . . . . . . . . 45
     9.1.  Basic NR/NC message exchange . . . . . . . . . . . . . . . 45
     9.2.  Relaying an NR message . . . . . . . . . . . . . . . . . . 46
     9.3.  Router advertisement . . . . . . . . . . . . . . . . . . . 47
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 48
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 48
   12. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 49
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 49
     13.2. Informative References . . . . . . . . . . . . . . . . . . 50
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51






































Shelby, et al.          Expires November 29, 2009               [Page 4]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


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 with the
   help of an adaptation header which comes before the IP header.  A
   link in 6LoWPAN is characterized as lossy, low-power, low bit-rate,
   short range, with many nodes saving energy with long deep sleep
   periods.  Multicast as used in IPv6 Neighbor Discovery [RFC4861] is
   not desirable in such a wireless low-power, lossy network.

   Moreover, LoWPAN links are non-symmetric and transient in nature;
   they are not always considered to be in a fixed network nor are they
   bounded by our standard definition of a wired-link.  A LoWPAN is
   potentially composed of a potentially large amount of overlapping
   radio ranges, eventually federated by a backbone or a backhaul link.
   Although a given radio range has broadcast capabilities, the
   aggregation of these is a complex Non-Broadcast MultiAccess (NBMA,
   [RFC2491]) structure with no multicast capabilities.  Link-local
   scope is in reality defined by reachability and radio strength.  The
   standard IPv6 Neighbor Discovery [RFC4861] control messages, the use
   of multicast and their default frequency also attribute to
   unnecessary waste of energy in LoWPANs.

   Neighbor discovery for 6LoWPAN provides for basic bootstrapping and
   network operation, along with advanced features such as claim and
   defend address generation and Extended LoWPANs over backbone links,
   while avoiding the use of multicast flooding.  The solution supports
   the use of both link-layer or LoWPAN mesh (Mesh Under) and IP routing
   (Route Over) multihop solutions.  Unlike standard IPv6 ND [RFC4861],
   this document specifically takes the characteristics of low-power,
   lossy wireless links into account.

   This specification introduces a registration mechanism over the radio
   edge of the NBMA network and proxy operation over the federating
   backbone or backhaul.  That registration mechanism provides a service
   somewhat similar to the Multicast Address Resolution Server (MARS)
   [RFC2022] for a limited purpose, and in a lot simpler and less
   generic fashion.  For those link scope multicasts that could not be
   avoided, such as for Router Advertisements, optimizations like the
   Trickle algorithm may be used to optimize the dissemination of the
   information in the Low Power network.

   The concept of a LoWPAN Whiteboard located at Edge Routers (ERs) is
   introduced, which allows for duplicate address detection and claim
   and defend addressing for the entire LoWPAN.  Address resolution is
   not needed, and thus makes LoWPAN operation power efficient and to
   reduces LoWPAN Node complexity.  A new registration/confirmation
   message sequence is specified, allowing nodes to register their IPv6



Shelby, et al.          Expires November 29, 2009               [Page 5]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


   addresses with an Edge Router.

   The Whiteboard makes use of soft bindings, thus nodes send periodic
   registration messages in order to maintain their bindings.  Changes
   in network topology, and mobility between ERs and LoWPANs are
   supported.  The dissemination of RA information between LoWPAN
   Routers in multihop IP LoWPANs is also discussed.

   This document also specifies the seamless integration of an Extended
   LoWPAN with multiple edge routers on a shared backbone link (e.g.
   Ethernet) to form a single IPv6 subnet.  This allows nodes to keep
   the same IPv6 address throughout a large network, and allows for easy
   communications with nodes over the backbone link and with other IPv6
   hosts.

   The document defines two new ICMPv6 messages: Node Registration and
   Node Confirmation.  In addition a new 6LOWPAN_ER anycast address is
   introduced, used by LoWPAN Routers in order to relay a registration
   message to any Edge Router.

1.1.  Goals & Assumptions

   This document has the following main goals and makes several
   assumptions.

   Goals:

      o Enable ND operations over an entire LoWPAN, even with non-
      transitive links and over multihop IP hops.

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

      o Disseminate context information throughout the LoWPAN.

      o Minimize the complexity of LoWPAN Nodes.

      o Interconnect LoWPANs with backbone links seamlessly.

      o Provide a mechanism for claim and defend addressing.

   Assumptions:

      o Link layer technology may be e.g.  IEEE 802.15.4 as in
      [RFC4944], or any other suitable link-layer.





Shelby, et al.          Expires November 29, 2009               [Page 6]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


      o Link-local IPv6 addresses are derived from a unique identifier
      (e.g.  EUI-64).

      o There is a direct mapping between the IPv6 address IID and the
      link-layer address (as in e.g.  [RFC4944]), thus address
      resolution is not required.

      o A subnet includes all the LoWPAN Nodes, Edge Router(s) and
      optionally their backbone link sharing the same IPv6 prefix.

1.2.  Why not standard 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
   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



Shelby, et al.          Expires November 29, 2009               [Page 7]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


   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 standard
   Neighbor Discovery is not suitable as it is and a 6LoWPAN-specific ND
   definition would be useful and efficient for the wide deployment of
   IPv6 over low-powered wireless networks of embedded devices.


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] and "Transmission of IPv6 Packets over IEEE
   802.15.4 Networks" [RFC4944].

   Readers would benefit from reading "Mobility Support in IPv6"
   [RFC3775], "Neighbor Discovery Proxies (ND Proxy)" [RFC4389] and
   "Optimistic Duplicate Address Detection" [RFC4429] prior to this
   specification for a clear understanding of state of the art in ND
   proxy and binding.

   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 hop limit is
      decremented.  In the LoWPAN context, IP routing is performed by
      LoWPAN Routers on a single interface within the same link to
      overcome the non-transient nature of the link.  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.






Shelby, et al.          Expires November 29, 2009               [Page 8]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


   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 non-symmetric (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.  Furthermore complex Non-broadcast
      Multi-Access (NBMA) behaviour is exhibited as these links do not
      support native multicast, and broadcast reaches only a subset of
      nodes on the link.  Such a wireless link may consist of multiple
      overlapping link-local scopes.  Link-local scope multicast on such
      a link is realized as a broadcast.

      The use of link-layer mesh technology (see Mesh Under) emulates
      transitivity across the link but still has problems with non-
      symmetricity.  Multicast on a link-layer mesh is usually
      implemented as a broadcast flood.

   Link-local

      Standard IPv6 link-local scope as defined in [RFC4291] and
      [RFC4861] is supported by the 6LoWPAN link and subnet model.
      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.

   On-link

      The set of nodes reachable using link-local scope are said to be
      on-link.  All other destinations are assumed to be off-link.

   LoWPAN Host

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

   LoWPAN Node







Shelby, et al.          Expires November 29, 2009               [Page 9]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


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

   LoWPAN Router

      A node that forwards datagrams between arbitrary source-
      destination pairs using a single 6LoWPAN interface performing IP
      routing on that interface.

   Mesh Under

      A term referring to a configuration where the link-local scope is
      defined by the boundaries of the LoWPAN 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
      behaviour.

   Route Over

      A term referring to a configuration where the link is non-
      transitive and the link-local scope reaches only a subset of the
      LoWPAN nodes.  IP routing is performed by LoWPAN Routers to
      overcome the non-transitive nature of the link.  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

      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 LoWPAN Nodes and Edge Routers sharing
      the same subnet prefix.  Due to the non-transitive nature of
      LoWPAN links, IP routing may be used on the link to provide
      transitivity.  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:






Shelby, et al.          Expires November 29, 2009              [Page 10]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


   Ad-hoc LoWPAN

      An isolated LoWPAN, not connected to any other IP networks.  Ad-
      Hoc LoWPANs make use of Unique Local 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.

   Binding

      The association of the LoWPAN node IPv6 address and Owner
      Interface ID with associated Whiteboard and ND states including
      the remaining lifetime of that association.

   Extended LoWPAN

      This is the aggregation of multiple LoWPANs as defined in
      [RFC4919] interconnected by a backbone link via Edge Routers and
      forming a single subnet, shown in Figure 2.

   LoWPAN Edge Router

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

   Simple LoWPAN

      A Simple LoWPAN consists of a single Edge Router and the set of
      LoWPAN nodes on the same LoWPAN Subnet, shown in Figure 1.  If the
      Edge Router has a Whiteboard, all nodes belonging to its LoWPAN
      have a whiteboard entry.

   Registration

      The process during which a LoWPAN node sends a Node Registration
      ND message to an Edge Router causing a binding for the LoWPAN node
      to be registered.

   Whiteboard







Shelby, et al.          Expires November 29, 2009              [Page 11]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


      A conceptual data structure similar to a MIPv6 binding cache which
      may be supported by Edge Routers.  The Whiteboard is used for
      performing DAD and NUD across the entire LoWPAN.  The Whiteboard
      contains bindings for LoWPAN nodes consisting of Owner Interface
      Identifier, IPv6 address, timeout, along with Transaction ID
      history.



          Infrastructure Cloud
                   |
                   |
                   |
                +-----+
                |     | Edge
                |     | router
                +-----+
                  o  o
               o   o    o
             o  o   o  o o        o: LoWPAN Node
              o   o  o  o
                o   o o

             Simple LoWPAN


                    Figure 1: A simple LoWPAN topology
























Shelby, et al.          Expires November 29, 2009              [Page 12]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


         Infrastucture Cloud
                  |
                  |
               +-----+                 +-----+
               |     | Router          |     | Host
               |     |                 |     |
               +-----+                 +-----+
                  |                       |
                  |     Backbone link     |
            +--------------------+------------------+
            |                    |                  |
         +-----+             +-----+             +-----+
         |     | Edge        |     | Edge        |     | Edge
         |     | Router      |     | Router      |     | Router
         +-----+             +-----+             +-----+
            o         o       o   o  o      o        o o
        o o   o  o  o  o  o o   o  o  o  o  o   o  o  o  o
       o  o o  o o   o    o   o  o  o  o     o   o  o  o o
       o   o  o  o     o    o    o  o     o      o  o   o
         o   o o     o          o  o      o    o       o

                         Extended LoWPAN

      Figure 2: Extended LoWPAN with a backbone link and edge routers


3.  Protocol Overview

   Neighbor discovery for 6LoWPAN provides additions and optimizations
   to IPv6 ND [RFC4861] specifically supporting 6LoWPAN.  Basic Neighbor
   Discovery mechanisms are optimized, avoiding the use of multicast
   flooding and minimizing link-local multicast (broadcast) frequency.
   The detection of duplicate addresses is performed across the entire
   LoWPAN.  This is achieved using a Whiteboard located on the Edge
   Routers of the LoWPAN network.  An Extended LoWPAN topology over a
   shared backbone link is optionally supported.

   The following list summarizes ND for 6LoWPAN operations and the
   differences with [RFC4861]:

   Router Discovery:  As in [RFC4861] with the addition of new 6LoWPAN
      specific options to Router Advertisements.

   Prefix Discovery:  The discovery of 6LoWPAN prefixes with context
      identifiers.  Destinations are assumed to be off-link unless
      explicitly known to be a neighbor.





Shelby, et al.          Expires November 29, 2009              [Page 13]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


   Address Autoconfiguration:  Stateless address autoconfiguration is
      supported as in [RFC4861].  Additionally a claim and defend
      address generation method is supported using the Whiteboard.

   Address Resolution:  Not performed as there is a direct mapping
      between the IID and the link-layer address.

   Next-hop Determination:  Next-hop determination is performed
      considering LoWPAN routing and link specifics, and is simplified
      compared to [RFC4861].

   Neighbor Unreachability Detection:  An algorithm is specified that
      makes use of ND messages and link-layer reachability information,
      without the use of NS/NA exchanges.  In addition, ICMP destination
      unreachable messages are supported.

   Duplicate Address Detection:  The detection of duplicate addresses is
      performed across the entire LoWPAN using a lookup on the
      Whiteboard using a new registration method.  Edge routers in an
      Extended LoWPAN formation perform standard [RFC4861] DAD on the
      backbone link.

   Redirect:  Redirect messages are not required.

   Node Registration (new):  Method in which nodes in the LoWPAN
      register with Edge Routers, creating Whiteboard state about all
      IPv6 addresses in the LoWPAN.

   Whiteboard Conflict Resolution (new):  This method is used in the
      Extended LoWPAN topology, using the backbone link to resolve
      conflicts between the Whiteboards of Edge Routers.

   This specification makes use of RS/RA message exchanges along with
   standard NS/NA on the backbone link.  The use of NS/NA message
   exchanges in the LoWPAN are not required by this document.  In
   addition ND for 6LoWPAN defines two new ICMP packet types:

   Node Registration:  Sent by a node to an Edge Router to register a
      binding for an IPv6 address in the Whiteboard.  Is relayed by an
      intermediate router if there is no Edge Router on-link.

   Node Confirmation:  The reponse sent by an Edge Router or router back
      to the registering node.  May be relayed by an intermediate
      router.







Shelby, et al.          Expires November 29, 2009              [Page 14]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


3.1.  Topology

   ND for 6LoWPAN is designed to work with a wide variety of 6LoWPAN
   topologies, including isolated Ad-hoc LoWPANs, Simple LoWPANs and
   Extended LoWPANs.  A Simple LoWPAN topology is assumed by default in
   the text.  The special case of Ad-hoc LoWPAN operation is described
   in Section 8.  Edge Router operation and Extended LoWPAN
   functionality are described in Section 7.  Edge Routers which will
   operate only in Simple LoWPANs do not need to support Extended LoWPAN
   functionality, such as Edge Routers which do not have a backbone link
   (but instead e.g. an ADSL interface).

3.2.  Links

   The use of IEEE 802.15.4 or any other similar link-layer technology
   which exhibits the characteristics defined for a 6LoWPAN link such as
   low data-rates, packet loss, limited range, asymmetricity and long
   sleep-cycles.  This specification is able to deal with the non-
   symmetric, non-transitive nature of these links.

   ND for 6LoWPAN is agnostic to the use of link-layer mesh or [RFC4944]
   mesh techniques, which alleviate the otherwise non-transitive nature
   of wireless links.  This so-called Mesh Under topology thus makes the
   entire link to appear to the IP layer as having a link-local scope
   covering all the 6LoWPAN interfaces in the LoWPAN.  This kind of
   LoWPAN is made up of hosts and Edge Routers.  This link still
   exhibits lossy, low-rate, asymmetric behaviour 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.  LoWPAN
   Routers are used in the LoWPAN to provide routing between all nodes
   in the LoWPAN.  LoWPAN Router operations are specified in Section 6.
   Link-local scope includes the neighbors of each node within symmetric
   wireless range.  Mesh Under and Route Over techniques are not
   mutually exclusive, and it is possible to combine IP routing and mesh
   link-layers within a LoWPAN.

3.3.  Bootstrapping

   1.  A Host first performs stateless autoconfiguration of its link-
   local unicast address for each LoWPAN interface from its EUI-64 as in
   [RFC4944].  When a LoWPAN Node wants to join a LoWPAN, it does so by
   listening for Route Advertisements from Edge Routers or LoWPAN
   Routers, or by broadcasting a Router Solicitation (RS) and receiving
   RA responses from on-link routers (see Figure 3).  If a valid prefix
   is advertised in the RA, the host will also form an optimistic global
   unique address with stateless address autoconfiguration.  At this



Shelby, et al.          Expires November 29, 2009              [Page 15]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


   point the node has also chosen one or more default routers.

   2.  Next the node will attempt to perform initial registration with
   an Edge Router.  As the node is not yet known in a routing algorithm,
   and its addresses are optimistic, initial registration is always
   performed with a link-local Edge Router or router by sending a
   unicast Node Registration (NR) message to it.  Registering directly
   with an Edge Router is of course preferred as shown in Figure 4 (the
   ER is differentiated by the Prf flag in its RA), although all LoWPAN
   Routers have the ability to relay NR/NC messages on behalf of a node
   as shown in Figure 5.

   These message exchanges are illustrated below.  The NR contains the
   addresses the node wants to register.  A node may request a short
   address to be generated on its behalf by including an Address Option
   with the A flag and an address of length 0 in the NR.

   3.  The Edge Router replies either directly with a Node Confirmation
   (NC), or through the relaying router.  Note that routers only exist
   in Route Over configurations, and in pure Mesh Under configurations
   nodes are always within link-local scope of an Edge Router.  This NC
   includes the set of addresses now confirmed to be bound to the
   Whiteboard of the ER.  The Host is now capable of using the LoWPAN
   fully, and the ER forwards on its behalf.


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


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



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


   Figure 4: Basic ND registration exchange when the Edge Router is on-



Shelby, et al.          Expires November 29, 2009              [Page 16]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


                                   link



   Node                 Router (ICMP relay)               Edge Router
    |                            |                             |
    |       ---- NR --->         |        ---- NR --->         |
    |                            |                             |
    |      <---- NC ----         |       <---- NC  ----        |
    |                            |                             |


   Figure 5: Registration exchange relayed by a router (no on-link ER),
                       the messages are ICMP relayed

3.4.  Basic operation

   The node may now send packets to any IPv6 address inside or outside
   the LoWPAN.  Destinations are assumed to be off-link unless known to
   be within link-local scope (valid entry in the neighbor cache).
   Address resolution is not performed with neighbors as in [RFC4861],
   but instead the IID part of the IPv6 address directly corresponds to
   a MAC address.  The support of NS/NA is optional for nodes.

   The Whiteboard address bindings and assignments are soft, and thus
   must be renewed periodically as indicated by the lifetime of the
   binding.  This is achieved by periodically sending a new NR to the
   ER.  If a host moves, or the network topology changes, and the
   current ER is no longer available, the host then starts the
   registration process with another ER.  If the host is still in the
   same Extended LoWPAN (same subnet prefix), its IPv6 addresses remain
   the same.  Claim and defend addresses generated by the Whiteboard
   must be remembered by the host and refreshed in order to keep the
   address.  If the host moves to a different LoWPAN (thus with a
   different subnet prefix), the bootstrapping process is initiated
   again.  See Section 5 for details on node operation.

   LoWPAN Routers periodically send RAs to their neighbors.  The Edge
   Router initiates the first RAs, and this information is included in
   the RAs of each router.  RA periods can be optimized to reduce
   signalling using a Trickle algorithm.  See Section 6 for detailed
   router operation.

3.5.  Optional features

   This documents specifies a method for forming Extended LoWPAN
   networks with multiple ERs on a backbone link.  This optional Edge
   Router feature allows for the detection of duplicate addresses across



Shelby, et al.          Expires November 29, 2009              [Page 17]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


   the entire Extended LoWPAN and backbone links, seen as a single
   subnet.  The method uniquely identifies the LoWPAN Host on the
   backbone, and overrides the claim on an address on behalf of a LoWPAN
   Host.  Thus a Host can keep the same address, and appears the same to
   other hosts on the backbone link, regardless of moving its binding
   from one ER to another.  See Section 7 for a description of Extended
   LoWPAN operation.  Extended LoWPAN operation does not require changes
   to node operation.

   Ad-hoc LoWPAN operation is also supported.  By configuring a router
   to implement Simple LoWPAN Edge Router functionality, and by
   generating a ULA prefix, an Ad-hoc LoWPAN can operate in an identical
   manner to a Simple LoWPAN.  Section 8 explains the operation of Ad-
   hoc LoWPANs.


4.  6LoWPAN ND Messages

   This section introduces message formats for all messages used in this
   document.  The new messages are all ICMPv6 messages and extend the
   capabilities of "The IPv6 Neighbor Discovery Protocol" [RFC4861].  In
   addition, new options for the ICMPv6 Router Advertisement message are
   defined.

   The following [RFC4861] are used with modifications as specificed in
   this section:

      Router Solicitation

      Router Advertisememt

      Neighbor Solicitation (Extended LoWPAN only)

      Neighbor Advertisement (Extended LoWPAN only)

   The following new ICMPv6 message types are defined:

      Node Registration

      Node Confirmation

   In addition, the following new ICMPv6 options are defined:

      Address Option

      6LoWPAN Prefix Information Option





Shelby, et al.          Expires November 29, 2009              [Page 18]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


      6LoWPAN Prefix Summary Option

      Owner Interface Identifier Option

4.1.  Node Registration/Confirmation Message

   The Node Registration (NR) and Node Confirmation (NC) messages are
   used by a node to register with an ER, and for the ER to confirm the
   binding.  Any option that is not recognized MUST be skipped silently.
   The Node Registration message is sent by the LoWPAN Node to the link-
   local unicast IPv6 address of an on-link Edge Router or LoWPAN
   Router.  NR/NC messages may be sent over multiple IP hops within the
   LoWPAN by relaying routers, thus received messages with a hop limit
   less than 255 MUST be accepted by LoWPAN Routers from senders with a
   source address in the same LoWPAN.  Relaying routers may also use the
   6LOWPAN_ER anycast address as the destination.

   When registering the first time (the node still has optimistic
   addresses) it sends an NR to the link-local unicast address of an on-
   link ER or LoWPAN Router.  The source address must be the IPv6
   unspecified address to comply with oDAD.

   Nodes send susequent NR messages to an on-link ER or router, however
   the IPv6 source address is then the link-local IPv6 address of the
   sender.  This same message format is also used for relayed NR/NC
   messages, with an alternative code that is set when the message has
   been relayed.  When relaying, a new message is created with an
   updated checksum, and a code is used to indicate relaying.  The hop
   limit is not decremented when relaying.

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

          Figure 6: Node Registration/Confirmation message format




Shelby, et al.          Expires November 29, 2009              [Page 19]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


   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 an
         on-link Edge Router or router when sent by a node.  The
         destination IPv6 address of an Edge Router or the 6LOWPAN_ER
         anycast address when sent by a relaying router.

      Hop Limit:  255

   ICMP Fields:

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

      Code:  0 indicates a message sent directly from the originating
         host. 1 indicates that the message has been relayed by a
         router.  Values 128-255 are reserved for error codes. 128 is
         sent in an NC response by a router to indicate that no ER is
         available. 129 is sent by a router or edge router to indicate
         that Whiteboard registration is not supported.

      Checksum:  The ICMP checksum.

      TID:  A unique Transaction ID assigned by the host and used to
         match replies.  A lollipop mechanism is used to increment the
         TID at each new message.  TID is set to 0 upon booting, and is
         incremented with each NR message.  After reaching 0xFFFF, the
         value loops to 16 (0x10) and is incremented from there.  Thus
         the values between 0-15 MUST only used after a boot or reboot.

      P: 1-bit Primary flag.  Set to indicate that the Edge Router is
         primary and MAY represent the node if used in a Extended
         LoWPAN.  If the flag is not set then the router MUST not
         represent the node on the backbone.  The flag is echoed in a
         confirmation.

      Status:  8-bit unsigned integer.  Values TBD. 0 means unqualified
         success.  Any value below 128 is a positive status that means
         that the binding was created or is being created
         optimistically.

      Lifetime:  32-bit unsigned integer.  The amount of time in units
         of seconds remaining before the binding of this owner interface
         identifier, and all associated address options and
         configuration options, MUST be considered expired.  A value of
         zero indicates that the Binding Cache entries for the



Shelby, et al.          Expires November 29, 2009              [Page 20]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


         registered owner interface identifier MUST be deleted.

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

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

   Possible Options:

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

      Configuration options:  Other configuration information requests
         and configuration settings may be carried in options of NR/NC
         messages.  Such options are not defined in this document.

      Source link-layer address:  This option SHOULD be added to the NC
         by the relaying router to indicate the identity of the ER for
         use by a host.  Format as defined in [RFC4861] and [RFC4944].

      Target link-layer address:  This option MAY be included by a node
         in an NR to indicate the preferred ER to be used by a relaying
         router.  Format as defined in [RFC4861] and [RFC4944].

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

4.2.  Router Solicitation Message

   The RS message format for 6LoWPAN is identical to the [RFC4861] RS
   message.  The following changes are made regarding the use of RS in
   LoWPANs.  If a node has only optimistic addresses, not yet confirmed
   by an Edge Router, then the IPv6 source address in the RS MUST be the
   IPv6 unspecified address.  The Source Link-Layer Address Option MUST
   NOT be included in the RS at any time, as the MAC address is
   implicitly known.  Instead the Owner Interface Identifier specified
   in this document MUST be included in the RS.

4.3.  Router Advertisement Message

   The RA message format for 6LoWPAN is identical to the [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.




Shelby, et al.          Expires November 29, 2009              [Page 21]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


   Updated Flag Definitions:

      M: Managed mode here refers to the availability of an Edge Router
         through this router, not DHCPv6 as in [RFC4861].  MUST be set
         to 1 by Edge Routers, and SHOULD be set to 1 by LoWPAN routers
         who are successfully registered with and have a route to an
         Edge Router.

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

   Possible Options:

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

      6LoWPAN Prefix Summary Option:  This option provides a sequence
         number associated with the current prefix options.  It allows
         the prefix options themselves to be sent only periodically in
         unsolicited RAs.

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

4.4.  NS/NA Messages

   NS/NA messages are also employed between ERs on the backbone link.
   For this use a unique identifier is required in the message as an
   option to uniquely identify a host's interface.  The standard NS/NA
   message is used in this document is as per [RFC4861] with the an
   additional Owner Interface Identifier Option defined in this
   document.  The Owner Interface Identifier is the same as that carried
   in NR/NC messages and associated with bindings.

   If NS/NA messages are sent on the LoWPAN link (which is not required
   by this specification), they do not carry link-layer address options,
   because of link non-transitivity and the Extended LoWPAN topologies
   do not preserve the MAC address.  For the same reason redirect is not
   supported.  Instead they MUST include the Owner Interface Identifier
   option to help resolve conflict.






Shelby, et al.          Expires November 29, 2009              [Page 22]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


4.5.  6LoWPAN ND Message Options

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

4.5.1.  Address Option

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

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


                      Figure 7: 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.  Values TBD. 0 means unqualified
      success.  Any value below 128 is a positive status that means that
      the binding for this address was created or is being created
      optimistically.  Only used in a confirmation.

   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
      assigned when A is set.  Otherwise must be 0.






Shelby, et al.          Expires November 29, 2009              [Page 23]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


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

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

      0: Prefix is carried inline.

      1: Prefix compressed and link-local (fe80::) is assumed.

      2: Prefix compressed and the default prefix (CID=0) is assumed.

      3-15:  Reserved.

   S: 4-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 and is derived from the link-layer short
         address as defined in RFC 4944.

      3: Suffix is a 6LoWPAN 16-bit short address as defined in RFC 4944
         or as appropriate for the link-layer of the LoWPAN.

      4-15:  Reserved.

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

4.5.2.  6LoWPAN Prefix 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 November 29, 2009              [Page 24]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Length    | Prefix Length |L|A|  CID  | R |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Valid Lifetime                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                            Prefix                             .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 8: 6LoWPAN Prefix 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.

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

   L: 1-bit on-link flag.  This flag MUST be unset for Route Over
      LoWPANs and Extended LoWPANs, and MAY be set for Mesh Under Simple
      LoWPANs.

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

   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.  CID = 0 identified the default prefix for
      the LoWPAN.

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







Shelby, et al.          Expires November 29, 2009              [Page 25]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


   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.

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

4.5.3.  6LoWPAN Prefix 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 9: 6LoWPAN Prefix 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 ER through this router.  The metric
      SHOULD be derived in a well-defined way from the routing protocol
      used in the LoWPAN (possibly by structuring the 16 bits available
      e.g. into a major and a minor metric), and has a mid-range default
      value of 0x8000.  Edge Routers most likely set this field to 0.  A
      host SHOULD take this metric into account when choosing default
      routers by making a scalar comparison, preferring routers with
      numerically lower ER Metric values.





Shelby, et al.          Expires November 29, 2009              [Page 26]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


   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.5.4.  Owner Interface Identifier Option

   This option is for use with standard NS and NA messages between ERs
   over a backbone link.  By using this option, the binding in question
   can be uniquely identified and matched with the whiteboard entries of
   each ER.

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

               Figure 10: Owner Interface Identifier Option

   Type:  TBD6

   Length:  2

   TID:  A unique Transaction ID assigned by the host in the associated
      NR and used to match NC replies.

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

   Owner Interface Identifier:  A globally unique identifier for the
      host's interface associated with the binding for the NS/NA message
      in question.  This is typically the EUI-64 of the interface.


5.  LoWPAN Node Specification

   This section specifies LoWPAN node operations, and explains the
   differences to [RFC4861] node operation, while specifying the new
   operations.  Instead of relying on multicast ND messages for DAD and
   neighbor unreachability detection, LoWPAN Nodes send unicast messages



Shelby, et al.          Expires November 29, 2009              [Page 27]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


   to an Edge Router in the LoWPAN which keeps a Whiteboard of all bound
   addresses from nodes attached to that ER.  Thus these functions are
   performed across the entire LoWPAN using the Whiteboard, which allows
   ND for 6LoWPAN to operate over asymmetric, non-transitive links and
   with sleeping nodes.  Node complexity and energy consumption are
   reduced as address resolution and the support of redirect are not
   required, ND traffic is reduced and nodes do not need to answer NS
   messages.  In an Extended LoWPAN topology, ND functions are performed
   across the entire Extended LoWPAN, and a node may change its point of
   attachment within the LoWPAN without changing its IPv6 addresses.
   Extended LoWPAN operation is transparent for nodes.

5.1.  Conceptual structures and variables

   LoWPAN Nodes make use of the same conceptual data structures as
   defined in [RFC4861] Section 5.1, with the following differences:

   Neighbor Cache  - The neighbor unreachability detection entry is not
      kept in this cache, but instead MAY be used with destination cache
      entries.

   Destination Cache  - The destination cache MAY include a neighbor
      unreachability detection entry, for destinations within the same
      LoWPAN.

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

   Default Router List  - As in [RFC4861], with the addition that Edge
      Routers are also be tracked by entries in this list.

   Edge Router List  - This new structure contains the list of Edge
      Routers the node is registered with an associated timeout and
      primary flag.  This list may be combined with the Default Router
      List.  Off-link ERs can be included in this list but this is not
      required as they can be reached using the 6LOWPAN_ER anycast
      address through a default router.

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




Shelby, et al.          Expires November 29, 2009              [Page 28]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


   The neighbor discovery variables defined in [RFC4861] Section 6.3.2
   are valid for 6LoWPAN for ND, and default values are overridden by
   information in Router Advertisements.  The LinkMTU variable is always
   1280 octets for 6LoWPAN.  ReachableTime and RetransTimer variables
   are used for neighbor unreachability detection using the Whiteboard.

5.2.  Interface initialization

   All nodes are required to autoconfigure at least one address, a link-
   local address, which is derived from the IEEE 64-bit extended MAC
   address that is globally unique to the interface as in [RFC4944].  As
   a result, knowledge of the 64-bit address of another LoWPAN Node is
   enough to derive its link-local address and reach it if on the same
   link.  Another consequence is that the link-local address is
   presumably unique on the Extended LoWPAN, which enables the use of
   Optimistic Duplicate Address Detection (oDAD) [RFC4429] over the
   backbone link and the LoWPAN.  The address SHOULD be created as
   optimistic before it has been confirmed by an Edge Router.  Due to
   the way 6LoWPAN networks perform address compression [RFC4944] nodes
   within a LoWPAN use addresses in a homogeneous way and the unicast
   IPv6 address IID resolves directly to a corresponding link-layer
   address.  As a result, address resolution within the LoWPAN is not
   required.

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

   Nodes MAY learn the address of Edge Routers or 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 SLLA Option, but instead MUST include the OII Option.
   If the sender of the RS has only optimistic addresses, it MUST not
   use them as the IPv6 source address for the RS, but instead uses the
   IPv6 unspecified address.  This procedure is to comply with the use
   of optimistic addresses as per oDAD [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 is derived using stateless address autoconfiguration.
   This address is marked optimistic until confirmed by the ER.  If the
   LoWPAN is operating in ad-hoc mode, then the prefix is a Unique Local
   IPv6 Address (ULA) prefix [RFC4193] as specified in Section 8.





Shelby, et al.          Expires November 29, 2009              [Page 29]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


5.3.  Registration process

   The binding process is very similar to that of a MIPv6 mobile node,
   though the messages used are new Neighbor Discovery ICMP messages.  A
   LoWPAN Node address is tentative or optimistic as long as the binding
   is not confirmed by the ER.

   The LoWPAN Node uses unicast Node Registrations with on-link ERs or
   LoWPAN Routers to perform the binding.  The destination address is
   the link-local unicast address of an on-link ER or LoWPAN Router.
   While a nodes addresses are still optimistic (first registration in a
   LoWPAN), the IPv6 unspecified address must be used as the source.
   Registration SHOULD be preferred with on-link ERs rather than LoWPAN
   Routers if available.  The Preference Flag of the RA is used to
   differentiate between ERs (Prf=01) and LoWPAN Routers (Prf=00).  The
   M Flag of the RA indicates if an ER is available through a neighbor
   LoWPAN Router.  If the M Flag is unset, that router SHOULD NOT be
   used for registration.  Furthermore the ER Metric in the 6LoWPAN
   Prefix Summary Option SHOULD be used to choose a router to use for
   registration.

   A unique Owner Interface Indentifier is included in the Node
   Registration so the binding can be identified throughout the LoWPAN.
   This is usually the EUI-64 identifier of the interface.  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 from the ER by setting the 'A' flag in an Address Option
   during registration.  This is useful for receiving a unique short
   link-layer address, and works in a claim and defend fashion.  Address
   generation using this NR/NC mechanism is stateless.  Although the
   address is generated by the ER and checked for uniqueness across the
   LoWPAN, it is just like any other address binding in the whiteboard
   of the ER after assignment.  Thus in order to keep using this address
   the host must keep refreshing the address binding, including when
   moving to another ER in the same LoWPAN.

   A unique Transaction ID (TID) is included by the host in the NR
   message and used to match replies.  A lollipop mechanism is used.
   TID is set to 0 upon booting, and is incremented with each NR
   message.  After reaching 0xFFFF, the value loops to 16 (0x10) and is
   incremented from there.  Thus the values between 0-15 MUST only used
   after a boot or reboot.




Shelby, et al.          Expires November 29, 2009              [Page 30]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


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

   If a Node Confirmation is received with an error code (128 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 an implementation specific timeout and number of
   retries, then there may be no Edge Routers in the LoWPAN.  See
   Section 8 for more information on ad-hoc network operation.

   This specification also introduces the concept of a secondary
   binding.  For redundancy, a node might place a secondary binding with
   one or more other Edge Routers on the same or different LoWPANs.  The
   'P' flag in the Router Registration Indentity Request Option
   indicates whether the binding is primary.  A primary binding MUST be
   maintained with exactly one Edge Router in each LoWPAN at any time.
   The use of this mechanism for fault tolerance is explained in
   Section 7.8.

   ER bindings have a timeout associated with them, therefore nodes must
   periodically send a new Node Registration message to renew the
   bindings.  If a node no longer receives RCs from any router in the
   current subnet, the registration process begins from the beginning.

5.4.  Next-hop determination

   Next-hop determination is performed as in Section 5.2 of [RFC4861]
   with the following exceptions.  All prefixes are assumed to be off-
   link as the subnet with that prefix may be larger than the link (non-
   transitive property), unless the destination address exists in the
   neighbor cache.  Exact-match search is performed on the neighbor and
   destination caches.  A node MAY attempt to transmit a packet to the
   link for destinations with the same LoWPAN prefix if no neighbor or
   destination cache entry is found before sending to a default router.
   Link-layer information and packet transmissions SHOULD be used to
   maintain the neighbor cache.  Multicast addresses are considered to
   be on-link and are resolved as specified in [RFC4944] or relative
   future documents.  A LoWPAN Node is not required to be a minimum of
   one buffer per neighbor as specied in [RFC4861], as address lookup is
   not performed as part of next-hop determination.

   Care must be used with anycast addresses, as anycast address



Shelby, et al.          Expires November 29, 2009              [Page 31]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


   resolution is normally performed with a multicast NS/NA exchange in
   [RFC4861].  As LoWPAN Nodes are not required to perform address
   resolution, and do no need to answer NS messages, anycast addresses
   MUST be considered to be off-link.  If a node does answer an NS with
   an NA, it MUST not include link-layer address options, but instead
   MUST include the OII Option.

5.5.  Destination unreachability detection

   LoWPAN Nodes do not perform [RFC4861] address resolution, DAD or NUD.
   Therefore the implementation of NS/NA message support by a node is
   optional, and thus to minimize implementation size a node MAY choose
   not to support NS/NA messages.

   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.


6.  LoWPAN Router Specification

   LoWPAN Routers are used in a route over configuration where the
   network is composed of overlapping link-local scopes.  As a result,
   we extend ND as specified in [RFC4861] to operate over such non-
   transitive LoWPAN links.  This section describes ND for 6LoWPAN
   router operations.  Note that this section does not apply to pure
   Mesh Under LoWPANs where the are no LoWPAN Routers.  In addition to
   the operations described in this section, LoWPAN Routers also need to
   implement the basic LoWPAN Node operations in Section 5.

   Network configuration parameters carried in Router Advertisements
   originate at edge routers and must disseminate to all routers and
   hosts within the LoWPAN.  The 6LoWPAN Prefix Summary Option is used
   to support information dissemination from one or more edge routers to
   all other nodes in the LoWPAN.  The option includes a "V" flag which
   indicates that the information contained in the Router Advertisement
   is valid.  The option also includes a sequence number to ensure that
   all nodes converge on the same settings.

   Because Node Registration/Confirmation exchanges between LoWPAN Nodes
   and LoWPAN Routers only occur over link-local scope, such messages
   must be relayed between nodes and ERs when separated by multiple IP
   hops.  Every LoWPAN Router MUST also serve as a relay to ensure that
   any neighboring node can successfully participate in the LoWPAN.






Shelby, et al.          Expires November 29, 2009              [Page 32]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


6.1.  Router Configuration Variables

   A router MUST allow conceptual variables as defined in Section 6.2.1
   of [RFC4861].

6.2.  Becoming an Advertising Interface

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

   A LoWPAN Router's interface MAY become an advertising interface
   before all of its router variables have been initialized.  The router
   MUST learn these variables (e.g.  AdvCurHopLimit, AdvReachableTime,
   prefix information, etc.) from neighboring routers.  While the
   variables are not initialized, the router MAY send Router
   Advertisement with the "Solicit" flag set to solicit Router
   Advertisements from neighboring routers.  However, the router MUST
   set the Router Lifetime field to zero while one or more of its
   variables are uninitialized.

6.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 constistent 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 LoWPAN Router.

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

      - In the Reachable Time field: the current value of
      AdvReachableTime.

      - In the Retrans Timer field: the current value of
      AdvRetransTimer.

      - In the options:





Shelby, et al.          Expires November 29, 2009              [Page 33]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


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

            - 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 ER through this router.

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

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

6.4.  Sending Unsolicited Router Advertisements

   As specified in Section 6.2.4 of [RFC4861].

6.5.  Ceasing To Be an Advertising Interface

   As specified in Section 6.2.5 of [RFC4861].

6.6.  Processing Router Solicitations

   As specified in Section 6.2.6 of [RFC4861].

6.7.  Relaying a Node Registration Message

   When a router receives a Node Registration message from a LoWPAN
   Node, it sets the Code field to 1 indicating that the message has
   been relayed.  The IPv6 source address is set to that of the router.
   Furthermore the checksum is re-calculated and the hop limit is set to
   255.

   By default, the router relays Node Registration messages to the
   6LOWPAN_ER anycast address.  However, the router MAY be configured to



Shelby, et al.          Expires November 29, 2009              [Page 34]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


   use a list of destination addresses, which MAY include unicast
   addresses, the 6LOWPAN_ER anycast address, or other addresses
   selected by the network administrator.  If a target link-layer
   address option is included, the router SHOULD take this into account
   as the prefered ER of the node.

   As initial Node Registration messages are sent with an unspecified
   IPv6 source address, the router needs to keep state regarding the
   node's OII to link-layer address mapping while waiting for the Node
   Confirmation.  This state is used to send the relayed NC to the
   correct MAC address for the node.

6.8.  Relaying a Node Confirmation Message

   When the router receives a Relay Node Confirmation message from an
   Edge Router, the Code field is set to 1.  The Owner Interface
   Identifier and relay state are used to form the link-local IPv6
   Destination Address for the Node Confirmation message.  The IPv6
   source address is set to the link-local address of the Router.  The
   Hop Limit of the Node Confirmation message is set to 255.

   Upon relaying a successful NC message back to a node, the router
   SHOULD use the information about IPv6 addresses in the message to
   update its neighbor cache.


7.  LoWPAN Edge Router Specification

   Edge Routers are the routers that connect LoWPANs to an IPv6
   infrastructure via backhaul or backbone links when such an
   infrastructure is available.  To achieve that role:

      Edge Routers MUST implement LoWPAN Router features on their LoWPAN
      interfaces,

      Edge Routers MUST support Whiteboard registration for LoWPAN Nodes
      within their subnets.

      Edge Routers MAY support the Extended LoWPAN modality where a
      LoWPAN subnet is aggregated over a higher speed backbone link.

      Edge Routers supporting the extended LoWPAN modality MUST perform
      ND proxy over the backbone on behalf of their registered LoWPAN
      Nodes.

   This specification documents the LoWPAN Whiteboard, a conceptual data
   structure that is used by the Edge Routers to maintain LoWPAN Node
   registrations.  This specification documents extensions to the IPv6



Shelby, et al.          Expires November 29, 2009              [Page 35]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


   Neighbor Discovery Protocol [RFC4861] that enables a LoWPAN Node to
   locate an Edge Rsouter and then claim and register addresses using
   unicast exchanges with that Edge Router.

   Another function of the Edge Router is to perform 6LoWPAN compression
   and uncompression between the LoWPAN and the rest of the IP network
   and ensure MTU compatibility.  Packets flow uncompressed over the
   Backbone or Backhaul Links and are routed normally towards a Gateway
   or an Application sitting outside of the LoWPAN.

   In the Extended LoWPAN case, the Edge Router also performs proxy ND
   operations over the Backbone Link on behalf of the LoWPAN Nodes that
   are registered to it.  The draft documents the proxy ND operation by
   the Edge Routers over the Backbone link and the conflict resolution
   process that enables transparent micro-mobility for the LoWPAN Nodes.

7.1.  The Whiteboard

   The white board is a conceptual data structure that is maintained by
   the Edge Routers to store their knowledge of the registered LoWPAN
   Nodes.  Information maintained for each registered node includes:

   IPv6 address:  The IPv6 address being registered.  This is an IPv6
      unicast address of any scope.

   Owner Interface Identifier:  The OII of the LoWPAN Node is used for
      Address collision detection and resolution.  (Section 7.6).

   Transaction Identifier History:  The TID history of the last
      successful registrations for a LoWPAN Node is used for Duplicate
      OII detection (Section 7.7)

   Primary flag:  Influences the proxy ND operation in the Extended
      LoWPAN case.

   Registration Age and Lifetime:  The registration age indicates how
      long ago the last registration flow took place.  When the age
      reaches the registration lifetime, the whiteboard entry is
      removed.

   It can be noted that no link-layer information is stored there.  If
   the Edge Router is also used as the default gateway for the LoWPAN
   node then it would possess LLA information in its neighbor cache.
   Otherwise, it will route packets towards the LoWPAN nodes and thus
   will not need or use the LLA of the LoWPAN node.

   It can also be noted that in the Extended LoWPAN case, an Edge Router
   only maintains the information on the LoWPAN Nodes that are



Shelby, et al.          Expires November 29, 2009              [Page 36]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


   registered to it.  So the full registry of all the LoWPAN Nodes in a
   subnet is actually distributed between the Edge Routers.

7.2.  Simple LoWPAN

   The support of the Simple LoWPAN modality is REQUIRED.  In that
   configuration, a single Edge Router serves a subnet that is formed by
   the LoWPAN nodes that are registered to that Edge Router, as
   represented in Figure 1.  The ER may be connected to an IP
   infrastructure and may inject the prefixes for its subnet in the
   routed infrastructure.

   In a Simple LoWPAN, the Edge Router is the repository of all
   registrations and can detect a registration collision by simply
   looking up its whiteboard, so the whiteboard is the reference for
   Neighbor Discovery operations.

   The Edge Router forms a link-local address in exactly the same way as
   any other node on the LoWPAN, for instance based on its link layer
   addresses to enable 6LoWPAN Header Compression.  If the resulting
   address is not present in the Whiteboard then the Edge Router owns
   the address right away.  The Edge Router announces itself using
   Router Advertisement (RA) messages that are broadcasted periodically
   over the LOWPAN.

7.3.  Extended LoWPAN

   The support of the Extended LoWPAN modality is OPTIONAL.  In that
   modality, a high speed Backbone Link interconnects multiple devices
   and Edge Routers to form a single subnet that encompasses IPv6 nodes
   attached to the Backbone Link and LoWPAN Nodes registered to the Edge
   Routers as represented in Figure 2.  As a result, all further
   reference to the Backbone Link and ND proxy operation over that link
   is OPTIONAL but come as a whole.

   In the Extended LoWPAN modality, the Backbone Link is used as a
   reference for address ownership and registration collision detection.
   Addresses that are not found in the Whiteboard are queried over the
   backbone using the ND operation in place for that type of link,
   typically [RFC4861]; Edge Routers represent themselves and the LoWPAN
   Nodes that are proactively registered to them.  An ND lookup over the
   backbone is not propagated over the LoWPANs, but answered by the Edge
   Router that has the registration for the target, if any.

   To enable proxying over the Backbone Link, an Edge Router must join
   the solicited-node multicast address on that link for all the
   registered addresses of the nodes in its LoWPANs.  The Edge Router
   answers the Neighbor Solicitation with a Neighbor Advertisement that



Shelby, et al.          Expires November 29, 2009              [Page 37]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


   indicates its own link-layer address in the Target link-layer address
   option.

   The Backbone Link Maximum Transmission Unit serves as base for Path
   MTU discovery and Transport layer Maximum Segment Size negotiation
   (see section 8.3 of [RFC2460]) for all nodes in the LoWPANs.  To
   achieve this, the Edge Router announces the MTU of the Backbone Link
   over the LoWPAN using the MTU option in the RA message as prescribed
   in section "4.6.4.  MTU" of IPv6 Neighbor Discovery [RFC4861].

   More information on the MTU issue with regard to ND-proxying can be
   found in Neighbor Discovery Proxies [RFC4389] and
   [I-D.van-beijnum-multi-mtu].

7.4.  Registration process

   An Edge Router configures the well-known 6LOWPAN_ER anycast address
   on the LoWPAN interfaces where it serves as Edge Router.  Note that
   the Edge Router will accept Node Registration messages with a hop
   limit that is lower than 255 but it MUST drop a Node Registration
   that does not come from a LoWPAN interface that is associated to the
   same subnet.

   The new Owner Interface Identifier Option in ND messages that carries
   the node EUI-64 address and the lollipop mechanism on the TID help
   differentiate an address collision from a new registration from the
   same node.  More details on collision detection and resolution are
   provided in Section 7.6.

   The Edge Router responds to a Node Registration with a Node
   Confirmation.  If the source address of the NR was not the
   Unspecified Address, then the destination address in the confirmation
   is the source in the Registration.  If the source address of the NR
   was the Unspecified Address, then the ER acts as LoWPAN Router for
   the source, and the destination address is the optimistic address
   being registered.  The destination Link Layer address is not taken
   from the ND cache but from the source Link Layer address in the NR.
   The source address is a unicast address of the ER that matches the
   scope of the destination, preferrably the destination in the NR if it
   is not anycast.

   The remainder of this section deals with the case of an Extended
   LoWPAN configuration.  In that case:

   When it inserts an address in its Whiteboard, an Edge Router SHOULD
   perform Duplicate Address Detection (DAD) over the Backbone Link to
   detect a collision.  Upon a new registration for a link-local, unique
   local or global unicast address based on an IEEE 64-bit extended MAC



Shelby, et al.          Expires November 29, 2009              [Page 38]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


   address, the Edge Router MAY use Optimistic DAD [RFC4429] on the
   Backbone Link.  A positive acknowledgement can be sent to the 6LoWPAN
   node right away if oDAD is used on the Backbone Link.

   A LoWPAN Node should be able to join a different Edge Router at any
   time without the complexities of terminating a current registration
   and renumbering.  To enable this, the ND operation on the backbone
   link upon a Node Registration/Confirmation flow wins the address
   ownership over an ND operation that is done asynchronously, on behalf
   of the same LoWPAN Node, upon a prior registration.  So an Edge
   Router that would happen to have a binding for that same address for
   the same LoWPAN Node identified by its EUI-64 address will yield and
   depreciate its binding.

   The override (O) bit is used to differentiate a registration flow
   from the asynchronous defense of an address by an Edge Router acting
   as a proxy.  Upon a registration flow, an Edge Router doing DAD or
   accepting a reregistration SHOULD set the override (O) bit in its NA
   messages.  Asynchronously to the registration, the Edge Router SHOULD
   NOT set the override (O) bit in its NA messages and should yield to
   an NA message with the override (O) bit set.

   So the Edge Router operation on the Backbone Link is similar to that
   of a Home Agent as specified in "Mobility Support for IPv6" [RFC3775]
   yet different.  In particular, the Neighbor Advertisement message is
   used as specified in section "10.4.1.  Intercepting Packets for a
   Mobile Node" with the exception that the override (O) bit is not set,
   indicating that this Edge Router acts as a proxy for the LoWPAN and
   will yield should another Edge Router claim that address on the
   Backbone Link.

   This specification also introduces the concept of a secondary
   binding.  Upon a secondary binding, the Edge Router will not announce
   or defend the address on the backbone link, but will be able to
   forward packets to the node over its LoWPAN interface.  This feature
   is used for fault tolerance, explained in Section 7.8.

   If the Edge Router is primary for a registration as indicated by the
   'P' flag and it is connected to a Backbone, then it SHOULD perform ND
   operations on the backbone.  In particular the Egde Router SHOULD
   reject the registration if DAD fails on the backbone.  When oDAD is
   used over the backbone the Edge Router MAY issue the Node
   Confirmation right away with a positive code, but if a collision is
   finally detected, it cancels the registration with an asynchronous
   Node Confirmation and a negative completion code on the same TID.

   If the NR message includes an Address Option with the 'A' flag set,
   this indicated the request of stateless address generation.  The ER



Shelby, et al.          Expires November 29, 2009              [Page 39]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


   aquires an appropriate, unique link-layer address for the network
   either by generating it and performing DAD, or with some other
   method.  If successful, this address is returned in an Address Option
   of the NC with the 'A' flag set and the assigned IPv6 address formed
   from the generated link-layer address with the defualt prefix inline.

7.5.  Forwarding packets between a LoWPAN and an IPv6 infrastructure

   Upon receiving packets on one of its LoWPAN interfaces, the Edge
   Router checks whether it has a binding for the source address.  If it
   does, then the Edge Router can forward the packet; otherwise, the
   Edge Router MUST discard the packet.

   If the packet is to be transmitted over a Backbone or Backhaul Link,
   then the 6LoWPAN sublayer is terminated and the full IPv6 packet is
   reassembled and expanded.  When forwarding a packet from the Backbone
   or Backhaul Link towards a LoWPAN interface, the Edge Router performs
   the 6LoWPAN sublayer operations of compression and fragmentation and
   passes the packet to the lower layer for transmission.

   From the standpoint of an Edge Router, the view of the subnet in the
   Extended LoWPAN modality is that all nodes in the subnet are either
   LoWPAN nodes registered to this ER or on-link on the Backbone Link,
   though in fact they might be proxide for by other ERs.  If the
   destination is a LoWPAN node registered to this ER, the ER will
   forward the packet over the LoWPAN interface either as a local
   delivery if the node is on-link or via intermediate LoWPAN routers
   using the routing in place in the LoWPAN.  If the destination is not
   a registered LoWPAN node, then the ER acts as if the subnet was on-
   link on the Backbone and looks up the node there using ND.  If the
   node is not found there either, it is assumed unreachable and an
   "Destination Unreachable" ICMP message is sent to the source as
   prescribed by [RFC4443].

7.6.  Address collision detection and resolution

   The assumption in this section is that the OII that is carried in the
   registration messages and in the NS/NA messages is globally unique.
   When this assumption fails, and additional collision resolution
   mechanism takes place, as detailed in Section 7.7.

   The address collision can be detected within the Edge Router if the
   Edge Router already has a registration for a given address, or over
   the Backbone Link using Duplicate Address Detection.  In the latter
   case, a new ND option, the Owner Interface Identifier Option is used
   in NS/NA messages to carry the Transaction ID and the Owner Interface
   Identifier that are required for the resolution th conflict
   resolution.  In any case, the Edge Router in charge of the resolution



Shelby, et al.          Expires November 29, 2009              [Page 40]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


   is the Edge Router that handles the registration.

   A registration is identified by the (OII, IPv6 address) pair.  A
   conflict occurs when a Node Registration is received for an IPv6
   address that is already registered with a different OII at the same
   or another Edge Router.  The resolution of such conflict is explained
   below.

   Additionally, the following principles apply to the resolution in the
   Extended LoWPAN modality:

      Mobility within a subnet is included and welcome.  In an Extended
      LoWPAN, a LoWPAN Node may migrate its registration to a new Edge
      Router transparently and at any time.  The protocol is designed to
      recognize the mobility and silently cleanup the registration
      states.

      A synchronous operation wins against a delayed proxy operation.
      An Edge Router that processes a Node Registration normally takes
      over an existing registration maintained by a defendant Edge
      Router.

      The decision to migrate the registration from an Edge Router to
      another is made by the Edge Router that processes a Node
      Registration message based on its own states for that registration
      and ND exchanges over the Backbone Link.

      A conflict may also occur with a node that is already present on
      the Backbone Link when the registration occurs, or with a node
      appears on the Backbone Link while a registration already exists
      for its claimed address.  The resolution of such conflict is done
      using standard Duplicate Address Detection as prescribed by
      [RFC4862].

   Upon a Node Registration message, an Edge Router looks up an existing
   registration for that IPv6 address in its LoWPAN whiteboard.  If the
   entry does not exist then the Edge Router looks up the address over
   the Backbone Link using the NS (DAD) mechanism.  The Edge Router
   SHOULD include an Owner Interface Identifier Option in the NS
   message.  An Edge Router that defends that address for an existing
   registration MUST include an Owner Interface Identifier Option in the
   NA message and SHOULD NOT set set the Override (O) bit.

   If no entry is found for that address and DAD times out, the Edge
   Router accepts the registration: it creates an entry on the
   whiteboard, sends a positive Node Confirmation Message to the node,
   and advertises the address on the Backbone Link.  Since this happens
   asynchronously to the Node Registration, the Edge Router SHOULD NOT



Shelby, et al.          Expires November 29, 2009              [Page 41]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


   set set Override (O) bit in the NA message.

   If an entry is found in the whiteboard for the same (OII, IPv6
   address) pair, additional checking is performed for duplicate OII
   detection as detailed in Section 7.7.  If no duplication is detected,
   then the Edge Router accepts the update of the reservation: it
   updates a entry on the whiteboard, sends a positive Node Confirmation
   Message to the node, and advertises the address on the Backbone Link.
   Since this happens synchronously to the Node Registration, the Edge
   Router SHOULD set set Override (O) bit in the NA message.

   If the address is already present on the Backbone Link and defended
   by a remote Edge Router, then that Edge Router defends the address
   with the Override (O) bit reset and the Owner Interface Identifier
   Option in the NA message.

   If the Edge Router receives an NA message during the DAD period, it
   checks for an Owner Interface Identifier Option in the NA message.
   If there is no OII or the (O) bit is set then this is a duplicate
   address, DAD fails and the registration is rejected.  If there is an
   Owner Interface Identifier Option in the NA message and the OII is
   different, then DAD fails and the registration is rejected.  If the
   OII is the same, additional checking is performed for duplicate OII
   detection as detailed in Section 7.7.  If there is no duplication
   then the NA is ignored and the DAD timer keeps going.

   If the Edge Router receives an NS (DAD) message from another node
   during the DAD period, it checks for a Owner Interface Identifier
   Option in the NS message.  If there is no OII then DAD fails and the
   registration is rejected.  If there is an Owner Interface Identifier
   Option in the NA message and the OII is different, then DAD fails and
   the registration is rejected.  If the OII is the same, then the
   greatest TID wins.  In other words, if the TID in the registration is
   smaller than or equal to the TID in the OII Option then DAD fails and
   the registration is rejected.  Otherwise the NS is ignored and the
   DAD timer keeps going.

   Other Edge Routers are informed of a take over decision by an NA with
   the Override (O) bit set and silently set their own state to non-
   operational.  An Edge Router that looses ownership should attempt to
   keep the registration entry in the whiteboard till the end of the
   registration lifetime for the purpose of duplicate OII detection if
   memory capacity allows.  The TID in the whiteboard entry is updated
   with that in the OII option in the NA.







Shelby, et al.          Expires November 29, 2009              [Page 42]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


7.7.  Duplicate OII detection

   The TID is a sequential number that is used to control the normal
   operation of a registration and detect a duplicate Owner Interface
   Identifier during the Neighbor Discovery operations.  The TID is set
   by a node in its Router Registration message and echoed by the Edge
   Router in the Node Confirmation message.  At least the 4 most recent
   values for a TID are also kept by the edge router in the whiteboard
   entry for validation purpose.

   The TID is maintained using the lollipop mechanism.  When a node
   starts or restarts, the TID is reset to zero.  After that, it is
   incremented with each Node Registration.  When the TID reaches its
   maximum value (0xFFFF) it wraps directly to its looping value at the
   base of the lollipop that is 16.  So a value in the straight part of
   the lollipop (between 0 and 0xF) is only used after a reboot and
   before the circular part of the lollipop is entered.

   Upon a positive Node Confirmation, if the current TID is less than
   16, then the node sets it to 16.  So a TID in the straight part
   denotes a node that just started/restarted and did not get registered
   yet.

   To compare TID1 and TID2, the following rules apply:

      If at least one of TID1 and TID2 is in the straight part of the
      lollipop (smaller than 16) then they compare directly.

      If both TID1 and TID2 are in the circular part then TID2 is
      greater than TID1 if (TID2 - TID1) is smaller than (TID1 - TID2).

   A TID value is consistent with the preceeding one if it is a small
   increment or decrement (more or less 16) from it.  During normal
   operations, the TIDs saved in the white board entry should be
   consistent.  As long as a TID is consistent with the previous one, it
   appears that the new message is coming from the same source as the
   previous one and there is no OII collision.  If the TID is a small
   decrement then the registration messages crossed and that message
   should be ignored, but still there's no collision.

   If the TID jumps to a low value in the lollipop this can be
   interpreted as either a new node competing for the OII and a reboot
   by the node owning the registration.  With this specification, this
   situation is optimistically interpreted as a reboot and not reported
   as a collision, but an actual collision will be detected and filtered
   out next.

   Otherwise, if an inconsistent TID value is detected between the new



Shelby, et al.          Expires November 29, 2009              [Page 43]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


   TID and the most recently accepted value, then the Edge Router
   compares with the older TID values that are saved in the whiteboard
   entry for that registration.  This might occur for instance with an
   entry that was rendered non-operational when the address was taken
   over by another Edge Router.

   If the new value is consistent with a recent value then it appears
   that 2 sources are competing for the same OII and an OII collision
   should be logged.  In that case the greater TID wins, that is if the
   new TID is greater than the previous one it is accepted, otherwise it
   is reported as a collision.

   If the new value is not consistent with a recent value saved in the
   whiteboard entry then it is rejected as a collision.

7.8.  Fault tolerance

   This specification allows for a secondary registration.  The
   secondary registration enables the node to prepare states within the
   network and make the move quicker between primary and secondary.

   If an external keep alive mechanism is in place between the primary
   and the secondary Edge Routers, then the secondary registration
   enables the secondary Edge Router to start intercepting packets on
   the backbone and forwarding them to the node before the node even
   knows that the primary is no longer operational.

   The secondary registration also enables the node to bicast a packet
   for extra reliability, that is send a copy of a packet to both Edge
   Routers without being subject to ingress filtering.  The mechanism
   that enables this filtering is not specified here.


8.  Ad-hoc LoWPAN Operation

   LoWPAN networks by nature may often work in an ad-hoc fasion, without
   an infrastructure.  Neighbor Discovery for 6LoWPAN may still be
   applied in such ad-hoc networks.

   If a LoWPAN Router in the Ad-hoc LoWPAN is configured to implement
   basic edge router Whiteboard functionality and generates a ULA prefix
   [RFC4193], then ND for 6LoWPAN can be applied throughout the LoWPAN
   as specified in this document.  There SHOULD be only one edge router
   in an Ad-hoc LoWPAN (just as in a Simple LoWPAN) to keep consistancy
   in the Whiteboard and ULA prefix.  However if edge routers in an ad-
   hoc LoWPAN are able to emulate backbone link functionality between
   each other, and to coordinate the ULA prefix then there MAY be
   multiple Edge Routers if they implement full Edge Router



Shelby, et al.          Expires November 29, 2009              [Page 44]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


   functionality.

   Ad-hoc LoWPANs make use of Unique Local 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
   in ad-hoc LoWPANs the subnet ID is not used.  The edge router is
   responsible for the generation of the ULA prefix to be advertised to
   the LoWPAN and used by all nodes.  ULA generation may use the
   algorithm suggested Section 3.2.2 of [RFC4193] or something
   appropriate to the Edge Router's capabilities.


9.  Message Examples

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

9.1.  Basic NR/NC message exchange

   In the basic case, when a host wanting to register to the whiteboard
   is on the same link with an ER, a simple NR/NC message exchange
   occurs.  In this example a host wants to register its address
   generated with SAA, and in addition requests a generated short
   address.

   First the Host sends an NR message to the link-local address of the
   ER.  In this example the host wants to use the edge router as
   primary, uses a 600s lifetime, and its EUI-64 as the Owner Interface
   Indentifier.  The message has two Address Options.  The host has just
   booted, therefore the TID starts with 0.

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


                       Figure 11: Basic NR message.




Shelby, et al.          Expires November 29, 2009              [Page 45]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


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


             Figure 12: Address Option 1, for the SAA 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   |  P=2  |  S=3  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|1|0|        Reserved         |         Padding = 0           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


          Figure 13: Address Option 2, for the requested address.

9.2.  Relaying an NR message

   In case an ER is not on-link for initial node registration, then the
   NR message from the previous example is sent to any on-link router in
   exactly the same format.  This router in turn relays the message to
   an ER.  As the OII of the Host is the same as its IID, the Router
   simply sets Code = 1 to indicate that the message was relayed.  The
   destination IPv6 address is that of an edge router or the 6LOWPAN_ER
   Anycast address and the source IPv6 address that of the relaying
   router.  The Address Options are not modified.

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




Shelby, et al.          Expires November 29, 2009              [Page 46]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


                      Figure 14: Relayed NR message.

9.3.  Router advertisement

   Routers and edge routers in LoWPAN networks periodically send RA
   messages.  In the following example is of an RA message sent by a
   router.  The only difference if an edge router would send the message
   is that the Preference flag would be 01 for high.

   In the example the M flag is set to indicate that an ER is available
   through this router, the Preference flag is 00 for normal, and a
   1200s Route Lifetime is advertised.  A 6LoWPAN Prefix Information
   Option is included.


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


                      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 = 60   |0|1| CID=0 | R |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Valid Lifetime = 3000                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                    Prefix = 2001:DB8::/64                     .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 16: 6LoWPAN Prefix Information Option example.







Shelby, et al.          Expires November 29, 2009              [Page 47]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


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

   The use of IP-level forwarding of NR/NC ND messages requires relaxed
   checking of Hop Limit values in ND packets received, compared to the
   validation required by [RFC4861].  This may make ND vulnerable to
   off-LoWPAN senders that accidentally or intentionally send ND
   messages.  This specification states that Edge Routers MUST implement
   measures to filter out such off-LoWPAN ND messages.


11.  IANA Considerations

   This document requires two new ICMPv6 message types:

      Node Registration (TBD1)

      Node Confirmation (TBD2)

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

      Address Option (TBD3)

      6LoWPAN Prefix Information Option (TBD4)

      6LoWPAN Prefix Summary Option (TBD5)

      Owner Interface Identifier Option (TBD6)




Shelby, et al.          Expires November 29, 2009              [Page 48]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


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

   There is also the need for a new link local anycast address,
   6LOWPAN_ER for 6LoWPAN edge routers and Routers; used as a functional
   address.

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


12.  Acknowledgments

   Special thanks to Carsten Bormann who has provided several important
   technical contributions, authored the security considerations section
   along with giving extensive comments on the document.

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


13.  References

13.1.  Normative References

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

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

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

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

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



Shelby, et al.          Expires November 29, 2009              [Page 49]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


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

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

13.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-04
              (work in progress), December 2008.

   [I-D.van-beijnum-multi-mtu]
              Beijnum, I., "Extensions for Multi-MTU Subnets",
              draft-van-beijnum-multi-mtu-02 (work in progress),
              February 2008.

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

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

   [RFC4389]  Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
              Proxies (ND Proxy)", RFC 4389, April 2006.

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



Shelby, et al.          Expires November 29, 2009              [Page 50]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


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


Authors' Addresses

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

   Phone: +358407796297
   Email: zach@sensinode.com


   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: pthubert@cisco.com


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

   Phone: +415 692 0828
   Email: jhui@archrock.com













Shelby, et al.          Expires November 29, 2009              [Page 51]


Internet-Draft       Neighbor Discovery for 6LoWPAN             May 2009


   Samita Chakrabarti
   IP Infusion
   1188 Arquest Street
   Sunnyvale, California
   USA

   Phone:
   Email: samitac@ipinfusion.com


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

   Phone:
   Email: Erik.Nordmark@Sun.COM

































Shelby, et al.          Expires November 29, 2009              [Page 52]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/