Internet DRAFT - draft-chakrabarti-nordmark-energy-aware-nd

draft-chakrabarti-nordmark-energy-aware-nd





INTAREA WG                                                S. Chakrabarti
Internet-Draft                                                  Ericsson
Updates: 4861 (if approved)                                  E. Nordmark
Intended status: Standards Track                           Cisco Systems
Expires: September 14, 2012                                 M. Wasserman
                                                       Painless Security
                                                          March 13, 2012


           Energy Aware IPv6 Neighbor Discovery Optimizations
             draft-chakrabarti-nordmark-energy-aware-nd-02

Abstract

   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
   optimizing legacy IPv6 Neighbor Discovery protocol to be more
   efficient in terms of number of signaling messages in the network.
   Efficient IPv6 Neighbor Discovery is useful for energy-efficient
   networks and as well for overlay networks such as VLANs with large
   number of nodes.  This document describes a method of optimizations
   by reducing periodic multicast messages, frequent Neighbor
   Solicitation messages and discusses interoperability with legacy IPv6
   nodes.  It also addresses the ND denial of service issues by
   introducing node Registration procedure.

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 http://datatracker.ietf.org/drafts/current/.

   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 September 14, 2012.

Copyright Notice




Chakrabarti, et al.    Expires September 14, 2012               [Page 1]

Internet-Draft               Energy-aware-nd                  March 2012


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







































Chakrabarti, et al.    Expires September 14, 2012               [Page 2]

Internet-Draft               Energy-aware-nd                  March 2012


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Definition Of Terms  . . . . . . . . . . . . . . . . . . . . .  5
   3.  Assumptions for energy-aware Neighbor Discovery  . . . . . . .  6
   4.  The set of Requirements for Energy-awareness and
       optimization . . . . . . . . . . . . . . . . . . . . . . . . .  7
   5.  Basic Operations . . . . . . . . . . . . . . . . . . . . . . .  7
   6.  Applicability Statement  . . . . . . . . . . . . . . . . . . .  8
   7.  New Neighbor Discovery Options and Messages  . . . . . . . . .  9
     7.1.  Address Registration Option  . . . . . . . . . . . . . . .  9
     7.2.  Refresh and De-registration  . . . . . . . . . . . . . . . 10
     7.3.  A New Router Advertisement Flag  . . . . . . . . . . . . . 11
   8.  Energy-aware Neighbor Discovery Messages . . . . . . . . . . . 11
   9.  Energy-Aware Host Behavior . . . . . . . . . . . . . . . . . . 13
   10. The Energy Aware Default Router (NEAR) Behavior  . . . . . . . 13
     10.1. Router Configuration Modes . . . . . . . . . . . . . . . . 14
   11. NCE Management in Energy-Aware Routers . . . . . . . . . . . . 15
     11.1. Handling ND DOS Attack . . . . . . . . . . . . . . . . . . 16
   12. Mixed-Mode Operations  . . . . . . . . . . . . . . . . . . . . 17
   13. Bootstrapping  . . . . . . . . . . . . . . . . . . . . . . . . 18
   14. Handling Sleepy Nodes  . . . . . . . . . . . . . . . . . . . . 19
   15. Use Case Analysis  . . . . . . . . . . . . . . . . . . . . . . 19
     15.1. Data Center Routers on the link  . . . . . . . . . . . . . 19
     15.2. Edge Routers and Home Networks . . . . . . . . . . . . . . 19
     15.3. M2M Networks . . . . . . . . . . . . . . . . . . . . . . . 20
   16. Mobility Considerations  . . . . . . . . . . . . . . . . . . . 20
   17. Other Considerations . . . . . . . . . . . . . . . . . . . . . 20
   18. Updated Neighbor Discovery Constants . . . . . . . . . . . . . 20
   19. Security Considerations  . . . . . . . . . . . . . . . . . . . 21
   20. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
   21. Changelog  . . . . . . . . . . . . . . . . . . . . . . . . . . 21
   22. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
   23. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     23.1. Normative References . . . . . . . . . . . . . . . . . . . 22
     23.2. Informative References . . . . . . . . . . . . . . . . . . 22
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23














Chakrabarti, et al.    Expires September 14, 2012               [Page 3]

