[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 draft-ietf-6lowpan-nd

6LoWPAN WG                                                S. Chakrabarti
Internet-Draft                                               IP Infusion
Expires: September 2, 2010                                   E. Nordmark
                                                            Oracle, Inc.
                                                           March 1, 2010

         IPv6 LoWPAN Neighbor Discovery and Addressing Choices


   IETF 6LoWPAN working group defines IPv6 over low-power personal area
   network (IEEE 802.15.4).  IEEE 802.15.4 and other low-power wireless
   networks have limited or no usage of broadcast or multicast signaling
   due to energy conservation.  Besides the wireless nodes may not
   strictly follow traditional concept of IP subnet and IP-links while
   connecting nodes and routers.  This document describes simple
   optimizations to IPv6 Neighbor Discovery protocol(RFC4861), and
   addressing mechanisms that are useful for small scale 6LoWPAN
   networks in star and mesh topologies.

   The optimizations include reducing the amount of Neighbor Discovery
   multicast traffic and allowing for a single subnet to span multiple
   routers in a "route-over" topology.

Status of this Memo

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

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

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on September 2, 2010.

Chakrabarti & Nordmark  Expires September 2, 2010               [Page 1]

Internet-Draft              6LoWPAN-ND-SIMPLE                 March 2010

Copyright Notice

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

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

Table of Contents

   1.  Introduction and Overview  . . . . . . . . . . . . . . . . . .  3
     1.1.  IPv6 Neighbor Discovery shortcomings in low-power
           wireless network . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Address Allocation Options in 6LoWPAN  . . . . . . . . . .  4
     1.3.  Mesh-under and Route-over Concept and Behavior . . . . . .  4
   2.  Definition Of Terms  . . . . . . . . . . . . . . . . . . . . .  6
   3.  Assumptions  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Applicability Statement  . . . . . . . . . . . . . . . . . . .  7
   5.  Autoconfiguration of 6LoWPAN Addresses . . . . . . . . . . . .  8
     5.1.  Address Assignment in Star Networks  . . . . . . . . . . .  8
     5.2.  Address Assignment in Mesh Network . . . . . . . . . . . .  8
     5.3.  DHCPv6 Address and Resource Allocation . . . . . . . . . .  8
   6.  New Neighbor Discovery options . . . . . . . . . . . . . . . .  8
     6.1.  Authoritative Router option  . . . . . . . . . . . . . . .  9
     6.2.  Node-lifetime option . . . . . . . . . . . . . . . . . . . 10
   7.  Optimized Neighbor Discovery for 6LoWPANs  . . . . . . . . . . 10
     7.1.  Operations Overview  . . . . . . . . . . . . . . . . . . . 11
     7.2.  Existing Neighbor Discovery Messages . . . . . . . . . . . 11
     7.3.  6LoWPAN Optimized Neighbor Discovery Messages  . . . . . . 11
     7.4.  Host Behavior  . . . . . . . . . . . . . . . . . . . . . . 12
     7.5.  6LBR Behavior  . . . . . . . . . . . . . . . . . . . . . . 13
     7.6.  6LR Behavior . . . . . . . . . . . . . . . . . . . . . . . 13
   8.  Remaining Multicast messages . . . . . . . . . . . . . . . . . 14
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 15
     12.2. Informative References . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16

Chakrabarti & Nordmark  Expires September 2, 2010               [Page 2]

Internet-Draft              6LoWPAN-ND-SIMPLE                 March 2010

1.  Introduction and Overview

   The IPv6-over-IEEE 802.15.4 [3] document specifies IPv6 headers
   carried over IEEE 802.15.4 network with the help of an adaptation
   layer which sits between the MAC layer and the IP network layer.  The
   LoWPAN network is characterized by low-powered, low bit-rate, short
   ranged, low cost nodes.  Thus, all-node multicast defined in Neighbor
   Discovery [2] may be unsuitable in the LoWPAN network which does not
   have direct multicast support at the link-layer.  Broadcast messages
   could be used in some cases to represent all-node multicast messages,
   but periodic broadcast messages should be minimized in the LoWPAN
   network in order to conserve energy.

   This document provides an overview of IPv6 Neighbor Discovery options
   and describes a base mechanism for optimized 6LoWPAN neighbor
   discovery mechanism.

   The optimizations include reducing the amount of Neighbor Discovery
   multicast traffic and allowing for a single subnet to span multiple
   routers in a "route-over" topology.

1.1.  IPv6 Neighbor Discovery shortcomings in low-power wireless network

   IPv6 ND [2] is based on multicast signaling messages on the local
   link in order to avoid broadcast messages.  Following power-on and
   initialization of the network in IPv6 Ethernet networks, a node joins
   the solicited-node multicast address on the interface and then
   performs duplicate address detection (DAD) for the acquired link-
   local address by sending a solicited-node multicast message to the
   link.  After that it sends multicast router solicitation (RS)
   messages to the all-router address to solicit router advertisements.
   Once the host receives a valid router advertisement (RA) with the "A"
   flag, it autoconfigures the IPv6 address with the advertised prefix
   in the router advertisement (RA).  Besides this, the IPv6 routers
   usually send router advertisements periodically on the network.  RAs
   are sent to the all-node multicast address.  Nodes send Neighbor
   Solicitation (NS) and Neighbor Advertisement (NA) messages to resolve
   the IPv6 address of the destination on the link.  These NS/NA
   messages are also often multicast messages and it is assumed that the
   node is on the same link and relies on the fact that the destination
   node is always powered and generally available.

   In 6LoWPAN 802.15.4 network, primarily two types of configurations
   are used - 1) Star network and 2) Mesh network.  A star network is
   similar to regular IPv6 subnet with a router and a set of nodes
   connected to it via the same link.  But in low-power mesh networks,
   the nodes are capable of routing and forwarding packets but due to
   lossy nature of wireless communication, the IPv6-link node sets may

