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

Versions: (draft-chakrabarti-nordmark-energy-aware-nd) 00 01 02 03 04 05 06 07

6man WG                                                   S. Chakrabarti
Internet-Draft                                                  Ericsson
Updates: 4861 (if approved)                                  E. Nordmark
Intended status: Standards Track
Expires: April 18, 2014                                       P. Thubert
                                                           Cisco Systems
                                                            M. Wasserman
                                                       Painless Security
                                                        October 15, 2013


        Wired and Wireless IPv6 Neighbor Discovery Optimizations
            draft-chakrabarti-nordmark-6man-efficient-nd-03

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, M2M and cellular networks there is a desire for optimizing
   the legacy IPv6 Neighbor Discovery protocol.  This document describes
   a method of optimization by reducing multicast messages and
   introducing an IPv6 address Registration mechanism.  The optimization
   of IPv6 Neighbor Discovery protocol is useful for Wirless and low-
   power IPv6 networks and as well as Data Centers and Home Networks.
   The solution is capable of handling existing legacy IPv6 nodes in the
   network with local mobility.

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 April 18, 2014.

Copyright Notice




Chakrabarti, et al.      Expires April 18, 2014                 [Page 1]


Internet-Draft           IPv6 Optimized-nd(WIND)            October 2013


   Copyright (c) 2013 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.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Problem Areas  . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Overview of the basic ND Optimization  . . . . . . . . . .  5
   2.  Definition Of Terms  . . . . . . . . . . . . . . . . . . . . .  6
   3.  Assumptions for efficiency-aware Neighbor Discovery  . . . . .  8
   4.  The set of Requirements for efficiency and optimization  . . .  8
   5.  Basic Operations . . . . . . . . . . . . . . . . . . . . . . .  9
   6.  Applicability Statement  . . . . . . . . . . . . . . . . . . . 10
   7.  New Neighbor Discovery Options and Messages  . . . . . . . . . 10
     7.1.  Address Registration Option  . . . . . . . . . . . . . . . 10
     7.2.  Refresh and De-registration  . . . . . . . . . . . . . . . 12
     7.3.  A New Router Advertisement Flag  . . . . . . . . . . . . . 13
     7.4.  The Transaction Identification(TID)  . . . . . . . . . . . 13
   8.  Efficiency-aware Neighbor Discovery Messages . . . . . . . . . 14
   9.  Efficiency-aware Host Behavior . . . . . . . . . . . . . . . . 15
   10. The Efficiency Aware Default Router (NEAR) Behavior  . . . . . 16
     10.1. Router Configuration Modes . . . . . . . . . . . . . . . . 17
     10.2. Movement Detection . . . . . . . . . . . . . . . . . . . . 17
       10.2.1.  Registration ownership  . . . . . . . . . . . . . . . 17
   11. NCE Management in efficiency-aware Routers . . . . . . . . . . 18
     11.1. Handling ND DOS Attack . . . . . . . . . . . . . . . . . . 20
   12. Mixed-Mode Operations  . . . . . . . . . . . . . . . . . . . . 20
   13. Bootstrapping  . . . . . . . . . . . . . . . . . . . . . . . . 21
   14. Handling Sleepy Nodes  . . . . . . . . . . . . . . . . . . . . 23
   15. Duplicate Address Detection  . . . . . . . . . . . . . . . . . 23
   16. Mobility Considerations  . . . . . . . . . . . . . . . . . . . 23
   17. Other Considerations . . . . . . . . . . . . . . . . . . . . . 24
     17.1. Detecting Network Attachment(DNA)  . . . . . . . . . . . . 24
     17.2. Proxying for Efficiency-Aware hosts  . . . . . . . . . . . 24
     17.3. DHCPv6 Interaction . . . . . . . . . . . . . . . . . . . . 25
   18. RPL Implications . . . . . . . . . . . . . . . . . . . . . . . 25
   19. Updated Neighbor Discovery Constants . . . . . . . . . . . . . 26



Chakrabarti, et al.      Expires April 18, 2014                 [Page 2]


Internet-Draft           IPv6 Optimized-nd(WIND)            October 2013


   20. Security Considerations  . . . . . . . . . . . . . . . . . . . 26
   21. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 26
   22. Changelog  . . . . . . . . . . . . . . . . . . . . . . . . . . 26
   23. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
   24. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
     24.1. Normative References . . . . . . . . . . . . . . . . . . . 27
     24.2. Informative References . . . . . . . . . . . . . . . . . . 28
   Appendix A.  Usecase Analysis  . . . . . . . . . . . . . . . . . . 29
     A.1.  Data Center Routers on the link  . . . . . . . . . . . . . 29
     A.2.  Edge Routers and Home Networks . . . . . . . . . . . . . . 29
     A.3.  M2M Networks . . . . . . . . . . . . . . . . . . . . . . . 30
     A.4.  Wi-fi Networks . . . . . . . . . . . . . . . . . . . . . . 30
     A.5.  3GPP Networks  . . . . . . . . . . . . . . . . . . . . . . 30
     A.6.  Industrial Networks  . . . . . . . . . . . . . . . . . . . 31
     A.7.  Set and forget offline network . . . . . . . . . . . . . . 31
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31



































