6LoWPAN                                                       P. Thubert
Internet-Draft                                                     Cisco
Intended status: Standards Track                           July 10, 2008
Expires: January 11, 2009


                        6LoWPAN Backbone Router
                draft-thubert-6lowpan-backbone-router-01

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 January 11, 2009.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   ISA100.11a is a Working Group at the ISA SP100 standard committee
   that covers Wireless Systems for Industrial Automation and Process
   Control.  The WG is mandated to design a scalable, industrial grade
   LowPAN for devices such as sensors, valves, and actuators.  The
   upcoming standard uses the 6LoWPAN format for the network header.  It
   also introduces the concept of a Backbone Router to merge small
   LoWPANs via a high speed transit and scale the ISA100.11a network.
   This paper proposes an IPv6 version of the Backbone Router concept.



Thubert                 Expires January 11, 2009                [Page 1]


Internet-Draft           6LoWPAN Backbone Router               July 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Neighbor Binding messages  . . . . . . . . . . . . . . . . . .  6
     4.1.  Binding Solicitation message . . . . . . . . . . . . . . .  7
     4.2.  Binding Confirmation message . . . . . . . . . . . . . . .  8
   5.  LowPAN device operations . . . . . . . . . . . . . . . . . . . 10
     5.1.  Forming addresses  . . . . . . . . . . . . . . . . . . . . 10
     5.2.  Binding process  . . . . . . . . . . . . . . . . . . . . . 11
     5.3.  Looking up neighbor addresses  . . . . . . . . . . . . . . 12
     5.4.  Answering address look up  . . . . . . . . . . . . . . . . 12
   6.  Backbone router operations . . . . . . . . . . . . . . . . . . 13
     6.1.  Exposing the Backbone Router . . . . . . . . . . . . . . . 13
     6.2.  Binding process  . . . . . . . . . . . . . . . . . . . . . 14
     6.3.  Looking up neighbor addresses  . . . . . . . . . . . . . . 15
     6.4.  Answering address look up  . . . . . . . . . . . . . . . . 15
     6.5.  Forwarding packets . . . . . . . . . . . . . . . . . . . . 15
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 16
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
     10.2. Informative References . . . . . . . . . . . . . . . . . . 17
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
   Intellectual Property and Copyright Statements . . . . . . . . . . 19
























Thubert                 Expires January 11, 2009                [Page 2]


Internet-Draft           6LoWPAN Backbone Router               July 2008


1.  Introduction

   ISA100.11a is a Working Group at the ISA SP100 standard committee
   that covers Wireless Systems for Industrial Automation and Process
   Control.  The ISA100.11a is mandated to design a scalable, industrial
   grade wireless network and application layer suite of protocols for
   low power devices such as sensors and actuators, with a response time
   on the order of 100ms.

   The ISA100.11a WG has also introduced the concept of a Backbone
   Router that would interconnect small LoWPANs over a high speed
   transit network and scale a single ISA100.11a network up to the
   thousands of nodes.

   This paper specifies IP layer functionalities that are required to
   implement the concept of a Backbone Router with IPv6, in particular
   the application of the "IP Version 6 Addressing Architecture"
   [RFC4291], " the Neighbor Discovery Protocol" [RFC4861] and "IPv6
   Stateless Address Autoconfiguration" [RFC4862].  The use of EUI-64
   based link local addresses, Neighbor Discovery Proxying [RFC4389] and
   Optimistic Duplicate Address Detection [RFC4429] are discussed.
   Also, the concept of Transit Link is introduced to implement the
   transit network that is envisioned by ISA100.11a.

   An extension to the Neighbor Discovery Protocol is introduced to
   enable LoWPAN nodes to register to one or more Backbone Routers that
   acts as white board for address resolution.  This feature enables to
   avoid the use of multicast over a Low power Wireless Personal Area
   Network for the purpose of address resolution.

   The Backbone Router might also acts as proxy for the Neighbor
   Discovery Protocol for all nodes attached to it through a process of
   registration and enables to merge multiple LoWPANs via a transit link
   into a larger link.

   A Backbone Router advertises itself using a new option in the ND
   Router Advertisement Message.  A new anycast address 6LOWPAN_BBR is
   also introduced for the purpose of reaching the nearest Backbone
   Router in the absence of any information.  This enables to reduce the
   use of multicast RAs for the router discovery operation.  The routing
   to the nearest router that owns that anycast address is out of scope
   for this specifiation.

   Another anycast address 6LOWPAN-NODE is introduced to enable any
   LowPAN node to receive a response to its registration whether it
   completes successfully or not.

   The way the PAN IDs and 16-bit short addresses are allocated and