Chakrabarti & Nordmark  Expires September 2, 2010               [Page 3]

Internet-Draft              6LoWPAN-ND-SIMPLE                 March 2010

   change due to external physical factors and thus the link and
   connection becomes unreliable.

   Thus optimizing the regular IPv6 Neighbor Discovery [2] to minimize
   total number of related signaling messages without loosing generality
   of Neighbor Discovery and autoconfiguration and making host and
   router communication reliable, is desirable in 6LoWPAN mesh

1.2.  Address Allocation Options in 6LoWPAN

   As 6LoWPAN and IEEE 802.15.4 technologies are evolving we can
   anticipate that regular IPv6 ND [2] might be used in some
   configuration where the physical medium and hardware support higher
   bandwidth and processing power with low-power consumption.

   Thus the following options of address allocations are envisioned in a
   6LoWPAN network depending on the configuration and network capacity.

   o  Address allocation through multicast IPv6 Neighbor Discovery [2]
      and IPv6 Autoconfiguration [6] with tuned parameters for 6LoWPAN
      usage.  The Neighbor Discovery and autoconfiguration parameters
      are configurable on the basis of deployment requirement(example:
      when all 6LoWPAN nodes are one-hop away from the IPv6 router).
   o  A simplified DHCPv6 method for IPv6 address allocation in a
      6LoWPAN network.  This is useful for a star network and mesh
      network where all the nodes are in reachable range of the DHCPv6
      server.  DHCPv6 services SHOULD be used for assigning IPv6-
      addresses using 16-bit short MAC addresses described in IEEE
      802.15.4 [9] in order to ensure uniqueness of IPv6 addresses.
   o  An optimized 6LoWPAN Neighbor Discovery is recommended for
      efficiency and power savings for the low-power and lossy wireless
      mesh networks.  The simple optimization of IPv6 Neighbor
      Discovery[2] for low-power network in this document.  This
      mechanism SHOULD be used for efficient handling of signaling
      messages in the 6LoWPAN mesh and star networks using nodes with
      EUI-64 MAC addresses.

   It is noted that all the above address allocation methods MUST follow
   the address allocation principles described in [8].

1.3.  Mesh-under and Route-over Concept and Behavior

   In 6LoWPAN network context, often the link-layer mesh routing
   mechanism for carrying IP packets as a data message is referred as
   "mesh-under" while routing/forwarding packets using IP-layer
   addresses are referred as "route-over".  The difference between mesh-
   under and route-over networks is similar to a bridged-network and IP-

Chakrabarti & Nordmark  Expires September 2, 2010               [Page 4]