Chakrabarti, et al.      Expires April 18, 2014                 [Page 3]


Internet-Draft           IPv6 Optimized-nd(WIND)            October 2013


1.  Introduction

   Conceptually, IPv6 multicast messages are supposed to avoid broadcast
   messages, but in practice, the multicast operation at the link level
   is that of a broadcast nevertheless.  This did not matter much at the
   time ND [ND] was originally designed, when an Ethernet network was
   more or less a single shared wire, but since then, large scale switch
   fabrics, low power sleeping devices, mobile wireless/cellular devices
   and virtual machines have changed the landscape dramatically.

   In a modern switch fabric, a number of intermediate devices (such as
   switches, routers and security middle boxes) host IPv6 State
   Maintaining Entities (SMEs) holding information such as the location
   of an IPv6 address or its mapping with a MAC address.  Such
   intermediate devices include Wireless Controllers that terminate a
   overlay tunnel and rapidly re-enable reachability for mobile
   devices(L2/L3), Network edge devices performing subscriber access,
   network devices that protect the ownership of an IPv6 address,
   Overlay networks in data centers, Home Networks for IPv6 clients.

   In general, there is a need for enhancing the IPv6 ND [ND] to make it
   less chatty and flexible to work with different types of networking
   elements, physical and virtual networks and at the same time
   maintaining the IPv6 states to avoid duplicates or denial of
   services.

1.1.  Problem Areas

   Specifically, the following are the issues with the IPv6 deployment
   in many wireless and high-density IPv6 subnets today:
   o  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 spends more energy since they are in
      continuous listening mode.  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.
   o  With WIFI, a multicast message will consume the wireless link on
      all Access Points around a switched fabric and will be transmitted
      at the lowest speed possible in order to ensure the maximum
      reception by all wireless nodes.  This means that in an
      environment where bandwidth is scarce, a single multicast packet
      may consume the bandwidth for hundreds of unicast packets.  Sadly,
      IPv6 ND is a major source of multicast messages in wireless
      devices, since such messages are triggered each time a wireless
      device changes its point of attachment.




Chakrabarti, et al.      Expires April 18, 2014                 [Page 4]


Internet-Draft           IPv6 Optimized-nd(WIND)            October 2013


   o  In a datacenter, where VM mobility and VM address reslution also
      trigger storms of IPv6 ND multicast messages, which become a major
      hassle as the number of VM may scale to the tens of thousands in a
      large Data Center.  At the IETF, a WG discusses such problems with
      Address Resolution in Massive Datacenters (ARMD).

   The following paragraph elaborates the source of all the multicast
   messages in IPv6 ND.

   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.  The minimum RA interval range can be 3sec to 600sec
   depending on applications.  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.

1.2.  Overview of the basic ND Optimization

   In a nutshell, the following basic optimizations are made from the
   original IPv6 Neighbor Discovery protocol [ND]:
   o  Adds Node Registration at the default subnet-router
   o  Introduces a EUI-64 identifier for identification during
      initiation
   o  Does not require unsolicited periodic Router Advertisements
   o  No multicast messages required for address resolution and DAD for
      non-link-local IP addresses
   o  Introduces a short-lived temporary NCE entry for unregistered
      nodes that turns into a regular NCE upon registration
   o  Supports mixed mode operations where legacy IPv6 nodes and
      enahnced optimized routers can co-exist during the transition
      period.

   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



Chakrabarti, et al.      Expires April 18, 2014                 [Page 5]