Thubert                 Expires January 11, 2009                [Page 3]


Internet-Draft           6LoWPAN Backbone Router               July 2008


   distributed in the case of an 802.15.4 network is not covered by this
   specification.  Similarly, the aspects of joining and securing the
   network are out of scope.


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 the art in ND-proxying and
   binding.  This document defines additional terms:

   Transit Link

      This is an IPv6 link that interconnects 2 or more backbone
      routers.  It is expected to be deployed as a high speed backbone
      in order to federate a potentially large set of LoWPANS.  Also
      referred to as a LoWPAN backbone or transit network.

   Backbone Router

      An IPv6 router that interconnects the LoWPAN with a Transit Link.

   Extended LoWPAN

      This is the aggregation of multiple LoWPANs as defined in
      [RFC4919] interconnected by a Transit Link via Backbone Routers
      and forming a single IPv6 link.

   Binding

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





Thubert                 Expires January 11, 2009                [Page 4]


Internet-Draft           6LoWPAN Backbone Router               July 2008


   Registration

      The process during which a LoWPAN node sends a Binding ND message
      to a Backbone Router causing a binding for the LoWPAN node to be
      registered.


3.  Overview

   A Transit Link federates multiple LoWPANs as a single IP link, the
   extended LoWPAN.  Each LoWPAN is anchored at a Backbone Router.  The
   Backbone Routers interconnect the LoWPANs over the Transit Link.  A
   node can move freely from a LoWPAN anchored at a Backbone Router to a
   LoWPAN anchored at another Backbone Router on the same Transit Link
   and conserve its link local and any other IPv6 address it has formed.


               ---+------------------------
                  |          Plant Network
                  |
               +-----+
               |     | Gateway
               |     |
               +-----+
                  |
                  |      Transit Link
            +--------------------+------------------+
            |                    |                  |
         +-----+             +-----+             +-----+
         |     | Backbone    |     | Backbone    |     | Backbone
         |     | 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

         LoWPAN              LoWPAN              LoWPAN


                Figure 1: Transit Link and Backbone Routers

   In order to achieve this, the Transit link is used as reference for
   Neighbor Discovery operations, by extending the concept of a Home
   Link as defined in [RFC3775] for Mobile IPv6.  In particular,
   Backbone Routers perform ND proxying for the LoWPAN nodes in the
   LoWPANs they own through a Primary registration.



Thubert                 Expires January 11, 2009                [Page 5]


Internet-Draft           6LoWPAN Backbone Router               July 2008


   The backbone router operation is compatible with that of a Home
   Agent.  This enables mobility support for sensor devices that would
   move outside of the network delimited by the transit link.  This also
   enables collocation of Home Agent functionality within Backbone
   Router functionality on the same interface of a router.

   The Backbone Router is centric for address resolution inside the
   LoWPAN.  The raison d'etre of the Backbone Router is to eliminate the
   need of the support for multicasting over the LoWPAN for address
   resolution that the Neighbor Discovery flows normally require.  This
   is based on a white board registration model that uses anycast and
   unicast only.

   As a result, a LoWPAN node performs unicast exchanges to its Backbone
   Router to claim and lookup addresses, and the Backbone Router proxies
   the ND requests over the Transit Link when necessary.

   In turn, the Backbone Routers operate as a distributed database of
   all the LoWPAN nodes and use the Neighbor Discovery Protocol to share
   that information across the transit link.

   This specification documents a Neighbor Binding protocol that enables
   a LoWPAN Node to claim and lookup addresses using a Backbone Router
   as a white board.

   This specification also documents the use of EUI-64 based link-local
   addresses and the way they are claimed by the Backbone Routers over
   the transit link.

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

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