Internet-Draft              6LoWPAN-ND-SIMPLE                 March 2010

   routing network in the Ethernet.  Thus, in a mesh-under network all
   nodes are considered part of an IPv6 subnet when a 6LoWPAN network is
   considered as one IPv6 subnet served by one or more 6LoWPAN border
   routers (6LBR).  The 6LBR could also be a gateway to the legacy IPv4
   or IPv6 network.

   In a route-over network, there are multiple IPv6 subnets connecting
   to each other in a 6LoWPAN network.  However, unlike fixed IP
   networks, these subnet members may be changing due to the nature of
   the low-power and lossy behavior of wireless LoWPANs.  Thus a route-
   over network is almost always a flexible set of mesh networks.  The
   design considerations are based on the above properties.  The
   optimized 6LoWPAN neighbor discovery are applicable to both "mesh-
   under" and "route-over" implementations.  However, in "route-over"
   networks, we like to define two types of routers - 6LoWPAN border
   Routers(6LBR) and 6LoWPAN-routers(6LR). 6LoWPAN border Routers sit at
   the boundary of the 6LoWPAN and the backbone network while 6LoWPAN-
   routers are inside the 6LoWPAN network and they can not communicate
   to a different network routers directly.  The 6LoWPAN-routers are
   assumed to be running a routing protocol.  In "route-over"
   configuration, the hosts are unable to take part in routing and
   forwarding packets and they are acting as simple IPv6 hosts.

   These neighbor discovery optimizations for "mesh-under" configuration
   where the 6LBR is acting as the IPv6 router where all the hosts in
   6LoWPAN are part of one subnet and they are only one IP hop away and
   no 6LR concept exist in "mesh-under" topology.  Thus, the IPv6 packet
   is carried as the data via a link-layer mesh routing protocol.

   When "route-over" configuration is used, the IPv6 Neighbor Discovery
   operation takes place between the requesting node and the 6LRs or
   6LBRs.  The 6LR nodes are able to send and receive Router
   Advertisements, Router Solicitations as well as forward and route
   IPv6 packets.  The packet forwarding happens at the routing layer.

   With "route-over" there is a need to allow a host to attach to
   different 6LRs over time (e.g., to handle changes in the radio
   conditions) while the host keeps the same IPv6 addresses.  Thus one
   (or more) subnet prefixes (see [8]) should be assigned to the
   6LoWPAN.  This implies that a 6LRs need to reliably know which IP
   addresses are directly reachable from that particular 6LR; this
   information will be used by the routing protocol that is used by the
   6LRs and 6LBRs.

   This document assumes that an implementation will have configuration
   knobs to determine whether it is running in "mesh-under" mode or
   "route-over" mode if the implementation supports both mechanisms.

Chakrabarti & Nordmark  Expires September 2, 2010               [Page 5]

Internet-Draft              6LoWPAN-ND-SIMPLE                 March 2010

2.  Definition Of Terms

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [1].

      It is a wireless link determined by single hop reachability of
      neighboring nodes.
   6LoWPAN-router (6LR):
      These are the intermediate routers in the 6LoWPAN network who can
      communicate with other 6LoWPAN-routers in the same 6LoWPAN
      network.  These are also the immediate first-hop router for
      6LoWPAN hosts. 6LoWPAN routers are present only in "route-over"
   6LoWPAN Border Router (6LBR):
      It is a border router located at the junction of separate 6LoWPAN
      networks or between a 6LoWPAN network and a non-6LoWPAN IP
      network.  There may be one or more 6LBR at the 6LoWPAN network
      border. 6LBR is the responsible authority for IPv6 Prefix
      propagation for the 6LoWPAN network it is serving.  An isolated
      6LoWPAN network also contains a 6LBR in the network, which
      provides the prefix(es) for the isolated network.
      A host in 6LoWPAN network is considered a IPv6 node without
      routing and forwarding capability.
      It is a configuration topology where 6LoWPAN hosts are connected
      to the 6LBR through a mesh using Layer-2 forwarding.  Thus in a
      "mesh-under" configuration all IPv6 hosts in a 6LoWPAN network are
      only one IP hop away from the 6LBR.  This topology simulates the
      typical IP-subnet topology with one router with multiple nodes in
      the same subnet.
      It is a configuration topology where 6LoWPAN hosts are connected
      to the 6LBR through the use of intermediate Layer-3 (IP) routing.
      Here hosts are typically multiple IP hops away from the 6LBR.  The
      Route-over topology typically consists of a 6LBR, a set of 6LRs
      and possibly some hosts.