Internet-Draft               Energy-aware-nd                  March 2012


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 cycle.  It requires energy for the sleepy nodes which may
   otherwise be sleeping during the idle period.  Non-sleepy nodes also
   save energy if instead of continuous listening, they actually pro-
   actively synchronize their states with one or two entities 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 in order to
   reduce user-cost.  This will eventually reduce stress on electrical
   grids and 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, et al.    Expires September 14, 2012               [Page 4]

Internet-Draft               Energy-aware-nd                  March 2012


   [LOWPAN] network, the concept is mostly applicable to a power-aware
   IPv6 network.  Therefore, this document generalizes the address
   registration and multicast reduction in [6LOWPAN-ND] to all IPv6
   links.

   Thus optimizing the regular IPv6 Neighbor Discovery [ND] to minimize
   total number of related signaling messages without losing 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.

   The goal of this document is to provide energy-aware and optimized
   Neighbor Discovery Protocols in the general IPv6 subnets and links.
   Research indicates that often networked- nodes require more energy
   than stand-alone nodes because a node's energy usage depends on
   network messages it receives and responds.  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.  Thus this document introduces the node registration
   concept discussed in 6LoWPAN [LOWPAN], without handling the 'multi-
   level subnets' scenarios that are not the typical usecases in classic
   IPv6 subnets.

   In the process, the node registration method is also deemed to be
   useful for preventing Neighbor Discovery denial of service (DOS)
   attacks.

   The proposed changes can be used in two different ways.  In one case
   all the hosts and routers on a link implement the new mechanisms,
   which gives the maximum benefits.  In another case the link has a
   mixture of new hosts and/or routers and legacy [RFC4861] hosts and
   routers, operating in a mixed-mode providing some of the benefits.

   In the following sections the document describes the basic operations
   of registration methods, optimization of Neighbor Discovery messages,
   interoperability with legacy IPv6 implementations and provides a
   section on use-case scenarios where it can be typically applicable.


2.  Definition Of Terms

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].




Chakrabarti, et al.    Expires September 14, 2012               [Page 5]

Internet-Draft               Energy-aware-nd                  March 2012


   multi-level Subnets:
      It is a wireless link determined by one IPv6 off-link prefix in a
      network where in order to reach a destination with same prefix a
      packet may have to travel throguh one more 'intermediate' routers
      which relays the packet to the next 'intermediate' router or the
      host in its own.
   Border Rotuer(BR):
      A border router is typically located at the junction Internet and
      Home Network.  An IPv6 router with one interface connected to IPv6
      subnet and other interface connecting to a non-classic IPv6
      interface such as 6LoWPAN interface.  Border router is usually the
      gateway to the IPv6 network or Internet.
   IPv6 ND-energy-aware Rotuer(NEAR):
      It is the default Router of the single hop IPv6 subnet.  This
      router implements the optimizations specified in this document.
      This router should be able to handle both legacy IPv6 nodes and
      nodes that sends registration request.
   Enery-Aware Host(EAH):
      A host in a IPv6 network is considered a IPv6 node without routing
      and forwarding capability.  The EAH is the host which implements
      the host functionality for optimized Neighbor Discovery mentioned
      in this document.
   Legacy IPv6 Host:
      A host in a IPv6 network is considered a IPv6 node without routing
      and forwarding capability and implements RFC 4861 host functions.
   Legacy IPv6 Router:
      An IPv6 Router which implements RFC 4861 Neighbor Discovery
      protocols.
   EUI-64:
      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)
      respectively.


3.  Assumptions for energy-aware Neighbor Discovery

   o  The energy-aware nodes in the network carry unique interface ID in
      the network in order to form the auto-configured IPv6 address
      uniquely.  An EUI-64 interface ID required for global
      communication.
   o  All nodes are single IPv6-hop away from their default router in
      the subnet.
   o  /64-bit IPv6 prefix is used for Stateless Auto-address
      configuration (SLAAC).  The IPv6 Prefix may be distributed with
      Router Advertisement (RA) from the default router to all the nodes



Chakrabarti, et al.    Expires September 14, 2012               [Page 6]

Internet-Draft               Energy-aware-nd                  March 2012


      in that link.