4.  Neighbor Binding messages

   This section introduces message formats for all messages used in this
   specification.  The new messages are all ICMP messages and extend the
   capabilities of " the IPv6 Neighbor Discovery Protocol" [RFC4861]





Thubert                 Expires January 11, 2009                [Page 6]


Internet-Draft           6LoWPAN Backbone Router               July 2008


4.1.  Binding Solicitation message

   The Binding Sollicitation has a function similar to that of the
   Binding Solicitation message in [RFC3775] for Mobile IPv6 and
   [RFC3963] for NEMO.  Any option that is not recognized MUST be
   skipped silently.  The Binding Solicitation message is sent by the
   LoWPAN node to its Backbone Router to register an 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      |    Code       |       Checksum                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Reserved                |O|P|       Sequence #              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            Lifetime                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            Reserved                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                       Binding Address                         +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   option(s)...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 2: Binding Solicitation message format

   IP fields

   Source Address:  An IP address assigned to the sending interface, or
      the unspecified address if no address is assigned to the sending
      interface.

   Destination Address:  The well-known Backbone Router anycast address
      6LOWPAN_BBR or the specific address of a given Backbone Router if
      available.

   Hop Limit:  255

   ICMP fields






Thubert                 Expires January 11, 2009                [Page 7]


Internet-Draft           6LoWPAN Backbone Router               July 2008


   Type:  8-bit unsigned integer.  Value is "to be assigned by IANA".

   Code:  0

   Checksum:  The ICMP checksum.  See [RFC4443]

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

   P: Primary Flag.  Set to indicate that the router is primary and MAY
      proxy for the node if Proxy ND is used on the transit link.  If
      the flag is not set then the router MUST not proxy for the node.

   O: Optimistic Flag.  Set to indicate that the node uses optimistic
      addresses and can accept packets on the Binding Address even
      before the binding is complete.  The Router MUST always use that
      Binding Address as destination for the response as opposed to the
      well-known anywast address.

   Sequence #:  A 16-bit unsigned integer used by the receiving node to
      sequence Binding Solicitation and by the sending node to match a
      returned Binding Confirmation.

   Lifetime:  32-bit unsigned integer.  The number of seconds remaining
      before the binding MUST be considered expired.  A value of zero
      indicates that the Binding Cache entry for the registered node
      MUST be deleted.

   Binding Address:  The link-layer address that the sender wishes to
      assign or maintain assigned to its interface.

   Possible options

   Target link-layer address:  The link-layer address for the target,
      i.e., the sender of the message.  See [RFC4861].  The link-layer
      address option MUST be included when the binding is created and
      MAY be omitted in renewal.

   MTU:  Specifies the maximum size of a fragmented message that the
      node stack can recompose.  See [RFC4861] and [RFC4944].

4.2.  Binding Confirmation message

   The Binding Confirmation has a function similar to that of the
   Binding Ack message in [RFC3775] for Mobile IPv6 and [RFC3963] for
   NEMO.  Any option that is not recognized MUST be skipped silently.
   The Binding Confirmation message is sent by the Backbone Router node
   to the LoWPAN node to confirm whether an IP address MAY be assigned



Thubert                 Expires January 11, 2009                [Page 8]


Internet-Draft           6LoWPAN Backbone Router               July 2008


   to an interface.

        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                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Reserved                |X|P|       Sequence #              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            Lifetime                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            Reserved                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                       Binding Address                         +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   option(s)...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 3: Binding Confirmation message format

   IP fields

   Source Address:  An IP address assigned to the sending interface of
      the router.

   Destination Address:  The well-known LoWPAN node anycast address
      6LOWPAN_NODE or the Binding Address for the LoWPAN node.

   Hop Limit:  255

   ICMP fields

   Type:  8-bit unsigned integer.  Value is "to be assigned by IANA".

   Code:  0

   Checksum:  The ICMP checksum.  See [RFC4443]

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





