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

Versions: 00 01 02 03 04 05 draft-ietf-6lowpan-nd

6LOWPAN WG                                                S. Chakrabarti
Internet-Draft                                               E. Nordmark
Expires: September 6, 2006                        Sun Microsystems, Inc.
                                                           March 5, 2006


                  LowPan Neighbor Discovery Extensions
                draft-chakrabarti-6lowpan-ipv6-nd-01.txt

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 September 6, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   IETF 6LowPan working group defines IPv6 over low-power personal area
   network (IEEE 802.15.4).  IEEE 802.15.4 link layer does not have
   multicast support, although it supports broadcast.  Due to the nature
   of LowPan network or sensor networks, broadcast messages should be
   minimized.  This document suggests some optimizations to IPv6
   Neighbor Discovery related multicast messages in order to reduce
   signaling in the low-cost low-powered network.




Chakrabarti & Nordmark  Expires September 6, 2006               [Page 1]


Internet-Draft    LowPan Neighbor Discovery Extensions        March 2006


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Goals  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Background on IPv6 Neighbor Discovery  . . . . . . . . . . . .  4
   4.  Assumptions about Topology and Address Mapping . . . . . . . .  6
   5.  Minimizing Multicast of Router Solicitations and
       Advertisements . . . . . . . . . . . . . . . . . . . . . . . .  7
     5.1.  Avoiding L2 broadcast of initial RS and RA . . . . . . . .  7
     5.2.  Avoiding L2 broadcast of periodic RAs  . . . . . . . . . .  8
   6.  Minimizing Multicast of Neighbor Solicitations . . . . . . . .  9
     6.1.  Avoiding L2 broadcast of NS messages for existing nodes  .  9
     6.2.  Avoiding L2 broadcast of NS messages for non-existent
           nodes  . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   7.  Minimizing Multicast for Duplicate Address Detection . . . . . 11
   8.  Neighbor Unreachability Detection  . . . . . . . . . . . . . . 11
   9.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 12
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 13
     13.2. Informative References . . . . . . . . . . . . . . . . . . 13
   Appendix A.  Supporting short addresses? . . . . . . . . . . . . . 13
   Appendix B.  Summary of proposed optimizations . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
   Intellectual Property and Copyright Statements . . . . . . . . . . 16
























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


Internet-Draft    LowPan Neighbor Discovery Extensions        March 2006


1.  Introduction

   The IPv6-over-IEEE 802.15.4 [2] document has specified IPv6 headers
   carrying over IEEE 802.15.4 network with the help of an adaptation
   layer which sits between the MAC layer and the network layer.  The
   LowPan network is characterized by low-powered, low bit-rate, short
   ranged, low cost network.  Thus, all-node multicast defined in
   Neighbor Discovery [1] is not often desirable in the LowPan network.
   But IEEE 802.15.4 does not have multicast support, however, it
   supports broadcast.  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.  The goal of this document is to minimize periodic
   multicast signals used by Neighbor Discovery [1], minimize total
   number of Neighbor Discovery related signaling messages without
   loosing generality of Neighbor Discovery and autoconfiguration.  It
   also aims to identify the default values for periodic advertisements,
   router and prefix lifetime values that are suitable for LowPan
   networks.

   The IPv6-over-IEEE 802.15.4 [2] document provides mesh routing
   capability at the link layer.  Yet each node is configured with IPv6
   addresses.  Thus a IEEE 802.15.4 may look like one single IPv6 subnet
   to the IP layer.  It may be possible that routing advertisements are
   used only for prefix advertisement purpose for auto-configuration of
   IPv6 addresses.  Yet, Neighbor Solicitation, Neighbor Advertisements,
   Neighbor Unreachability Detection (NUD) take place as usual for
   neighbor to neighbor communication.  Also, some LowPan networks may
   use IPv6 routing (for example, star topology).  Hence minimizing
   periodic router signaling messages are required for efficient use of
   IPv6 in the LowPan network.

   Please note that this version of draft is not complete in determining
   a solution for reducing the Neighbor Discovery signaling messages;
   the work is in progress by the authors.