4.  The set of Requirements for Energy-awareness and optimization

   In future homes, machine-to-machine networks and Data-center Virtual
   networks, it is essential to reduce unnecessary number of IPv6
   Neighbor Discovery signalings for saving energy and saving bits in
   the network.

   In the cloud computing environment, the concept of IPv6-subnet of
   link-local nodes is often extended across different networks over a
   Virtual LAN.  Thus reducing Neighbor Discovery signaling messages is
   a key for enhanced services.

   o  Node Registration: Node initiated Registration and address
      allocation is done in order to avoid periodic multicast Router
      Advertisement messages and often Neighbor Address resolution can
      be skipped as all packets go via the default router which now
      knows about all the registered nodes.  Node Registration enables
      reduction of all-node and solicited-node multicast messages in the
      subnet.
   o  Address allocation of registered nodes [ND] are performed using
      IPv6 Autoconfiguration [AUTOCONF].
   o  Host initiated Registration and Refresh is done by sending a
      Router Solicitation and then a Neighbor Solicitation Messge using
      Address Registration Option (described below).
   o  The node registration may replace the requirement of doing
      Duplicate Address Detection.
   o  Sleepy hosts are supported by this Neighbor Discovery procedures
      as they are not woken up periodically by Router Advertisement
      multicast messages or Neighbor Solicitation multicast messages.
      Sleepy nodes may wake up in its own schedule and send unicast
      registration refresh messages when needed.
   o  Since this document requires formation of an IPv6 address with an
      unique 64-bit Interface ID(EUI-64) is required for global IPv6
      addresses.  If the network is an isolated one and uses ULA [ULA]
      as its IPv6 address then the deployment should make sure that each
      MAC address in that network has unique address and can provide a
      unique 64-bit ID for each node in the network.
   o  /64-bit Prefix is required to form the IPv6 address.
   o  MTU requirement is same as IPv6 network.


5.  Basic Operations

   In the energy-aware IPv6 Network, the NEAR routers are the default
   routers for the energy-aware hosts (EAH).  During the startup or



Chakrabarti, et al.    Expires September 14, 2012               [Page 7]

Internet-Draft               Energy-aware-nd                  March 2012


   joining the network the host does not wait for the Router
   Advertisements as the NEAR routers do not perform periodic multicast
   RA as per RFC 4861.  Instead, the EAH sends a multicast RS to find
   out a NEAR router in the network.  The RS message is the same as in
   RFC 4861.  The advertising routers in the link responds to the RS
   message with RA with Prefix Information Option and any other options
   configured in the network.  If EAH hosts will look for a RA from a
   NEAR (E-flag) and choose a NEAR as its default router and
   consequently sends a unicast Neighbor Solicitation Message with ARO
   option in order to register itself with the default router.  The EAH
   does not do Duplicate Address Detection or NS Resolution of
   addresses.  NEAR maintains a binding of registered nodes and
   registration life-time information along with the neighbor Cache
   information.  The NEAR is responsible for forwarding all the messages
   from its EAH including on-link messages from one EAH to another.  For
   details of protocol operations please see the sections below.

   When a IPv6 network consists of both legacy hosts and EAH, and if the
   NEAR is configured for 'mixed mode' operation, it should be able to
   handle ARO requests and send periodic RA.  Thus it should be able to
   serve both energy-aware hosts and legacy hosts.  Similarly, a legacy
   host compatible EAH falls back to RFC 4861 host behavior if a NEAR is
   not present in the link.  See the section on 'Mixed Mode Operations'
   for details below.


6.  Applicability Statement

   This document aims to guide the implementors to choose an appropriate
   IPv6 neighbor discovery and Address configuration procedures suitable
   for any efficient IPv6 network.  These optimization is useful for the
   classical IPv6 subnet i.e home networks, Data-Center IPv6 overlay
   networks where saving Neighbor Discovery messages will reduce cost of
   control signaling and network bandwidth and as well as energy of the
   connected nodes.  See use cases towards the end of the document.

   Note that the specification allows 'Mixed-mode' operation in the
   energy-aware nodes for backward compatibility and transitioning to a
   complete energy-aware network of hosts and routers.  Though the
   energy-aware only nodes will minimize the ND signalling and DOS
   attacks in the LAN.

   Applicability of this solution is limited to the legacy IPv6 nodes
   and subnets and it optimizes the generic IPv6 siganling activities at
   network layer.  However, further optimization at the application
   layers are possible for increased efficiency based on particular
   usecases and applications.




Chakrabarti, et al.    Expires September 14, 2012               [Page 8]