Internet-Draft           IPv6 Optimized-nd(WIND)            October 2013


   optimization [6LOWPAN-ND] applies to 6LoWPAN [LOWPAN] networks, the
   concept is mostly applicable to power-aware IPv6 networks.
   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, autoconfiguration and reliable host-router
   communication, are desirable in any modern IPv6 networks such as
   Home, Enterprise networks, Data Centers and Operator's Cellular/
   Wireless networks.

   The optimization will be highly effective for links and nodes which
   do not support multicast and as well as for a multicast network
   without MLD snooping switches.  Moreover, in the MLD-snooping
   networks the MLD switches will deal with less number of multicasts.

   The goal of this document is to provide an efficient Neighbor
   Discovery Protocol in classic IPv6 subnets in wireless/wired links.
   In the process, the node registration method is also deemed to be
   useful for preventing Neighbor Discovery denial of service ( ND 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.
   This document also describes an optional feature for enabling node
   mobility in the LLN network using backbone routers(BBR) or multiple
   default subnet routers.  This optional feature generates a sequence
   ID by the host in the registration message for deploying some routing
   protocols (example: RPL [RFC6550]) with reliability in the LLN.


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 April 18, 2014                 [Page 6]


Internet-Draft           IPv6 Optimized-nd(WIND)            October 2013


   multi-level Subnets:
      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 through one or more 'intermediate'
      routers which relay the packet to the next 'intermediate' router
      or the host in its own.
   Border Router(BR):
      A border router is typically located at the junction of Internet
      and Home Network.  An IPv6 router with one interface connected to
      an IPv6 subnet and other interface connecting to a non-classic
      IPv6 interface such as 6LoWPAN interface.  A Border router is
      usually the gateway between the IPv6 network and Internet.
   Backbone:
      This is an IPv6 transit link that interconnects 2 or more Low
      Power Lossy Networks (LLNs).  It is expected to be deployed as a
      high speed backbone in order to federate a potentially large set
      of LLN nodes.  Also referred to as a LLN backbone or Backbone
      network in this document.
   Backbone Router:
      An IPv6 router that federates the LLN using a transit link as a
      backbone.  A BBR acts as a 6LoWPAN Border Router (6LBR) and an
      Efficiency Aware Default Router (NEAR).
   Efficiency-Aware Network:
      An Efficiency-Aware network is composed of network elements that
      are sensitive to energy usage or number of signaling messages in
      the network.  An efficiency-aware network may also contain links
      that do not support multicast or it does not have MLD snooping
      capabilities and yet the network likes to communicate most
      efficiently with minimum number of signaling messages.  Data
      center networks with virtual machines, cellular IPv6 networks, any
      IPv6 networks with energy-sensitive nodes are examples of
      Efficiency-Aware networks.
   IPv6 ND-efficiency-aware Router(NEAR):
      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.
   Efficiency-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.






Chakrabarti, et al.      Expires April 18, 2014                 [Page 7]


Internet-Draft           IPv6 Optimized-nd(WIND)            October 2013


   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.
   LLN:
      It is a low power and lossy network where nodes are typically
      constrained in system resources and energy, for instance battery
      powered nodes.  Alternately LLN could be a network of line-powered
      nodes with radio links with lossy characteristics.  Wifi, ZigBee,
      Celular networks are examples of such a network.
   Extended LLN:
      This is the aggregation of multiple LLNs as defined in [RFC4919]
      interconnected by a Backbone Link via Backbone Routers and forming
      a single IPv6 link.


3.  Assumptions for efficiency-aware Neighbor Discovery

   o  The efficiency-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
      in that link.
   o  The efficiency-aware node MAY maintain a sequence counter in
      permanent memory according to section 7 of RFC 6550.


4.  The set of Requirements for efficiency and optimization

   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.




Chakrabarti, et al.      Expires April 18, 2014                 [Page 8]


Internet-Draft           IPv6 Optimized-nd(WIND)            October 2013


   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 Message 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  A /64-bit Prefix is required to form the IPv6 address.
   o  MTU requirement is same as IPv6 network.


5.  Basic Operations

   In the efficient-nd IPv6 Network, the NEAR routers are the default
   routers for the efficiency-aware hosts (EAH).  During the startup or
   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 Address Registration Option(ARO) requests and send periodic
   RA.  Thus it should be able to serve both efficiency-aware hosts and
   legacy hosts.  Similarly, a legacy host compatible EAH falls back to



Chakrabarti, et al.      Expires April 18, 2014                 [Page 9]


Internet-Draft           IPv6 Optimized-nd(WIND)            October 2013


   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 implementers to choose an appropriate
   IPv6 neighbor discovery and Address configuration procedures suitable
   for any efficient IPv6 network.  These optimizations are equally
   useful for the energy-sensitive, non-multicast links and for
   classical IPv6 networks i.e. home networks, Data-Center IPv6 overlay
   networks where saving Neighbor Discovery messages will reduce cost
   and increase bandwidth availability.

   The address registration mechanism and associated extension to the
   Neighbor Discovery protocol allow a low-power host to move between
   the LLN and the classic IPv6 networks as well as movement from one
   Border Router registration area to another while staying within the
   same IPv6 subnet.

   Note that the specification allows 'Mixed-mode' operation in the
   efficiency-aware nodes for backward compatibility and transitioning
   to a complete efficiency-aware network of hosts and routers.  Though
   the efficiency-aware only nodes will minimize the ND signaling 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 signaling activities at
   network layer.  However, further optimization at the application
   layers are possible for increased efficiency based on particular use-
   cases and applications.


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 EUI-64 ID for
   registration.  The address registration is used for maintaining
   reachability of the node or host by the router.  This option is
   almost the same ARO as in [6LOWPAN-ND].  A Transaction ID field and a
   corresponding bit have been introduced in order to detect duplicate
   address registration and local mobility of a node.




Chakrabarti, et al.      Expires April 18, 2014                [Page 10]


Internet-Draft           IPv6 Optimized-nd(WIND)            October 2013


   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(LLN) and as well as wired IPv6
   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 and SLLA option MUST be included [
   except for the point-to-point links (example: IP-in-IP tunnel)] and
   the target address for to-be registered node MUST be the IPv6 source
   address of the Neighbor Solicitation message.

   Note that a node should be able to register with a default router
   with multiple IPv6 addresses (including privacy addresses).

   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    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Reservd   |T|  TID          |     Registration Lifetime     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +               EUI-64 or equivalent                            +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Chakrabarti, et al.      Expires April 18, 2014                [Page 11]


Internet-Draft           IPv6 Optimized-nd(WIND)            October 2013


   Fields:
   Type:          33 ( 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.
   TID:           8-bit integer.  It is a transaction id maintained by
                  the host and incremented with each registration. it is
                  recommended that the node maintains a persistent
                  storage for TID.  TID is used as a sequence counter to
                  detect the most recent registration request from a
                  host and its mobility within the same subnet across
                  multiple default Border Routers.  Its operation
                  follows section 7 of RPL [RFC6550] for sequence
                  counters.
   Registration Lifetime:  16-bit unsigned integer.  The amount of time
                  in a unit of 60 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.
   T bit:         One bit flag.  Set if the TID octet is present for
                  processing.

   The Status values used in Neighbor Advertisements are:

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

                                  Table 1

7.2.  Refresh and De-registration

   A host SHOULD send a Registration message in order to renew its
   registration before its registration lifetime expires in order to
   continue its connectivity with the network.  If anytime, the node
   decides that it does not need the default router's service anymore,



Chakrabarti, et al.      Expires April 18, 2014                [Page 12]


Internet-Draft           IPv6 Optimized-nd(WIND)            October 2013


   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 Advertisement flag [RF] is needed in order to
   distinguish a router advertisement from a efficiency-aware default
   router or a legacy IPv6 router.  This flag is ignored by the legacy
   IPv6 hosts.  EAH hosts use this flag in order 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 efficiency-aware Router behavior for Neighbor
   Discovery as per this document.  All other cases the E bit MUST be 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 efficiency-
   aware support in the default router in the link.

7.4.  The Transaction Identification(TID)

   The TID field is used together with age of a registration for
   arbitration between two routers (default or backbone) to ensure
   freshness and ownership of the registration of a given target
   address.  Same value of TID indicates that both states of
   registration are valid.  In case of a mismatch between comparable
   TIDs, the most recent TID wins.  The TID definition used in section
   6.4.1 of RFC 6550 for DAOSequence number would be applicable for here
   for TID in ARO message.

   It is 8 bit field.  TID is generated by the host at the time of a new
   registraton request.

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





Chakrabarti, et al.      Expires April 18, 2014                [Page 13]


Internet-Draft           IPv6 Optimized-nd(WIND)            October 2013


8.  Efficiency-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 efficiency-aware mode
                           support.  Unlike RFC4861 which suggests
                           multicast 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 except for the point-to-point
                           links.  Since no periodic RAs are allowed in
                           the efficiency-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 efficiency-aware mode.




Chakrabarti, et al.      Expires April 18, 2014                [Page 14]


Internet-Draft           IPv6 Optimized-nd(WIND)            October 2013


                           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.
   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.  Efficiency-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 is not required to join the 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 efficiency-aware router
   (NEAR) in the link.

   The efficiency-aware host MUST NOT send or accept re-direct messages.



Chakrabarti, et al.      Expires April 18, 2014                [Page 15]


Internet-Draft           IPv6 Optimized-nd(WIND)            October 2013


   It does not join solicited node multicast address.

   If the EAH is capable of generating TID and configured for this
   operation, the EAH MUST use the TID field and appropriate associated
   operation bits in the ARO message during registration and refresh.

   In some cases, hosts may need to send MAX_RTR_SOLICITATIONS(3) to
   receive the reply back from the default router.  In a lossy link or
   due to sleepy default router, the hosts may have to send more than 3
   solicitations [Resilient-RS].  But this can easily increase the
   number of siganling traffic in the network.  Thus it is RECOMMEDED
   that the EAH nodes start with the default MAX_RTR_SOLICITATION [ND]
   value in a low power network.

   However, in some scenarios the packet loss resilient router
   solicitation method may be applicable [Resilient-RS].


10.  The Efficiency 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).

   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 efficiency-aware hosts or a
   efficiency-aware router(NEAR).

   The efficiency-aware default router MUST not send periodic RA unless
   it is configured to support both legacy IPv6 and efficiency-aware
   hosts.  If the Router is configured for efficiency-aware hosts
   support, it MUST send Router Advertisements 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



Chakrabarti, et al.      Expires April 18, 2014                [Page 16]


Internet-Draft           IPv6 Optimized-nd(WIND)            October 2013


   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 efficiency-aware Router(NEAR) MUST be able to configure in
   efficiency-aware-only mode where it will expect all hosts register
   with the router following RS; thus NEAR will not support legacy
   hosts.  However, it will create legacy NCE for the routers in the
   network assuming that the routers do not register with it.  This mode
   is able to prevent ND flooding on the link.

   An efficiency-aware Router(NEAR) SHOULD be able to have configuration
   knob to configure itself in Mixed-Mode where it will support both
   efficiency-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 efficiency-aware
   router is Mixed-mode.  Though it cannot reap the full benefit of
   efficiency related optimization described in this document.

10.2.  Movement Detection

   When a host moves from one subnet to another its IPv6 prefix changes
   and the movement detection is determined according to the existing
   IPv6 movement detection described in [DNA].

   However, if the movement happens across different default routers in
   the subnet and the node likes to register with one of the default
   routers closest to its present location, it MUST send another
   registration request to the new default router.  The new default
   router then first sends a NS to its peers with a link scope multicast
   message to IPv6 address ff02::2 with the ARO option.

10.2.1.  Registration ownership

   The subnet-local-routers check their respective NCE table for the
   particular registration.  If the registration entry exists, the NEAR
   default router then calculates the 'age' of the registration by



Chakrabarti, et al.      Expires April 18, 2014                [Page 17]


Internet-Draft           IPv6 Optimized-nd(WIND)            October 2013


   subtracting the present time from the registration received time
   recorded at the NCE.  The NEAR router then responds with a NA with
   ARO option Status being equal to 3 and replaces the 'registration
   lifetime' field with the 'age' of registration.  Upon receiving the
   NA from the neighboring routers the prospective default router
   determines its registration ownership.  If the other router
   registration age is higher than its own registration age, then the
   current router is considered to have the most recent registration
   ownership.

   If both routers registration age are zero or within a 50msec window,
   then the TID field is used to determine the ownership.  The higher
   value of TID wins.  Note that the registration ownership and local
   movement detection behavior in NEAR router MUST be optionally
   configured.  The NEAR routers MAY implement this feature.
   Configuring this option is needed when the NEAR routers are used in a
   low power and lossy network environment.


11.  NCE Management in efficiency-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 efficiency-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



Chakrabarti, et al.      Expires April 18, 2014                [Page 18]


Internet-Draft           IPv6 Optimized-nd(WIND)            October 2013


   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 'Efficiency-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 efficiency-aware hosts.
   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 efficiency-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 efficiency-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].

   In addition, NEAR default routers MUST associate a record of the age
   of the registration.  'Age' is a simple way to detect movement of a
   node from local default router to another.  'Age' information SHOULD
   contain System-time when the registration is first created or last
   refreshed.  This system-time is deducted from the current system-time
   to determine the "age" of the registration and it is used for age