2.  Goals

   This document aims to reduce signaling messages due to IPv6 Neighbor
   Discovery protocol, and in particular those messages that are
   multicast.

   A LowPan network does not have multicast capability in the layer 2.
   However, the link-layer provides broadcast functionality, supporting
   IPv6 for broadcast would defeat its purpose.  Also the Neighbor
   Discovery document [1] is designed for regular Internet Network where
   nodes are sufficiently powered and they are configured in a stable



Chakrabarti & Nordmark  Expires September 6, 2006               [Page 3]


Internet-Draft    LowPan Neighbor Discovery Extensions        March 2006


   infrastructure of network, unlike LowPan or sensor networks.  The
   strawman idea for this section is to attempt to minimize the
   multicast Neighbor Discovery signaling packets.

   The following are the goals:
   1.  Minimizing Multicast messages such as:
       *  Reduce or avoid multicast for Duplicate Address Detection.
       *  Limit multicast Router Solicitations and Router
          Advertisements.
       *  Avoid/Reduce Multicast Neighbor Solicitations.
   2.  Reduce or avoid (unicast) Neighbor Unreachability Detection
       messages.


3.  Background on IPv6 Neighbor Discovery

   IPv6 Neighbor Discovery [1] provides several important functions such
   as Router Discovery, Address Resolution, Duplicate Address Detection,
   Redirect, Prefix and Parameter Discovery.  In order to get a feel for
   how this works we provide a short walk-through of a device
   initializing on a network.  The walk-through uses the "normal" type
   of usage of Neighbor Discovery on an Ethernet.

   During power-on and initialization the following steps are common on
   Ethernet networks:
   1.  The host picks a link-local IPv6 address, and checks whether it
       is unique on the link by multicasting a Neighbor Solicitation as
       part of the Duplicate Address Detection mechanism.  Before it
       does this, the host joins the solicited-node multicast address on
       the interface.  This joining of the solicited-node group requires
       sending a MLD join message in order to handle links where there
       are MLD-snooping switches.
   2.  When the host initializes its network it multicasts one or a few
       Neighbor Solicitation messages to the all-router IPv6 multicast
       address, until it receives a Router Advertisement.
   3.  The router(s) that receives the Router Solicitation, responds
       with a Router Advertisement.  Per the ND specification the
       routers can unicast the RA (if the RS contained a Sender Link-
       layer Address option), or the router can multicast the RA to the
       all-nodes IPv6 multicast address.
   4.  Once the host has received a RA with one or more Prefix options
       that have the "A" flag set, the host performs stateless address
       autoconfiguration.  For each IPv6 address it forms as part of
       this, it does Duplicate Address Detection by multicasting a
       Neighbor Solicitation message to the solicited-node multicast
       address.

   In addition, periodically the routers multicast Router Advertisements



Chakrabarti & Nordmark  Expires September 6, 2006               [Page 4]


Internet-Draft    LowPan Neighbor Discovery Extensions        March 2006


   to the all-nodes IPv6 multicast address.  This is done so that the
   hosts can determine when a router has been removed (without relying
   on Neighbor Unreachability Detection), find out about the extension
   of the lifetimes for the prefixes, and also be informed about new and
   removed prefixes (i.e. in the case of renumbering) or other
   configuration changes.  By default the periodic router advertisements
   are approximately at every 7 minutes on an average, and the default
   router lifetimes is 90 minutes.  By default the lifetime for the
   prefixes are 7 days, thus this doesn't require very frequent
   advertisements.

   When a host attached to the link wants to communicate with another
   host, if that host's address is part of the on-link prefixes, then
   the host will multicast a Neighbor Solicitation to find the peer's
   link layer address.  This also applies when the router receives a
   packet that it needs to forward to a host in the on-link prefix.  The
   response to the NS is a Neighbor Advertisement which is unicast.

   If the destination is not part of the on-link prefixes, then the host
   just sends the packet to one of the default routers; the host has the
   L2 address of the routers from the Router Advertisement messages it
   has received.

   The Neighbor Discovery standard allows a configuration where the
   routers do not advertise any prefixes with the "on-link" ("L") flag
   set, but it can still advertise them with the "stateless address
   config" ("A") flag.  This configuration isn't typically used on
   Ethernets.  Should it be used, the above description still applies;
   since no destination is part of the on-link prefixes, the packet
   would be sent to one of the default routers.  This would cause the
   routers to forward the packet to the destination.  Should the
   destination be on the same link as the source, then the routers can
   send a Redirect message back to the sender informing it of this fact.
   Unlike in IPv4, the Redirect message can include the link-layer
   address of the destination.  If this is done, then subsequence
   messages between the hosts will be sent without involving the router.

   The information about the neighbors and their L2 addresses are cached
   in a neighbor cache.  The entries in this cache do not need to be
   timed out, but a node can discard them if it runs low on memory.
   This means that the information can be stale, in two different ways:
   o  The layer 2 address has changed, for instance due to somebody
      replacing the Ethernet NIC, resulting in a different Ethernet
      address for the node.
   o  The node is no longer reachable; it could be down.

   The nodes detect such unreachability using Neighbor Unreachability
   Detection, which consists of sending unicast Neighbor Solicitations