Internet-Draft               Energy-aware-nd                  March 2012


7.  New Neighbor Discovery Options and Messages

   This section will discuss the registration and de-registration
   procedure of the hosts in the network.

7.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.  This option is
   exactly the same as in [6LOWPAN-ND] which is reproduced here for the
   benefits of the readers.

   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, et al.    Expires September 14, 2012               [Page 9]

Internet-Draft               Energy-aware-nd                  March 2012


   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 or equivalent                            +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Fields:
   Type:          TBD1 ( See [6LOWPAN-ND] )
   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

7.2.  Refresh and De-registration

   A host SHOULD send a Registration messge in order to renew its
   registration before its registration lifetime expires in order to
   continue its connectivity with the network.  If anytime, the node



Chakrabarti, et al.    Expires September 14, 2012              [Page 10]

Internet-Draft               Energy-aware-nd                  March 2012


   decides that it does not need the default router's service anymore,
   it MUST send a de-registration message - i,e, a registration message
   with lifetime being set to zero.  A mobile host SHOULD first de-
   register with the default router before it moves away from the
   subnet.

7.3.  A New Router Advertisement Flag

   A new Router Advertisment flag [RF] is needed in order to distnguish
   a router advertisement from a energy-aware default router or a legacy
   IPv6 router.  This flag is ignored by the legacy IPv6 hosts.  EAH
   hosts use this flag in oder to discover a NEAR router if it receives
   multiple RA from both legacy and NEAR routers.



             0 1 2 3 4 5 6 7
            +-+-+-+-+-+-+-+-+
            |M|O|H|Prf|P|E|R|
            +-+-+-+-+-+-+-+-+


   The 'E' bit above MUST be 1 when a IPv6 router implements and
   configures the Energy-aware Router behavior for Neighbor Discovery as
   per this document.  All other cases E bit is 0.

   The legacy IPv6 hosts will ignore the E bit in RA advertisement.  All
   EAH MUST look for E bit in RA in order to determine the Energy-aware
   support in the default router in the link.

   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 or both(Mixed mode).


8.  Energy-aware Neighbor Discovery Messages

   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.  A new flag
                           (E-flag) is introduced in the RA in order to
                           characterize the energy-aware mode support.
                           Unlike RFC4861 which suggests multicast



Chakrabarti, et al.    Expires September 14, 2012              [Page 11]

Internet-Draft               Energy-aware-nd                  March 2012


                           Router Advertisements, this specification
                           optimizes the exchange by always unicasting
                           RAs in response to RS.  This is possible
                           since the RS always includes a SLLA option,
                           which is used by the router to unicast the
                           RA.
   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 the energy-aware IPv6 network, the
                           host may send periodic unicast RS to the
                           routers.  The time-periods for the RS varies
                           on the deployment scenarios and the Default
                           Router Lifetime advertised in the RAs.
   Default Router Selection:   Same as in section 6.3.6 of RFC 4861[ND].
   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 registration.
   Neighbor Advertisement (NA):   As defined in [ND] and ARO option.
   Redirect Messages:      A router SHOULD NOT send a Redirect message
                           to a host since the link has non-transitive
                           reachability.  The host behavior is same as
                           described in section 8.3 of RFC 4861[ND],
                           i,e. a host MUST NOT send or accept redirect
                           messages when in energy-aware mode.
                           Same as in RFC 4861[ND]
   MTU option:             As per the RFC 4861.
   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.






Chakrabarti, et al.    Expires September 14, 2012              [Page 12]

Internet-Draft               Energy-aware-nd                  March 2012


   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.  This way no extra message for
                           NUD is required.


9.  Energy-Aware 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).  The EAH MUST process the E-bit in RA
   as described in this document.  The EAH MUST use ARO option to
   register with the neighboring NEAR router.

   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).  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
   protocol.  A legacy IPv6 Host compliant EAH SHOULD be able to fall
   back to RFC 4861 host behavior if there is no energy-aware router
   (NEAR) in the link.

   The energy-aware host MUST NOT send or accept re-direct messages.  It
   does not join solicited node multicast address.


10.  The Energy Aware Default Router (NEAR) Behavior

   The main purpose of the default router in the context of this
   document is to receive and process the registration request, forward
   packets from one neighbor to the other, informs the routing protocol
   about the un-availability of the registered nodes if the routing
   protocol requires this information for the purpose of mobility or
   fast convergence.  A default router (NEAR) behavior may be observed
   in one or more interfaces of a Border Router(BR).




