[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: September 10, 2009                                        Cisco
                                                                  J. Hui
                                                               Arch Rock
                                                          S. Chakrabarti
                                                             IP Infusion
                                                             E. Nordmark
                                                                     Sun
                                                           March 9, 2009


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

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 September 10, 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents



Shelby, et al.         Expires September 10, 2009               [Page 1]


Internet-Draft       Neighbor Discovery for 6LoWPAN           March 2009


   carefully, as they describe your rights 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 extended multihop
   topologies.  However, the use of standard IPv6 Neighbor Discovery
   with 6LoWPAN has several problems.  Standard Neighbor Discovery was
   not designed for wireless links, and the standard IPv6 link concept
   and heavy use of multicast makes it inefficient.  This document
   spefies a new ND mechanism allowing for efficient Duplicate Address
   Detection over entire LoWPANs.  In addition it specifies context
   dissemination for use with router advertisements, claim and defend
   addressing, and the support of extended LoWPANs over backbone links.



































Shelby, et al.         Expires September 10, 2009               [Page 2]


Internet-Draft       Neighbor Discovery for 6LoWPAN           March 2009


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.1.  Goals & Assumptions  . . . . . . . . . . . . . . . . . . .  6
     1.2.  Why not standard IPv6 ND?  . . . . . . . . . . . . . . . .  7
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  8
   3.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . . 10
     3.1.  Bootstrapping  . . . . . . . . . . . . . . . . . . . . . . 13
     3.2.  Basic operation  . . . . . . . . . . . . . . . . . . . . . 14
     3.3.  Optional features  . . . . . . . . . . . . . . . . . . . . 15
   4.  6LoWPAN ND Messages  . . . . . . . . . . . . . . . . . . . . . 15
     4.1.  Router Registration/Confirmation Message . . . . . . . . . 16
     4.2.  Router Advertisement Message . . . . . . . . . . . . . . . 18
     4.3.  NS/NA Messages . . . . . . . . . . . . . . . . . . . . . . 20
     4.4.  6LoWPAN ND Message Options . . . . . . . . . . . . . . . . 20
       4.4.1.  Address Option . . . . . . . . . . . . . . . . . . . . 20
       4.4.2.  6LoWPAN Prefix Information Option  . . . . . . . . . . 22
       4.4.3.  Multihop Information Option  . . . . . . . . . . . . . 23
       4.4.4.  Owner Interface Identifier Option  . . . . . . . . . . 23
   5.  LoWPAN Subnet  . . . . . . . . . . . . . . . . . . . . . . . . 24
   6.  LoWPAN Node Specification  . . . . . . . . . . . . . . . . . . 25
     6.1.  Forming addresses  . . . . . . . . . . . . . . . . . . . . 25
     6.2.  Registration process . . . . . . . . . . . . . . . . . . . 26
     6.3.  Next-hop determination . . . . . . . . . . . . . . . . . . 28
     6.4.  Address lookup . . . . . . . . . . . . . . . . . . . . . . 28
   7.  LoWPAN Router Specification  . . . . . . . . . . . . . . . . . 29
     7.1.  Router Configuration Variables . . . . . . . . . . . . . . 29
     7.2.  Becoming an Advertising Interface  . . . . . . . . . . . . 29
     7.3.  Router Advertisement Message Content . . . . . . . . . . . 29
     7.4.  Sending Unsolicited Router Advertisements  . . . . . . . . 31
     7.5.  Ceasing To Be an Advertising Interface . . . . . . . . . . 31
     7.6.  Processing Router Solicitations  . . . . . . . . . . . . . 31
     7.7.  Relaying a Router Registration Message . . . . . . . . . . 31
     7.8.  Relaying a Router Confirmation Message . . . . . . . . . . 31
   8.  LoWPAN Edge Router Specification . . . . . . . . . . . . . . . 31
     8.1.  Registration process . . . . . . . . . . . . . . . . . . . 32
     8.2.  Exposing the edge router . . . . . . . . . . . . . . . . . 33
     8.3.  Forwarding packets . . . . . . . . . . . . . . . . . . . . 35
     8.4.  Address collision detection and resolution . . . . . . . . 35
     8.5.  Duplicate OII detection  . . . . . . . . . . . . . . . . . 37
     8.6.  Fault tolerance  . . . . . . . . . . . . . . . . . . . . . 38
   9.  Ad-hoc LoWPAN Operation  . . . . . . . . . . . . . . . . . . . 39
   10. Message Examples . . . . . . . . . . . . . . . . . . . . . . . 39
     10.1. Basic RR/RC message exchange . . . . . . . . . . . . . . . 39
     10.2. Relayed RR/RCC message exchange  . . . . . . . . . . . . . 41
     10.3. Router advertisement . . . . . . . . . . . . . . . . . . . 41
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 42
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 43



Shelby, et al.         Expires September 10, 2009               [Page 3]


Internet-Draft       Neighbor Discovery for 6LoWPAN           March 2009


   13. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 43
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 43
     14.2. Informative References . . . . . . . . . . . . . . . . . . 44
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45














































Shelby, et al.         Expires September 10, 2009               [Page 4]


Internet-Draft       Neighbor Discovery for 6LoWPAN           March 2009


1.  Introduction

   The IPv6 over IEEE 802.15.4 [RFC4944] document has specified IPv6
   headers carried over an IEEE 802.15.4 and similar network with the
   help of an adaptation header which comes before the IP header.  A
   LoWPAN link is characterized as lossy, low-power, low bit-rate, short
   range, with long deep sleep periods.  Multicast as used in IPv6
   Neighbor Discovery [RFC4861] is not desirable in such a wireless low-
   power, lossy network.

   Moreover, LoWPAN links are transient in nature; they are not always
   considered to be in a fixed network nor they are bounded by our
   standard definition of a wired-link.  The link is in reality defined
   by reachability and radio strength.  The standard IPv6 Neighbor
   Discovery [RFC4861] control messages and their default frequency also
   attribute to unnecessary loss of power in LoWPANs.

   Neighbor discovery for 6LoWPAN provides for basic bootstrapping and
   network operation, along with advanced features such as claim and
   defend addressing and extended LoWPANs over backbone links, while
   avoiding the use of multicast and providing both mesh under and route
   over support.  Unlike standard IPv6 ND [RFC4861], this document takes
   the characteristics of low-power, lossy wireless links into account.

   A LoWPAN is composed of a potentially large amount of radio links,
   eventually federated by a backbone or a backhaul link.  Although a
   given link has broadcast capabilities, the aggregation of links is a
   complex Non-Broadcast MultiAccess (NBMA, [RFC2491]) structure with no
   multicast capabilities.  This specification introduces a registration
   mechanism over the radio edge of the NBMA network and proxy operation
   over the federating backbone or backhaul.  That registration
   mechanism provides a service somewhat similar to MARS ([RFC2022]) for
   the limited purpose of ND NS/NA, and in a lot simpler and less
   generic fashion.  For those link scope multicasts that could not be
   avoided, such as ND RAs, 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 is
   introduced, which allows for duplicate address detection and claim
   and defend addressing for the entire LoWPAN.  Address resolution
   simplifications are included to make LoWPAN operation efficient and
   reduce LoWPAN Node complexity.  A new registration/confirmation
   message sequence is specified, allowing nodes to register their IPv6
   addresses with an edge router whiteboard.

   The ER whiteboard makes use of soft bindings, thus nodes send
   periodic registration messages in order to maintain their bindings.



Shelby, et al.         Expires September 10, 2009               [Page 5]


Internet-Draft       Neighbor Discovery for 6LoWPAN           March 2009


   Changes in network topology, and mobility between ERs and subnets are
   supported.  The dissemination of RA information throughout multihop
   route over networks is also discussed.

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

   The document defines two new ICMPv6 messages: Router Registration and
   Router Confirmation.  In addition a new 6LOWPAN_ER anycast address is
   introduced, allowing for nodes to send register without knowing the
   specific edge router's or router's unicast address.

1.1.  Goals & Assumptions

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

   Goals:

      o Avoid the use of 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 Either [RFC4944] or [I-D.ietf-6lowpan-hc] 6LoWPAN header
      compression used.

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

      o Link-local addresses are derived from an EUI-64 identifier.

      o Mesh-under nodes know the edge router link-layer addresses of
      their mesh network from some L2 mechanism.

      o A subnet includes all the LoWPAN nodes and their backbone link.





Shelby, et al.         Expires September 10, 2009               [Page 6]


Internet-Draft       Neighbor Discovery for 6LoWPAN           March 2009


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 initialisation of the network in IPv6 ethernet
   networks, a node joins the solicited-node multicast address on the
   interface and then it performs duplicate address detection (DAD) for
   the acquired link-local address by sending solicited-node multicast
   message to the link.  After that it sends multicast messages to all-
   router address to solicit router advertisements.  Once the host
   receives a valid router advertisement with the "A" flag, it
   autoconfigures the IPv6 address with the advertised prefix in the
   rotuer advertisement (RA).  Besides this, the IPv6 routers usually
   send router advertisements periodically on the network.  It sends the
   RA to all-node multicast address.  Nodes send Neighbor Solicitation/
   Neighbor Advertisement messages to resolve the IPv6 address of the
   destination on the link.  These NS/NA messages are also often
   multicast messages and it assumes that the node is on the same link
   and relies on the fact that the destination node is always powered
   and generally reliable.

   A LoWPAN network typically uses two types of L2 addresses - 16-bit
   short addresses and 64-bit unique addresses as defined in [RFC4944].
   Moreover, the link bandwidth is often on the order of less than 100
   bytes where we often might need to use header compression and use a
   minimum payload.  The network is lossy and low-powered, and it does
   not provide multicast capability at the link-layer, thus simulating
   multicast behavior by both using broadcast or sending a number of
   unicast messages, both expensive for the low-powered network and the
   low-processing capable nodes.  Often these low-powered nodes conserve
   energy by using sleep schedules; waking them up to receive IPv6
   signaling messages such as multicast messages for NS, and periodic RA
   is not practical.  Nor they are capable of processing address-
   resolution for its neighbors effectively.  Due to radio strength of
   its neighboring router or its own strength, a node may often move
   from one router to another without physically moving from one place
   to another.  Considering the above characteristics in a LoWPAN, and
   IPv6 Neighbor Discovery [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.







Shelby, et al.         Expires September 10, 2009               [Page 7]


Internet-Draft       Neighbor Discovery for 6LoWPAN           March 2009


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

   Readers are expected to be familiar with all the terms and concepts
   that are discussed in "Neighbor Discovery for IP version 6"
   [RFC4861], "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 document defines additional terms:

   LoWPAN Host

      A node that only sources or sinks IPv6 datagrams.  Referred to as
      a host in this document.  The term node (see LoWPAN Node) is used
      when the the differentiation between host and router is not
      important.

   LoWPAN Edge Router

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

   LoWPAN Router

      A node that forwards datagrams between arbitrary source-
      destination pairs using a single 6LoWPAN interface performing IP
      routing (and thus only exist in route over LoWPANs).  A LoWPAN
      Router may also serve as a LoWPAN Host - both sourcing and sinking
      IPv6 datagrams.  Refered to as a router in 6LoWPAN documents.  All
      LoWPAN Routers perform ND message relay on behalf of other nodes.

   LoWPAN Node

      A node that composes a LoWPAN.  In mesh under, each intermidiate
      node performs multi-hop forwarding at L2.  In route over, each
      intermidiate node serves as a LoWPAN router performing IP routing.




Shelby, et al.         Expires September 10, 2009               [Page 8]


Internet-Draft       Neighbor Discovery for 6LoWPAN           March 2009


   Mesh Under

      A LoWPAN configuration where the link-local scope is defined by
      the boundaries of the LoWPAN and includes all nodes within.
      Forwarding and multihop routing functions are achieved at L2
      between mesh nodes.

   Route Over

      A LoWPAN configuration where the link-local scope is defined by
      those nodes reachable over a single radio transmission.  Due to
      the time-varying characteristics of wireless communication, the
      neighbor set may change over time even when nodes maintain the
      same physical locations.  Multihop is achieved using IP routing.

   Backbone Link

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

   Backhaul Link

      This is an IPv6 link that connects a single edge router to another
      network.

   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.

   LoWPAN Link

      A low-power wireless link which is shared by a link-local scope in
      a LoWPAN.  In a LoWPAN, a link can be a very instable set of
      nodes, for instance the set of nodes that can receive a packet
      that is broadcast over the air in a route over LoWPAN, or the set
      of nodes currently reachable in an L2 mesh in a mesh under LoWPAN.
      Such a set may vary from one packet to the next as the nodes move
      or as the radio propagation conditions change.

   LoWPAN Subnet

      A subnet including a LoWPAN or an Extended LoWPAN, together with
      the backbone link with the same subnet prefix and prefix length.





Shelby, et al.         Expires September 10, 2009               [Page 9]


Internet-Draft       Neighbor Discovery for 6LoWPAN           March 2009


   Binding

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

   Registration

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


3.  Protocol Overview

   Neighbor discovery for 6LoWPAN provides additions and optimizations
   to IPv6 ND [RFC4861] specifically supporting 6LoWPAN.  Basic
   bootstrapping and network maintenenace mechanisms are provided, and
   the use of multicast is avoided.  Duplicate address detection and
   claim and defend addressing are supported as part of bootstrapping.
   This is achieved using a whiteboard located on the LoWPAN edge
   routers of the LoWPAN network.  Extended LoWPANs over backbone links
   are optionally supported.

   Multihop route over networks are supported by routers relaying ND
   messages.  ND for 6LoWPAN is designed to work with many network
   topologies, including isolated ad-hoc networks, single ER networks,
   and networks with multiple ERs interconnected by a backbone link.
   The use of both IEEE 802.15.4 and other suitable 6LoWPAN link-layer
   technologies is considered.  Both the use of mesh under and route
   over paradigms are supported.


                   |
                   |
                   |
                +-----+
                |     | Edge
                |     | router
                +-----+
                 m  m
               m      m
             m   m  m   m     m: Mesh node
              m   m  m  m
               m   m  m

                LoWPAN




Shelby, et al.         Expires September 10, 2009              [Page 10]


Internet-Draft       Neighbor Discovery for 6LoWPAN           March 2009


                      Figure 1: A Mesh under LoWPAN.

   In a mesh under network, shown above, multihop forwarding is dealt
   with below layer 3.  Thus the entire LoWPAN forms a link-layer mesh.
   This means that the IPv6 link-local scope includes all the nodes of
   the LoWPAN.  Link-local scope stops however at the ER, and does not
   include any backbone link.  The implication of this regarding ND for
   6LoWPAN, is that it can always be assumed that the ER and hosts are
   on the same link.  In these networks only LoWPAN Node and edge router
   functionalities are needed.  Multicast with mesh under technologies
   most often induces flooding, and therefore it is avoided.


                   |
                   |
                   |
                +-----+
                |     | Edge
                |     | router
                +-----+
                 r  h
               r   r   r
             h  r   h  r h        h: Host
              h   r  r  h         r: Router
                h   h  h

                LoWPAN


                      Figure 2: A Route over LoWPAN.

   A route over network performs multihop using standard layer 3 IP
   routing.  The link-local scope is defined by a LoWPAN link, which
   includes nodes reachable over a single radio transmission at each
   instant.  The implication for ND for 6LoWPAN is that if the ER is out
   of radio range of a host, the ND messages require relaying by
   intermediate routers.  In these networks also LoWPAN Router
   functionality needs to be implemented by all routers in the LoWPAN.
   Multicast may also involve flooding in such networks and often does
   not work, and thus is avoided.











Shelby, et al.         Expires September 10, 2009              [Page 11]


Internet-Draft       Neighbor Discovery for 6LoWPAN           March 2009


             Infrastructure
                 Cloud
                   z
                   z
                   z  Backhaul link
                   z
                   z
                +-----+
                |     | Edge
                |     | router
                +-----+
                  o  o
               o   o    o
             o  o   o  o o        o: Any node
              o   o  o  o
                o   o o

                LoWPAN


             Figure 3: A LoWPAN connected to a backhaul link.

   The simplest topology is a LoWPAN connected by a single edge router
   to another network, over a so-called backhaul link.  The edge router
   maintains a whiteboard of all hosts in the network.  The edge router
   terminates 6LoWPAN framing from the LoWPAN, and forwards packets.
   The LoWPAN subnet covers all the interfaces in the LoWPAN, which have
   the same prefix and prefix length.























Shelby, et al.         Expires September 10, 2009              [Page 12]


Internet-Draft       Neighbor Discovery for 6LoWPAN           March 2009


         Infrastucture Cloud
                  |
                  |
               +-----+                 +-----+
               |     | Gateway         |     | Host
               |     |                 |     |
               +-----+                 +-----+
                  |                       |
                  |     Backbone link     |
            +--------------------+------------------+
            |                    |                  |
         +-----+             +-----+             +-----+
         |     | Edge        |     | Edge        |     | Edge
         |     | router      |     | router      |     | router
         +-----+             +-----+             +-----+
            o         o       o   o  o      o        o o
        o o   o  o  o  o  o o   o  o  o  o  o   o  o  o  o
       o  o o  o o   o    o   o  o  o  o     o   o  o  o o
       o   o  o  o     o    o    o  o     o      o  o   o
         o   o o     o          o  o      o    o       o

                         Extended LoWPAN

      Figure 4: Backbone link and edge routers with a 6LoWPAN subnet

   In the backbone link topology, a backbone link federates multiple
   LoWPANs into a single LoWPAN Subnet, the Extended LoWPAN.  Each
   LoWPAN is anchored at one or more edge router.  The edge routers
   interconnect the LoWPANs over the backbone link.  A node can move
   freely from a LoWPAN anchored at an edge router to a LoWPAN anchored
   at another edge router on the same backbone link and conserve all
   IPv6 address it has formed.

   The following sections summarizes how ND for 6LoWPAN works, starting
   with bootrapping on the network, maintenance of the network, and
   finally optional features.

3.1.  Bootstrapping

   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 Host wants to join a LoWPAN, it does so by
   listening for Route Advertisements from edge routers or routers, or
   by broadcasting a Router Solicitation (RS).  If a valid prefix is
   advertised in the RA, the host may form an optimistic global unique
   address with stateless address autoconfiguration.

   Next the Host registers with an on-link edge router or router by



Shelby, et al.         Expires September 10, 2009              [Page 13]


Internet-Draft       Neighbor Discovery for 6LoWPAN           March 2009


   sending a Router Registration (RR) message to it, either unicast or
   using the 6LOWPAN_ER anycast address.  These message exchanges are
   illustrated below.  The RR contains the addresses the node wants to
   register.  If the network is configured to support whiteboard claim
   and defend addressing, e.g., generating short addresses for nodes,
   this is indicated in the RA message with the M flag.  In such
   networks a node may request an address to be generated on its behalf
   by including an Address Option with the A flag and an address of
   length 0 in the RR.  Note that registration must be performed
   separately for each interface of a host.

   The edge router replies either directly with a Router Confirmation
   (RC), or through a router by relaying.  Note that routers only exist
   in route over networks, and in mesh under networks nodes are on the
   same link with edge routers.  This confirmation includes the set of
   addresses now bound to the whiteboard of the ER.  The Host is now
   capable of using the LoWPAN, and the ER forwards on its behalf.


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


      Figure 5: Basic ND registration exchange when the Node and edge
                       router are on the same link.



   Node                    Router (relay)                 edge router
    |                            |                             |
    |       ---- RR --->         |        ---- RR --->         |
    |                            |                             |
    |      <---- RC ----         |       <---- RC  ----        |
    |                            |                             |


     Figure 6: Relay ND registration exchange in route over networks.

3.2.  Basic operation

   The whiteboard address bindings and assignments are soft, and thus
   must be renewed periodically as indicated by the lifetime of the
   binding.  This is achieved by periodically sending a new RR to the
   ER.  If a host moves, or the network topology changes, and the



Shelby, et al.         Expires September 10, 2009              [Page 14]


Internet-Draft       Neighbor Discovery for 6LoWPAN           March 2009


   current ER is no longer available, the host then starts the
   registration process with another ER.  If the host is still in the
   same Extended LoWPAN (same prefix), its IPv6 addresses remain the
   same.  Claim and defend addresses generated by the whiteboard must be
   remembered by the host and refreshed in order to keep the address.
   If the host moves to a different LoWPAN, with a different prefix, the
   bootstrapping process is initiated again.  In route over networks,
   routers (which act as relays) must disseminate RAs to their
   neighbors.  The edge router initiates RAs, and this information is
   included in the RAs of each router.

3.3.  Optional features

   This documents specifies a method for forming Extended LoWPAN
   networks with multiple ERs on a backbone link.  This optional feature
   allows for DAD across the entire Extended LoWPAN and backbone links,
   seen as a single subnet.  The method uniquely identifies the LoWPAN
   Host on the backbone, and overrides the claim on an address on behalf
   of a LoWPAN Host.  Thus a Host can keep the same address, and appears
   the same to other hosts on the backbone link, regardless of moving
   its binding from one ER to another.

   Ad-hoc LoWPAN operation is also optionally supported.  By electing a
   router to implement a subset of edge router functionality, and by
   generating a ULA prefix, an ad-hoc LoWPAN can operate in an identical
   manner to an infrastructure connected LoWPAN.


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 new ICMPv6 message types are defined:

      Router Registration

      Router Confirmation

   In addition, the following new ICMPv6 options are defined:

      Address Option

      6LoWPAN Prefix Information Option




Shelby, et al.         Expires September 10, 2009              [Page 15]


Internet-Draft       Neighbor Discovery for 6LoWPAN           March 2009


      Multihop Information Option

      Owner Interface Identifier Option

4.1.  Router Registration/Confirmation Message

   The Router Registration (RR) and Router Confirmation (RC) messages
   are used by a Host to register with an ER, and for the ER to confirm
   the binding.  Any option that is not recognized MUST be skipped
   silently.  The Router Registration message is sent by the LoWPAN Node
   to an on-link ER or router, and may be sent unicast or to the
   6LOWPAN_ER anycast address.  This same message format is also used
   for relayed RR/RC messages, with an alternative code that is set when
   the message has been relayed.

    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 7: Router Registration/Confirmation message format

   IP Fields:

      Source Address:  The IPv6 address of the source.  This address may
         be an optimistic address.

      Destination Address:  The destination IPv6 address of an on-link
         edge router or Router.  May be the 6LOWPAN_ER anycast address.

      Hop Limit:  255

   ICMP Fields:







Shelby, et al.         Expires September 10, 2009              [Page 16]


Internet-Draft       Neighbor Discovery for 6LoWPAN           March 2009


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

      Code:  0 indicates a message sent directly from the orginating
         host. 1 indicates that the message has been relayed by a
         router.

      Checksum:  The ICMP checksum.

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

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

      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 amout of time in units of
         seconds remaining before the binding of this owner interface
         identifier, and all associated address options and
         configuration options, MUST be considered expired.  A value of
         zero indicates that the Binding Cache entries for the
         registered owner interface identifier MUST be deleted.

      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 dervied 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 RR/RC
         messages.  Such options are not defined in this document.





Shelby, et al.         Expires September 10, 2009              [Page 17]


Internet-Draft       Neighbor Discovery for 6LoWPAN           March 2009


      Source link-layer address:  Included in a Relay RR message in case
         the Owner Interface Identifier is not the same as the link-
         layer address of the host interface.  Format as defined in
         [RFC4861] and [RFC4944].  If the RR was relayed, then this
         option MAY be added to the RC by the relaying router to
         indicate the identity of the ER for use by a host.

      Target link-layer address:  Included in a relayed RC message in
         case the Owner Interface Identifier is not the same as the
         link-layer address of the host interface.  Format as defined in
         [RFC4861] and [RFC4944].  MAY be included in an RR message from
         a host to a router to indicate the prefered edge router to
         relay the message to.

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


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |     Code      |          Checksum             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Cur Hop Limit |M|O|H|Prf|P|R|R|       Router Lifetime         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Reachable Time                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Retrans Timer                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Options ...
     +-+-+-+-+-+-+-+-+-+-+-+


               Figure 8: Router Advertisement Message Format

   IP Fields:

      Source Address:  MUST be the link-local address assigned to the
         interface from which this message is sent.





Shelby, et al.         Expires September 10, 2009              [Page 18]


Internet-Draft       Neighbor Discovery for 6LoWPAN           March 2009


      Destination Address:  Typically the Source Address of an invoking
         Router Solicitation or the all-nodes multicast address.

      Hop Limit:  255

   ICMP Fields:

      Type:  134

      Code:  0

      Checksum:  The ICMP checksum.

      Cur Hop Limit:  As specified in [RFC4861].

      M: As specified in [RFC4861] with the exception that managed mode
         here refers to the claim and defend address mechanism specified
         in this document, not DHCPv6 as in [RFC4861].

      O: As specified in [RFC4861].

      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.

      Router Lifetime:  As specified in [RFC4861].

      Reachable Time:  As specified in [RFC4861].

   Possible Options:

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

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

      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.






Shelby, et al.         Expires September 10, 2009              [Page 19]


Internet-Draft       Neighbor Discovery for 6LoWPAN           March 2009


4.3.  NS/NA Messages

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

4.4.  6LoWPAN ND Message Options

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

4.4.1.  Address Option

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

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





Shelby, et al.         Expires September 10, 2009              [Page 20]


Internet-Draft       Neighbor Discovery for 6LoWPAN           March 2009


   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.

   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:/10) 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 RR/RC message header.

      2: Suffix compressed and is derived from the 6LoWPAN short address
         option 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.







Shelby, et al.         Expires September 10, 2009              [Page 21]


Internet-Draft       Neighbor Discovery for 6LoWPAN           March 2009


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

    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 10: 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 for route over
      LoWPANs and backbone link LoWPANs, and MAY be set for mesh-under
      LoWPANs without a backbone.

   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.  The use
      of this Context Identifier is not specified in this document.







Shelby, et al.         Expires September 10, 2009              [Page 22]


Internet-Draft       Neighbor Discovery for 6LoWPAN           March 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.4.3.  Multihop Information 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.

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

                  Figure 11: Multihop Information Option

   Type:  TBD5

   Length:  1

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

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

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

4.4.4.  Owner Interface Identifier Option

   This option is 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.




Shelby, et al.         Expires September 10, 2009              [Page 23]


Internet-Draft       Neighbor Discovery for 6LoWPAN           March 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    |              TID              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Reserved                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                  Owner Interface Identifier                   +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 12: Owner Interface Identifier Option

   Type:  TBD6

   Length:  2

   TID:  A unique Transaction ID assigned by the host in the associated
      RR and used to match RC 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.


5.  LoWPAN Subnet

   In a LoWPAN, a link can be a very unstable set of nodes, for instance
   the set of nodes that can receive a packet that is broadcast over the
   air at that instant.  Such a set may vary from one packet to the next
   as the node moves or as the radio propagation conditions change.  In
   addition, a LoWPAN is a complex collection of NBMA links without
   multicast support.  As a result, a link does not define the proper
   set of nodes to perform ND operations such as Duplicate Address
   Detection and Address Resolution, nor is it stable enough to be
   assigned a prefix usable for routing or address configuration.
   Therefore in ND for 6LoWPAN, those operations are performed over the
   entire LoWPAN or Extended LoWPAN.  In LoWPANs it is critical that IP
   routing, homogeneous addressing across the LoWPAN, and the mobility
   of nodes are supported.

   In this document, a LoWPAN subnet is defined to be a collection of
   LoWPAN links interconnected by routers that have the same subnet
   prefix.  In particular, DAD is performed over a LoWPAN subnet for all



Shelby, et al.         Expires September 10, 2009              [Page 24]


Internet-Draft       Neighbor Discovery for 6LoWPAN           March 2009


   types of addresses, inclucing link-local.  Thus a LoWPAN subnet
   differs from the IPv6 subnet defined in [RFC4291] as the LoWPAN
   subnet is associated with a collection of links and is a multi-link
   subnet.  In a LoWPAN, setting the hop-limit to 1 limits a packet to
   the link, but hop limit assumptions MUST NOT be made about the
   subnet.  Multi-link subnet issues are discussed in [RFC4903].  The
   issues pointed out in [RFC4903] are not relevant in 6LoWPAN where
   existing applications do not exist, and the network is a variation of
   NBMA.

   In the backhaul model, the edge router's interface and all the LoWPAN
   Node interfaces registered to that edge router form a subnet.  In
   this model, the edge router serves all the prefixes that are defined
   on the subnet and can be connected to an IP routed infrastructure.
   With the backhaul model, in a mesh under network the link and subnet
   are equivalent as the link spans the entire LoWPAN.

   In the backbone model, a Backbone Link federates multiple LoWPANs
   into a single subnet.  Each LoWPAN is a collection of links anchored
   at an edge router.  The edge routers interconnect the LoWPANs over
   the Backbone Link.  A node can move freely from a LoWPAN anchored at
   an edge router to a LoWPAN anchored at another edge router in the
   same subnet and conserve its link-local and any other IPv6 address it
   has formed.


6.  LoWPAN Node Specification

   Instead of relying on multicast ND messages for DAD and neighbor
   address resolution, LoWPAN Nodes make use of an edge router in the
   LoWPAN which keeps a whiteboard of all bound addresses from nodes
   attached to that ER.  In addition, ERs may support a backbone link,
   creating an extended LoWPAN sharing the same subnet prefix.  This
   allows a node to change its point of attachment without changing its
   IPv6 addresses.  This specification simplifies address resolution
   compared to standard IPv6 ND.  Claim and defend addressing is also
   specified as part of the binding process.  This section specifies
   LoWPAN node operations.

6.1.  Forming addresses

   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



Shelby, et al.         Expires September 10, 2009              [Page 25]


Internet-Draft       Neighbor Discovery for 6LoWPAN           March 2009


   Optimistic Duplicate Address Detection (oDAD) [RFC4429] over the
   Transit Link and the LoWPAN.  The address SHOULD be created as
   optimistic to enable its use in the binding process with the edge
   router.

   To simplify address resolution it is assumed that nodes within a
   LoWPAN use addresses in a homogeneous way and that the unicast IPv6
   address IIDs resolve directly to a corresponding link-layer address.
   Thus avoiding address resolution whenever possible.

   Nodes MAY learn the address of edge routers or routers using
   traditional means such as L2 configuration or Router Advertisement
   messages.  This specification also introduces a new anycast address
   6LOWPAN_ER that the node can use to reach any edge router or router
   on the link.  This specification tolerates movement within the LoWPAN
   so the node does not have to stick with a given router and MAY keep
   using the 6LOWPAN_ER anycast address for all its registrations.

   The node SHOULD also form a global unicast address for routing inside
   the LoWPAN and reachability from outside of the Extended LoWPAN.  If
   a valid prefix is available from an RA ('A' flag is set), then a
   global unicast address is derived using SAA.  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 as specified in Section 9.

   This specification includes a method for requesting a unique address
   from the edge router 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 fasion.  The node
   can tell if address generation is available if the 'M' flag of the RA
   from that router is set.  Address generation using the RR/RC
   mechanism is stateless.  Although the address is generated by the ER
   and checked for uniqueness across the LoWPAN using DAD, 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.

6.2.  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 edge router.

   The LoWPAN Node uses unicast Router Registrations to perform the
   binding.  The destination address is that of an on-link edge router



Shelby, et al.         Expires September 10, 2009              [Page 26]


Internet-Draft       Neighbor Discovery for 6LoWPAN           March 2009


   or router, or the 6LOWPAN_ER anycast address.  Registration SHOULD be
   preferred with on-link ERs rather than Routers.  The Preference Flag
   of the RA is used to differentiate between ERs (Prf=01) and routers
   (Prf=00).  The source address is the link local address of the node.
   A unique Owner Interface Indentifier is included in the Router
   Registration so the binding can be identified throughout the subnet.
   This is usually the EUI-64 identifier of the interface.  The RR
   message includes an Address Option for each address to be registered.
   Thus the message is structured as follows.

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

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

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

   If no Router Confirmation is received within an implementation
   specific timeout and number of retries, then there may be no edge
   routers in the LoWPAN.  See Section 9 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.  The use of this mechanism
   for fault tolerance is explained in Section 8.6.

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





Shelby, et al.         Expires September 10, 2009              [Page 27]


Internet-Draft       Neighbor Discovery for 6LoWPAN           March 2009


6.3.  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 LoWPAN subnet with that prefix may be larger than the
   link in route over topologies, unless the destination address exists
   in the neighbor cache.  Link-layer information should be used to
   maintain the neighbor cahce whenever possible rather than using ND
   traffic.  The ERs and routers used for registration are kept in the
   default router List.  Multicast addresses resolve to a broadcast as
   specified in [RFC4944].

6.4.  Address lookup

   A LoWPAN node does not use multicast for its Neighbor Solicitation as
   prescribed by IPv6 ND [RFC4861] and oDAD [RFC4429].  When lookup is
   necessary, all NS messages are sent in unicast to the edge router,
   which answers in unicast as well.  The message is a standard Neighbor
   Solicitation but for the destination is set to the edge router
   address or the well known 6LOWPAN_ER anycast address as opposed to
   the solicited-node multicast address for the destination address.  A
   LoWPAN Node SHOULD retain a small queue for packets to neighbors
   awaiting to be delivered while address lookup is being performed.
   The size of the queue should be suitable to the available RAM of the
   node, and is not required to be a minimum of one buffer per neighbor
   as in [RFC4861].

   The Target link-layer address in the response is either that of the
   destination if a short cut is possible over the LoWPAN, or that of
   the edge router if the destination is reachable over the Transit
   Link, in which case the edge router will terminate 6LoWPAN and relay
   the packet.

   A LoWPAN Node does not need to join the solicited-node multicast
   address for its own addresses and SHOULD NOT have to answer a
   multicast Neighbor Solicitation.  It MAY be configured to answer a
   unicast NS but that is not required by this specification.

   Care must be used with the 6LOWPAN_ER and other anycast addresses, as
   anycast resolution is normally performed with a multicast NS/NA
   exchange.  As nodes are not required to answer NS messages, the next
   hop determination process SHOULD map the anycast address to the link
   layer address of a neighbor using available L2 or other ND
   information.







Shelby, et al.         Expires September 10, 2009              [Page 28]


Internet-Draft       Neighbor Discovery for 6LoWPAN           March 2009


7.  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 an entire
   LoWPAN subnet, rather than a single IP link.  This section describes
   ND for 6LoWPAN router operations.  Note that this section does not
   apply to mesh under LoWPANs.

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

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

7.1.  Router Configuration Variables

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

7.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 initializes.  The router
   MUST learn these variables (e.g.  AdvCurHopLimit, AdvReachableTime,
   prefix information, etc.) from neighboring routers.  While the
   variables are not initialized, the router MAY send Router
   Advertisement with the "Solicit" flag set to solicit Router
   Advertisements from neighboring routers.  However, the router MUST
   set the Router Lifetime field to zero while one or more of its
   variables are uninitialized.

7.3.  Router Advertisement Message Content

   A router sends periodic as well as solicited Router Advertisements
   out its advertising interface.  Outgoing Router Advertisements are



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


Internet-Draft       Neighbor Discovery for 6LoWPAN           March 2009


   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:

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

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

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

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






Shelby, et al.         Expires September 10, 2009              [Page 30]


Internet-Draft       Neighbor Discovery for 6LoWPAN           March 2009


7.4.  Sending Unsolicited Router Advertisements

   As specified in Section 6.2.4 of [RFC4861].

7.5.  Ceasing To Be an Advertising Interface

   As specified in Section 6.2.5 of [RFC4861].

7.6.  Processing Router Solicitations

   As specified in Section 6.2.6 of [RFC4861].

7.7.  Relaying a Router Registration Message

   When a router receives a Router Registration message from a LoWPAN
   Node, it sets the Code field to 1 indicating that the message has
   been relayed.  The IPv6 source address is set to that of the router.

   By default, the router relays Router Registration messages to the
   6LOWPAN_ER anycast address.  However, the router MAY be configured to
   use a list of destination addresses, which MAY include unicast
   addresses, the 6LOWPAN_ER anycast address, or other addresses
   selected by the network administrator.  If the RR includes a Target
   link-layer address option, then that SHOULD be used to form the
   desination address as it indicates the ER which the LoWPAN node
   prefers.

7.8.  Relaying a Router Confirmation Message

   When the router receives a Relay Router Confirmation message from an
   edge router, the Code field is set to 1.  The Owner Interface
   Identifier is used to form the IPv6 Destination Address for the
   Router Confirmation message.  If a Target link-layer address option
   is included in the message, then that is used to form the IPv6
   destination address instead of the Owner Interface Identifier.  The
   IPv6 source address is set to that of the Router.  The Hop Limit of
   the Router Confirmation message is set to 255.


8.  LoWPAN Edge Router Specification

   Edge routers are introduced to scale the Neighbor Discovery
   Operations by reducing the amount of costly multicast ND messages
   over a LoWPAN subnet that may cover hundreds or thousands of nodes.

   Instead of multicasting ND messages, a LoWPAN Node performs unicast
   exchanges with an edge router to claim and lookup addresses using
   unicast and anycast addresses, and the edge router performs ND



Shelby, et al.         Expires September 10, 2009              [Page 31]


Internet-Draft       Neighbor Discovery for 6LoWPAN           March 2009


   operations on its behalf over the Backbone Link when necessary, for
   example DAD.

   This specification documents the extensions to IPv6 Neighbor
   Discovery that enables a LoWPAN Node to claim and lookup addresses
   using an edge router as an intermediate proxy.  The draft also
   documents the use of EUI-64 based link-local addresses and the way
   they are claimed by the edge routers over the Backbone link.

   This specification documents the LoWPAN whiteboard, a conceptual data
   structure that is similar to the MIPv6 binding cache.

   Another function of the edge router is to perform 6LoWPAN compression
   and uncompression between the LoWPAN and the Backbone Link and ensure
   MTU compatibility.  Packets flow uncompressed over the Backbone Link
   and are routed normally towards a Gateway or an Application sitting
   on the Backbone link or on a different link that is reachable via IP.

8.1.  Registration process

   Upon a new registration for a link-local or global unicast address
   based on an IEEE 64-bit extended MAC address, the edge router MAY use
   optimistic DAD on the Transit Link.  A positive acknowledgement can
   be sent to the 6LoWPAN node right away if oDAD is used on the Transit
   Link.

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

   The new Owner Interface Identifier Option in NS/NA messages that
   carries the node EUI-64 address and the lollypop mechanism on the TID
   help differentiate an address collision over the backbone from a
   movement of a node from one edge router to the next.  More details on
   collision detection and resolution are provided in Section 8.4.

   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



Shelby, et al.         Expires September 10, 2009              [Page 32]


Internet-Draft       Neighbor Discovery for 6LoWPAN           March 2009


   an NA message with the override (O) bit set.

   So the edge router operation on the transit 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 8.6.

   The edge router responds to a Router Registration with a Router
   Confirmation.  The source address is a link-local address of the
   router and the destination is the optimistic address of the node from
   which the RR was received.  The ER responds to relayed RR messages
   with an RC message, where the destination address is the address of
   the Router which sent the relayed RR message.

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

   If the RR message includes an Address Option with the 'A' flag set,
   this indicated the request of stateless address generation.  If the
   ER supports managed address mode ('M' flag set in its RAs), then the
   ER aquires an appropriate, unique link-layer address for the network
   either by generating it and performing DAD, or with some other
   method.  If successful, this address is returned in an Address Option
   of the RC with the 'A' flag set and the assigned IPv6 address formed
   from the generated link-layer address with the defualt prefix inline.

8.2.  Exposing the edge router

   The Backbone link is used as a reference for Neighbor Discovery
   operations.  When an edge router does not have an entry in its
   registration table for a target node, it looks it up over the
   backbone using ND an operation in place for that medium. edge routers



Shelby, et al.         Expires September 10, 2009              [Page 33]


Internet-Draft       Neighbor Discovery for 6LoWPAN           March 2009


   also represent the LoWPAN Nodes that are proactively registered to
   them.  That way, a lookup over the backbone is not propagated over
   the LoWPANs, but answered by the edge router that has the
   registration for the target, if any.

   To enable proxying over the backbone Link, an edge router must join
   the solicited-node multicast address on that link for all the
   registered addresses of the nodes in its LoWPANs.  The edge router
   answers the Neighbor Solicitation with a Neighbor Advertisement that
   indicates its own link-layer address in the Target link-layer address
   option.

   An edge router expects and answers unicast Neighbor Solicitations for
   all nodes in its LoWPANs.  It answers as a proxy for the real target.
   The target link-layer address in the response is either that of the
   destination if a short cut is possible over the LoWPAN, or that of
   the Backbone Router if the destination is reachable over the Transit
   Link, in which case the Backbone Router will terminate 6LoWPAN and
   relay the packet.

   The edge router forms a link-local address in exactly the same way as
   any other node on the LoWPAN.

   The edge router configures the well known 6LOWPAN_ER anycast address
   on the LoWPAN interfaces where it serves as edge router.  Note that
   the edge router will accept registration packets with a hop limit
   that is lower than 255 on that specific address.

   The edge router announces itself using Router Advertisement (RA)
   messages that are broadcasted periodically over the LOWPAN and the
   backbone link.  The edge router MAY also announce any prefix that is
   configured on the transit link, and serve as the default gateway for
   any node on the Transit Link or on the attached LoWPANs.

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

   LoWPAN Nodes SHOULD form IPv6 packets that are smaller than that MTU.
   As a result, those packets should not require any fragmentation over
   the transit link though they might be intranet-fragmented over the
   LoWPAN itself as prescribed by [RFC4944].

   More information on the MTU issue with regard to ND-proxying can be
   found in Neighbor Discovery Proxies [RFC4389] and



Shelby, et al.         Expires September 10, 2009              [Page 34]


Internet-Draft       Neighbor Discovery for 6LoWPAN           March 2009


   [I-D.van-beijnum-multi-mtu].

8.3.  Forwarding packets

   Upon receiving packets on one of its LoWPAN interfaces, the Edge
   Router checks whether it has a binding for the source address.  If it
   does, then the edge router can forward the packet to another LoWPAN
   Node or over the Backbone link.  The hop limit is decremented upon
   forwarding.  Otherwise, the edge router MUST discard the packet.  If
   the packet is to be transmitted over the Transit link, then the
   6LoWPAN sublayer is terminated and the full IPv6 packet is
   reassembled and expanded.

   When forwarding a packet from the Backbone Link towards a LoWPAN
   interface, the edge router performs the 6LoWPAN sublayer operations
   of compression and fragmentation and passes the packet to the lower
   layer for transmission.

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

   The address collision can be detected within the edge router if the
   edge router already has a registration for a given address, or over
   the transit link using Duplicate Address Detection.  The edge router
   in charge of the resolution is the edge router that handles the
   registration.

   The general principles are as follows:

      Mobility is included and welcome.  A node may migrate its
      registration to a new edge router transparently and at any time.
      The protocol is designed to recognize the mobility and silently
      cleanup the registration states.

      A synchronous operation wins against a delayed proxy operation.
      An edge router that processes a router registration normally takes
      over an existing registration maintained by a defendant edge
      router.

      The decision to migrate the registration from an edge router to
      another is made by the edge router that processes a Router
      Registration message based on its own states for that registration
      and ND exchanges over the transit link.




Shelby, et al.         Expires September 10, 2009              [Page 35]


Internet-Draft       Neighbor Discovery for 6LoWPAN           March 2009


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

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

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

   If no entry is found for that address and DAD times out, the edge
   router accepts the registration: it creates an entry on the
   whiteboard, sends a positive Router Confirmation Message to the node,
   and advertises the address on the transit link.  Since this happens
   asynchronously to the Router Registration, the edge router SHOULD NOT
   set set Override (O) bit in the NA message.

   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 8.5.  If no duplication is detected,
   then the edge router accepts the update of the reservation: it
   updates a entry on the whiteboard, sends a positive Router
   Confirmation Message to the node, and advertises the address on the
   transit link.  Since this happens synchronously to the Router
   Registration, the edge router SHOULD set set Override (O) bit in the
   NA message.

   If the address is already present on the transit link and defended by
   a remote edge router, then that edge router defends the address with
   the Override (O) bit reset and the Owner Interface Identifier Option
   in the NA message.

   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



Shelby, et al.         Expires September 10, 2009              [Page 36]


Internet-Draft       Neighbor Discovery for 6LoWPAN           March 2009


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

8.5.  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 Router Confirmation message.  At least the 4 most
   recent values for a TID are also kept by the edge router in the
   whiteboard entry for validation purpose.

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

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




Shelby, et al.         Expires September 10, 2009              [Page 37]


Internet-Draft       Neighbor Discovery for 6LoWPAN           March 2009


   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 lollypop this can be
   interpreted as either a new node competing for the OII and a reboot
   by the node owning the registration.  With this specification, this
   situation is optimistically interpreted as a reboot and not reported
   as a collision, but an actual collision will be detected and filtered
   out next.

   Otherwise, if an inconsistent TID value is detected between the new
   TID and the most recently accepted value, then the edge router
   compares with the older TID values that are saved in the whiteboard
   entry for that registration.  This might occur for instance with an
   entry that was rendered non-operational when the address was taken
   over by another edge router.

   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.

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



Shelby, et al.         Expires September 10, 2009              [Page 38]


Internet-Draft       Neighbor Discovery for 6LoWPAN           March 2009


   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.


9.  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 router in the LoWPAN implements 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.  The election of such an edge router in an ad-hoc network
   is implementation specific.  There SHOULD be only one edge router in
   an ad-hoc 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 eachother, and to
   coordinate the ULA prefix then there MAY be multiple edge routers.

   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.


10.  Message Examples

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

10.1.  Basic RR/RC message exchange

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



Shelby, et al.         Expires September 10, 2009              [Page 39]


Internet-Draft       Neighbor Discovery for 6LoWPAN           March 2009


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

    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 13: Basic RR message.


    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 14: 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 15: Address Option 2, for the requested address.





Shelby, et al.         Expires September 10, 2009              [Page 40]


Internet-Draft       Neighbor Discovery for 6LoWPAN           March 2009


10.2.  Relayed RR/RCC message exchange

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

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


                      Figure 16: Relayed RR message.

10.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 generated addresses
   are available, the Preference flag is 00 for normal, and a 1200s
   Route Lifetime is advertised.  A 6LoWPAN Prefix Information Option is
   included.












Shelby, et al.         Expires September 10, 2009              [Page 41]


Internet-Draft       Neighbor Discovery for 6LoWPAN           March 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 = 134   |   Code = 0    |          Checksum             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Cur Hop Limit |1|0|0|00 |Rsrvd|    Router Lifetime = 1200     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Reachable Time = 0                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Retrans Timer = 0                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                      Figure 17: 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 18: 6LoWPAN Prefix Information Option example.


11.  Security Considerations

   This specification expects that the link layer is sufficiently
   protected, either by means of physical or IP security for the
   backbone link or MAC sublayer cryptography.  In particular, it is
   expected that the LoWPAN MAC provides secure unicast to/from Routers
   and secure broadcast from the Routers in a way that prevents
   tempering with or replaying the RA messages.  However, any future
   6LoWPAN security protocol that applies to Neighbor Discovery for
   6LoWPAN protocol, is out of scope of this document.

   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.




Shelby, et al.         Expires September 10, 2009              [Page 42]


Internet-Draft       Neighbor Discovery for 6LoWPAN           March 2009


12.  IANA Considerations

   This document requires two new ICMPv6 message types:

      Router Registration (TBD1)

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

      Multihop Information Option (TBD5)

      Owner Interface Identifier Option (TBD6)

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


13.  Acknowledgments

   The authors thank Carsten Bormann, Geoff Mulligan and Julien Abeille
   for useful discussions and comments that have helped shaped and
   improve this document.


14.  References

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



Shelby, et al.         Expires September 10, 2009              [Page 43]


Internet-Draft       Neighbor Discovery for 6LoWPAN           March 2009


              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.

   [RFC4429]  Moore, N., "Optimistic Duplicate Address Detection (DAD)
              for IPv6", RFC 4429, April 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.

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

   [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)",



Shelby, et al.         Expires September 10, 2009              [Page 44]


Internet-Draft       Neighbor Discovery for 6LoWPAN           March 2009


              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.

   [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
   Kidekuja 2
   Vuokatti  88600
   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 September 10, 2009              [Page 45]


Internet-Draft       Neighbor Discovery for 6LoWPAN           March 2009


   Samita Chakrabarti
   IP Infusion
   1188 Arquest Street
   Sunnyvale, California
   USA

   Phone:
   Email: samitac@ipinfusion.com


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

   Phone:
   Email: Erik.Nordmark@Sun.COM

































Shelby, et al.         Expires September 10, 2009              [Page 46]


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