Chakrabarti & Nordmark  Expires September 6, 2006               [Page 5]


Internet-Draft    LowPan Neighbor Discovery Extensions        March 2006


   to the currently known L2 address of the neighbor and expect a
   unicast Neighbor Advertisement in response.  If there is no response
   after 3 unicast NSes the node will declare the neighbor unreachable
   and fall back to sending multicast NSes to try to discover a
   potentially new L2 address for the peer.

   The first case can in general appear for both a host and a router;
   what matters is whether the L2 address changes of the node.  The
   second case can also happen for both a host and a router, but the
   recovery is different in the two cases.  If it is a router that is no
   longer reachable, and there are multiple default routers on the link,
   then the unreachability will result in the host trying to use one of
   the other default routers.  But if a host is unreachable there is no
   alternate path to use.  Thus in that case the only benefit of NUD is
   to be able to generate ICMP errors.


4.  Assumptions about Topology and Address Mapping

   In order to minimize the multicast packets we need to make some
   assumptions that tie together the L2 functional elements and the L3
   functional elements.  We also state our understanding of how IPv6
   would map to a LowPan network:
   o  One PAN-ID defines one LowPan Network.
   o  Each LowPan corresponds to one IPv6 subnet as PAN-ID may be used
      to determine a subnet.
   o  There is one PAN co-ordinator or PAN group leader per one LowPan.
   o  The IPv6 router which sits in the boundary of the LowPan is a PAN
      co-ordinator.
   o  There can be multiple co-ordinators in the LowPan.
   o  When a device connects to the LowPan at layer 2, it finds out a
      (unicast) layer 2 address for its co-ordinator.
   o  By recursive construction, the previous item implies that a co-
      ordinator knows its co-ordinator from when it connected to the
      LowPan, hence there is distributed knowledge of unicast addresses
      that lead all the way to the PAN co-ordinator.
   o  The IPv6 router assigns addresses through prefix advertisement.
   o  The other FFDs in the network do not act as a IPv6 router, but
      they generally route data packet in the L2 layer (Mesh layer
      routing).
   o  Star topology assumes that each node is one hop away from the PAN
      co-ordinator.
   o  This document defines a mesh topology (see diagram below).  In
      mesh topology, each node is capable of forwarding.  Thus it can be
      assumed as a network of full functional devices (FFDs) with one
      PAN co-ordinator and multiple co-ordinators.





Chakrabarti & Nordmark  Expires September 6, 2006               [Page 6]


Internet-Draft    LowPan Neighbor Discovery Extensions        March 2006


   o  FFDs may or may not be more than one hop away from the PAN co-
      ordinator.
   o  We assume that the 64-bit EUI-64 addresses are used as link-layer
      address in the lowpan, since these addresses never change for a
      given node.  Appendix A discusses some additional considerations
      should we apply this to the 16-bit addresses.

   This document currently supports the following topologies:


            1)  Star  Topology

                 PAN-C
                    O
                 /  |   \
                o   o    o  <------- RFDs or FFDs

           2) Mesh Topology

            Example-1                               Example-2

                   O    PAN-C                     O <--  PAN-C
              /    |      \     o              /  |    \
             /     |       \   /              /   |     \
            FFD----FFD----- FFD              FFD--FFD-----FFD
             \     |\       /  \              \    | \    /|
              \    | \     /|   o              \   |  \  / |
               \   |  \   / |                   \  |   \/  |
                \  |   \ /  |                    \ |   /\  |
                 \ |    \   |                     \|  /  \ |
                  \|   / \  |                      |/     \|
                   FFD    \ |                      FFD    FFD
                /  | \     FFD
               o   0  o    / \
                           o  o  <--RFDs

   Each FFD may act as simple co-ordinators but there is only one PAN
   co-ordinator in the mesh LowPan topology.


