INTAREA WG                                                S. Chakrabarti
Internet-Draft                                                  Ericsson
Updates: 4861 (if approved)                                  E. Nordmark
Intended status: Standards Track                           Cisco Systems
Expires: January 3, 2012                                    July 2, 2011

           Energy Aware IPv6 Neighbor Discovery Optimizations


   IPv6 Neighbor Discovery (RFC 4861) protocol has been designed for
   neighbor's address resolution, unreachability detection, address
   autoconfiguration, router advertisement and solicitation.  With the
   progress of Internet adoption on various industries including home,
   wireless and machine-to-machine communications, there is a desire for
   extension or optimization of RFC 4861 protocol for more energy-
   efficient networks and nodes.  Research indicates that often
   networked- nodes require more energy than stand-alone nodes because a
   node's energy usage depends on network messages it has to receive and
   or respond.  While reducing energy consumption is essential for
   battery operated nodes in some machines, saving energy actually a
   cost factor in business in general as the explosion of more device
   usage is leading to usage of more servers and network infrastructure
   in all sectors of the society and business.  This document describes
   methods of optimizations by reducing periodic multicast messages,
   frequent Neighbor Solicitation messages and provides a mechanism of
   built-in prefix-dissemination in simple scenarios.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

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

   This Internet-Draft will expire on January 3, 2012.

Copyright Notice

Chakrabarti & Nordmark   Expires January 3, 2012                [Page 1]