Chakrabarti, et al.      Expires April 18, 2014                [Page 19]


Internet-Draft           IPv6 Optimized-nd(WIND)            October 2013


   reporting with Neighbor advertisement for selection of registration
   ownership among the default-router contenders in case of local
   movement of the host from one default-router to another in the same
   subnet.  'Age' is always considered zero for a fresh registration or
   a registration refresh message.

11.1.  Handling ND DOS Attack

   IETF community has discussed possible issues with /64 DOS attacks on
   the ND networks when an attacker host can send thousands of packets
   to the router with an 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 efficiency-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 RECOMMENDED that Mixed-mode operation and legacy hosts SHOULD
   NOT be mixed in the IPv6 link in order to avoid the ND DOS attacks.
   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 efficiency-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 efficiency-aware-hosts in the network
      and a NEAR router




Chakrabarti, et al.      Expires April 18, 2014                [Page 20]


Internet-Draft           IPv6 Optimized-nd(WIND)            October 2013


   o  legacy IPv6 default-router and efficiency-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 efficiency-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 efficiency-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 efficiency-aware Host implementation SHOULD support falling back
   to legacy IPv6 node behavior when no efficiency-aware routers are
   available in the network during the startup.  If the EAH was
   operational in efficiency-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 efficiency-aware router
   is indicated from the RA, then the EAH SHOULD fall back into RFC 4861
   behavior.  On the other hand, in the efficiency-aware mode EAH SHOULD
   ignore multicast Router Advertisements(RA) sent by the legacy and
   Mixed-mode routers in the link.

   In mixed mode operation, the Router SHOULD be able to do local
   movement detection based on ARO if it is configured for that
   operation for EAH hosts.  For the legacy hosts, the mixed-mode router
   MAY follow classical IPv6 methods of movement detection and MAY act
   as ND proxy by sending NA with 'O' bit.[ Reference??]

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

   In mixed mode, the NEAR SHOULD have a configurable interval for
   periodic unsolicited router advertisements based on the media type.