3.  Assumptions

   o  6LBRs are capable of routing/forwarding packets between 6LoWPAN
      networks and other networks.  The 6LBRs are responsible for
      assigning one or more /64 IPv6 prefix to the 6LoWPAN network.  It
      advertises this/these IPv6 prefixes to the 6LoWPAN network.

Chakrabarti & Nordmark  Expires September 2, 2010               [Page 6]

Internet-Draft              6LoWPAN-ND-SIMPLE                 March 2010

   o  The 6LR that are in range of 6LBR use the prefixes advertised by
      the the 6LBR.  The 6LRs store these prefixes and use them for
      forming its own global autoconfigured addresses.  When sending
      Router Advertisements, 6LRs advertise the same prefix(es).  A
      6LoWPAN-router SHOULD relay any prefix related options received
      from its parent router during Neighbor Discovery procedure.
   o  The 6LoWPAN hosts either autoconfigure their IPv6 address(es)
      based on the prefix(es) received in the Router Advertisement, or
      it uses DHCP service for address assignment.  It can receive
      multiple Router Advertisements and should be able to configure
      multiple default routers as its immediate nexthop.  The 6LoWPAN
      hosts always send their packets to the default router.  If one
      default router becomes unavailable, it chooses the next available
      default router.  This behavior is the same as standard IPv6 hosts
   o  In an isolated 6LoWPAN network an ULA prefix and address SHOULD be
      generated by the 6LBR.  Thus in this topology, 6LBR prefix is
      formed according to [11].
   o  The Prefix Options send by 6LBRs and 6LRs do not set the 'L' flag.
      This is necessary to get the hosts to send packets to (one of)
      their default router(s).
   o  The local mobility or mobility within a 6LoWPAN is supported in
      this solution by using the same IPv6 prefix across the 6LoWPAN.

4.  Applicability Statement

   This document aims to guide the implementors to choose an appropriate
   IPv6 neighbor discovery and Address configuration procedures suitable
   for a 6LoWPAN network.  If the 6LoWPAN network does not have
   Multicast capability at the link-layer, then it SHOULD use the
   Optimized IPv6 Neighbor Discovery for the 6LoWPAN network.

   This document does not specify a method for ensuring address
   uniqueness across a LoWPAN.  In general such a mechanism is needed
   for the IPv6 addresses autoconfigured in the subnet prefix(es).  In
   the general case of ND we use multicast Neighbor Solicitation to
   perform Duplicate Address Detection (DAD) [6] but that is both
   undesirable in a 6LoWPAN due to the undesirability of multicast
   packets, and insufficient in the case of "route-over" when the subnet
   prefix spans several links and 6LRs.

   The scope of this document is limited to addresses that are
   autoconfigured based on EUI-64 based Interface-ids.  For such
   addresses DAD is not required.  Other IPv6 addresses, including those
   based on 16-bit IEEE 802.15.4 short addresses, are out of scope.
   Potentially DHCPv6 can be used to allocate unique addresses for short

Chakrabarti & Nordmark  Expires September 2, 2010               [Page 7]

Internet-Draft              6LoWPAN-ND-SIMPLE                 March 2010

5.  Autoconfiguration of 6LoWPAN Addresses

   The following discussion will include address auto-configuration
   procedure at the IP-layer.

5.1.  Address Assignment in Star Networks

   In a star network, all the nodes are one hop away from the IPv6-
   router and from each-other.  Upon starting a node sends an IPv6 ND
   [2] Router Solicitation (RS) to the All-Routers multicast address.
   The 6LBR sends unicast Router Advertisement (RA) and the node
   configures its IPv6 address using autoconfiguration [6].  If the
   nodes are using EUI-64 style MAC address, the Duplicate Address
   Detection SHOULD be skipped.  The 6LBR is assumed to be the only
   router in the 6LoWPAN network - thus it should use a unique id, for
   example IEEE 802.15.4 PAN-ID as its subnet-id of the IPv6-address.

   If the node uses a short(16-bit) MAC addresses, address assignment
   through DHCP is advised.