Chakrabarti, et al.    Expires September 14, 2012              [Page 13]

Internet-Draft               Energy-aware-nd                  March 2012


   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.  One or more of the interfaces of the Border
   Router may be connected with the energy-aware hosts or a energy-aware
   router(NEAR).

   The Energy-Aware default router MUST not send periodic RA unless it
   is configured to support both legacy IPv6 and energy-aware hosts.  If
   the Router is configured for Energy-Aware hosts support, it MUST send
   Router Advertisments with E-bit flag ON and MUST NOT set 'L' bit in
   the advertisements.

   The router SHOULD NOT garbage collect Registered Neighbor Cache
   entries since they need to retain them until the Registration
   Lifetime expires.  If a NEAR receives a NS message from the same host
   one with ARO and another without ARO then the NS message with ARO
   gets the precedence and the NS without ARO is ignored.  This behavior
   protects the router from Denial Of Service attacks.  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.  If an ARO arrives for an NCE that is in
   UNCREACHABLE state, that NCE should be marked as STALE.

   A default router keeps a cache for all the nodes' IP addresses,
   created from the Address Registration processing.

10.1.  Router Configuration Modes

   An energy-aware Router(NEAR) MUST be able to configure in energy-
   aware-only mode where it will expect all hosts register with the
   router following RS; thus will not support legacy hosts.  However, it
   will create legacy NCE for NS messages for other routers in the
   network.  This mode is able to prevent ND flooding on the link.

   An energy-aware Router(NEAR) SHOULD be able to have configuration
   knob to configure itself in Mixed-Mode where it will support both
   energy-aware hosts and legacy hosts.  However even in mixed-mode the
   router should check for duplicate entries in the NCE before creating
   a new ones and it should rate-limit creating new NCE based on
   requests from the same host MAC address.

   The RECOMMENDED default mode of operation for the energy-aware router
   is Mixed-mode.




Chakrabarti, et al.    Expires September 14, 2012              [Page 14]

Internet-Draft               Energy-aware-nd                  March 2012


11.  NCE Management in Energy-Aware Routers

   The use of explicit registrations with lifetimes plus the desire to
   not multicast Neighbor Solicitation messages for hosts imply that we
   manage the Neighbor Cache entries slightly differently than in [ND].
   This results in two different types of NCEs and the types specify how
   those entries can be removed:

   Legacy:               Entries that are subject to the normal rules in
                         [ND] that allow for garbage collection when low
                         on memory.  Legacy entries are created only
                         when there is no duplicate NCE.  In mixed-mode
                         and energy-aware mode the legacy entries are
                         converted to the registered entries upon
                         successful processing of ARO.  Legacy type can
                         be considered as union of garbage-collectible
                         and Tentative Type NCEs described in
                         [6LOWPAN-ND].
   Registered:           Entries that have an explicit registered
                         lifetime and are kept until this lifetime
                         expires or they are explicitly unregistered.

   Note that the type of the NCE is orthogonal to the states specified
   in [ND].

   When a host interacts with a router by sending Router Solicitations
   that does not match with the existing NCE entry of any type, a Legacy
   NCE is first created.  Once a node successfully registers with a
   Router the result is a Registered NCE.  As Routers send RAs to legacy
   hosts, or receive multicast NS messages from other Routers the result
   is Legacy NCEs.  There can only be one kind of NCE for an IP address
   at a time.

   A Router Solicitation might be received from a host that has not yet
   registered its address with the router or from a legacy[ND] host in
   the Mixed-mode of operation.

   In the 'Enrgy-aware' only mode the router MUST NOT modify an existing
   Neighbor Cache entry based on the SLLA option from the Router
   Solicitation.  Thus, a router SHOULD create a tentative Legacy
   Neighbor Cache entry based on SLLA option when there is no match with
   the existing NCE.  Such a legacy Neighbor Cache entry SHOULD be timed
   out in TENTATIVE_LEGACY_NCE_LIFETIME seconds unless a registration
   converts it into a Registered NCE.

   However, in 'Mixed-mode' operation, the router does not require to
   keep track of TENTATIVE_LEGACY_NCE_LIFETIME as it does not know if
   the RS request is from a legacy host or the energy-aware hosts.