13.  Bootstrapping

   The bootstrapping mechanism described here is applicable for the



Chakrabarti, et al.      Expires April 18, 2014                [Page 21]


Internet-Draft           IPv6 Optimized-nd(WIND)            October 2013


   efficiency-aware hosts and routers.  At the start, the host 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 an IPv6 address.


      Node                                                  Router

   0.  |[Forms LL IPv6 addr]                                  |

   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 efficiency-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 efficiency-aware
   functionalities of rotuers are available in the network.  It is
   RECOMMENDED that the EAH implementation SHOULD be able to behave like
   a legacy IPv6 host if it discovers that no efficiency-aware routing
   support is present in the link.



Chakrabarti, et al.      Expires April 18, 2014                [Page 22]


Internet-Draft           IPv6 Optimized-nd(WIND)            October 2013


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.  Duplicate Address Detection

   In efficiency-aware mode, there is no need for Duplicate Address
   Detection(DAD) assuming that the deployment ensures unique 64bit
   identification availability for each registered host.  In the event
   of collision of EUI64 field of ARO by two registration requests, the
   later request is denied if the first one is a valid request.  The
   denied EAH node SHOULD pick another alternative IPv6 address to
   register to prevent further registration denial.  The method of
   assignment of alternate IPv6 address is out of scope of this
   document.

   In some networks there are multiple default routers and the
   registering node may move from one default router (where it was
   registered before) to another default router in the same subnet.
   Thus in order to differentiate between the duplicate request and the
   movement, the router checks the 64-bit MAC address and 'age' of the
   request.  If there is an entry in the node already with 0 < 'age' <
   registration-life-time and the TID field of the existing entry and
   the new request is same with TID of the new request, it is a
   duplicate.

   If the default router does not have a registered entry for this host,
   it should check whether it is a local movement.  Please see 'Mobility
   Consideration section' for details.


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.
   If a node moves away without de-registration and returns to the
   network before the registration lifetime expires, its registration is
   still considered valid.  For run-away nodes the registration expires
   after the lifetime expiry or due to unreachablity whichever comes
   first.  Otherwise, the regular IPv6 Mobility [IPV6M]behavior applies.