5.2.  Address Assignment in Mesh Network

   In a "mesh-under" configuration, the nodes are considered one hop
   away.  Thus address assignment/auto-configuration happens the same
   way as in Star Network configuration.  However, 6LBR is acts as an
   Prefix authority and initial delegator of that prefix.

   In a "route-over" configuration, one or more 6LBR advertise the
   global prefix(es) along with a new IPv6 Router Advertisement option
   called Authoritative Router option.  This option contains information
   about the 6LBR IP-address and a sequence number.  The next-level 6LR
   receive the RA from 6LBR and store/auto-config with the advertised
   prefix.  The received prefix from 6LBR and the new Authoritative
   Router option option are then propagated throughout the 6LoWPAN
   network hop by hop.  The hosts use the address prefix to configure
   the address when they receive the Router Advertisements from their
   respective Neighborhood 6LR.

5.3.  DHCPv6 Address and Resource Allocation

   DHCP address allocation procedure for 6LoWPAN is out of scope of this

6.  New Neighbor Discovery options

   The optimized ND uses two new Neighbor Discovery options -
   Authoritative Router option option and Node-lifetime option.

Chakrabarti & Nordmark  Expires September 2, 2010               [Page 8]

Internet-Draft              6LoWPAN-ND-SIMPLE                 March 2010

6.1.  Authoritative Router option

   The Prefix Information options originate at the 6LBRs and are
   propagated by the 6LRs.  Thus 6LRs receive Prefix Information options
   from other 6LRs.  This implies that we can't just have the most
   recently received RA win.  In order to be able to reliably remove
   prefixes from the 6LoWPAN we need to carry information from the
   authoritative 6LBR.  We do that by introducing a sequence number
   which the 6LRs propagate as they propagate the prefixes.  When there
   are multiple 6LBRs they would have a separate sequence number spaces.
   Thus we need to carry the IP address of the 6LBR that created the
   sequence number.

   The Authoritative Router option is included in Router Advertisement
   messages.  It is required in "route-over" configurations.

    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 = 3 |          Reserved             |
   |                       Sequence Number                         |
   |                                                               |
   +                                                               +
   |                                                               |
   +                          6LBR Address                         +
   |                                                               |
   +                                                               +
   |                                                               |
   ~                            Address[1] etc                     ~

   Type:          TBD [To be allocated by the IANA.]
   Length:        8-bit unsigned integer.  The length of the option in
                  units of 8 octets.  Always 3.
   Reserved:      16-bits.  This field is unused.  It MUST be
                  initialized to zero by the sender and MUST be ignored
                  by the receiver.
   Registration Period:  32-bit unsigned integer.  The amount of time in
                  seconds between successive registration messages for
                  the same IP address.

Chakrabarti & Nordmark  Expires September 2, 2010               [Page 9]

Internet-Draft              6LoWPAN-ND-SIMPLE                 March 2010

   6LBR Address:  IP address of 6LBR that is authoritative for the
                  sequence number.

6.2.  Node-lifetime option

   The 6LRs need to know the set of IP addresses that are directly
   reachable.  This needs to be maintained as the radio reachability
   changes.  We introduce a Node-Lifetime option that is carried in the
   unicast NS and NA messages sent by hosts.  Thus it can be used on the
   unicast NS messages that that a host sends as part of NUD to
   determine that it can still reach a default router.  This Node-
   Lifetime is used by the 6LR to reliably maintain its Neighbor Cache.

   The Node-lifetime is required for 6LoWPAN network for reliability and
   power saving to minimize frequent need for updating Neighbor status
   with the neighboring 6LR for liveliness.  Thus the requested Node-
   lifetime provides flexibility to the requester to receive an address
   which should be usable (continue to be advertised by the 6LR in the
   routing protocol etc) during its intended of sleep schedule.

    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 = 1  |          Reserved             |
   |                     Registration Lifetime                     |

   Type:          TBD [To be allocated by the IANA.]
   Length:        8-bit unsigned integer.  The length of the option in
                  units of 8 octets.  Always 1.
   Reserved:      16-bits.  This field is unused.  It MUST be
                  initialized to zero by the sender and MUST be ignored
                  by the receiver.
   Registration Lifetime:  32-bit unsigned integer.  The amount of time
                  in seconds that the 6LR should retain the Neighbor
                  Cache entry for the sender of the NS/NA that includes
                  this option.