Chakrabarti, et al.    Expires September 14, 2012              [Page 15]

Internet-Draft               Energy-aware-nd                  March 2012


   However, it creates the legacy type of NCE and updates it to a
   registered NCE if the ARO NS request arrives corresponding to the
   legacy NCE.  Successful processing of ARO will complete the NCE
   creation phase.

   If ARO did not result in a duplicate address being detected, and the
   registration life-time is non-zero, the router creates and updates
   the registered NCE for the IPv6 address. if the Neighbor Cache is
   full and new entries need to be created, then the router SHOULD
   respond with a NA with status field set to 2.  For successful
   creation of NCE, the router SHOULD include a copy of ARO and send NA
   to the requestor with the status field 0.  A TLLA(Target Link Layer)
   Option is not required with this NA.

   Typically for energy-aware routers (NEAR), the registration life-time
   and EUI-64 are recorded in the Neighbor Cache Entry along with the
   existing information described in [ND].  The registered NCE are meant
   to be ready and reachable for communication and no address resolution
   is required in the link.  The energy-aware hosts will renew their
   registration to keep maintain the state of reachability of the NCE at
   the router.  However the router may do NUD to the idle or unreachable
   hosts as per [ND].

11.1.  Handling ND DOS Attack

   IETF community has discussed possible issues with /64 DOS attacks on
   the ND networks when a attacker host can send thousands of packets to
   the router with a on-link destination address or sending RS messages
   to initiate a Neighbor Solicitation from the neighboring router which
   will create a number of INCOMPLETE NCE entries for non-existent nodes
   in the network resulting in table overflow and denial of service of
   the existing communications.

   The energy-aware behavior documented in this specification avoids the
   ND DOS attacks by:

   o  Having the hosts register with the default router
   o  Having the hosts send their packets via the default router
   o  Not resolving addresses for the Routing Solicitor by mandating
      SLLA option along with RS
   o  Checking for duplicates in NCE before the registration
   o  Checking against the MAC-address and EUI-64 id is possible now for
      NCE matches
   o  On-link IPv6-destinations on a particular link must be registered
      else these packets are not resolved and extra NCEs are not created

   It is recomended that Mixed-mode operation and legacy hosts SHOULD
   NOT be used in the IPv6 link in order to avoid the ND DOS attacks.



Chakrabarti, et al.    Expires September 14, 2012              [Page 16]

Internet-Draft               Energy-aware-nd                  March 2012


   For the general case of Mixed-mode the router does not create
   INCOMPLETE NCEs for the registered hosts, but it follows the [ND]
   steps of NCE states for legacy hosts.


12.  Mixed-Mode Operations

   Mixed-Mode operation discusses the protocol behavior where the IPv6
   subnet is composed with legacy IPv6 Neighbor Discovery compliant
   nodes and energy-aware IPv6 nodes implementing this specification.

   The mixed-mode model SHOULD support the following configurations in
   the IPv6 link:
   o  The legacy IPv6 hosts and energy-aware-hosts in the network and a
      NEAR router
   o  legacy IPv6 default-router and energy-aware hosts(EAH) in the link
   o  one router is in mixed mode and the link contains both legacy IPv6
      hosts and EAH
   o  A link contains both energy-aware IPv6 router and hosts and legacy
      IPv6 routers and hosts and each host should be able to communicate
      with each other.

   In mixed-mode operation, a NEAR MUST be configured for mixed-mode in
   order to support the legacy IPv6 hosts in the network.  In mixed-
   mode, the NEAR MUST act as proxy for Neighbor Solicitation for DAD
   and Address Resolution on behalf of its registered hosts on that
   link.  It should follow the NCE management for the EAH as described
   in this document and follow RFC 4861 NCE management for the legacy
   IPv6 hosts.  Both in mixed-mode and energy-aware mode, the NEAR sets
   E-bit flag in the RA and does not set 'L' on-link bit.

   If a NEAR receives NS message from the same host one with ARO and
   another without ARO then the NS message with ARO gets the precedence.

   An Energy-Aware Host implementation SHOULD support falling back to
   legacy IPv6 node behavior when no energy-aware routers are available
   in the network during the startup.  If the EAH was operational in
   energy-aware mode and it determines that the NEAR is no longer
   available, then it should send a RS and find an alternate default
   router in the link.  If no energy-aware router is indicated from the
   RA, then the EAH SHOULD fall back into RFC 4861 behavior.  On the
   otherhand, in the energy-aware mode EAH SHOULD ignore multicast
   Router Advertisements(RA) sent by the legacy and Mixed-mode routers
   in the link.

   The routers that are running on energy-aware mode or legacy mode
   SHOULD NOT dynamically switch the mode without flushing the Neighbor
   Cache Entries.