Thubert                 Expires January 11, 2009                [Page 9]


Internet-Draft           6LoWPAN Backbone Router               July 2008


   P: Primary Flag.  MUST echo the P flag in the Binding solicitation.

   X: Proxy Flag.  Indicates that the route actually proxies for the
      node.  This can only happen if the P flag is set as well.

   Sequence #:  A 16-bit unsigned integer used by the receiving node to
      sequence Binding Solicitation and by the sending node to match a
      returned Binding Confirmation.

   Lifetime:  32-bit unsigned integer.  The number of seconds remaining
      before the binding MUST be considered expired.  A value of zero
      indicates that the Binding Cache entry for the registered node
      MUST be deleted.

   Binding Address:  The link-layer address that the sender wishes to
      assign or maintain assigned to its interface.

   Possible options

   Source link-layer address:  The link-layer address of the interface
      from which the Router Advertisement is sent.  See [RFC4861].

   MTU:  Specifies the maximum size of a fragmented message that the
      router stack can recompose.  See [RFC4861] and [RFC4944].

   Prefix Information:  The preferred address for the router.  See
      [RFC4861] and [RFC3775].  When this information is present, the
      Source link-layer address option MUST be present as well.  The
      Prefix Information option MUST be included when the binding is
      created and MAY be omitted in renewal.


5.  LowPAN device operations

5.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 media
   access control address that is globally unique to the device.  Link-
   local address are described in section 2.5.6 of [RFC4291].  Appendix
   A of that specification explains how the node builds an interface-ID
   based on the IEEE 64-bit extended MAC address by inverting the "u"
   (universal/local) bit.

   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



Thubert                 Expires January 11, 2009               [Page 10]


Internet-Draft           6LoWPAN Backbone Router               July 2008


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

   Nodes should also autoconfigure the well known anycast address
   6LOWPAN_NODE.  If they do not, they have to use their link local
   address in optimistic node and indicate so in the binding flows so
   that the Backbone Router uses that address in its replies.

   Nodes MAY learn the address of the Backbone Routers using traditional
   means such as configuration or the Neighbor Discovery Protocol Router
   Advertisement messages.  But those messages are multicast and might
   not be sent at a short interval or at all over the LoWPAN.  This
   specification introduces a new anycast address 6LOWPAN_BBR that the
   node can use to reach the nearest Backbone Router without previous
   knowledge of that router address.  This specification tolerates
   movement within the LoWPAN so the node does not have to stick with a
   given backbone router and MAY keep using the 6LOWPAN_BBR address for
   all its registrations.

   The Link Layer Address associated to the 6LOWPAN_BBR address is that
   of the PAN coordinator unless the node has a specific reason to
   select an alternate next hop.  It is expected that the selected next
   hop has a route to the nearest Backbone Router but the routing
   protocol involved is outside the scope of this specification.  It
   results that the next hop might have to forward the registration
   message and decrement the Hop Limit.  This is why the Backbone Router
   MUST accept Binding Solicitations with a Hop Limit that is lower than
   255 (min value TBD).

   The node might also form Unique Local and Global Unicast addresses,
   for instance if it needs to be reachable from the outside of the
   Extended LoWPAN, or if it can manage its own mobility as prescribed
   by Mobile IPv6 [RFC3775].  In that case, the node needs to bind each
   individual address individually.

5.2.  Binding process

   The binding process is very similar to that of a MIP6 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 Backbone Router.

   The LoWPAN node uses unicast Binding Solicitations to perform the
   binding.  The destination Address is that of the Backbone Router or a
   well know anycast address 6LOWPAN_BBR that indicates the function of
   the Backbone Routers.  The source address is the unspecified address



Thubert                 Expires January 11, 2009               [Page 11]