Chakrabarti, et al.      Expires April 18, 2014                [Page 23]


Internet-Draft           IPv6 Optimized-nd(WIND)            October 2013


   In the multiple default router scenario, a node may move from its
   current primary default router to a prospective primary default
   router.  At this point, the default routers use Neighbor
   Advertisements(NA) to arbitrate the latest ownership of the
   registration of host.  The ownership of registration is useful for
   the Border Routers if they participate in a routing protocol which
   advertises proximity preferences or adjusts its own forwarding
   preference based on the host registration.  This kind of forwarding
   or routing mechanisms are useful for energy efficiency and
   performance of the networks.  See 'Movement Detection' section for
   details.


17.  Other Considerations

17.1.  Detecting Network Attachment(DNA)

   IPv6 DNA[DNA] uses unicast ND probes and link-layer indications to
   detect movement of its network attachments.  Upon detecting link-
   layer indication, it sends a all-routers Solicitation message.  When
   the node implements this document along with DNA, it MUST send ARO
   option with its Neighbor Solicitation unicast message if the
   candidate router advertisement indicates that the router is a NEAR
   router.  If the candiate router is a legacy router then and it is the
   only choice then the EAH host SHOULD adapt to the legacy behavior.
   However if EAH node implements DNA host capability as well, then it
   SHOULD give preference to the NEAR routers in its candidate list of
   routers.

   Thus the ND optimization solution will work seamlessly with DNA
   implementations and no change is required in DNA solution because of
   Neighbor Discovery updates.  It is a deployment and configuration
   consideration as to run the network in mixed mode or efficient-mode.

17.2.  Proxying for Efficiency-Aware hosts

   The efficient-ND SHOULD continue to support the legacy IPv6 Neighbor
   Solicitation requests in the mixed mode.  The NEAR router SHOULD act
   as the ND proxy on behalf of EAH hosts for the legacy nodes' NS
   requests for EAH.

   In the context of this specification, proxy ND means: defending a
   registered address over the backbone using NA messages with and ARO
   option and the Override bit set if the ARO option in the NS indicates
   either a different node (different EUI-64) or a older registration
   (when comparing the TID).