Chakrabarti, et al.    Expires September 14, 2012              [Page 17]

Internet-Draft               Energy-aware-nd                  March 2012


13.  Bootstrapping

   If the network is a energy-aware IPv6 subnet, and the energy-aware
   Neighbor Discovery mechansim is used by the hosts and routers as
   described in this document.  At the start, 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
   identifiers which is used to form the IPv6 address.


      Node                                                  Router

       |                                                      |

   1.  |       ---------- Router Solicitation -------->       |

       |                     [SLLAO]                          |

   2.  |       <-------- Router Advertisement ---------       |

       |                     [PIO + SLLAO]                    |
       |                                                      |

   3.  |       ----- Address Registration (NS) -------->      |

       |                     [ARO + SLLAO]                    |

   4.  |       <-------- Neighbor Advertisement -------       |

       |                    [ARO with Status code]            |

   5. ====> Address Assignment Complete


    Figure 1: Neighbor Discovery Address Registration and bootstrapping

   In the mixed mode operation, it is expected that logically there will
   be at least one legacy IPv6 router and another NEAR router present in
   the link.  The legacy IPv6 router will follow RFC 4861 behavior and
   NEAR router will follow the energy-aware behavior for registration,
   NCE maintenance, forwarding packets from a EAH and it will also act
   as a ND proxy for the legacy IPv6 hosts querying to resolve a EAH
   node.

   A legacy IPv6 host and EAH are not expected to see a difference in
   their bootstrapping if both legacy and energy-aware functionalities



Chakrabarti, et al.    Expires September 14, 2012              [Page 18]

Internet-Draft               Energy-aware-nd                  March 2012


   of rotuers are available in the network.  It is RECOMMEDED that the
   EAH implementation SHOULD be able to behave like a legacy IPv6 host
   if it discovers that no energy-aware routing support is present in
   the link.


14.  Handling Sleepy Nodes

   The solution allows the sleepy nodes to complete its sleep schedule
   without waking up due to periodic Router Advertisement messages or
   due to Multicast Neighbor Solicitation for address resolution.  The
   node registration lifetime SHOULD be synchronized with its sleep
   interval period in order to avoid waking up in the middle of sleep
   for registration refresh.  Depending on the application, the
   registration lifetime SHOULD be equal to or integral multiple of a
   node's sleep interval period.


15.  Use Case Analysis

   This section provides applicability scenarios where the energy-aware
   Neighbor Discovery will be most beneficial.

15.1.  Data Center Routers on the link

   Energy-aware Routers and hosts are useful in IPv6 networks in the
   Data Center as they produce less signaling and also provides ways to
   minimize the ND flood of messages.  Moreover, this mechanism will
   work with data-center nodes which are deliberately in sleep mode for
   saving energy.

   This solution will work well in Data Center Virtual network and VM
   scenarios where number of VLANs are very high and ND signalings are
   undesirably high due the multicast messaging and periodic Router
   Advertisments and Neighbor Unreachability detections.

15.2.  Edge Routers and Home Networks

   An Edge Router in the network will also benefit implementing the
   energy-aware Neighbor Discovery behavior in order to save the
   signaling and keeping track of the registered nodes in its domain.  A
   BNG sits at the operator's edge network and often the BNG has to
   handle a large number of home CPEs.  If a BNG runs Neighbor Discovery
   protocol and acts as the default router for the CPE at home, this
   solution will be helpful for reducing the control messages and
   improving network performances.

   The same solution can be run on CPE or Home Residential Gateways to



Chakrabarti, et al.    Expires September 14, 2012              [Page 19]

Internet-Draft               Energy-aware-nd                  March 2012


   assign IPv6 addresses to the wired and wireless home devices without
   the problem of ND flooding issues and consuming less power.  It
   provides mechanism for the sleepy nodes to adjust their registration
   lifetime according to their sleep schedules.