7.  Optimized Neighbor Discovery for 6LoWPANs

   The goal of having an optimized Neighbor Discovery is to basically
   use regular IPv6 Neighbor Discovery [2] with some optimization for
   low-power networks.  The main objective is to minimize the multicast
   messages and use unicast messages instead of multicast messages when
   possible.  Note that IPv6 use multicast messages instead of broadcast

Chakrabarti & Nordmark  Expires September 2, 2010              [Page 10]

Internet-Draft              6LoWPAN-ND-SIMPLE                 March 2010

   messages.  But layer-2 technologies that do not support multicast but
   provides broadcast support, usually map the IP multicast messages to
   L2 broadcast messages.  IEEE 802.15.4 networks do this.

7.1.  Operations Overview

   The mandatory part of the optimized Neighbor Discovery protocol is
   described here.  Upon starting up, a node figures out whether it is
   configured as a router or a simple host.  The procedure of
   determining this node behavior is local to the system and it is
   implementation specific.

   The use of subnet and link-local address prefixes is specified in
   [8]).  In this case, the link-local addresses can only reach the set
   of nodes that are reachable from the sender at the time it sends a
   packet.  We can define that as 6LoWPAN-link.

7.2.  Existing Neighbor Discovery Messages

   IPv6 Neighbor Discovery [2] protocol operates with Router
   Solicitation(RS), Router Advertisement(RA), Neighbor
   Solicitation(NS), Neighbor Advertisement (NA), and Redirect messages,
   link-layer address options, prefix options, MTU options etc., and a
   set of protocol constants.  Moreover, duplicate address detection
   (DAD) is performed during address assignment.

   The following sections describe optimizations (if any) of the above
   messages of IPv6 Neighbor Discovery Protocol[2] for 6LoWPAN.

7.3.  6LoWPAN Optimized Neighbor Discovery Messages

   1.   Router Advertisement(RA): Periodic RAs SHOULD be avoided.  Only
        solicited RAs are recommended for the 6LBRs (on their 6LoWPAN
        interfaces) and 6LRs.  An RA MUST contain the Source Link-layer
        Address option containing Router's link-layer address (this is
        optional in [2].  An RA MUST carry Prefix information option
        with L bit being unset, so that hosts do not multicast any NS
        messages as part of address resolution.  In addition to the
        Prefix option the RA should carry Authoritative Router option
        option generated by the 6LBR.
   2.   Router Solicitation(RS): Upon system startup, the node sends a
        multicast or link broadcast (when multicast is not supported at
        the link-layer) RS to find out the available routers in the
        wireless link.  An RS may be sent at other times as described in
        section 6.3.7 of RFC 4861.  A Router Solicitation MUST carry
        Source Link-layer Address option.  Since no periodic RAs are
        allowed in a 6LoWPAN network, the host may restart sending
        multicast RS messages after NUD declares a default router

Chakrabarti & Nordmark  Expires September 2, 2010              [Page 11]

Internet-Draft              6LoWPAN-ND-SIMPLE                 March 2010

   3.   Default Router Selection: Same as in section 6.3.6 of RFC 4861.
   4.   Neighbor Solicitation (NS): Neighbor solicitation is used
        between the hosts and the default-router as part of NUD and
        registering the host's address(es).  An NS messages MUST use the
        Node-lifetime option in order to accomplish the registration.
   5.   Neighbor Advertisement (NA): As defined in [2]
   6.   Redirect Messages: A router in the 6LoWPAN network may send a
        Redirect message to a host.  When to send the redirect message
        is implementation specific; a router may be overloaded or by
        some means it can determine the proximity of source and
        destination and decide that they should directly talk to each
        other.  The host behavior is same as described in section 8.3 of
        RFC 4861 [2].
   7.   Message Validation: Same as in RFC 4861[2]
   8.   MTU option: As per the RFC 4861.
   9.   Address Resolution: No multicast NS/NA are sent as the prefixes
        are treated as off-link.  Thus no address resolution is
        performed at the hosts.  The routers keep track of Neighbor
        Solicitations with Node-Lifetime options and create a neighbor
        cache of directly reachable addresses.  The router also knows
        the nexthop link-local address and corresponding link-layer
        address when it wants to route a packet.
   10.  Neighbor Unreachability Detection(NUD): NUD is performed in
        "forward-progress" fashion as described in section 7.3.1 of [2].
        The unicast Neighbor Solicitation and Advertisement messages
        sent by a host as part of NUD include the Node-Lifetime option.