Chakrabarti, et al.      Expires April 18, 2014                [Page 24]


Internet-Draft           IPv6 Optimized-nd(WIND)            October 2013


   o  advertising a registered address over the backbone using NA
      messages, asynchronously or as a response to a Neighbor
      Solicitation messages.
   o  Looking up a destination over the backbone in order to deliver
      packets arriving from the EAH host using Neighbor Solicitation
      messages.
   o  Forwarding packets from the EAH over the backbone, and the other
      way around at a time if the devide has known sleeping periods or
      resides on a different link such as an LLN attached to the
      backbone.
   Eventually triggering a look-up for a destination EAH that would not
   be registered at a given point of time, or as a verification of a
   registration.

17.3.  DHCPv6 Interaction

   Co-existence with DHCP: For classical IPv6, if DHCPv6 or central
   address allocation mechanism is used, then Neighbor Discovery
   autoconfiguration is not used for global address allocation.
   However, link-local duplicate address detection, Neighbor
   solicitation, Neighbor unreachability detection are still used.  Upon
   assignment of the IPv6-address from DHCPv6, a EAH node SHOULD then
   register the IP-address with the default router for avoiding
   Duplicate address detection and Address Resolution.  For Legacy
   DHCPv6 nodes there is no change in behavior.  NOTE: DHCPv6 Server
   MUST be notified by NEAR for its efficiency-aware service interfaces.
   DHCPv6 server then SHOULD inform the DHCP requestor node about the
   default-rotuer capability during the address assignment period.

   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.


18.  RPL Implications

   RPL [RFC6550] does not provide means for duplicate address detection
   and in particular does not have a concept of unique identifier.  On
   the other hand, RPL is designed to discover and resolve conflicts
   that arise when a mobile device changes its point of attachment, with
   a sequence counter that is owned by the device and incremented at
   each new registration, called a DAOSequence.  As we extend 6LoWPAN ND
   operation over a backbone and scale, there is a similar need to
   resolve the latest point of attachment of a device, whether this
   device moves at layer 2 over a WIFI infrastructure, or at layer 3
   within a RPL DODAG or from a DODAG to another one attached to the



Chakrabarti, et al.      Expires April 18, 2014                [Page 25]


Internet-Draft           IPv6 Optimized-nd(WIND)            October 2013


   same backbone.  In order to cover all cases in a consistent fashion,
   this document requires that a sequence counter call TID for
   Transaction ID and with the similar rules as the RPL DAOSequence is
   added to the ND registration.  This document defines the TID
   operations and RPL may use the reserved fields for their purpose
   inside the LLN.


19.  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 efficiency-aware-nd implementation.  These values SHOULD be
   configurable and tunable to fit implementations and deployment.

   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

   Also refer to [ENH-ND] , [IMPAT-ND] and [6LOWPAN-ND] for further
   tuning of ND constants.


20.  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
   efficiency-aware mode.  See Section 11.1.


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


22.  Changelog

   Changes from draft-chakrabarti-nordmark-energy-aware-nd-02:



Chakrabarti, et al.      Expires April 18, 2014                [Page 26]


Internet-Draft           IPv6 Optimized-nd(WIND)            October 2013


      o Added clarification that SLLA is not required for ARO in a
      point-to-point link
      o Clarified that the document is indeed an optimization for legacy
      IPv6 ND
      o Adressed editorial comments and fixed typoes.  Some more
      editorial work is needed
      o Added another usecase for Z-Wave example.  Clarified 3GPP
      Networks related comments on existing ND optimizations.


23.  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
   Wasserman who saw a need for such a document at the IOT workshop at
   Prague IETF.

   The authors acknowledge the ND denial of service issues and key
   causes mentioned in the draft-halpern-6man-nddos-mitigation document
   by Joel Halpern.  Thanks to Joel Halpern for pinpointing the problems
   that are now addressed in the NCE management section.

   The authors like to thank Dave Thaler, Stuart Cheshire, Jari Arkko,
   Ylva Jading, Niklas J. Johnsson, Reda Nedjar, Purvi Shah, Jaume Rius
   Riu, Fredrik Garneij, Andrew Yourtchenko, Jouni Korhonen, Suresh
   Krishnan, Brian Haberman, Anders Brandt, Mark Smith, Lorenzo Colitti,
   David Miles and Carsten Bormann for their useful comments and
   suggestions on this work.


24.  References

24.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., Nordmark, E., and C. Bormann,
              "ND Optimizations for 6LoWPAN", RFC 6775, November 2012.



Chakrabarti, et al.      Expires April 18, 2014                [Page 27]