Internet-Draft               Energy-aware-nd                   July 2011

   Copyright (c) 2011 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
   ( 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 Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Definition Of Terms  . . . . . . . . . . . . . . . . . . . . .  4
   3.  Assumptions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  The New Set Of Requirements  . . . . . . . . . . . . . . . . .  5
   5.  New Neighbor Discovery Options and Messages  . . . . . . . . .  5
     5.1.  Address Registration Option  . . . . . . . . . . . . . . .  6
     5.2.  Authoritative Border Router Option . . . . . . . . . . . .  7
   6.  Applicability Statement  . . . . . . . . . . . . . . . . . . .  9
   7.  Energy-aware Neighbor Discovery Messages . . . . . . . . . . . 10
   8.  Host Behavior  . . . . . . . . . . . . . . . . . . . . . . . . 11
   9.  The Border Router(BR) Behavior . . . . . . . . . . . . . . . . 11
   10. Intermediate-router Behavior . . . . . . . . . . . . . . . . . 12
   11. Bootstrapping  . . . . . . . . . . . . . . . . . . . . . . . . 12
   12. Local Mobility . . . . . . . . . . . . . . . . . . . . . . . . 12
   13. Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   14. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     16.1. Normative References . . . . . . . . . . . . . . . . . . . 13
     16.2. Informative References . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14

Chakrabarti & Nordmark   Expires January 3, 2012                [Page 2]

Internet-Draft               Energy-aware-nd                   July 2011

1.  Introduction

   IPv6 ND [ND] 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.

   The periodic RA messages in IPv6 ND [ND], and NS/NA messages require
   all IPv6 nodes in the link to be in listening mode even when they are
   in idle mode.  It requires energy for the sleepy nodes which may be
   otherwise sleeping during idle mode.  Non-sleepy nodes also may save
   energy if instead of continuous listening mode, they actually pro-
   actively synchronize their state with one or two entity in the
   network.  With the explosion of Internet-of-things and machine to
   machine communication, more and more devices would be using IPv6
   addresses in the near future.  Today, most electricity usage in
   United States and in developing countries are in the home buildings
   and commercial buildings; the electronic Internet appliances/tablets
   etc. are gaining popularities in the modern home networks.  These
   network of nodes must be conscious about saving energy as their
   number increases as otherwise it will cost more and increase stress
   on electrical grids, and increases carbon foot-print.

   IPv6 Neighbor Discovery Optimization for 6LoWPAN [6LOWPAN-ND]
   addresses many of the concerns described above by optimizing the
   Router advertisement, minimizing periodic multicast packets in the
   network and introducing two new options - one for node registration
   and another for prefix dissemination in a network where all nodes in
   the network are uniquely identified by their 64-bit Interface
   Identifier.  EUI-64 identifiers are recommended as unique Interface
   Identifiers, however if the network is isolated from the Internet,
   uniqueness of the identifiers may be obtained by other mechanisms
   such as a random number generator with lowest collision rate.
   Although, the ND optimization [6LOWPAN-ND] applies to 6LoWPAN

Chakrabarti & Nordmark   Expires January 3, 2012                [Page 3]

Internet-Draft               Energy-aware-nd                   July 2011

   [LOWPAN] network, the concept is mostly applicable to IPv6 network
   that wants to optimize power.

   Thus optimizing the regular IPv6 Neighbor Discovery [ND] 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 any IPv6 energy-aware
   networks such as Home or Enterprise building networks and as well as
   Data Centers.

   [ This document is under construction and will have an update soon to
   solidify the content of the draft]

2.  Definition Of Terms

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

      It is a wireless link determined by single hop reachability of
      neighboring nodes.
      These are the intermediate routers in the home network who can
      communicate with other intermediate routers in the same home
      network.  These are also the immediate first-hop router for the
      physically attached hosts or wirelessly reachable hosts.
   Root-node or Border Rotuer(BR):
      It is a border router typically located at the junction Internet
      and Home Network.
      A host in a IPv6 network is considered a IPv6 node without routing
      and forwarding capability.
      It is the IEEE defined 64-bit extended unique identifier formed by
      concatenation of 24-bit or 36-bit company id value by IEEE
      Registration Authority and the extension identifier within that
      company-id assignment.  The extension identifiers are 40-bit (for
      24-bit company-id) or 28-bit (for the 36-bit company-id)

3.  Assumptions

   o  All nodes in the network carry unique interface ID in order to
      form the auto-configured IPv6 address uniquely.

Chakrabarti & Nordmark   Expires January 3, 2012                [Page 4]

Internet-Draft               Energy-aware-nd                   July 2011

   o  All nodes use the same IPv6 prefix if multi-level prefix
      distribution technique (described in this document) is used
   o  The special scenario for multi-level prefix dissemination requires
      a topology where all packets of that network must go through a
      access-gateway of that network.  The access gateway may support
      multi-level intermediate-rotuers with packet forwarding capability
      and prefix-distribution capability as discussed in this document.
      The hosts in this network must send and receive packets through a
      default router.  The default router could be the access-gateway or
      the Border Router or the intermediate-router depending on the
      location of the host.

4.  The New Set Of Requirements

   In future homes and new machine-to-machine networks, it will be very
   often a hierarchical networks of sub-networks which are all directly
   or indirectly served by a root-node router or gateway with an access
   to the Internet.

   In the cloud computing environment, it is possible that part of the
   network or sub-network are geographically separated.  Thus the
   concept of IPv6-subnet of link-local nodes may be extended.

   o  Node initiated Registration and address allocation in order to
      avoid periodic multicast messages.
   o  Address allocation through multicast IPv6 Neighbor Discovery [ND]
      and IPv6 Autoconfiguration [AUTOCONF] with tuned parameters for
      different sub-networks under one gateway or root home router.  For
      example, one sub-network consists of television and game station
      networks and another network is a IEE 802.15.4 ZigBee IP network
      running 6LoWPAN [LOWPAN].
   o  A Requirement of distribution of configuration securely cascading
      through the network of sub-networks.
   o  The node registration may replace the requirement of doing
      Duplicate Address Detection.

5.  New Neighbor Discovery Options and Messages

   This document points to the section of 6LoWPAN-ND [6LOWPAN-ND] as
   appropriate. 6LoWPAN-ND [6LOWPAN-ND] assumes a concept of 6Lowpan-
   link which is equivalent to a subnet in classical IPv6-subnet sharing
   the same IPv6-prefix but it is a collection of sub-networks connected
   by special routers called 6LR [6LOWPAN-ND].

Chakrabarti & Nordmark   Expires January 3, 2012                [Page 5]

Internet-Draft               Energy-aware-nd                   July 2011

5.1.  Address Registration Option

   The Address Registration Option(ARO) is useful for avoiding Duplicate
   Address Detection messages since it requires a unique ID for
   registration.  The address registration is used for maintaining
   reachability of the node or host by the router.

   The routers keep track of host IP addresses that are directly
   reachable and their corresponding link-layer addresses.  This is
   useful for lossy and lowpower networks and as well as wired networks.
   An Address Registration Option (ARO) can be included in unicast
   Neighbor Solicitation (NS) messages sent by hosts.  Thus it can be
   included in the unicast NS messages that a host sends as part of
   Neighbor Unreachability Detection to determine that it can still
   reach a default router.  The ARO is used by the receiving router to
   reliably maintain its Neighbor Cache.  The same option is included in
   corresponding Neighbor Advertisement (NA) messages with a Status
   field indicating the success or failure of the registration.  This
   option is always host initiated.

   The ARO is required for reliability and power saving.  The lifetime
   field provides flexibility to the host to register an address which
   should be usable (the reachability information may be propagated to
   the routing protocols) during its intended sleep schedule of nodes
   that switches to frequent sleep mode.

   The sender of the NS also includes the EUI-64 of the interface it is
   registering an address from.  This is used as a unique ID for the
   detection of duplicate addresses.  It is used to tell the difference
   between the same node re-registering its address and a different node
   (with a different EUI-64) registering an address that is already in
   use by someone else.  The EUI-64 is also used to deliver an NA
   carrying an error Status code to the EUI-64 based link-local IPv6
   address of the host.

   When the ARO is used by hosts an SLLA option MUST be included and the
   address that is to be registered MUST be the IPv6 source address of
   the Neighbor Solicitation message.

Chakrabarti & Nordmark   Expires January 3, 2012                [Page 6]

Internet-Draft               Energy-aware-nd                   July 2011

   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 = 2  |    Status     |   Reserved    |
   |           Reserved            |     Registration Lifetime     |
   |                                                               |
   +                            EUI-64                             +
   |                                                               |

   Type:          TBD1
   Length:        8-bit unsigned integer.  The length of the option in
                  units of 8 bytes.  Always 2.
   Status:        8-bit unsigned integer.  Indicates the status of a
                  registration in the NA response.  MUST be set to 0 in
                  NS messages.  See below.
   Reserved:      This field is unused.  It MUST be initialized to zero
                  by the sender and MUST be ignored by the receiver.
   Registration Lifetime:  16-bit unsigned integer.  The amount of time
                  in a unit of 10 seconds that the router should retain
                  the Neighbor Cache entry for the sender of the NS that
                  includes this option.
   EUI-64:        64 bits.  This field is used to uniquely identify the
                  interface of the registered address by including the
                  EUI-64 identifier assigned to it unmodified.

   The Status values used in Neighbor Advertisements are:

          | Status |                 Description                |
          |    0   |                   Success                  |
          |    1   |              Duplicate Address             |
          |    2   |             Neighbor Cache Full            |
          |  3-255 | Allocated using Standards Action [RFC2434] |

                                  Table 1

5.2.  Authoritative Border Router Option

   This is a special optional operation introducing prefix dissemination
   for a simple scenario where a network of nodes under the same Border
   Router (example: Home gateway) share the same prefix.  The routers

Chakrabarti & Nordmark   Expires January 3, 2012                [Page 7]

Internet-Draft               Energy-aware-nd                   July 2011

   below the Border Router have limited forwarding/routing capabilities
   and the packets sent/received by them from the Internet MUST go via
   the Border Router.  This can assume that /64 bit prefix is delegated
   from the authoritative Border Router node then propagated down
   through the intermediate nodes to the hosts without change.  The
   intermediate routers should keep a copy of this prefix for local
   distribution and are responsible for periodic synchronization.

                           | BR |
                    |         |
                   iR1        iR2--H1
                   / \         \
                  H2  H3       iR3
                               / \
                              H4  H5

                   A typical Topology where ABRO is useful

   In the above example, we can can think of BR as a Home gateway while
   iR routers represent intermediate routers which can be considered as
   in-home smaller routers connecting hosts for different applications
   or usages such as appliance network or home-entertainment network.

   The Authoritative Border Router option MUST be included in all Router
   Advertisement messages when Router Advertisements are used to
   propagate information between routers in the topology described

Chakrabarti & Nordmark   Expires January 3, 2012                [Page 8]

Internet-Draft               Energy-aware-nd                   July 2011

    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   |        Version Number         |
   |                            Reserved                           |
   |                                                               |
   +                                                               +
   |                                                               |
   +                          BR Address                           +
   |                                                               |
   +                                                               +
   |                                                               |

   Type:          TBD3
   Length:        8-bit unsigned integer.  The length of the option in
                  units of 8 bytes.  Always 3.
   Version Number:  16-bit unsigned integer.  The version number
                  corresponding to this set of information contained in
                  the RA message.  The authoritative Border router
                  originating the prefix increases this version number
                  each time its set of prefix or context information
                  changes.  This version number uses sequence number
                  arithmetic as it may wrap around.
   Reserved:      This field is unused.  It MUST be initialized to zero
                  by the sender and MUST be ignored by the receiver.
   BR Address:    IPv6 address of the Border Router that is the origin
                  of the included version number.

   This document assumes that an implementation will have configuration
   knobs to determine whether it is running in classical IPv6 ND [ND] or
   Optimized Energy Aware ND (this document) mode

6.  Applicability Statement

   This document aims to guide the implementors to choose an appropriate
   IPv6 neighbor discovery and Address configuration procedures suitable
   for any IPv6 energy-aware network.  These optimization is useful for
   the classical IPv6 subnet and as well as future home network where
   the network is composed of several sub-networks served by a root-node
   or home-gateway and the hosts always send packets through a default-

Chakrabarti & Nordmark   Expires January 3, 2012                [Page 9]

Internet-Draft               Energy-aware-nd                   July 2011

7.  Energy-aware Neighbor Discovery Messages

   1.   Router Advertisement(RA): Periodic RAs SHOULD be avoided.  Only
        solicited RAs are recommended.  An RA MUST contain the Source
        Link-layer Address option containing Router's link-layer address
        (this is optional in [ND].  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 may carry Authoritative Router option
        option generated by the root-node.
   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
        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 send periodic unicast messages
        RS to the routers.  The time-periods for the RS varies on the
        deployment scenarios and the Default Router Lifetime advertised
        in the RAs.
   3.   Default Router Selection: Same as in section 6.3.6 of RFC
   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 message MUST use the
        Address Registration option in order to accomplish the
   5.   Neighbor Advertisement (NA): As defined in [ND]
   6.   Redirect Messages: A router 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[ND], i,e. a host
        MUST NOT send redirect messages.
   7.   Message Validation: Same as in RFC 4861[ND]
   8.   MTU option: As per the RFC 4861.
   9.   Address Resolution: No 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 Address Registration options(ARO) and create an extended
        neighbor cache of 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 RFC
        4861[ND].  However, if Address Registration Option is used, the
        NUD SHOULD be combined with the Re-registration of the node.

Chakrabarti & Nordmark   Expires January 3, 2012               [Page 10]

Internet-Draft               Energy-aware-nd                   July 2011

        This way no extra message for NUD is required.

8.  Host Behavior

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

   A host SHOULD be able to autoconfigure its IPv6 addresses using the
   IPv6 prefix obtained from Router Advertisement.  The host SHOULD form
   its link-local address from the EUI-64 as specified by IEEE
   Registration Authority and RFC 2373.  If this draft feature is
   implemented and configured, the host MUST NOT re-direct Neighbor
   Discovery messages.  The host does not require to join solicited-node
   multicast address but it MUST join the all-node multicast address.

   A host always sends packets to (one of) its default router(s) unless
   it receives Router redirect messages from a neighboring router.  This
   is accomplished by the routers never setting the 'L' flag in the
   Prefix options.

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

9.  The Border Router(BR) Behavior

   A Border Router normally may have multiple interfaces and connects
   the nodes in a link like a regular IPv6 subnet(s) or acts as a
   gateway between separate networks such as Internet and home networks
   .  The Border Router is responsible for distributing one or more /64
   prefixes to the nodes to identify a packet belonging to the
   particular network.

   The routers SHOULD NOT garbage collect Registered Neighbor Cache
   entries since they need to retain them until the Registration
   Lifetime expires.  Similarly, if Neighbor Unreachability Detection on
   the router determines that the host is UNREACHABLE (based on the
   logic in [ND]), the Neighbor Cache entry SHOULD NOT be deleted but be
   retained until the Registration Lifetime expires.  A renewed ARO
   should mark the cache entry as STALE.

   When the BR sends a Router Advertisement it SHOULD include a
   Authoritative Router option that includes its own address.

   A BR keeps a cache for all the nodes' IP addresses, created from the
   Address Registration processing.  It may send the Router

Chakrabarti & Nordmark   Expires January 3, 2012               [Page 11]

Internet-Draft               Energy-aware-nd                   July 2011

   advertisement with Prefix option and Authoritative Border Router

10.  Intermediate-router Behavior

   The intermediate routers may exist in some special scenarios of home
   networks or other networks where the Border Router sits at the root
   of the network and all packets go in and out of the gateway.

   The behavior of this node is still under discussion.  But it aids in
   prefix dissemination or distribution if the Border Router sends the
   ABRO option with Router Advertisements.  The intermediate-router role
   is somewhat similar to 6LR as defined in [6LOWPAN-ND].  If the
   intermediate-router acts as a default router to its neighboring
   hosts, then it should be able to process the Address Registration
   option and register the neighboring nodes.

11.  Bootstrapping

   If the network is a classic IPv6 subnet, and the energy-aware
   Neighbor Discovery mechansim is used, then the node uses its link-
   local address to send Router Solicitation and then it sends the Node
   Registration message as described in this document in order to form
   the address.  The Duplicate address detection process should be
   skipped if the network is guaranteed to have unique interface

   The intermerdiate-routers may also first bootstrap as a host and then
   turn themselves into router-mode.  The detail messages will be
   discussed in the next version of the document.

12.  Local Mobility

   If energy-aware Neighbor Discovery model is used and same IPv6 prefix
   is shared by all the nodes in the network that is accessed by the
   Border Router, then it assures transparent mobility of the nodes
   inside the network bordered by Border Router.

   The local mobility transparency is quite useful in a home network
   environment where multiple networks may exist and be served by a
   Border Router or a Home Gateway.  Thus one can wirelessly move a node
   from one home sub-network to another without disrupting data

Chakrabarti & Nordmark   Expires January 3, 2012               [Page 12]

Internet-Draft               Energy-aware-nd                   July 2011

13.  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, careful security considerations will be handled
   in a follow-up IETF publication of this draft.

14.  IANA Considerations


15.  Acknowledgements

   The primary idea of this document are from 6LoWPAN Neighbor Discovery
   document [6LOWPAN-ND] and the discussions from the 6lowpan working
   group members, chairs Carsten Bormann and Geoff Mulligan and through
   our discussions with Zach Shelby.

   The inspiration of such a IPv6 generic document came from Margaret
   Wasserman who saw a need for such a document at the IOT workshop at
   Prague IETF.

16.  References

16.1.  Normative References

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

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

              Shelby, Z., Chakrabarti, S., and E. Nordmark, "ND
              Optimizations for 6LoWPAN", draft-ietf-6lowpan-nd-17.txt
              (work in progress), June 2011.

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

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

Chakrabarti & Nordmark   Expires January 3, 2012               [Page 13]

Internet-Draft               Energy-aware-nd                   July 2011

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

16.2.  Informative References

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

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

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

              Baccelli, E. and M. Townsley, "IP Addressing Model in
              Adhoc Networks",
              draft-ietf-autoconf-adhoc-addr-model-02.txt (work in
              progress), December 2009.

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

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

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

Authors' Addresses

   Samita Chakrabarti
   San Jose, CA


   Erik Nordmark
   Cisco Systems
   San Jose, CA


Chakrabarti & Nordmark   Expires January 3, 2012               [Page 14]