7.4.  Host Behavior

   A 6LoWPAN host sends Router Solicitation at the system startup and
   also when it suspects that one of its default routers have become
   unreachable (after NUD fails).  The latter part is a behavioral
   change from RFC 4861 [2], since RFC 4861 assumes that when NUD fails
   for a router there will be some multicast RA messages that will make
   the host find out a new set of working default routers.  Here we
   avoid multicast RA messages completely which implies that the host
   needs to send a RS after NUD fails, just as it does in the case when
   the interface is reinitialized after a temporary interface failure in
   section 6.3.7 in [2].  Thus in essence we treat a NUD failure for a
   default router the same way as a temporary interface failure, which
   seems consistent with how [2] operates on a wired network.

   A host SHOULD be able to autoconfigure its IPv6 addresses and
   optionally it can act as a simple DHCPv6 client.

   A host always sends packets to (one of) its default router(s).  This
   is accomplished by the 6LBRs and 6LRs never setting the 'L' flag in

Chakrabarti & Nordmark  Expires September 2, 2010              [Page 12]

Internet-Draft              6LoWPAN-ND-SIMPLE                 March 2010

   the Prefix options.  A router can control the host's selection of a
   default router by sending Redirect messages, however care must be
   taken to ensure that that router is indeed reachable from the host.
   Should this not be the case then normal operation of NUD per RFC 4861
   will end up deleting the redirect.

   The host is unable to forward routes or participate in a routing

7.5.  6LBR Behavior

   A 6LBR normally has multiple interfaces and connects the 6LoWPAN to
   other 6LoWPAN networks or to non-6LoWPAN network(s).  The 6LBR is
   responsible for distributing one or more /64 prefixes to the 6LoWPAN
   nodes to identify a packet belonging to the particular 6LoWPAN

   When the 6LBR sends a Router Advertisement it SHOULD include a
   Authoritative Router option that includes its own address and a
   sequence number.  (The Authoritative Router option is required in the
   "route-over" configuration.)  Each time the information in the RA
   changes (such as adding or deleting prefixes, or changing the
   lifetime of the prefixes) the sequence number should be increased by
   one.  The 6LBR SHOULD keep the sequence number in stable storage or
   otherwise ensure that after a reboot it will not reuse "old" sequence

   A 6LBR keeps a cache for all the 6LoWPAN nodes' IP addresses, created
   from the routing protocol.  The 6LBR may act as a DHCPv6 server for
   the 6LoWPAN network as well.  It does not send unsolicited Router
   Advertisements on 6LoWPAN interfaces. 6LBR holds the authority of
   Prefix generation and initial Prefix allocation in the 6LoWPAN

7.6.  6LR Behavior

   6LRs are only present in "Route-over" mesh topology.  They
   participate in forwarding packets in from a host to another host or
   to the nexthop router.  They may configure their own address based on
   the /64-bit prefix(es) they receive in RAs.

   A 6LR keeps a cache of neighbor information collected from the Node-
   Lifetime options in Neighbor messages.  This information is made
   available to the routing protocol.  When receiving a packet the 6LR
   compares the destination against this neighbor cache.  If present the
   host is directly connected to the 6LR and it can forward the packet
   to the host.  Otherwise the packet is forwarded using the routing

Chakrabarti & Nordmark  Expires September 2, 2010              [Page 13]

