[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: May 22, 2009                                              Cisco
                                                                  J. Hui
                                                               Arch Rock
                                                          S. Chakrabarti
                                                             IP Infusion
                                                             E. Nordmark
                                                                     Sun
                                                       November 18, 2008


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

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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 May 22, 2009.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   This document specifies Neighbor Discovery optimized for 6LoWPAN.



Shelby, et al.            Expires May 22, 2009                  [Page 1]


Internet-Draft       Neighbor Discovery for 6LoWPAN        November 2008


   The 6LoWPAN format allows IPv6 to be used over very low-power, low-
   bandwidth wireless networks often making use of extended multihop
   topologies.  However, the use of standard IPv6 Neighbor Discovery
   over 6LoWPAN networks has several problems.  Standard Neighbor
   Discovery was not designed for wireless links, the standard IPv6 link
   concept and heavy use of multicast makes it inefficient.  This
   document spefies a new mechanism allowing efficient Duplicate Address
   Detection over entire 6LoWPAN networks.  In addition it specifies
   prefix and context dissemination for use with router advertisements,
   allows for stateless address assignment, and the use of Neighbor
   Discovery Proxy.

   This document is an identical replacement of
   draft-shelby-6lowpan-nd-01.  This document was now submitted as a
   6lowpan working group document.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Goals & Assumptions  . . . . . . . . . . . . . . . . . . .  5
     1.2.  Why not standard IPv6 ND?  . . . . . . . . . . . . . . . .  6
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  7
   3.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  8
     3.1.  Bootstrapping  . . . . . . . . . . . . . . . . . . . . . . 12
     3.2.  Basic operation  . . . . . . . . . . . . . . . . . . . . . 13
     3.3.  Optional features  . . . . . . . . . . . . . . . . . . . . 13
   4.  6LoWPAN ND Messages  . . . . . . . . . . . . . . . . . . . . . 13
     4.1.  Router Registration/Confirmation Message . . . . . . . . . 14
     4.2.  Router Advertisement Message . . . . . . . . . . . . . . . 16
     4.3.  Neighbor Solicitation Message  . . . . . . . . . . . . . . 18
     4.4.  6LoWPAN ND Message Options . . . . . . . . . . . . . . . . 18
       4.4.1.  Address Option . . . . . . . . . . . . . . . . . . . . 18
       4.4.2.  6LoWPAN Prefix Information Option  . . . . . . . . . . 20
       4.4.3.  Multihop Information Option  . . . . . . . . . . . . . 21
       4.4.4.  Host Interface Identifier Option . . . . . . . . . . . 21
   5.  LoWPAN Subnet  . . . . . . . . . . . . . . . . . . . . . . . . 22
   6.  LoWPAN Node Specification  . . . . . . . . . . . . . . . . . . 23
     6.1.  Forming addresses  . . . . . . . . . . . . . . . . . . . . 23
     6.2.  Registration process . . . . . . . . . . . . . . . . . . . 24
     6.3.  Next-hop determination . . . . . . . . . . . . . . . . . . 25
     6.4.  Address lookup . . . . . . . . . . . . . . . . . . . . . . 25
   7.  LoWPAN Router Specification  . . . . . . . . . . . . . . . . . 26
     7.1.  Router Configuration Variables . . . . . . . . . . . . . . 26
     7.2.  Becoming an Advertising Interface  . . . . . . . . . . . . 27
     7.3.  Router Advertisement Message Content . . . . . . . . . . . 27
     7.4.  Sending Unsolicited Router Advertisements  . . . . . . . . 29
     7.5.  Ceasing To Be an Advertising Interface . . . . . . . . . . 29



Shelby, et al.            Expires May 22, 2009                  [Page 2]


Internet-Draft       Neighbor Discovery for 6LoWPAN        November 2008


     7.6.  Processing Router Solicitations  . . . . . . . . . . . . . 29
     7.7.  Router Advertisement Consistency . . . . . . . . . . . . . 29
     7.8.  Relaying a Router Registration Message . . . . . . . . . . 29
     7.9.  Relaying a Router Confirmation Message . . . . . . . . . . 29
   8.  LoWPAN Edge Router Specification . . . . . . . . . . . . . . . 29
     8.1.  Registration process . . . . . . . . . . . . . . . . . . . 30
     8.2.  Exposing the Edge Router . . . . . . . . . . . . . . . . . 31
     8.3.  Forwarding packets . . . . . . . . . . . . . . . . . . . . 33
     8.4.  Fault tolerance  . . . . . . . . . . . . . . . . . . . . . 33
   9.  Ad-hoc LoWPAN Operation  . . . . . . . . . . . . . . . . . . . 33
   10. Message Examples . . . . . . . . . . . . . . . . . . . . . . . 33
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 33
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 34
   13. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 34
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 34
     14.2. Informative References . . . . . . . . . . . . . . . . . . 35
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
   Intellectual Property and Copyright Statements . . . . . . . . . . 37
































Shelby, et al.            Expires May 22, 2009                  [Page 3]


Internet-Draft       Neighbor Discovery for 6LoWPAN        November 2008


1.  Introduction

   The IPv6 over IEEE 802.15.4 [RFC4944] document has specified IPv6
   headers carried over an IEEE 802.15.4 network with the help of an
   adaptation header which comes before the IP header.  A LoWPAN network
   is characterized as a low-power, low bit-rate, short range, low cost
   network.  Thus, all-node multicast defined in IPv6 Neighbor Discovery
   [RFC4861] is not often desirable in a wireless low-power, lossy
   network.  In addition IEEE 802.15.4 and similar wireless technologies
   do not have multicast support, but supports broadcast.  Broadcast
   messages could be used in some cases to represent all-node multicast
   messages, but periodic broadcast messages should be minimized in
   LoWPANs in order to conserve energy.  Moreover, LoWPAN nodes are
   transient in nature; they are not always considered to be in a fixed
   network nor they are bounded by our standard definition of a wired-
   link.  The link is 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 the 6lowpan network.

   The goal of this document is to minimize/remove periodic multicast
   signals used by IPv6 Neighbor Discovery [RFC4861] while enabling the
   LoWPAN to work as efficiently and optimally as possible and reducing
   the complexity of LoWPAN node implementations.

   Neighbor discovery for 6LoWPAN provides for basic bootstrapping, and
   network operation, along with advanced features such as stateless
   address assignment and ND-Proxy, while avoiding the use of multicast
   and providing both mesh under and route over support.  Unlike
   standard IPv6 ND [RFC4861], this document takes the lossy
   characteristics of wireless networks into account.

   The concept of a LoWPAN whiteboard located at Edge Routers is
   introduced, which allows for duplicate address detection and
   stateless address assignment for the entire LoWPAN.  Address
   resolution simplifications are included to make LoWPAN operation
   efficient and reduce LoWPAN Nodes complexity.  A new registration/
   confirmation message sequence is specified, allowing nodes to
   register their IPv6 addresses with an Edge Router, and to request
   global unique address assignment.

   The ER whiteboard makes use of soft bindings, thus nodes send
   periodic registration messages in order to maintain their binding and
   address assignments.  Changes in network topology, and mobility
   between ERs and subnets are supported.  The dissemination of RA
   information throughout multihop route over networks is also
   discussed.




Shelby, et al.            Expires May 22, 2009                  [Page 4]


Internet-Draft       Neighbor Discovery for 6LoWPAN        November 2008


   This paper also specifies the use of ND Proxy by Edge Routers,
   allowing for the seamless integration of an extended LoWPAN and
   multiple Edge Routers on a shared backbone link (e.g.  Ethernet) to
   form a single IPv6 subnet.  This allows hosts to keep the same IPv6
   address throughout a large network, and allows for easy
   communications with backbone link IPv6 hosts.

   This paper 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 prefix and context information throughout the
      LoWPAN.

      o Minimize the complexity of LoWPAN nodes.

      o Interconnect LoWPANs with backbone links seamlessly.

      o Provide a mechanism for stateles address assignment.

   Assumptions:

      o Either [RFC4944] or [draft-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 The use of optimistic DAD.

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

      o A subnet covers all the LoWPANs and their backbone link with the
      same IPv6 global or local prefix.




Shelby, et al.            Expires May 22, 2009                  [Page 5]


Internet-Draft       Neighbor Discovery for 6LoWPAN        November 2008


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.  Besides often these low-powered nodes
   conserve energy by using sleep schedules; waking them up to receive
   IPv6 signaling messages such as multicast messages for NS, and
   periodic RA is not practical.  Nor they are capable of processing
   address-resolution for its neighbors effectively.  Besides due to
   radio strength of its neighboring router or its own strength, a node
   may often move between one subnet to another without physically
   moving from one place to another.  Considering the above
   characteristics in a LoWPAN, and IPv6 Neighbor Discovery [RFC4861]
   base protocol requirements, it was concluded that standard Neighbor
   Discovery is not suitable as it is and a 6lowpan-specific ND protocol
   would be useful and efficient for wide deployment of IPv6 over low-
   powered wireless networks of embedded devices.







Shelby, et al.            Expires May 22, 2009                  [Page 6]


Internet-Draft       Neighbor Discovery for 6LoWPAN        November 2008


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 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/802.15.4 interface.  A
      LoWPAN Router may also serve as a LoWPAN Host - both sourcing and
      sinking IPv6 datagrams.  Refered to as a Router in this document.
      All LoWPAN Routers perform ND message relay on behalf of other
      nodes.

   Mesh Under

      A LoWPAN configuration where the link-local scope is defined by
      the boundaries of the LoWPAN and includes all nodes within.
      Multihop forwarding is achieved at L2 between mesh nodes.





Shelby, et al.            Expires May 22, 2009                  [Page 7]


Internet-Draft       Neighbor Discovery for 6LoWPAN        November 2008


   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 2 or more Edge Routers.
      It is expected to be deployed as a high speed backbone in order to
      federate a potentially large set of LoWPANS.

   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 Subnet

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

   Binding

      The association of the LoWPAN node IPv6 address and Interface ID
      with associated whiteboard and proxy 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] supporting 6LoWPAN low-power wireless stub
   networks.  Basic bootstrapping and network maintenenace mechanisms



Shelby, et al.            Expires May 22, 2009                  [Page 8]


Internet-Draft       Neighbor Discovery for 6LoWPAN        November 2008


   are provided, and the use of multicast for ND messages is avoided.
   Duplicate address detection and stateless address assignment are
   supported as part of bootstrapping.  This is achieved using a
   whiteboard located on the 6LoWPAN Edge Routers of the LoWPAN network.

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


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

                LoWPAN


                      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 on ND for
   6LoWPAN, is that it can always be assumed that the ER and hosts are
   on the same link.  Multicast with mesh under technologies most often
   induces flooding, and therefore it is avoided.










Shelby, et al.            Expires May 22, 2009                  [Page 9]


Internet-Draft       Neighbor Discovery for 6LoWPAN        November 2008


                   |
                   |
                   |
                +-----+
                |     | 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 those nodes reachable
   over a single radio transmission.  The implication for ND for 6LoWPAN
   is that if the ER is out of radio range of a host, the ND messages
   require relaying by intermediate Routers.  Multicast may also involve
   flooding in such networks, and is avoided.



             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.



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


Internet-Draft       Neighbor Discovery for 6LoWPAN        November 2008


   The simplest topology is a LoWPAN connected by a single Edge Router
   to another network, over a so-called backhaul link.  The Edge Router
   maintains a whiteboard of all hosts in the network, and assigns
   addresses.  The Edge Router terminates 6LoWPAN framing from the
   LoWPAN, and forwards packets.  Multiple such networks may also
   overlap to form an Extended LoWPAN.



         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 as a single IP link, the Extended LoWPAN.  Each LoWPAN is
   anchored at one or more Edge Router.  The Edge Routers interconnect
   the LoWPANs over the backbone link.  A node can move freely from a
   LoWPAN anchored at an Edge Router to a LoWPAN anchored at another
   Edge Router on the same backbone link and conserve its link local and
   any other IPv6 address it has formed.  If ND Proxy is used, a
   standard IPv6 Host on the backbone link can communicate with any host
   in the Extended LoWPAN and vice versa.

   The following sections explain the basics of how ND for 6LoWPAN
   works, starting with bootrapping on the network, maintenance of the
   network, and finally optional features such as ND Proxy.




Shelby, et al.            Expires May 22, 2009                 [Page 11]


Internet-Draft       Neighbor Discovery for 6LoWPAN        November 2008


3.1.  Bootstrapping

   A Host first performs stateless autoconfiguration of its link-local
   address for each 6LoWPAN interface from its EUI-64 as in [RFC4944].
   When a LoWPAN Host wants to join a LoWPAN network, it does so by
   listening for Route Advertisements from Edge Routers or Routers, or
   by broadcasting a Router Solicitations.  If a local or global prefix
   is included in the RA, the host may form an optimistic global unique
   address with stateless autoconfiguration.

   Next the Host registers with an on-link Edge Router or Router by
   sending a Router Registration (RR) message to it, either unicast or
   using the 6LOWPAN_ER anycast address.  These message exchanges are
   illustrated below.  The RR contains the addresses the node wants to
   register.  If the network is configured to assign, e.g., short
   addresses to nodes, this is incidated in the RA message with the M
   flag.  In such networks a node may request a stateless link-layer
   address to be assigned to it 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.  This Confirmation includes
   the set of addresses now bound to the whiteboard of the ER, including
   a possible assigned addresses.  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.



   Node                    Router (relay)                 Edge Router
    |                            |                             |
    |       ---- RR --->         |        ---- RR --->         |
    |                            |                             |
    |      <---- RC ----         |       <---- RC  ----        |
    |                            |                             |





Shelby, et al.            Expires May 22, 2009                 [Page 12]


Internet-Draft       Neighbor Discovery for 6LoWPAN        November 2008


                 Figure 6: Relay ND registration exchange.

3.2.  Basic operation

   The whiteboard address binding and assignment 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 current ER is no
   longer available, the host then starts the registration process with
   another ER.  If the host is still in the same Extended LoWPAN, its
   IPv6 addresses remain the same.  As assigned addresses are stateless,
   they 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 default prefix, the bootstrapping process is initiated
   again.  In route over networks, Routers that act as relays must
   disseminate RAs to their neighbors.  The Edge Router disseminates
   RAs, and this information is included in the RAs of each Router.

3.3.  Optional features

   ND Proxy is specified in [RFC4389], and allows for two segments to be
   merged into a single IPv6 link.  This documents explains the
   application of ND Proxy for use with Extended LoWPAN networks with
   multiple ERs on a backbone link.  This optional feature allows for
   DAD across the entire Extended LoWPAN and backbone links, and for the
   subnet to appear as a single IPv6 link.  This document extends ND
   Proxy to include an option to uniquely identify the LoWPAN Host on
   the backbone, and override the claim on an address on behalf of a
   LoWPAN Host.  Thus a Host can keep the same address, and appears the
   same to other Hosts on the backbone link, regardless of moving its
   binding from one ER to another.  Forwarding can be performed
   automatically regardless of which ER the host is proxied by.


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 the ICMPv6 Router Advertisement is updated with a new flag
   and options.

   The following new ICMPv6 message types are defined:

      Router Registration

      Router Confirmation




Shelby, et al.            Expires May 22, 2009                 [Page 13]


Internet-Draft       Neighbor Discovery for 6LoWPAN        November 2008


   In addition, the following new ICMPv6 options are defined:

      Address Option

      6LoWPAN Prefix Information Option

      Multihop Information Option

      Host 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 Relay 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|X| Reserved  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Reserved                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Lifetime                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                   Host 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.






Shelby, et al.            Expires May 22, 2009                 [Page 14]


Internet-Draft       Neighbor Discovery for 6LoWPAN        November 2008


      Destination Address:  The destination IPv6 address of an Edge
         Router or Edge Router Relay.  May be the 6LOWPAN_ER anycast
         address.

      Hop Limit:  255

   ICMP Fields:

      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.

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

      X: 1-bit Proxy Flag.  Only used in a confirmation, indicates that
         the router actually proxies for all of the addresses in the
         option fields that are being assigned to the node.  This can
         only happen if the P flag is set as well.  Set to 0 in a
         request.

      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.  Only used in a confirmation.

      Lifetime:  32-bit unsigned integer.  The amout of time in units of
         seconds remaining before the binding of this node 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 host 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.







Shelby, et al.            Expires May 22, 2009                 [Page 15]


Internet-Draft       Neighbor Discovery for 6LoWPAN        November 2008


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

      Source link-layer address:  Included in a Relay RR message in case
         the Host Interface Identifier is not the same as the link-layer
         address of the host interface.  Used as defined in [RFC4861]
         and [RFC4944].  If the RR was relayed, then this option is
         included in the RC to indicate the identity of the ER.

      Target link-layer address:  Included in a Relay RC message in case
         the Host Interface Identifier is not the same as the link-layer
         address of the host interface.  Used as defined in [RFC4861]
         and [RFC4944].

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

4.2.  Router Advertisement Message

   The RA message for 6LoWPAN is based on the [RFC4861] RA message with
   the addition of a new flag "E".  In addition 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|x|x|x|x|E|x|         Router Lifetime       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Reachable Time                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Retrans Timer                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Options ...
     +-+-+-+-+-+-+-+-+-+-+-+




Shelby, et al.            Expires May 22, 2009                 [Page 16]


Internet-Draft       Neighbor Discovery for 6LoWPAN        November 2008


               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.

      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 stateless address assignment mechanism
         specified in this document, not DHCPv6 as in [RFC4861].

      O: As specified in [RFC4861].

      x: Bits currently reserved for existing RA flags as per [RFC5175].

      E: 1-bit "Edge Router" flag.  When set, it indicates that the
         router is an Edge Router.

      Router Lifetime:  As specified in [RFC4861].

      Reachable Time:  As specified in [RFC4861].

   Possible Options:

      6LoWPAN Prefix Information Option:  This option includes
         information about the default subnet prefix for the LoWPAN
         along with other shared contexts for the subnet.

      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.




Shelby, et al.            Expires May 22, 2009                 [Page 17]


Internet-Draft       Neighbor Discovery for 6LoWPAN        November 2008


      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.3.  Neighbor Solicitation Message

   Neighbor Solicitation messages employed between ERs on the backbone
   link when ND proxy is used.  A unique identifier is required in the
   message as an option to uniquely identify a host's interface.  The
   standard NS message is used in this document is as per [RFC4861] with
   the an addition Host Interface Identifier Option defined in this
   document.  The Host Interface Identifier is the same as that carried
   in RR/RC messages and associated with the 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 stateless address assignment, 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.







Shelby, et al.            Expires May 22, 2009                 [Page 18]


Internet-Draft       Neighbor Discovery for 6LoWPAN        November 2008


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

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

   A: 1-bit Address Assignment flag.  Set to indicate that the host is
      requesting stateless address assignment.  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 in use, if
      any.

      0: Prefix is carried inline.

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

      2: Prefix compressed and the default prefix is assumed.

      3-15:  Reserved.

   S: 4-bit unsigned integer.  Identifies suffix compression in use, if
      any.

      0: Suffix carried inline.

      1: Suffix compressed and assumes the same value as the Host
         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-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 May 22, 2009                 [Page 19]


Internet-Draft       Neighbor Discovery for 6LoWPAN        November 2008


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.  When set, indicates that this prefix can be
      used for on-link determination.  When not set the advertisement
      makes no statement about on-link or off-link properties of the
      prefix.  In other words, if the L flag is not set a host MUST NOT
      conclude that an address derived from the prefix is off-link.
      That is, it MUST NOT update a previous indication that the address
      is on-link.

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






Shelby, et al.            Expires May 22, 2009                 [Page 20]


Internet-Draft       Neighbor Discovery for 6LoWPAN        November 2008


   CID:  4-bit Context Identifier for this prefix information.  The use
      of this Context Identifier is not specified in this document.

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

   This option is for use with standard NS and NA messages between ERs
   over a backbone link together with ND-Proxy.  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 May 22, 2009                 [Page 21]


Internet-Draft       Neighbor Discovery for 6LoWPAN        November 2008


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

                Figure 12: Host Interface Identifier Option

   Type:  TBD6

   Length:  2

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

   Host 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 instable set of nodes, for instance
   the set of nodes that can receive a packet that is broadcast over the
   air.  Such a set may vary from one packet to the next as the node
   moves or as the radio propagation conditions change.  As a result, a
   link does not define the proper set of nodes to perform ND operations
   such as Duplicate Address Detection and Neighbor lookup.  So in ND
   for 6LoWPAN, those operations are performed over a subnet.  A subnet
   is a collection of LoWPAN links interconnected by routers that may
   share one or more local or global prefixes.  In particular, DAD is
   performed over a subnet for all types of addresses, inclucing link
   local.

   In the backhaul model, an Edge Router and all the LoWPAN Nodes
   registered to that Edge Router form a subnet.  In that model, the
   Edge Router serves all the prefixes that are defined on its subnet
   and can be connected to an IP routed infrastructure.

   In the backbone model, a Backbone Link federates multiple LoWPANs
   into a single IP subnet.  Each LoWPAN is a collection of links
   anchored at an Edge Router.  The Edge Routers interconnect the



Shelby, et al.            Expires May 22, 2009                 [Page 22]


Internet-Draft       Neighbor Discovery for 6LoWPAN        November 2008


   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 the same ER.  In addition, ERs may perform ND proxy on a
   backbone link, creating an extended LoWPAN sharing the same subnet
   prefix.  ND proxy allows nodes to change their point of attachment
   without changing its IPv6 addresses.  This specification simplifies
   address resolution compared to standard IPv6 ND.  Stateless address
   assignment is also specified as part of the binding process.

6.1.  Forming addresses

   All nodes are required to autoconfigure at least one address, a link-
   local address that is derived from the IEEE 64-bit extended MAC
   address that is globally unique to the device as in [RFC4944].  As a
   result, knowledge of the 64-bit address of another node on the same
   extended LoWPAN is enough to derive its link-local address and reach
   it over IP.  Another consequence is that the link local address is
   presumably unique on the Extended LoWPAN, which enables the use of
   Optimistic Duplicate Address Detection (oDAD) [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.

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

   The node might also form Unique Local and Global Unicast addresses,
   for instance if it needs to be reachable from outside of the Extended
   LoWPAN.  If a Global Prefix is available from an RA ('A' flag is
   set), then a Global Unicast address can be derived using SAA.  This
   address is marked optimistic until confirmed by the ER.

   This specification includes a method for requesting a unique
   stateless address from the Edge Router by setting the 'A' flag in an



Shelby, et al.            Expires May 22, 2009                 [Page 23]


Internet-Draft       Neighbor Discovery for 6LoWPAN        November 2008


   Address Option during registration.  This is useful in the case of
   e.g. short addresses and avoids the need for a separate mechanism
   such as DHCPv6 or manual assignment.  The node can tell if address
   assignment is available if the 'M' flag of the RA from that router is
   set.  Address assignment using the RR/RC mechanism is stateless.
   Although the address is generated by the ER and checked for
   uniqueness across the subnet using DAD, it is just like any other
   address binding in the whiteboard of the ER after assignment.  Thus
   in order to keep using the assigned address the host must keep
   refreshing the address binding, including when moving to another ER
   in the same subnet.

   To simplify address resolution it is assumed that LoWPAN nodes are
   assigned addresses in a homogeneous so that the unicast IPv6
   addresses IID resolve directly to a corresponding link-layer address.
   Thus avoiding address resolution when possible.

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
   or Router or the 6LOWPAN_ER anycast address.  Registration SHOULD be
   preferred with on-link ERs rather than Routers.  The source address
   is the link local address of the node.  A unique Host Interface
   Indentifier is included in the Router Registration so the binding can
   be identified throughout the subnet.  This is usually the EUI-64
   identifier of the sending node.  The RR message includes an Address
   Option for each address to be bound or requested.  Thus the message
   is structured as follows.

   ICMPv6 (Router Registration (Address Options))

   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.

   The 'X' flag in the Router Confirmation Indentity Reply Option
   indicates that the Edge Router has completed DAD and now owns the



Shelby, et al.            Expires May 22, 2009                 [Page 24]


Internet-Draft       Neighbor Discovery for 6LoWPAN        November 2008


   Binding Address over the Transit Link.

   This specification also introduces the concept of a secondary
   binding.  For redundancy, a node might place a secondary binding with
   one or more other Edge Routers over a same or different LoWPANs.  The
   'P' flag in the Router Registration Indentity Request Option
   indicates whether the binding is primary.

   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 (with the same network prefix), the registration
   process begins from the beginning.

6.3.  Next-hop determination

   Next-hop determination is performed as in Section 5.2 of [RFC4861]
   with the following exceptions.  Global and Local prefix are assumed
   to be off-link as the LoWPAN subnet with that prefix may be much
   larger than the link in route over topologies, unless the destination
   address exists in the neighbor cache.  Link-layer information should
   be used to maintain the neighbor cahce whenever possible rather than
   using ND traffic.  The ERs and Routers used for registration are kept
   in the Default Router List.  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 the ND protocol [RFC4861] and oDAD [RFC4429].  When
   lookup is necessary, all NS messages are sent in unicast to the Edge
   Router, that answers in unicast as well.  The message is a standard
   Neighbor Solicitation but for the destination is set to the Edge
   Router address or the well known 6LOWPAN_ER anycast address as
   opposed to the solicited-node multicast address for the destination
   address.  A LoWPAN Node SHOULD retain a small queue for packets to
   neighbors awaiting to be delivered while address lookup is being
   performed.  The size of the queue should be suitable to the available
   RAM of the node, and is not required to be a minimum of one buffer
   per neighbor as in [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



Shelby, et al.            Expires May 22, 2009                 [Page 25]


Internet-Draft       Neighbor Discovery for 6LoWPAN        November 2008


   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.


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 must extend ND as specified in [RFC4861] to operate over an entire
   subnet, specifically the subnet controlled by Edge Routers, rather
   than a single IP link.

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

   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 the following conceptual variables to be
   configured by system management.  The specific variable names are
   used for demonstration purposes only, and an implementation is not
   required to have them, so long as its external behavior is consistent
   with that described in this document.  The meaning of these variables
   are as defined in Section 6.2.1 of [RFC4861].  Default values are
   specified to simplify configuration in common cases.

      - IsRouter





Shelby, et al.            Expires May 22, 2009                 [Page 26]


Internet-Draft       Neighbor Discovery for 6LoWPAN        November 2008


      - MaxRtrAdvInterval

      - MinRtrAdvInterval

      - AdvDefaultLifetime

   A router MUST allow the following conceptual variables to be
   configured by information received in Router Advertisement messages.
   The specific variable names are used for demonstration purposes only,
   and an implementation is not required to have them, so long as its
   external behavior is consistent with that described in this document.
   The meaning of these variables are as defined in Section 6.2.1 of
   [RFC4861].  However, default values are not relevant as a router
   should not be advertising such values until they have been received
   from other neighboring routers.

      - AdvManagedFlag

      - AdvOtherConfigFlag

      - AdvReachableTime

      - AdvRetransTimer

      - AdvCurHopLimit

      - AdvPrefixList

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
   filled with the following values constistent with the message format



Shelby, et al.            Expires May 22, 2009                 [Page 27]


Internet-Draft       Neighbor Discovery for 6LoWPAN        November 2008


   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.

      - The E flag is not set.

      - 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 May 22, 2009                 [Page 28]


Internet-Draft       Neighbor Discovery for 6LoWPAN        November 2008


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.  Router Advertisement Consistency

   TBD

7.8.  Relaying a Router Registration Message

   When a router receives a Router Registration message from a LoWPAN
   Node, it sets the Code 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 wants
   to prefer.

7.9.  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 Host 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 Host 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 subnet that may cover hundreds or thousands of nodes.



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


Internet-Draft       Neighbor Discovery for 6LoWPAN        November 2008


   Instead of multicasting ND messages, a LoWPAN Node performs unicast
   exchanges to its Edge Router to claim and lookup addresses using
   unicast and anycast addresses, and the Edge Router proxies the ND
   requests over the Backbone Link when necessary.

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

   For the purpose of Neighbor Discovery proxying, this specification
   documents the LoWPAN registration table, a conceptual data structure
   that is similar to the MIPv6 binding cache.

   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 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 renumber.  To enable this, the ND proxy operation upon a Router
   Registration/Confirmation flow wins the address ownership over a ND
   proxy operation that is done asynchronously, on behalf of the same
   LoWPAN Node, upon a prior registration.  So an Edge Router that would
   happen to have a binding for that same address for the same LoWPAN
   Node identified by its EUI-64 address will yield and deprecate its
   binding.

   The new Host Interface Identifier Option in NS/NA messages that
   carries the node EUI-64 address enables to differentiate an address
   collision from a movement of a node from one Edge Router to the next.
   Upon a registration flow, a node doing DAD SHOULD ignore NA without
   the the override (O) bit, and set the override (O) bit in its own NA
   messages.  Asynchronously to the registration, a node SHOULD NOT set
   the override (O) bit in its NA messages and should yield to an NA
   message with the override (O) bit set.

   So the Edge Router operation on the transit link is similar to that



Shelby, et al.            Expires May 22, 2009                 [Page 30]


Internet-Draft       Neighbor Discovery for 6LoWPAN        November 2008


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

   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 in the Identity Request Option and it is connected to a
   Backbone, then it SHOULD perform proxy ND operations on the backbone
   and indicate so in the Router Confirmation message using the 'X' flag
   of the Identity Reply Option.  In particular the Egde Router SHOULD
   reject the registration if DAD fails on the backbone.  When oDAD is
   used over the backbone the Edge Router MAY issue the Router
   Confirmation right away with a positive code, but if a collision is
   finally detected, it cancels the registration with an asynchronous
   Router Confirmation and a negative completion code on the same TID.

   If the RR message includes an Address Option with the 'A' flag set,
   this indicated the request of a stateless address assignment.  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 assigned link-layer address and the defualt prefix inline.

8.2.  Exposing the Edge Router

   The Backbone link is used as reference for Neighbor Discovery
   operations.  When an Edge Router does not have an entry in its
   registration table for a target node, it looks it up over the
   backbone using ND operation in place for that medium.  Edge Routers
   also perform ND proxying for the LoWPAN Nodes that are proactively
   registered to them.  That way, a lookup over the backbone is not



Shelby, et al.            Expires May 22, 2009                 [Page 31]


Internet-Draft       Neighbor Discovery for 6LoWPAN        November 2008


   propagated over the LoWPANs, but answered by the proxy 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.  It uses the same link local address
   for the Backbone Link and for all the associated LoWPAN(s) connected
   to that Edge Router.

   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.

   A new (E) bit in the RA indicates the Edge Router capability.  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]).



Shelby, et al.            Expires May 22, 2009                 [Page 32]


Internet-Draft       Neighbor Discovery for 6LoWPAN        November 2008


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

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

   To be completed in the next revision.


9.  Ad-hoc LoWPAN Operation

   To be completed in the next revision.


10.  Message Examples

   This section provides examples of creating and processing messages
   and options from this document along with example messages.

   To be completed in the next revision.


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.




Shelby, et al.            Expires May 22, 2009                 [Page 33]


Internet-Draft       Neighbor Discovery for 6LoWPAN        November 2008


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)

      Host Interface Identifier Option (TBD6)

   A new flag is required for the IPv6 ND Router Advertisement called
   the "E - Edge Router Flag".  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/icmpv6-parameters]


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.

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




Shelby, et al.            Expires May 22, 2009                 [Page 34]


Internet-Draft       Neighbor Discovery for 6LoWPAN        November 2008


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

   [RFC5175]  Haberman, B. and R. Hinden, "IPv6 Router Advertisement
              Flags Option", RFC 5175, March 2008.

14.2.  Informative References

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

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

   [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








Shelby, et al.            Expires May 22, 2009                 [Page 35]


Internet-Draft       Neighbor Discovery for 6LoWPAN        November 2008


   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


   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 May 22, 2009                 [Page 36]


Internet-Draft       Neighbor Discovery for 6LoWPAN        November 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Shelby, et al.            Expires May 22, 2009                 [Page 37]


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