5.  Minimizing Multicast of Router Solicitations and Advertisements

   We have potential issues with multicast of RS and RA during the
   initialization of a host, and also due to the periodic RAs.

5.1.  Avoiding L2 broadcast of initial RS and RA

   Since we assume that the PAN co-ordinator is also the IPv6 router we



Chakrabarti & Nordmark  Expires September 6, 2006               [Page 7]


Internet-Draft    LowPan Neighbor Discovery Extensions        March 2006


   can completely avoid multicast RS and RA during the initialization of
   a lowpan node as follows.

   When a lowpan node initializes and needs to send a Router
   Solicitation addressed to the IPv6 all-routers multicast address, it
   should only send the request to the node's co-ordinator.  Thus the L2
   destination address will be that of the co-ordinator.  In a star
   topology the co-ordinator is also the PAN co-ordinator hence the IPv6
   router.  Thus this will result in the RS being delivered to the
   router.  In a mesh topology, when such a packet is received by a co-
   ordinator, it will look at the IPv6 header and if that is destined to
   the all-routers IPv6 multicast address, then it will relay that
   packet (without decrementing the IPv6 hop limit) to its co-ordinator.
   This will deliver the RS towards the PAN co-ordinator.

   The lowpan nodes MUST include a Sender Link-layer Address option in
   the Router Solicitation, since this then allows the router to unicast
   a Router Advertisement in response.

   Since every host sends a RS when it attaches to the PAN and there is
   a single router for the PAN (the PAN co-ordinator), this router will
   observe the arrival of all the IPv6 link local addresses [TBD: how
   can it also find out about the other addresses?  Guess based on the
   advertised prefixes?].  This allows the router to have a complete
   list of all the nodes on the link with their L2 addresses, which can
   be useful for other optimizations below.

   The above behavior is also consistent with the approach in DNA, which
   relies on every host sending a RS when it attaches to a new link.

5.2.  Avoiding L2 broadcast of periodic RAs

   It isn't clear whether a periodic RA sent every 7 minutes to all-
   nodes will be a major problem.  But, in mesh topology, an periodic
   Router Advertisement(RA) from the IPv6 router means flooding in the
   network.  There are a few alternatives discussed in this document.
   Firstly, it might very well be possible to increase the default time
   significantly as long as the hosts can use some other mechanism to
   detect when the router (the PAN co-ordinator) disappears.

   Secondly, instead of broadcasting such router advertisements at layer
   2, since the router knows all the layer 2 addresses of the nodes in
   the PAN from the Router Solicitations it has received, it can instead
   do replicated unicast at layer 2.  Thus sending a packet to the all-
   nodes IPv6 multicast address would result in sending one copy to each
   unicast address.  This requires more energy for the router, but might
   overall be a benefit for the nodes in the PAN.




Chakrabarti & Nordmark  Expires September 6, 2006               [Page 8]


Internet-Draft    LowPan Neighbor Discovery Extensions        March 2006


   Alternately, there could be a hybrid mechanism of the above two
   proposals.  In this case, the PAN co-ordinator aka IPv6 router sends
   periodic RA to the co-ordinators in its PAN by sending unicast
   messages to each of them.  The RA announcement interval must be
   longer than the default RA interval.  Each co-ordinator can act as
   proxy IPv6 router advertiser and they can broadcast the RA on behalf
   of the IPv6-router in their own domain periodically (interval is
   TBD).  In this method, the co-ordinators could use the beacon enabled
   L2 slots for router advertisements to avoid collisions and power
   wastage.  But, in this method, a new mechanism needs to be developed
   for co-ordinator to co-ordinator message exchange.


6.  Minimizing Multicast of Neighbor Solicitations

   There are two cases to consider when it comes to reducing or
   eliminating the multicast Neighbor Solicitation messages.  One is
   finding the actual neighbors and their L2 addresses, whether
   initiated from nodes in the lowpan network or from the outside.
   Another case is the resource spent on looking for non-existent
   neighbors.  For example a non-existent or unreachable IPv6 address
   may have same subnet prefix(es) assigned to the 6lowpan network.  A
   neighbor solicitation for a non-existing IPv6 address might happen by
   accident, or as a DoS attack from outside the lowpan network.