15.3.  M2M Networks

   Any Machine-to-machine(M2M) networks such as IPv6 surveilance
   networks, wireless monitoring networks and other m2m networks desire
   for energy-aware control protocols and dynamic address allocation.
   The in-built address allocation and autoconfiguration mechanism in
   IPv6 along with the default router capability will be useful for the
   simple small-scale networks without having the burden of DHCPv6
   service and Routing Protocols.


16.  Mobility Considerations

   If the hosts move from one subnet to another, they MUST first de-
   register and then register themselves in the new subnet or network.
   Otherwise, the regular IPv6 Mobility [IPV6M]behavior applies.


17.  Other Considerations

   IPv6 DNA[DNA] also uses unicast ND probes to detect movement of its
   network attachments.  However DNA [DNA] optimizes the IPv6 address
   operability while a node is moving and its network attachments are
   changing with respect to the neighboring routers.  This document does
   not expect Router Advertisements from the neighboring routers, thus
   this solution will rely on the ND probes for movement detection and
   as well as link-layer indication.

   Although the solution described in this document prevents unnecesary
   multicast messages in the IPv6 ND procedure, it does not affect
   normal IPv6 multicast packets and ability of nodes to join and leave
   the multicast group or forwarding multicast traffic or responding to
   multicast queries.

   ND proxy support in mixed-mode operation [TBD].


18.  Updated Neighbor Discovery Constants

   This section discusses the updated default values of ND constants
   based on [ND] section 10.  New and changed constants are listed only
   for energy-aware-nd implementation.




Chakrabarti, et al.    Expires September 14, 2012              [Page 20]

Internet-Draft               Energy-aware-nd                  March 2012


   Router Constants:
   MAX_RTR_ADVERTISEMENTS(NEW)             3 transmissions
   MIN_DELAY_BETWEEN_RAS(CHANGED)          1 second
   TENTATIVE_LEGACY_NCE_LIFETIME(NEW)      30 seconds

   Host Constants:
   MAX_RTR_SOLICITATION_INTERVAL(NEW)      60 seconds


19.  Security Considerations

   These optimizations are not known to introduce any new threats
   against Neighbor Discovery beyond what is already documented for IPv6
   [RFC 3756].

   Section 11.2 of [ND] applies to this document as well.

   This mechanism minimizes the possibility of ND /64 DOS attacks in
   energy-aware mode.  See Section 11.1.


20.  IANA Considerations

   A new flag (E-bit) in RA has been introduced.  IANA assignment of the
   E-bit flag is required upon approval of this document.


21.  Changelog

   Changes from 00 to 01:
      o Removed ABRO options and Multi-level subnet concept
      o Removed intermediate-router concept, behavior and definition
      o Added use-cases, Support for Mixed-mode operations and a diagram
      for bootstrapping scenario.
      o Added updates to ND constant values
      o A new co-author has beed added
      o Text for NCE Management and ND-DOS handling has been added
      o A new Router Advertisement flag has been added


22.  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, editor of the [6LOWPAN-ND].

   The inspiration of such a IPv6 generic document came from Margaret



Chakrabarti, et al.    Expires September 14, 2012              [Page 21]

Internet-Draft               Energy-aware-nd                  March 2012


   Wasserman who saw a need for such a document at the IOT workshop at
   Prague IETF.


23.  References

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

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

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

23.2.  Informative References

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

   [DNA]      Krishnan, S. and G. Daley, "Simple Procedures for
              Detecting Network Attachments in IPv6", RFC 6059,
              November 2010.

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




Chakrabarti, et al.    Expires September 14, 2012              [Page 22]

Internet-Draft               Energy-aware-nd                  March 2012


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

   [RF]       Haberman, B. and B. Hinden, "IPv6 Router Advertisement
              Flags option", RFC 5175, March 2008.

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

   [IPV6M]    Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 6275, July 2011.


Authors' Addresses

   Samita Chakrabarti
   Ericsson
   San Jose, CA
   USA

   Email: samita.chakrabarti@ericsson.com


   Erik Nordmark
   Cisco Systems
   San Jose, CA
   USA

   Email: nordmark@cisco.com


   Margaret Wasserman
   Painless Security


   Email: mrw@lilacglade.org







Chakrabarti, et al.    Expires September 14, 2012              [Page 23]