Internet-Draft           IPv6 Optimized-nd(WIND)            October 2013


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

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

   [RFC6550]  "RPL: IPv6 Routing Protocol for Low-Power and Lossy
              Networks", RFC 6550, March 2012.

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

   [AUTOADHOC]
              Baccelli, E. and M. Townsley, "IP Addressing Model in
              Adhoc Networks", RFC 5889, September 2010.

   [NDDOS-halpern]
              Halpern, J., "IP Addressing Model in Adhoc Networks",
              draft-halpern-6man-nddos-mitigation-00.txt (work in
              progress), October 2011.

   [ENH-ND]   Kumari, W., Gashinsky, I., Jaeggli, J., and K.
              Chittimaneni, "Neighbor Discovery Enhancement for DOS
              mitigation", draft-gashinsky-6man-v6nd-enhance-02 (work in
              progress), October 2012.

   [IMPAT-ND]
              Nordmark, E. and I. Gashinsky, "Neighbor Unreachability
              Detection is too impatient",



Chakrabarti, et al.      Expires April 18, 2014                [Page 28]


Internet-Draft           IPv6 Optimized-nd(WIND)            October 2013


              draft-ietf-6man-impatient-nud-05 (work in progress),
              October 2012.

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

   [Resilient-RS]
              Krishnan, S., Anipko, D., and D. Thaler, "Packet loss
              resiliency for Router Solicitations",
              draft-ietf-6man-resilient-rs-01 (work in progress),
              May 2013.

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


Appendix A.  Usecase Analysis

   This section provides applicability scenarios where the efficiency-
   aware Neighbor Discovery will be most beneficial.  Most likely the
   usecases will be detailed in a separate document.

A.1.  Data Center Routers on the link

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

A.2.  Edge Routers and Home Networks

   An Edge Router in the network will also benefit implementing the
   efficiency-aware Neighbor Discovery behavior in order to save the
   signaling and keeping track of the registered nodes in its domain.  A



Chakrabarti, et al.      Expires April 18, 2014                [Page 29]


Internet-Draft           IPv6 Optimized-nd(WIND)            October 2013


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

A.3.  M2M Networks

   Any Machine-to-machine(M2M) networks such as IPv6 surveilance
   networks, wireless monitoring networks and other m2m networks desire
   for efficiency-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.

A.4.  Wi-fi Networks

   In Wi-fi networks, a multicast message will consume the wireless link
   on all Access Points around a switched fabric and will be transmitted
   at the lowest speed possible in order to ensure the maximum reception
   by all wireless nodes.  This means that in an environment where
   bandwidth is scarce, a single multicast packet may consume the
   bandwidth for hundreds of unicast packets.

   The Wi-fi IPv6 hosts can act as efficiency-aware hosts and register
   with their nearest default router with NEAR behavior.  This method
   reduces multicast operations in the wireless access points or routers
   by using this optimization.

A.5.  3GPP Networks

   Section 9.2.1.1 of TS23.060 allows periodic RA and TS 123.401 stays
   silent about periodic RA while 3GPP TS29.061 recommends large values
   for minimum and maximum periodic router advertisements for reduced
   periodic mesages.  Though RFC6459 describes best practices about IPv6
   3GPP systems behavior, this ND optimization standard specification
   will be a helpful reference for 3GPP documents.  LTE terminals (cell
   phones) may also benefit with reduced multicast messages described in
   this document in the wireless mode.





Chakrabarti, et al.      Expires April 18, 2014                [Page 30]


Internet-Draft           IPv6 Optimized-nd(WIND)            October 2013


A.6.  Industrial Networks

   RPL [RFC6550] is used for Industrial wireless networks.

A.7.  Set and forget offline network

   Home control modules designed for networked environments may be
   deployed in very simple settings like garden path lighting controlled
   by wireless light and motion sensors.  Once the network has been
   created and sensors have been associated with the light modules, the
   installer takes away the configuration tool which was used to set up
   the network.  Most likely a ULA prefix is used, since multiple hops
   may be needed.  None of the sensors and light modules has the
   capability of handing out fresh prefixes.  Thus, for a set-and-forget
   style off-line network to work, the nodes must be provided an
   infinite prefix lifetime since they have nowhere to ask for a fresh
   one.


Authors' Addresses

   Samita Chakrabarti
   Ericsson
   San Jose, CA
   USA

   Email: samita.chakrabarti@ericsson.com


   Erik Nordmark
   San Jose, CA
   USA

   Email: nordmark@sonic.net


   Pascal Thubert
   Cisco Systems


   Email: pthubert@cisco.com










Chakrabarti, et al.      Expires April 18, 2014                [Page 31]


Internet-Draft           IPv6 Optimized-nd(WIND)            October 2013


   Margaret Wasserman
   Painless Security


   Email: mrw@lilacglade.org














































Chakrabarti, et al.      Expires April 18, 2014                [Page 32]


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