Internet-Draft           6LoWPAN Backbone Router               July 2008


   as long as the address is still optimistic or tentative, and it is
   the link local address of the node after it is successfully bound.

   The acknowledgment to a Binding Solicitation is a unicast Binding
   Confirmation message that contains the status of the binding.  The
   source of the packet is the link-local address of the Backbone
   Router.  The destination address is a well-know anycast address
   6LOWPAN_NODE unless the optimistic bit is set in the Binding
   Solicitation or the address was already bound, in which case the link
   local address of the node is used.

   Upon successful completion in the Binding Confirmation message, the
   LoWPAN node sets the address from optimistic or tentative to
   preferred.

   The 'X' flag in the Binding Confirmation message indicates that the
   Backbone Router has completed DAD and now owns the Binding Address
   over the Transit Link.

   This specification also introduces the concept of secondary binding.
   For redundancy, a node might place a secondary binding with one or
   more other Backbone Routers over a same or different LoWPANs.  The
   'P' flag in the Binding Solicitation message indicates whether the
   binding is primary (set) or secondary (reset).

5.3.  Looking up neighbor addresses

   A LoWPAN node does not use multicast for its Neighbor Solicitation as
   prescribed by the ND protocol [RFC4861] and oDAD [RFC4429].  For
   lookup purposes, all NS messages are sent in unicast to the Backbone
   Router, that answers in unicast as well.  The message is a standard
   Neighbor Solicitation but for the destination that set to the
   Backbone Router address or the well known 6LOWPAN_BBR address as
   opposed to the solicited-node multicast address for the destination
   address.

   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.

5.4.  Answering address look up

   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 programmed to answer a
   unicast NS but that is not required by this specification.



Thubert                 Expires January 11, 2009               [Page 12]


Internet-Draft           6LoWPAN Backbone Router               July 2008


6.  Backbone router operations

6.1.  Exposing the Backbone Router

   The Backbone 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 Transit Link and for all the associated LoWPAN(s)
   connected to that Backbone Router.

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

   The Backbone Router announces itself using Router Advertisements (RA)
   messages that are broadcasted periodically over the LOWPAN. (note:
   can we merge RA with some other maintenance packet or distribute the
   info from the manager in some specific cases like ISA100.11a where
   such a thing exists?). (also, when the node moves to another LoWPAN,
   is there a way to let it know faster which is the Backbone Router so
   that it can stimulate a RA using RS?).

   A new option in the RA indicates the Backbone Router capability.  In
   this way a node can learn the PAN-ID and the 16-bit short address for
   the Backbone Router if it was not already acquired from another
   process that is not covered by this specification.

   The Backbone 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 Backbone 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
   [I-D.van-beijnum-multi-mtu].



Thubert                 Expires January 11, 2009               [Page 13]


Internet-Draft           6LoWPAN Backbone Router               July 2008