6.1.  Avoiding L2 broadcast of NS messages for existing nodes

   Sending Neighbor Solicitation messages to resolve a layer 2 address
   for a IPv6 address is also a waste of bandwidth and energy in the
   LowPan network.  Thus the following proposal attempts to distribute
   the link-layer information of nodes to the PAN co-ordinator which has
   higher possibility of being a full-functional device.  Even if the
   co-ordinator lives a couple of L2 hops away from the enquiring node
   (assuming mesh routing at the L2 layer), each neighbor solicitation
   in this proposal will involve only a few nodes in the path of
   traversal of the packet.  This is in effect, a unicast solicitation
   for resolving an address.

   This part of the proposal does not require any protocol changes but
   instead relies on the existing support in Neighbor Discovery.  The
   prefix advertising router would not set the "on-link" ("L") flag in
   the prefixes it advertises, even though these prefixes are on-link.
   This would result in the hosts in the PAN initially sending packets
   to all through the router for on-link destination nodes (The hosts
   don't know the destination is on-link).  This causes the router to
   both forward the packet back to the PAN and send a Redirect message
   back to the sender.  The redirect can include the L2 address for the
   target, since it is likely to have that information in its neighbor



Chakrabarti & Nordmark  Expires September 6, 2006               [Page 9]


Internet-Draft    LowPan Neighbor Discovery Extensions        March 2006


   cache.

   The above works well when the router knows the L2 addresses for each
   IPv6 address (link-local and global) in the PAN.  If the router
   doesn't know this (e.g., for a global address), the router would need
   to multicast Neighbor Solicitation before sending the redirect.  More
   thoughts are needed to specify the protocol behavior when the
   router's cache entry becomes stale or when a lowpan node moves away
   from the PAN.  What if the router itself looses power?  Should there
   be multiple routers/co-ordinators who keep the neighbor information
   in distributed fashion - so that absence or failure of one router
   will not affect the neighbor solicitation negatively?  Or will a PAN
   co-ordinator failure be noticed by all the lowpan nodes, so that they
   all can send a new RS to the router (which would inform the new PAN
   co-ordinator (the IPv6 router) of their L2 addresses.

6.2.  Avoiding L2 broadcast of NS messages for non-existent nodes

   If we apply the above configuration with no advertised on-link
   prefixes, the packet for an unknown or non-existent node would end up
   at the router for the lowpan.  This is true whether the packet was
   originated by a node in the lowpan, or originated somewhere else in
   the Internet and forwarded to the lowpan router.

   In the standard Neighbor Discovery behavior, this would result in the
   router multicasting a Neighbor Solicitation message.  If the node
   doesn't exist or is unreachable from the router, then repeated
   packets would result in repeated multicast NS messages (limited to
   one per second for a single IPv6 address).

   We can avoid this resource consumption if the router (the PAN co-
   ordinator) can keep an authoritative list of all the IPv6 addresses
   that are present in the lowpan - and their L2 addresses.  We've shown
   above how this list can be maintained for the link-local IPv6
   addresses by relying on the reception of Router Solicitations.  If we
   can have the router also maintain this for global IPv6 addresses,
   then we can avoid any NS messages for unknown destinations.

   Then if a node sends a packet for a destination which does not exist
   in the LowPan network, the PAN co-ordinator will not be able to find
   the node in its lookup table.  The PAN co-ordinator can immediately
   send a ICMPv6 unknown destination error message to the originator in
   response to the packet.  This will avoid any multicast Neighbor
   Solicitation messages.

   Note that the above assumes that if there are multiple IPv6 routers
   attached to the PAN, they all can somehow efficiently find out the
   IPv6 address and L2 addresses that are in the PAN.



Chakrabarti & Nordmark  Expires September 6, 2006              [Page 10]


Internet-Draft    LowPan Neighbor Discovery Extensions        March 2006


7.  Minimizing Multicast for Duplicate Address Detection

   Duplicate Address Detection (DAD) is sent to the solicited-node
   multicast address which is derived from lower 24 bits of the target
   IPv6 address.  Should nodes in LowPan network use duplicate address
   detection Avoiding duplicate address detection will save broadcast
   signaling in the PAN-since 802.15.4 does not have multicast
   capabilities.  Besides, each duplicate address detection message is
   capable of waking up sleeping reduced function devices in the network
   and making the devices less and less energy efficient.

   In a star topology, it might be OK to broadcast the DAD message, but
   in a multi-hop LowPan network, it means flooding.  In the following
   optimization case, the assumption is that the IPv6 Router keeps a
   table of IPv6 to EUI-64bit MAC address mapping of each IPv6
   configured node in the PAN.

   When a node (RFD or FFD) boots up or configures its LowPan interface,
   it can send the Duplicate Address Detection message the same way we
   suggested sending the Router Solicitations.  In a multi-hop network
   the message is relayed to the PAN co-ordinator (IPv6 router) by the
   nodes co-ordinator.  The IPv6 router can check in its complete list
   of neighbor whether the address is a duplicate, and respond
   appropriately.  (If we want to allow Secure Neighbor Discovery , then
   it makes sense for the router to relay the message (without
   decrementing the hop limit) to the "owner" of the address, so that
   this node can answer with the appropriate SeND signature etc.)

   Alternatively, if we assume that each IPv6 configured node has EUI-
   64bit MAC address and the nodes do not use IPv6 temporary addresses
   [RFC 3041] or CGA addresses , then all the IPv6 addresses would be
   directly derived from the EUI-64, hence will be unique.  In that case
   IPv6 Duplicate Address Detection mechanism is not needed in the
   LowPan network.


8.  Neighbor Unreachability Detection

   If we used the EUI-64 MAC addresses in the lowpan and an IPv6 address
   is never reassigned to a different node in the lowpan, then there is
   no need to perform NUD towards a host.  This is because the IPv6->MAC
   address mapping would never change.

   In addition, if we had some other mechanism, e.g. a layer 2
   detecttion of a PAN co-ordinator failure and recovery or replacement
   by a different PAN co-ordinator, then we do not need to do NUD
   towards the router.




Chakrabarti & Nordmark  Expires September 6, 2006              [Page 11]


Internet-Draft    LowPan Neighbor Discovery Extensions        March 2006


   How does a node find out about unreachability (link-down, host-down)
   of a node in the link?  Should this be restricted only when data-
   delivery happens?  Should this be left to the L2-routing errors?
   Note, for star topology, NUD to router is not an issue, but perhaps
   redundant.


9.  Open Issues

   The following are the known open issues:
   o  For LowPan nodes, should we say that all NS messages must contain
      the source link-layer address option to avoid triggering a
      followup neighbor solicitation in reverse direction?
   o  What is the best way to keep the neighbor cache information
      distributed among different routers/co-ordinators for fault-
      tolerance?  Should we develop an inter co-ordinator message
      exchange protocol for distributed information, proxy and caching?
   o  Should a node de-register itself from router/co-ordinator's
      neighbor cache if it decides to move away?
   o  What is the default lifetime and interval values for routers and
      prefixes?
   o  Is there a L2 lowpan mechanism by which a host can detect should
      its co-ordinator fail?  Is there a mechanism for a node in a PAN
      to detect when the PAN co-ordinator, which might be several hops
      away, fails?  If there is, then we can potentially removed the
      need for periodic Router Advertisements.
   o  We have a mechanism for the PAN co-ordinator to find out all the
      IPv6 link-local addresses in the lowpan.  We need to extend this
      to the global addresses that are used as well.


10.  Security Considerations

   These optimizations are not known to introduce any new threats
   against Neighbor Discovery beyond what is already document in .  If
   those threats are a concern, and the lowpan layer 2 security is not
   used, Secure Neighbor Discovery may be considered in combination with
   these optimizations.


11.  IANA Considerations

   There are no IANA considerations for this document.


12.  Acknowledgements

   XXX TBD



Chakrabarti & Nordmark  Expires September 6, 2006              [Page 12]


Internet-Draft    LowPan Neighbor Discovery Extensions        March 2006


13.  References

13.1.  Normative References

   [1]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor
        Discovery for IP version 6", draft-ietf-ipv6-2461bis-04.txt
        (work in progress), May 2005.

   [2]  Montenegro, G. and N. Kushalnagar, "Transmission of IPv6 Packets
        over IEEE 802.15.4 networks",
        draft-montenegro-lowpan-ipv6-over-802.15.4-02.txt (work in
        progress), February 2005.

   [3]  Kushalnagar, N. and G. Montenegro, "6LoWPAN: Overview,
        Assumptions, Problem Statement and Goals",
        draft-kushalnagar-lowpan-goals-assumptions-00.txt (work in
        progress), February 2005.

13.2.  Informative References

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

   [5]   Narten, T. and R. Draves, "Privacy Extensions for Stateless
         Address Autoconfiguration in IPv6", RFC 3041, January 2001.

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

   [7]   Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
         Discovery(ND) Trust Models and Threats", RFC 3756, May 2004.

   [8]   Thomson, S. and T. Narten, "IPv6 Stateless Address
         Autoconfiguration", RFC 2462, December 1998.

   [9]   Aura, T., "Cryptographically Generated Addresses", RFC 3972,
         March 2005.

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


Appendix A.  Supporting short addresses?

   [Discuss issues with supporting 16bit addresses with lowpan-ND.]

   We would at least need NUD to handle 16 bit MAC addresses, since they
   can change.  Depending on how frequently they change, supporting 16



Chakrabarti & Nordmark  Expires September 6, 2006              [Page 13]


Internet-Draft    LowPan Neighbor Discovery Extensions        March 2006


   bit MAC addresses might make some other proposed optimization
   techniques (in this document) more difficult or impossible.  In other
   situation of unreachability, the sender node (if it's a router) sends
   a multicast neighbor soliciation following a NUD failure or if the
   sender is a host it deletes the unreachable neighbor's entry and then
   sends the solicitation packet to the IPv6-router(PAN co-ordinator).

   Also, when the L2 address changes, usually the affected node sends
   unsolicited Neighbor Advertisements to the neighbors to note the L2
   address change in their neighbor cache.  Since 16bit short addresses
   are not unique, there is higher probability that these addresses will
   change and thus we need to optimize unsolicited neighbor
   advertisments in the LowPan network.  Perhaps the IPv6-router or the
   PAN co-ordinator can be used as the central contact point.  Hence the
   changed node may notify the PAN co-ordinator about the change.  But
   then either the PAN co-ordinator will have to notify all nodes about
   that change or other nodes need to find out the change through
   neighbor solicitation following a NUD.  It seems, IEEE EUI-64
   addresses are simple to use in case of IPv6.


Appendix B.  Summary of proposed optimizations



---------------------------------------------------------------------------------
| Scenarios                        |             Optimization                   |
---------------------------------------------------------------------------------
|   Initial  RS to all-routers     |  Initial RS to PAN co-ord address (unicast)|
|                                  |     Must use  SLLA option for L2 addr      |
+-------------------------------------------------------------------------------+
|   Initial  RA to all-nodes       |         Avoid                              |
+-------------------------------------------------------------------------------+
|  Periodic  RA to all-nodes       |          See 5.2 for proposals             |
+-------------------------------------------------------------------------------+
|  Neighbor Solicitation           | Send unicast message to the IPv6-router    |
+-------------------------------------------------------------------------------+
| Unsolicited Neighbor Adv         |         Avoid by using IEEE EUI-64 MAC     |
+-------------------------------------------------------------------------------+
| Neighbor Unreachability Detection|    Avoided if IEEE EUI-64 MAC addr used    |
+-------------------------------------------------------------------------------+
|  Duplicate address Detection     |             Same   as above                |
+-------------------------------------------------------------------------------+
|  ND Constants                    |               TBD                          |
+-------------------------------------------------------------------------------+













Chakrabarti & Nordmark  Expires September 6, 2006              [Page 14]


Internet-Draft    LowPan Neighbor Discovery Extensions        March 2006


Authors' Addresses

   Samita Chakrabarti
   Sun Microsystems, Inc.
   16 Network Circle
   Menlo Park, CA 94025
   USA

   Email: Samita.Chakrabarti@Sun.COM


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

   Email: Erik.Nordmark@Sun.COM

































Chakrabarti & Nordmark  Expires September 6, 2006              [Page 15]


Internet-Draft    LowPan Neighbor Discovery Extensions        March 2006


Intellectual Property Statement

   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.


Disclaimer of Validity

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


Copyright Statement

   Copyright (C) The Internet Society (2006).  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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Chakrabarti & Nordmark  Expires September 6, 2006              [Page 16]


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