Internet-Draft              6LoWPAN-ND-SIMPLE                 March 2010

   A 6LR receives Router Advertisements from 6LBRs and 6LRs and uses the
   received Prefix options and Authoritative Router option to construct
   the Router Advertisements it sends.  The 6LR MUST ignore any RA that
   does not contain an Authoritative Router option.  When a RA is
   received it compares the sequence number and 6LBR Address against a
   cache of such information.  If it has information for the 6LBR
   Address and the received sequence number is less or equal to last
   sequence number, then it MUST ignore the received Prefix options.
   Otherwise it updates the prefixes and the sequence number to what was
   received.  This mechanism needs to be able to handle different 6LBRs
   advertising different prefixes.  Among other things that implies that
   a RA sent by the 6LR can only include prefixes (and the Authoritative
   Router option) originated from one of the 6LBRs.

   Unlike regular routers, 6LRs send multicast RS messages once upon
   startup to receive a RA message.  After that they are not required to
   send RS messages, since they run a routing protocol.

8.  Remaining Multicast messages

   With the optimizations specified above the only place where Neighbor
   Discovery messages are multicast is Router Solicitations.  Such
   messages must be conceptually multicast, both when a host is powered
   on and also when the NUD indicates that a default router is
   unreachable, since the host needs to be able to find at least one new
   router at that point in time.

   Potentially this could be further optimized if there is some L2
   mechanism to perform some form of anycast, since all that is needed
   is for the host to reach at least one router.  However, it isn't
   known to the authors whether 6LoWPAN has an L2 anycast address can be
   used to reach routers.  If such an address can be used, then the RS
   messages can be multicast at L3 (sent to the "all-routers" IPv6
   multicast address) while being anycast at L2.

9.  Security Considerations

   These optimizations are not known to introduce any new threats
   against Neighbor Discovery beyond what is already documented for IPv6
   [RFC 3756].  However, the effect of a rogue router is more severe in
   Low-power wireless network than in the network of powered systems.
   The 6LoWPAN security analysis [12] discusses possible threats.  The
   security of 6LoWPAN Neighbor Discovery will be handled in a separate
   follow-up IETF publication.

Chakrabarti & Nordmark  Expires September 2, 2010              [Page 14]

Internet-Draft              6LoWPAN-ND-SIMPLE                 March 2010

10.  IANA Considerations

   If this document is approved then two Neighbor Discovery option types
   need to be allocated.

11.  Acknowledgements

   The primary idea and inspiration of this document to note different
   addressing mechanism and simple ND procedures are from Geoff

   Also thanks to the 6LoWPAN and 6man working group members to provide
   ideas on simplification.  Part of the ideas are also discussed at the
   IETF mailing list as a summary of base 6LoWPAN-ND requirement.

12.  References

12.1.  Normative References

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

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

   [3]   Montenegro, G. and N. Kushalnagar, "Transmission of IPv6
         Packets over IEEE 802.15.4 networks", RFC 4944, September 2007.

   [4]   Kushalnagar, N. and G. Montenegro, "6LoWPAN: Overview,
         Assumptions, Problem Statement and Goals", RFC 4919,
         August 2007.

12.2.  Informative References

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

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

   [7]   Arkko, J., Kempf, J., Zill, B., and P. Nikander, "Secure
         Neighbor Discovery", RFC 3971, March 2005.

   [8]   Baccelli, E. and M. Townsley, "IP Addressing Model in Adhoc
         Networks", draft-ietf-autoconf-adhoc-addr-model-02.txt (work in

Chakrabarti & Nordmark  Expires September 2, 2010              [Page 15]

Internet-Draft              6LoWPAN-ND-SIMPLE                 March 2010

         progress), December 2009.

   [9]   IEEE Computer Society, "IEEE Std. 802.15.4-2003",  ,
         October 2003.

   [10]  Miwakawya, S., "Requirements for Prefix Delegation", RFC 3769,
         June 2004.

   [11]  "Unique Local IPv6 Addresses", RFC 4193.

   [12]  Park, D., Kim, K., Seo, E., and S. Chakrabarti, "IPv6 over Low
         Power WPAN Security Analysis",
         draft-daniel-6lowpan-security-analysis-02.txt (work in
         progress), January 2007.

Authors' Addresses

   Samita Chakrabarti
   IP Infusion
   1188 Arquest Street
   Sunnyvale, CA

   Email: samitac@ipinfusion.com

   Erik Nordmark
   Oracle, Inc.
   17 Network Circle
   Menlo Park, CA 94025

   Email: Erik.Nordmark@Sun.COM

Chakrabarti & Nordmark  Expires September 2, 2010              [Page 16]

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