6.2.  Binding process

   Upon a new binding for a link-local address based on a IEEE 64-bit
   extended MAC address, the Backbone Router MAY use Optimistic DAD on
   the Transit Link.  Any other Backbone Router that would happen to
   have a binding for that same address SHOULD yield and deprecate its
   binding to secondary if it was primary.  A positive acknowledgement
   can be sent to the LoWPAN node right away if oDAD is used on the
   Transit Link.  Note: A new option with a sequence number from the
   Binding Solicitation should be used to select the winner

   The Backbone Router operation on the transit link is similar to that
   of a Home Agent as specified in Mobility Support for IPv6 [RFC3775].
   In particular, the Neighbor Advertisement message is used as
   specified in section "10.4.1.  Intercepting Packets for a Mobile
   Node" with one exception that the override (O) bit is not set,
   indicating that this Backbone Router acts as a proxy for the LoWPAN
   and will yield should another Backbone Router claim that address on
   the Transit Link.  This enables the LoWPAN node to join a different
   Backbone Router at any time without the complexities of terminating a
   current binding.

   This specification also introduces the concept of secondary binding.
   Upon a secondary binding, the Backbone Router will not announce or
   defend the address on the transit link, but will be able to forward
   packets to the node over its LoWPAN interface.  For other addresses,
   the rules in [RFC3775] apply for compatibility.

   The Backbone Router responds to a Binding Solicitation with a Binding
   Confirmation.  The source address is a link local address of the
   router and the destination is the well known 6LOWPAN_NODE address
   unless a binding flow has already successfully completed in which
   case the router MAY use the node's Binding.  The router will also use
   the Binding Address if the 'O' flag is raised in the Solicitation,
   indicating that the node accepts packets on that address prior to a
   successful binding but may not accept packets on the 6LOWPAN_NODE
   address.

   If the Backbone Router is primary for a registration (as indicated by
   the 'P' flag) and it is connected to a Backbone, then it SHOULD
   perform proxy ND operations on the backbone and indicate so in the
   Confirmation message using the 'X' flag.  In particular it SHOULD
   reject the registration if DAD fails on the backbone.  When oDAD is
   used over the backbone the Backbone Router MAY issue the Binding
   Confirmation right away with a positive code, but if a collision is
   finally detected, it cancels the registration with an asynchronous
   Binding Confirmation and a negative completion code.




Thubert                 Expires January 11, 2009               [Page 14]


Internet-Draft           6LoWPAN Backbone Router               July 2008


6.3.  Looking up neighbor addresses

   A Backbone Router knows and proxies for all the IPv6 addresses that
   are registered to it.  When resolving a target address, the Backbone
   Router first considers its binding cache.  If this address is in the
   cache, then the target is reachable over the LoWPAN as indicated in
   the cache.  Else, the Backbone Router locates the target over the
   transit link using standard "Neighbor Discovery" [RFC4861] over that
   link.

   If the target is located over a LoWPAN owned by another Backbone
   Router, then that other Backbone Router is in charge of answering the
   Neighbor Solicitation on behalf of the target node.

6.4.  Answering address look up

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

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

6.5.  Forwarding packets

   Upon receiving packets on one of its LoWPAN interfaces, the Backbone
   Router checks whether it has a binding for the source address.  If it
   does, then the Backbone Router can forward the packet to another
   LoWPAN node or over the Transit link.  Otherwise, the Backbone 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 Transit Link towards a LOwPAN
   interface, the Backbone Router performs the 6LoWPAN sublayer
   operations of compression and fragmentation and passes the packet to
   the lower layer for transmission.






Thubert                 Expires January 11, 2009               [Page 15]


Internet-Draft           6LoWPAN Backbone Router               July 2008


7.  Security Considerations

   This specification expects that the link layer is sufficiently
   protected, either by means of physical or IP security for the Transit
   Link or MAC sublayer cryptography.  In particular, it is expected
   that the LoWPAN MAC provides secure unicast to/from the Backbone
   Router and secure broadcast from the Backbone Router in a way that
   prevents tempering with or replaying the RA messages.

   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.


8.  IANA Considerations

   This specification requires 2 new ICMP types for the binding flow.
   The is also a need for 2 new link local anycast addresses,
   6LOWPAN_BBR for the routers and 6LOWPAN_NODE the nodes; those
   addresses used as functional addresses.


9.  Acknowledgments

   The author wishes to thank Geoff Mulligan for his help and in-depth
   review.


10.  References

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

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



Thubert                 Expires January 11, 2009               [Page 16]


Internet-Draft           6LoWPAN Backbone Router               July 2008


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

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

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

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

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

   [RFC3963]  Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
              Thubert, "Network Mobility (NEMO) Basic Support Protocol",
              RFC 3963, January 2005.

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

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

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

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












Thubert                 Expires January 11, 2009               [Page 17]


Internet-Draft           6LoWPAN Backbone Router               July 2008


Author's Address

   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







































Thubert                 Expires January 11, 2009               [Page 18]


Internet-Draft           6LoWPAN Backbone Router               July 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).





Thubert                 Expires January 11, 2009               [Page 19]