< draft-chakrabarti-nordmark-6man-efficient-nd-02.txt   draft-chakrabarti-nordmark-6man-efficient-nd-03.txt >
6man WG S. Chakrabarti 6man WG S. Chakrabarti
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: 4861 (if approved) E. Nordmark Updates: 4861 (if approved) E. Nordmark
Intended status: Standards Track P. Thubert Intended status: Standards Track
Expires: January 16, 2014 Cisco Systems Expires: April 18, 2014 P. Thubert
Cisco Systems
M. Wasserman M. Wasserman
Painless Security Painless Security
July 15, 2013 October 15, 2013
Efficiency aware IPv6 Neighbor Discovery Optimizations Wired and Wireless IPv6 Neighbor Discovery Optimizations
draft-chakrabarti-nordmark-6man-efficient-nd-02 draft-chakrabarti-nordmark-6man-efficient-nd-03
Abstract Abstract
IPv6 Neighbor Discovery (RFC 4861) protocol has been designed for IPv6 Neighbor Discovery (RFC 4861) protocol has been designed for
neighbor's address resolution, unreachability detection, address neighbor's address resolution, unreachability detection, address
autoconfiguration, router advertisement and solicitation. With the autoconfiguration, router advertisement and solicitation. With the
progress of Internet adoption on various industries including home, progress of Internet adoption on various industries including home,
wireless, M2M and cellular networks there is a desire for optimizing wireless, M2M and cellular networks there is a desire for optimizing
the legacy IPv6 Neighbor Discovery protocol. This document describes the legacy IPv6 Neighbor Discovery protocol. This document describes
a method of optimization by reducing multicast messages and a method of optimization by reducing multicast messages and
introducing an IPv6 address Registration mechanism. Efficient IPv6 introducing an IPv6 address Registration mechanism. The optimization
Neighbor Discovery protocol is useful for energy-efficient and low- of IPv6 Neighbor Discovery protocol is useful for Wirless and low-
power IPv6 networks and as well as Data Center and Home Networks. power IPv6 networks and as well as Data Centers and Home Networks.
The solution is capable of handling existing legacy IPv6 nodes in the The solution is capable of handling existing legacy IPv6 nodes in the
network with local mobility. network with local mobility.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 16, 2014. This Internet-Draft will expire on April 18, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Problem Areas . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Overview of the ND Optimization . . . . . . . . . . . . . 5 1.2. Overview of the basic ND Optimization . . . . . . . . . . 5
2. Definition Of Terms . . . . . . . . . . . . . . . . . . . . . 6 2. Definition Of Terms . . . . . . . . . . . . . . . . . . . . . 6
3. Assumptions for efficiency-aware Neighbor Discovery . . . . . 8 3. Assumptions for efficiency-aware Neighbor Discovery . . . . . 8
4. The set of Requirements for efficiency and optimization . . . 8 4. The set of Requirements for efficiency and optimization . . . 8
5. Basic Operations . . . . . . . . . . . . . . . . . . . . . . . 9 5. Basic Operations . . . . . . . . . . . . . . . . . . . . . . . 9
6. Applicability Statement . . . . . . . . . . . . . . . . . . . 9 6. Applicability Statement . . . . . . . . . . . . . . . . . . . 10
7. New Neighbor Discovery Options and Messages . . . . . . . . . 10 7. New Neighbor Discovery Options and Messages . . . . . . . . . 10
7.1. Address Registration Option . . . . . . . . . . . . . . . 10 7.1. Address Registration Option . . . . . . . . . . . . . . . 10
7.2. Refresh and De-registration . . . . . . . . . . . . . . . 12 7.2. Refresh and De-registration . . . . . . . . . . . . . . . 12
7.3. A New Router Advertisement Flag . . . . . . . . . . . . . 12 7.3. A New Router Advertisement Flag . . . . . . . . . . . . . 13
7.4. The Transaction Identification(TID) . . . . . . . . . . . 13 7.4. The Transaction Identification(TID) . . . . . . . . . . . 13
8. Efficiency-aware Neighbor Discovery Messages . . . . . . . . . 13 8. Efficiency-aware Neighbor Discovery Messages . . . . . . . . . 14
9. Efficiency-aware Host Behavior . . . . . . . . . . . . . . . . 15 9. Efficiency-aware Host Behavior . . . . . . . . . . . . . . . . 15
10. The Energy Aware Default Router (NEAR) Behavior . . . . . . . 15 10. The Efficiency Aware Default Router (NEAR) Behavior . . . . . 16
10.1. Router Configuration Modes . . . . . . . . . . . . . . . . 16 10.1. Router Configuration Modes . . . . . . . . . . . . . . . . 17
10.2. Movement Detection . . . . . . . . . . . . . . . . . . . . 17 10.2. Movement Detection . . . . . . . . . . . . . . . . . . . . 17
10.2.1. Registration ownership . . . . . . . . . . . . . . . 17 10.2.1. Registration ownership . . . . . . . . . . . . . . . 17
11. NCE Management in efficiency-aware Routers . . . . . . . . . . 17 11. NCE Management in efficiency-aware Routers . . . . . . . . . . 18
11.1. Handling ND DOS Attack . . . . . . . . . . . . . . . . . . 19 11.1. Handling ND DOS Attack . . . . . . . . . . . . . . . . . . 20
12. Mixed-Mode Operations . . . . . . . . . . . . . . . . . . . . 20 12. Mixed-Mode Operations . . . . . . . . . . . . . . . . . . . . 20
13. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . . 21 13. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . . 21
14. Handling Sleepy Nodes . . . . . . . . . . . . . . . . . . . . 22 14. Handling Sleepy Nodes . . . . . . . . . . . . . . . . . . . . 23
15. Duplicate Address Detection . . . . . . . . . . . . . . . . . 23 15. Duplicate Address Detection . . . . . . . . . . . . . . . . . 23
16. Mobility Considerations . . . . . . . . . . . . . . . . . . . 23 16. Mobility Considerations . . . . . . . . . . . . . . . . . . . 23
17. Other Considerations . . . . . . . . . . . . . . . . . . . . . 24 17. Other Considerations . . . . . . . . . . . . . . . . . . . . . 24
17.1. Detecting Network Attachment(DNA) . . . . . . . . . . . . 24 17.1. Detecting Network Attachment(DNA) . . . . . . . . . . . . 24
17.2. Proxying for Efficiency-Aware hosts . . . . . . . . . . . 24 17.2. Proxying for Efficiency-Aware hosts . . . . . . . . . . . 24
17.3. DHCPv6 Interaction . . . . . . . . . . . . . . . . . . . . 25 17.3. DHCPv6 Interaction . . . . . . . . . . . . . . . . . . . . 25
18. RPL Implications . . . . . . . . . . . . . . . . . . . . . . . 25 18. RPL Implications . . . . . . . . . . . . . . . . . . . . . . . 25
19. Updated Neighbor Discovery Constants . . . . . . . . . . . . . 26 19. Updated Neighbor Discovery Constants . . . . . . . . . . . . . 26
20. Security Considerations . . . . . . . . . . . . . . . . . . . 26 20. Security Considerations . . . . . . . . . . . . . . . . . . . 26
21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
22. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 26 22. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 26
23. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 23. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
24. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 24. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
24.1. Normative References . . . . . . . . . . . . . . . . . . . 27 24.1. Normative References . . . . . . . . . . . . . . . . . . . 27
24.2. Informative References . . . . . . . . . . . . . . . . . . 28 24.2. Informative References . . . . . . . . . . . . . . . . . . 28
Appendix A. Usecase Analysis . . . . . . . . . . . . . . . . . . 29 Appendix A. Usecase Analysis . . . . . . . . . . . . . . . . . . 29
A.1. Data Center Routers on the link . . . . . . . . . . . . . 29 A.1. Data Center Routers on the link . . . . . . . . . . . . . 29
A.2. Edge Routers and Home Networks . . . . . . . . . . . . . . 29 A.2. Edge Routers and Home Networks . . . . . . . . . . . . . . 29
A.3. M2M Networks . . . . . . . . . . . . . . . . . . . . . . . 29 A.3. M2M Networks . . . . . . . . . . . . . . . . . . . . . . . 30
A.4. Wi-fi Networks . . . . . . . . . . . . . . . . . . . . . . 30 A.4. Wi-fi Networks . . . . . . . . . . . . . . . . . . . . . . 30
A.5. 3GPP Networks . . . . . . . . . . . . . . . . . . . . . . 30 A.5. 3GPP Networks . . . . . . . . . . . . . . . . . . . . . . 30
A.6. Industrial Networks . . . . . . . . . . . . . . . . . . . 30 A.6. Industrial Networks . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 A.7. Set and forget offline network . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
Conceptually, IPv6 multicast messages are supposed to avoid broadcast Conceptually, IPv6 multicast messages are supposed to avoid broadcast
messages, but in practice, the multicast operation at the link level messages, but in practice, the multicast operation at the link level
is that of a broadcast nevertheless. This did not matter much at the is that of a broadcast nevertheless. This did not matter much at the
time ND [ND] was originally designed, when an Ethernet network was time ND [ND] was originally designed, when an Ethernet network was
more or less a single shared wire, but since then, large scale switch more or less a single shared wire, but since then, large scale switch
fabrics, low power sleeping devices, mobile wireless/cellular devices fabrics, low power sleeping devices, mobile wireless/cellular devices
and virtual machines have changed the landscape dramatically. and virtual machines have changed the landscape dramatically.
skipping to change at page 4, line 31 skipping to change at page 4, line 31
devices(L2/L3), Network edge devices performing subscriber access, devices(L2/L3), Network edge devices performing subscriber access,
network devices that protect the ownership of an IPv6 address, network devices that protect the ownership of an IPv6 address,
Overlay networks in data centers, Home Networks for IPv6 clients. 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 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 less chatty and flexible to work with different types of networking
elements, physical and virtual networks and at the same time elements, physical and virtual networks and at the same time
maintaining the IPv6 states to avoid duplicates or denial of maintaining the IPv6 states to avoid duplicates or denial of
services. services.
1.1. Background 1.1. Problem Areas
IPv6 ND [ND] is based on multicast signaling messages on the local Specifically, the following are the issues with the IPv6 deployment
link in order to avoid broadcast messages. Following power-on and in many wireless and high-density IPv6 subnets today:
initialization of the network in IPv6 Ethernet networks, a node joins o The periodic RA messages in IPv6 ND [ND], and NS/NA messages
the solicited-node multicast address on the interface and then require all IPv6 nodes in the link to be in listening mode even
performs duplicate address detection (DAD) for the acquired link- when they are in idle cycle. It requires energy for the sleepy
local address by sending a solicited-node multicast message to the nodes which may otherwise be sleeping during the idle period.
link. After that it sends multicast router solicitation (RS) Non-sleepy nodes also spends more energy since they are in
messages to the all-router address to solicit router advertisements. continuous listening mode. With the explosion of Internet-of-
Once the host receives a valid router advertisement (RA) with the "A" things and machine to machine communication, more and more devices
flag, it autoconfigures the IPv6 address with the advertised prefix would be using IPv6 addresses in the near future.
in the router advertisement (RA). Besides this, the IPv6 routers o With WIFI, a multicast message will consume the wireless link on
usually send router advertisements periodically on the network. RAs all Access Points around a switched fabric and will be transmitted
are sent to the all-node multicast address. The minimum RA interval at the lowest speed possible in order to ensure the maximum
range can be 3sec to 600sec depending on applications. Nodes send reception by all wireless nodes. This means that in an
Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages environment where bandwidth is scarce, a single multicast packet
to resolve the IPv6 address of the destination on the link. These may consume the bandwidth for hundreds of unicast packets. Sadly,
NS/NA messages are also often multicast messages and it is assumed IPv6 ND is a major source of multicast messages in wireless
that the node is on the same link and relies on the fact that the devices, since such messages are triggered each time a wireless
destination node is always powered and generally available. device changes its point of attachment.
The periodic RA messages in IPv6 ND [ND], and NS/NA messages require o In a datacenter, where VM mobility and VM address reslution also
all IPv6 nodes in the link to be in listening mode even when they are trigger storms of IPv6 ND multicast messages, which become a major
in idle cycle. It requires energy for the sleepy nodes which may hassle as the number of VM may scale to the tens of thousands in a
otherwise be sleeping during the idle period. Non-sleepy nodes also large Data Center. At the IETF, a WG discusses such problems with
spends more energy since they are in continuous listening mode. With Address Resolution in Massive Datacenters (ARMD).
the explosion of Internet-of-things and machine to machine
communication, more and more devices would be using IPv6 addresses in
the near future. Since Neighbor Discovery is at the heart of IPv6
protocol, there is a need to make this protocol more efficient.
1.2. Overview of the ND Optimization The following paragraph elaborates the source of all the multicast
messages in IPv6 ND.
IPv6 Neighbor Discovery Optimization for 6LoWPAN [6LOWPAN-ND] Following power-on and initialization of the network in IPv6 Ethernet
addresses many of the concerns described above by optimizing the networks, a node joins the solicited-node multicast address on the
Router advertisement, minimizing periodic multicast packets in the interface and then performs duplicate address detection (DAD) for the
network and introducing two new options - one for node registration acquired link-local address by sending a solicited-node multicast
and another for prefix dissemination in a network where all nodes in message to the link. After that it sends multicast router
the network are uniquely identified by their 64-bit Interface solicitation (RS) messages to the all-router address to solicit
Identifier. EUI-64 identifiers are recommended as unique Interface router advertisements. Once the host receives a valid router
Identifiers, however if the network is isolated from the Internet, advertisement (RA) with the "A" flag, it autoconfigures the IPv6
uniqueness of the identifiers may be obtained by other mechanisms address with the advertised prefix in the router advertisement (RA).
such as a random number generator with lowest collision rate. Besides this, the IPv6 routers usually send router advertisements
Although, the ND optimization [6LOWPAN-ND] applies to 6LoWPAN periodically on the network. RAs are sent to the all-node multicast
[LOWPAN] network, the concept is mostly applicable to a power-aware address. The minimum RA interval range can be 3sec to 600sec
IPv6 network. Therefore, this document generalizes the address depending on applications. Nodes send Neighbor Solicitation (NS) and
registration and multicast reduction in [6LOWPAN-ND] to all IPv6 Neighbor Advertisement (NA) messages to resolve the IPv6 address of
links. 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
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 Thus optimizing the regular IPv6 Neighbor Discovery [ND] to minimize
total number of related signaling messages without losing generality total number of related signaling messages without losing generality
of Neighbor Discovery, autoconfiguration and reliable host-router of Neighbor Discovery, autoconfiguration and reliable host-router
communication, are desirable in any modern IPv6 networks such as communication, are desirable in any modern IPv6 networks such as
Home, Enterprise networks, Data Centers and Operator's Cellular/ Home, Enterprise networks, Data Centers and Operator's Cellular/
Wireless networks. Wireless networks.
The optimization will be highly effective for links and nodes which The optimization will be highly effective for links and nodes which
do not support multicast and as well as for a multicast network do not support multicast and as well as for a multicast network
without MLD snooping switches. Moreover, in the MLD-snooping without MLD snooping switches. Moreover, in the MLD-snooping
networks the MLD switches will deal with less number of multicasts. networks the MLD switches will deal with less number of multicasts.
The goal of this document is to provide an efficient Neighbor The goal of this document is to provide an efficient Neighbor
Discovery Protocol in classic IPv6 subnets and links. Research Discovery Protocol in classic IPv6 subnets in wireless/wired links.
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 In the process, the node registration method is also deemed to be
useful for preventing Neighbor Discovery denial of service ( ND DOS) useful for preventing Neighbor Discovery denial of service ( ND DOS)
attacks. attacks.
The proposed changes can be used in two different ways. In one case 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, all the hosts and routers on a link implement the new mechanisms,
which gives the maximum benefits. In another case the link has a which gives the maximum benefits. In another case the link has a
mixture of new hosts and/or routers and legacy [RFC4861] hosts and mixture of new hosts and/or routers and legacy [RFC4861] hosts and
routers, operating in a mixed-mode providing some of the benefits. routers, operating in a mixed-mode providing some of the benefits.
In the following sections the document describes the basic operations In the following sections the document describes the basic operations
of registration methods, optimization of Neighbor Discovery messages, of registration methods, optimization of Neighbor Discovery messages,
interoperability with legacy IPv6 implementations and provides a interoperability with legacy IPv6 implementations and provides a
section on use-case scenarios where it can be typically applicable. section on use-case scenarios where it can be typically applicable.
This document also describes an optional feature for node mobility in This document also describes an optional feature for enabling node
the LLN network using backbone routers(BBR) or multiple default mobility in the LLN network using backbone routers(BBR) or multiple
subnet routers. This optional feature in generating a sequence ID by default subnet routers. This optional feature generates a sequence
the host in the registration message will be helpful for deploying ID by the host in the registration message for deploying some routing
RPL[RFC6550] with reliability in the LLN. protocols (example: RPL [RFC6550]) with reliability in the LLN.
2. Definition Of Terms 2. Definition Of Terms
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
multi-level Subnets: multi-level Subnets:
It is a wireless link determined by one IPv6 off-link prefix in a A wireless link determined by one IPv6 off-link prefix in a
network where in order to reach a destination with same prefix a network where in order to reach a destination with same prefix a
packet may have to travel through one more 'intermediate' routers packet may have to travel through one or more 'intermediate'
which relays the packet to the next 'intermediate' router or the routers which relay the packet to the next 'intermediate' router
host in its own. or the host in its own.
Border Router(BR): Border Router(BR):
A border router is typically located at the junction Internet and A border router is typically located at the junction of Internet
Home Network. An IPv6 router with one interface connected to IPv6 and Home Network. An IPv6 router with one interface connected to
subnet and other interface connecting to a non-classic IPv6 an IPv6 subnet and other interface connecting to a non-classic
interface such as 6LoWPAN interface. Border router is usually the IPv6 interface such as 6LoWPAN interface. A Border router is
gateway to the IPv6 network or Internet. usually the gateway between the IPv6 network and Internet.
Backbone: Backbone:
This is an IPv6 transit link that interconnects 2 or more Low This is an IPv6 transit link that interconnects 2 or more Low
Power Lossy Networks (LLNs). It is expected to be deployed as a Power Lossy Networks (LLNs). It is expected to be deployed as a
high speed backbone in order to federate a potentially large set high speed backbone in order to federate a potentially large set
of LLN nodes. Also referred to as a LLN backbone or Backbone of LLN nodes. Also referred to as a LLN backbone or Backbone
network. network in this document.
Backbone Router: Backbone Router:
An IPv6 router that federates the LLN using a transit link as a An IPv6 router that federates the LLN using a transit link as a
backbone. A BBR acts as a 6LoWPAN Border Routers (6LBR) and an backbone. A BBR acts as a 6LoWPAN Border Router (6LBR) and an
Energy Aware Default Router (NEAR). Efficiency Aware Default Router (NEAR).
Efficiency-Aware Network: Efficiency-Aware Network:
An Efficiency-Aware network is composed of network elements that An Efficiency-Aware network is composed of network elements that
are sensitive to energy usage or number of signaling messages in are sensitive to energy usage or number of signaling messages in
the network. An efficiency-aware network may also contain links the network. An efficiency-aware network may also contain links
that do not support multicast or it does not have MLD snooping that do not support multicast or it does not have MLD snooping
capabilities and yet the network likes to communicate most capabilities and yet the network likes to communicate most
efficiently with minimum number of signaling messages. Data efficiently with minimum number of signaling messages. Data
center networks with virtual machines, cellular IPv6 networks, any center networks with virtual machines, cellular IPv6 networks, any
IPv6 networks with energy-sensitive nodes are examples of IPv6 networks with energy-sensitive nodes are examples of
Efficiency-Aware networks. Efficiency-Aware networks.
IPv6 ND-efficiency-aware Router(NEAR): IPv6 ND-efficiency-aware Router(NEAR):
It is the default Router of the single hop IPv6 subnet. This The default Router of the single hop IPv6 subnet. This router
router implements the optimizations specified in this document. implements the optimizations specified in this document. This
This router should be able to handle both legacy IPv6 nodes and router should be able to handle both legacy IPv6 nodes and nodes
nodes that sends registration request. that sends registration request.
Efficiency-Aware Host(EAH): Efficiency-Aware Host(EAH):
A host in a IPv6 network is considered a IPv6 node without routing A host in a IPv6 network is considered a IPv6 node without routing
and forwarding capability. The EAH is the host which implements and forwarding capability. The EAH is the host which implements
the host functionality for optimized Neighbor Discovery mentioned the host functionality for optimized Neighbor Discovery mentioned
in this document. in this document.
Legacy IPv6 Host: Legacy IPv6 Host:
A host in a IPv6 network is considered a IPv6 node without routing A host in a IPv6 network is considered a IPv6 node without routing
and forwarding capability and implements RFC 4861 host functions. and forwarding capability and implements RFC 4861 host functions.
Legacy IPv6 Router: Legacy IPv6 Router:
An IPv6 Router which implements RFC 4861 Neighbor Discovery An IPv6 Router which implements RFC 4861 Neighbor Discovery
protocols. protocols.
EUI-64: EUI-64:
It is the IEEE defined 64-bit extended unique identifier formed by It is the IEEE defined 64-bit extended unique identifier formed by
concatenation of 24-bit or 36-bit company id value by IEEE concatenation of 24-bit or 36-bit company id value by IEEE
Registration Authority and the extension identifier within that Registration Authority and the extension identifier within that
company-id assignment. The extension identifiers are 40-bit (for company-id assignment. The extension identifiers are 40-bit (for
24-bit company-id) or 28-bit (for the 36-bit company-id) 24-bit company-id) or 28-bit (for the 36-bit company-id)
respectively. respectively.
skipping to change at page 8, line 34 skipping to change at page 9, line 4
4. The set of Requirements for efficiency and optimization 4. The set of Requirements for efficiency and optimization
o Node Registration: Node initiated Registration and address o Node Registration: Node initiated Registration and address
allocation is done in order to avoid periodic multicast Router allocation is done in order to avoid periodic multicast Router
Advertisement messages and often Neighbor Address resolution can Advertisement messages and often Neighbor Address resolution can
be skipped as all packets go via the default router which now be skipped as all packets go via the default router which now
knows about all the registered nodes. Node Registration enables knows about all the registered nodes. Node Registration enables
reduction of all-node and solicited-node multicast messages in the reduction of all-node and solicited-node multicast messages in the
subnet. subnet.
o Address allocation of registered nodes [ND] are performed using o Address allocation of registered nodes [ND] are performed using
IPv6 Autoconfiguration [AUTOCONF]. IPv6 Autoconfiguration [AUTOCONF].
o Host initiated Registration and Refresh is done by sending a o Host initiated Registration and Refresh is done by sending a
Router Solicitation and then a Neighbor Solicitation Message using Router Solicitation and then a Neighbor Solicitation Message using
Address Registration Option (described below). Address Registration Option (described below).
o The node registration may replace the requirement of doing o The node registration may replace the requirement of doing
Duplicate Address Detection. Duplicate Address Detection.
o Sleepy hosts are supported by this Neighbor Discovery procedures o Sleepy hosts are supported by this Neighbor Discovery procedures
as they are not woken up periodically by Router Advertisement as they are not woken up periodically by Router Advertisement
multicast messages or Neighbor Solicitation multicast messages. multicast messages or Neighbor Solicitation multicast messages.
Sleepy nodes may wake up in its own schedule and send unicast Sleepy nodes may wake up in its own schedule and send unicast
registration refresh messages when needed. registration refresh messages when needed.
o Since this document requires formation of an IPv6 address with an o Since this document requires formation of an IPv6 address with an
unique 64-bit Interface ID(EUI-64) is required for global IPv6 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 addresses, if the network is an isolated one and uses ULA [ULA] as
its IPv6 address then the deployment should make sure that each its IPv6 address then the deployment should make sure that each
MAC address in that network has unique address and can provide a MAC address in that network has unique address and can provide a
unique 64-bit ID for each node in the network. unique 64-bit ID for each node in the network.
o /64-bit Prefix is required to form the IPv6 address. o A /64-bit Prefix is required to form the IPv6 address.
o MTU requirement is same as IPv6 network. o MTU requirement is same as IPv6 network.
5. Basic Operations 5. Basic Operations
In the efficient-nd IPv6 Network, the NEAR routers are the default In the efficient-nd IPv6 Network, the NEAR routers are the default
routers for the efficiency-aware hosts (EAH). During the startup or routers for the efficiency-aware hosts (EAH). During the startup or
joining the network the host does not wait for the Router joining the network the host does not wait for the Router
Advertisements as the NEAR routers do not perform periodic multicast Advertisements as the NEAR routers do not perform periodic multicast
RA as per RFC 4861. Instead, the EAH sends a multicast RS to find 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 out a NEAR router in the network. The RS message is the same as in
skipping to change at page 9, line 40 skipping to change at page 10, line 9
When a IPv6 network consists of both legacy hosts and EAH, and if the 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 NEAR is configured for 'mixed mode' operation, it should be able to
handle Address Registration Option(ARO) requests and send periodic handle Address Registration Option(ARO) requests and send periodic
RA. Thus it should be able to serve both efficiency-aware hosts and RA. Thus it should be able to serve both efficiency-aware hosts and
legacy hosts. Similarly, a legacy host compatible EAH falls back to 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 RFC 4861 host behavior if a NEAR is not present in the link. See the
section on 'Mixed Mode Operations' for details below. section on 'Mixed Mode Operations' for details below.
6. Applicability Statement 6. Applicability Statement
This document aims to guide the implementers to choose an appropriate This document aims to guide implementers to choose an appropriate
IPv6 neighbor discovery and Address configuration procedures suitable IPv6 neighbor discovery and Address configuration procedures suitable
for any efficient IPv6 network. These optimization is equally useful for any efficient IPv6 network. These optimizations are equally
for the energy-sensitive, non-multicast links and for classical IPv6 useful for the energy-sensitive, non-multicast links and for
networks i.e. home networks, Data-Center IPv6 overlay networks where classical IPv6 networks i.e. home networks, Data-Center IPv6 overlay
saving Neighbor Discovery messages will reduce cost and increase networks where saving Neighbor Discovery messages will reduce cost
bandwidth availability. and increase bandwidth availability.
The address registration mechanism and associated extension on The address registration mechanism and associated extension to the
Neighbor Discovery protocol allow a low-power host to move between Neighbor Discovery protocol allow a low-power host to move between
the LLN and the classic IPv6 networks as well as movement from one the LLN and the classic IPv6 networks as well as movement from one
Border Router registration area to another while staying within the Border Router registration area to another while staying within the
same IPv6 subnet. same IPv6 subnet.
Note that the specification allows 'Mixed-mode' operation in the Note that the specification allows 'Mixed-mode' operation in the
efficiency-aware nodes for backward compatibility and transitioning efficiency-aware nodes for backward compatibility and transitioning
to a complete efficiency-aware network of hosts and routers. Though to a complete efficiency-aware network of hosts and routers. Though
the efficiency-aware only nodes will minimize the ND signaling and the efficiency-aware only nodes will minimize the ND signaling and
DOS attacks in the LAN. DOS attacks in the LAN.
skipping to change at page 10, line 31 skipping to change at page 10, line 46
This section will discuss the registration and de-registration This section will discuss the registration and de-registration
procedure of the hosts in the network. procedure of the hosts in the network.
7.1. Address Registration Option 7.1. Address Registration Option
The Address Registration Option(ARO) is useful for avoiding Duplicate The Address Registration Option(ARO) is useful for avoiding Duplicate
Address Detection messages since it requires a unique EUI-64 ID for Address Detection messages since it requires a unique EUI-64 ID for
registration. The address registration is used for maintaining registration. The address registration is used for maintaining
reachability of the node or host by the router. This option is 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 almost the same ARO as in [6LOWPAN-ND]. A Transaction ID field and a
benefits of the readers. Additionally a Transaction ID field and a
corresponding bit have been introduced in order to detect duplicate corresponding bit have been introduced in order to detect duplicate
address registration and local mobility of a node. address registration and local mobility of a node.
The routers keep track of host IP addresses that are directly The routers keep track of host IP addresses that are directly
reachable and their corresponding link-layer addresses. This is reachable and their corresponding link-layer addresses. This is
useful for lossy and lowpower networks(LLN) and as well as wired useful for lossy and lowpower networks(LLN) and as well as wired IPv6
networks. An Address Registration Option (ARO) can be included in networks. An Address Registration Option (ARO) can be included in
unicast Neighbor Solicitation (NS) messages sent by hosts. Thus it unicast Neighbor Solicitation (NS) messages sent by hosts. Thus it
can be included in the unicast NS messages that a host sends as part can be included in the unicast NS messages that a host sends as part
of Neighbor Unreachability Detection to determine that it can still of Neighbor Unreachability Detection to determine that it can still
reach a default router. The ARO is used by the receiving router to reach a default router. The ARO is used by the receiving router to
reliably maintain its Neighbor Cache. The same option is included in reliably maintain its Neighbor Cache. The same option is included in
corresponding Neighbor Advertisement (NA) messages with a Status corresponding Neighbor Advertisement (NA) messages with a Status
field indicating the success or failure of the registration. This field indicating the success or failure of the registration. This
option is always host initiated. option is always host initiated.
skipping to change at page 11, line 17 skipping to change at page 11, line 33
The sender of the NS also includes the EUI-64 of the interface it is 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 registering an address from. This is used as a unique ID for the
detection of duplicate addresses. It is used to tell the difference detection of duplicate addresses. It is used to tell the difference
between the same node re-registering its address and a different node between the same node re-registering its address and a different node
(with a different EUI-64) registering an address that is already in (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 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 carrying an error Status code to the EUI-64 based link-local IPv6
address of the host. address of the host.
When the ARO is used by hosts an SLLA option MUST be included and the When the ARO is used by hosts and SLLA option MUST be included [
address that is to be registered MUST be the IPv6 source address of except for the point-to-point links (example: IP-in-IP tunnel)] and
the Neighbor Solicitation message. 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
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 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 | | Type | Length = 2 | Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reservd |T| TID | Registration Lifetime | | Reservd |T| TID | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ EUI-64 or equivalent + + EUI-64 or equivalent +
skipping to change at page 13, line 8 skipping to change at page 13, line 24
IPv6 hosts. EAH hosts use this flag in order to discover a NEAR 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. router if it receives multiple RA from both legacy and NEAR routers.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|M|O|H|Prf|P|E|R| |M|O|H|Prf|P|E|R|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
The 'E' bit above MUST be 1 when a IPv6 router implements and The 'E' bit above MUST be 1 when a IPv6 router implements and
configures the efficiency-aware Router behavior for Neighbor configures the efficiency-aware Router behavior for Neighbor
Discovery as per this document. All other cases E bit is 0. 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 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- EAH MUST look for E bit in RA in order to determine the efficiency-
aware support in the default router in the link. aware support in the default router in the link.
7.4. The Transaction Identification(TID) 7.4. The Transaction Identification(TID)
The TID field is used together with age of a registration for The TID field is used together with age of a registration for
arbitration between two routers (default or backbone) to ensure arbitration between two routers (default or backbone) to ensure
freshness and ownership of the registration of a given target freshness and ownership of the registration of a given target
skipping to change at page 13, line 30 skipping to change at page 13, line 46
registration are valid. In case of a mismatch between comparable registration are valid. In case of a mismatch between comparable
TIDs, the most recent TID wins. The TID definition used in section 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 6.4.1 of RFC 6550 for DAOSequence number would be applicable for here
for TID in ARO message. for TID in ARO message.
It is 8 bit field. TID is generated by the host at the time of a new It is 8 bit field. TID is generated by the host at the time of a new
registraton request. registraton request.
This document assumes that an implementation will have configuration This document assumes that an implementation will have configuration
knobs to determine whether it is running in classical IPv6 ND [ND] or knobs to determine whether it is running in classical IPv6 ND [ND] or
Optimized Energy Aware ND (this document) mode or both(Mixed mode). Efficiency Aware ND (this document) mode or both(Mixed mode).
8. Efficiency-aware Neighbor Discovery Messages 8. Efficiency-aware Neighbor Discovery Messages
Router Advertisement(RA): Periodic RAs SHOULD be avoided. Only Router Advertisement(RA): Periodic RAs SHOULD be avoided. Only
solicited RAs are RECOMMENDED. An RA MUST solicited RAs are RECOMMENDED. An RA MUST
contain the Source Link-layer Address option contain the Source Link-layer Address option
containing Router's link-layer address (this containing Router's link-layer address (this
is optional in [ND]. An RA MUST carry Prefix is optional in [ND]. An RA MUST carry Prefix
information option with L bit being unset, so information option with L bit being unset, so
that hosts do not multicast any NS messages that hosts do not multicast any NS messages
skipping to change at page 14, line 12 skipping to change at page 14, line 31
This is possible since the RS always includes This is possible since the RS always includes
a SLLA option, which is used by the router to a SLLA option, which is used by the router to
unicast the RA. unicast the RA.
Router Solicitation(RS): Upon system startup, the node sends a Router Solicitation(RS): Upon system startup, the node sends a
multicast or link broadcast (when multicast multicast or link broadcast (when multicast
is not supported at the link-layer) RS to is not supported at the link-layer) RS to
find out the available routers in the link. find out the available routers in the link.
An RS may be sent at other times as described An RS may be sent at other times as described
in section 6.3.7 of RFC 4861. A Router in section 6.3.7 of RFC 4861. A Router
Solicitation MUST carry Source Link-layer Solicitation MUST carry Source Link-layer
Address option. Since no periodic RAs are Address option except for the point-to-point
allowed in the efficiency-aware IPv6 network, links. Since no periodic RAs are allowed in
the host may send periodic unicast RS to the the efficiency-aware IPv6 network, the host
routers. The time-periods for the RS varies may send periodic unicast RS to the routers.
on the deployment scenarios and the Default The time-periods for the RS varies on the
Router Lifetime advertised in the RAs. 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]. Default Router Selection: Same as in section 6.3.6 of RFC 4861[ND].
Neighbor Solicitation (NS): Neighbor solicitation is used between Neighbor Solicitation (NS): Neighbor solicitation is used between
the hosts and the default-router as part of the hosts and the default-router as part of
NUD and registering the host's address(es). NUD and registering the host's address(es).
An NS message MUST use the Address An NS message MUST use the Address
Registration option in order to accomplish Registration option in order to accomplish
the registration. the registration.
Neighbor Advertisement (NA): As defined in [ND] and ARO option. Neighbor Advertisement (NA): As defined in [ND] and ARO option.
Redirect Messages: A router SHOULD NOT send a Redirect message Redirect Messages: A router SHOULD NOT send a Redirect message
to a host since the link has non-transitive to a host since the link has non-transitive
skipping to change at page 15, line 32 skipping to change at page 16, line 4
A host always sends packets to (one of) its default router(s). This 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 is accomplished by the routers never setting the 'L' flag in the
Prefix options. Prefix options.
The host is unable to forward routes or participate in a routing The host is unable to forward routes or participate in a routing
protocol. A legacy IPv6 Host compliant EAH SHOULD be able to fall 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 back to RFC 4861 host behavior if there is no efficiency-aware router
(NEAR) in the link. (NEAR) in the link.
The efficiency-aware host MUST NOT send or accept re-direct messages. The efficiency-aware host MUST NOT send or accept re-direct messages.
It does not join solicited node multicast address. It does not join solicited node multicast address.
If the EAH is capable of generating TID and configured for this If the EAH is capable of generating TID and configured for this
operation, the EAH MUST use the TID field and appropriate associated operation, the EAH MUST use the TID field and appropriate associated
operation bits in the ARO message during registration and refresh. operation bits in the ARO message during registration and refresh.
10. The Energy Aware Default Router (NEAR) Behavior 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 The main purpose of the default router in the context of this
document is to receive and process the registration request, forward document is to receive and process the registration request, forward
packets from one neighbor to the other, informs the routing protocol packets from one neighbor to the other, informs the routing protocol
about the un-availability of the registered nodes if the routing about the un-availability of the registered nodes if the routing
protocol requires this information for the purpose of mobility or protocol requires this information for the purpose of mobility or
fast convergence. A default router (NEAR) behavior may be observed fast convergence. A default router (NEAR) behavior may be observed
in one or more interfaces of a Border Router(BR). in one or more interfaces of a Border Router(BR).
A Border Router normally may have multiple interfaces and connects A Border Router normally may have multiple interfaces and connects
skipping to change at page 16, line 34 skipping to change at page 17, line 18
Lifetime expires. If an ARO arrives for an NCE that is in Lifetime expires. If an ARO arrives for an NCE that is in
UNCREACHABLE state, that NCE should be marked as STALE. UNCREACHABLE state, that NCE should be marked as STALE.
A default router keeps a cache for all the nodes' IP addresses, A default router keeps a cache for all the nodes' IP addresses,
created from the Address Registration processing. created from the Address Registration processing.
10.1. Router Configuration Modes 10.1. Router Configuration Modes
An efficiency-aware Router(NEAR) MUST be able to configure in An efficiency-aware Router(NEAR) MUST be able to configure in
efficiency-aware-only mode where it will expect all hosts register efficiency-aware-only mode where it will expect all hosts register
with the router following RS; thus will not support legacy hosts. with the router following RS; thus NEAR will not support legacy
However, it will create legacy NCE for NS messages for other routers hosts. However, it will create legacy NCE for the routers in the
in the network. This mode is able to prevent ND flooding on the network assuming that the routers do not register with it. This mode
link. is able to prevent ND flooding on the link.
An efficiency-aware Router(NEAR) SHOULD be able to have configuration An efficiency-aware Router(NEAR) SHOULD be able to have configuration
knob to configure itself in Mixed-Mode where it will support both knob to configure itself in Mixed-Mode where it will support both
efficiency-aware hosts and legacy hosts. However even in mixed-mode efficiency-aware hosts and legacy hosts. However even in mixed-mode
the router should check for duplicate entries in the NCE before the router should check for duplicate entries in the NCE before
creating a new ones and it should rate-limit creating new NCE based creating a new ones and it should rate-limit creating new NCE based
on requests from the same host MAC address. on requests from the same host MAC address.
The RECOMMENDED default mode of operation for the efficiency-aware The RECOMMENDED default mode of operation for the efficiency-aware
router is Mixed-mode. Though it cannot reap the full benefit of router is Mixed-mode. Though it cannot reap the full benefit of
efficiency related optimization described in this document. efficiency related optimization described in this document.
10.2. Movement Detection 10.2. Movement Detection
When a host moves from one subnet to another its IPv6 prefix changes When a host moves from one subnet to another its IPv6 prefix changes
and the movement detection is determined according to the existing and the movement detection is determined according to the existing
IPv6 movement detection described in [DNA]. IPv6 movement detection described in [DNA].
However, if the movement happens across different default routers in However, if the movement happens across different default routers in
the subnet and the node likes to register with one of the default the subnet and the node likes to register with one of the default
routers closest to its present location, it must send another routers closest to its present location, it MUST send another
registration request to the new default router. The new default registration request to the new default router. The new default
router then first send an NS to its peers with a link scope multicast router then first sends a NS to its peers with a link scope multicast
message to IPv6 address ff02::2 with the ARO option. message to IPv6 address ff02::2 with the ARO option.
10.2.1. Registration ownership 10.2.1. Registration ownership
The subnet-local-routers check their respective NCE table for the The subnet-local-routers check their respective NCE table for the
particular registration. If the registration entry exists, the NEAR particular registration. If the registration entry exists, the NEAR
default router then calculates the 'age' of the registration by default router then calculates the 'age' of the registration by
subtracting the present time from the registration received time subtracting the present time from the registration received time
recorded at the NCE. The NEAR router then responds with a NA with recorded at the NCE. The NEAR router then responds with a NA with
ARO option Status being equal to 3 and replaces the 'registration ARO option Status being equal to 3 and replaces the 'registration
skipping to change at page 21, line 18 skipping to change at page 21, line 46
In mixed mode operation, the Router SHOULD be able to do local In mixed mode operation, the Router SHOULD be able to do local
movement detection based on ARO if it is configured for that movement detection based on ARO if it is configured for that
operation for EAH hosts. For the legacy hosts, the mixed-mode router operation for EAH hosts. For the legacy hosts, the mixed-mode router
MAY follow classical IPv6 methods of movement detection and MAY act MAY follow classical IPv6 methods of movement detection and MAY act
as ND proxy by sending NA with 'O' bit.[ Reference??] as ND proxy by sending NA with 'O' bit.[ Reference??]
The routers that are running on efficiency-aware mode or legacy mode The routers that are running on efficiency-aware mode or legacy mode
SHOULD NOT dynamically switch the mode without flushing the Neighbor SHOULD NOT dynamically switch the mode without flushing the Neighbor
Cache Entries. Cache Entries.
In mixed mode, the NEAR SHOULD have a configurable interval for
periodic unsolicited router advertisements based on the media type.
13. Bootstrapping 13. Bootstrapping
If the network is a efficiency-aware IPv6 subnet, and the efficiency- The bootstrapping mechanism described here is applicable for the
aware Neighbor Discovery mechanism is used by the hosts and routers efficiency-aware hosts and routers. At the start, the host uses its
as described in this document. At the start, the node uses its link- link-local address to send Router Solicitation and then it sends the
local address to send Router Solicitation and then it sends the Node Node Registration message as described in this document in order to
Registration message as described in this document in order to form form the address. The Duplicate address detection process should be
the address. The Duplicate address detection process should be
skipped if the network is guaranteed to have unique interface skipped if the network is guaranteed to have unique interface
identifiers which is used to form an IPv6 address. identifiers which is used to form an IPv6 address.
Node Router Node Router
0. |[Forms LL IPv6 addr] | 0. |[Forms LL IPv6 addr] |
1. | ---------- Router Solicitation --------> | 1. | ---------- Router Solicitation --------> |
| [SLLAO] | | [SLLAO] |
skipping to change at page 22, line 41 skipping to change at page 22, line 47
be at least one legacy IPv6 router and another NEAR router present in 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 the link. The legacy IPv6 router will follow RFC 4861 behavior and
NEAR router will follow the efficiency-aware behavior for NEAR router will follow the efficiency-aware behavior for
registration, NCE maintenance, forwarding packets from a EAH and it registration, NCE maintenance, forwarding packets from a EAH and it
will also act as a ND proxy for the legacy IPv6 hosts querying to will also act as a ND proxy for the legacy IPv6 hosts querying to
resolve a EAH node. resolve a EAH node.
A legacy IPv6 host and EAH are not expected to see a difference in A legacy IPv6 host and EAH are not expected to see a difference in
their bootstrapping if both legacy and efficiency-aware their bootstrapping if both legacy and efficiency-aware
functionalities of rotuers are available in the network. It is functionalities of rotuers are available in the network. It is
RECOMMEDED that the EAH implementation SHOULD be able to behave like RECOMMENDED that the EAH implementation SHOULD be able to behave like
a legacy IPv6 host if it discovers that no efficiency-aware routing a legacy IPv6 host if it discovers that no efficiency-aware routing
support is present in the link. support is present in the link.
14. Handling Sleepy Nodes 14. Handling Sleepy Nodes
The solution allows the sleepy nodes to complete its sleep schedule The solution allows the sleepy nodes to complete its sleep schedule
without waking up due to periodic Router Advertisement messages or without waking up due to periodic Router Advertisement messages or
due to Multicast Neighbor Solicitation for address resolution. The due to Multicast Neighbor Solicitation for address resolution. The
node registration lifetime SHOULD be synchronized with its sleep node registration lifetime SHOULD be synchronized with its sleep
interval period in order to avoid waking up in the middle of sleep interval period in order to avoid waking up in the middle of sleep
skipping to change at page 24, line 22 skipping to change at page 24, line 28
17.1. Detecting Network Attachment(DNA) 17.1. Detecting Network Attachment(DNA)
IPv6 DNA[DNA] uses unicast ND probes and link-layer indications to IPv6 DNA[DNA] uses unicast ND probes and link-layer indications to
detect movement of its network attachments. Upon detecting link- detect movement of its network attachments. Upon detecting link-
layer indication, it sends a all-routers Solicitation message. When layer indication, it sends a all-routers Solicitation message. When
the node implements this document along with DNA, it MUST send ARO the node implements this document along with DNA, it MUST send ARO
option with its Neighbor Solicitation unicast message if the option with its Neighbor Solicitation unicast message if the
candidate router advertisement indicates that the router is a NEAR candidate router advertisement indicates that the router is a NEAR
router. If the candiate router is a legacy router then and it is the router. If the candiate router is a legacy router then and it is the
only choice then the EAH host adapt to the legacy behavior. However only choice then the EAH host SHOULD adapt to the legacy behavior.
if EAH node implements DNA host capability as well, then it SHOULD However if EAH node implements DNA host capability as well, then it
give preference to the NEAR routers in its candidate list of routers. SHOULD give preference to the NEAR routers in its candidate list of
routers.
Thus the ND optimization solution will work seamlessly with DNA Thus the ND optimization solution will work seamlessly with DNA
implementations and no change is required in DNA solution because of implementations and no change is required in DNA solution because of
Neighbor Discovery updates. It is a deployment and configuration Neighbor Discovery updates. It is a deployment and configuration
consideration as to run the network in mixed mode or efficient-mode. consideration as to run the network in mixed mode or efficient-mode.
17.2. Proxying for Efficiency-Aware hosts 17.2. Proxying for Efficiency-Aware hosts
The efficient-ND SHOULD continue to support the legacy IPv6 Neighbor The efficient-ND SHOULD continue to support the legacy IPv6 Neighbor
Solicitation requests in the mixed mode. The NEAR router SHOULD act Solicitation requests in the mixed mode. The NEAR router SHOULD act
skipping to change at page 25, line 4 skipping to change at page 25, line 11
option and the Override bit set if the ARO option in the NS indicates 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 either a different node (different EUI-64) or a older registration
(when comparing the TID). (when comparing the TID).
o advertising a registered address over the backbone using NA o advertising a registered address over the backbone using NA
messages, asynchronously or as a response to a Neighbor messages, asynchronously or as a response to a Neighbor
Solicitation messages. Solicitation messages.
o Looking up a destination over the backbone in order to deliver o Looking up a destination over the backbone in order to deliver
packets arriving from the EAH host using Neighbor Solicitation packets arriving from the EAH host using Neighbor Solicitation
messages. messages.
o Forwarding packets from the EAH over the backbone, and the other 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 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 resides on a different link such as an LLN attached to the
backbone. backbone.
Eventually triggering a look up for a destination EAH that would not 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 be registered at a given point of time, or as a verification of a
registration. registration.
17.3. DHCPv6 Interaction 17.3. DHCPv6 Interaction
Co-existence with DHCP: For classical IPv6, if DHCPv6 or central Co-existence with DHCP: For classical IPv6, if DHCPv6 or central
address allocation mechanism is used, then Neighbor Discovery address allocation mechanism is used, then Neighbor Discovery
autoconfiguration is not used for global address allocation. autoconfiguration is not used for global address allocation.
However, link-local duplicate address detection, Neighbor However, link-local duplicate address detection, Neighbor
solicitation, Neighbor unreachability detection are still used. Upon solicitation, Neighbor unreachability detection are still used. Upon
skipping to change at page 26, line 42 skipping to change at page 27, line 4
efficiency-aware mode. See Section 11.1. efficiency-aware mode. See Section 11.1.
21. IANA Considerations 21. IANA Considerations
A new flag (E-bit) in RA has been introduced. IANA assignment of the A new flag (E-bit) in RA has been introduced. IANA assignment of the
E-bit flag is required upon approval of this document. E-bit flag is required upon approval of this document.
22. Changelog 22. Changelog
Changes from draft-chakrabarti-nordmark-energy-aware-nd-02: Changes from draft-chakrabarti-nordmark-energy-aware-nd-02:
o Replaced energy-aware with efficency-aware which covers both
energy efficiency and other operational efficiency
o Added consideration for DNA, ND proxy and clarified that this is
useful for networks with MLD-snooping switches as well
o Added use-cases, Support for Mixed-mode operations and a diagram
for bootstrapping scenario.
o Clarified its applicability when DHCP is used for address o Added clarification that SLLA is not required for ARO in a
allocation. 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 23. Acknowledgements
The primary idea of this document are from 6LoWPAN Neighbor Discovery The primary idea of this document are from 6LoWPAN Neighbor Discovery
document [6LOWPAN-ND] and the discussions from the 6lowpan working document [6LOWPAN-ND] and the discussions from the 6lowpan working
group members, chairs Carsten Bormann and Geoff Mulligan and through group members, chairs Carsten Bormann and Geoff Mulligan and through
our discussions with Zach Shelby, editor of the [6LOWPAN-ND]. our discussions with Zach Shelby, editor of the [6LOWPAN-ND].
The inspiration of such a IPv6 generic document came from Margaret 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 Wasserman who saw a need for such a document at the IOT workshop at
Prague IETF. Prague IETF.
The authors acknowledge the ND denial of service issues and key The authors acknowledge the ND denial of service issues and key
causes mentioned in the draft-halpern-6man-nddos-mitigation document causes mentioned in the draft-halpern-6man-nddos-mitigation document
by Joel Halpern. Thanks to Joel Halpern for pinpointing the problems by Joel Halpern. Thanks to Joel Halpern for pinpointing the problems
that are now addressed in the NCE management section. that are now addressed in the NCE management section.
The authors like to thank Dave Thaler, Jari Arkko, Ylva Jading, The authors like to thank Dave Thaler, Stuart Cheshire, Jari Arkko,
Niklas J. Johnsson, Reda Nedjar, Purvi Shah, Jaume Rius Riu, Fredrik Ylva Jading, Niklas J. Johnsson, Reda Nedjar, Purvi Shah, Jaume Rius
Garneij for their useful comments on this work. 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. References
24.1. Normative References 24.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
skipping to change at page 29, line 10 skipping to change at page 29, line 18
October 2003. October 2003.
[PD] Miwakawya, S., "Requirements for Prefix Delegation", [PD] Miwakawya, S., "Requirements for Prefix Delegation",
RFC 3769, June 2004. RFC 3769, June 2004.
[RF] Haberman, B. and B. Hinden, "IPv6 Router Advertisement [RF] Haberman, B. and B. Hinden, "IPv6 Router Advertisement
Flags option", RFC 5175, March 2008. Flags option", RFC 5175, March 2008.
[ULA] "Unique Local IPv6 Addresses", RFC 4193. [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 [IPV6M] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011. in IPv6", RFC 6275, July 2011.
Appendix A. Usecase Analysis Appendix A. Usecase Analysis
This section provides applicability scenarios where the efficiency- This section provides applicability scenarios where the efficiency-
aware Neighbor Discovery will be most beneficial. 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 A.1. Data Center Routers on the link
Efficiency-aware Routers and hosts are useful in IPv6 networks in the Efficiency-aware Routers and hosts are useful in IPv6 networks in the
Data Center as they produce less signaling and also provides ways to Data Center as they produce less signaling and also provides ways to
minimize the ND flood of messages. Moreover, this mechanism will minimize the ND flood of messages. Moreover, this mechanism will
work with data-center nodes which are deliberately in sleep mode for work with data-center nodes which are deliberately in sleep mode for
saving energy. saving energy.
This solution will work well in Data Center Virtual network and VM This solution will work well in Data Center Virtual network and VM
skipping to change at page 30, line 27 skipping to change at page 30, line 43
bandwidth for hundreds of unicast packets. bandwidth for hundreds of unicast packets.
The Wi-fi IPv6 hosts can act as efficiency-aware hosts and register The Wi-fi IPv6 hosts can act as efficiency-aware hosts and register
with their nearest default router with NEAR behavior. This method with their nearest default router with NEAR behavior. This method
reduces multicast operations in the wireless access points or routers reduces multicast operations in the wireless access points or routers
by using this optimization. by using this optimization.
A.5. 3GPP Networks A.5. 3GPP Networks
Section 9.2.1.1 of TS23.060 allows periodic RA and TS 123.401 stays Section 9.2.1.1 of TS23.060 allows periodic RA and TS 123.401 stays
silent about periodic RA. Though the informational drafts and silent about periodic RA while 3GPP TS29.061 recommends large values
RFC6459 about 3GPP systems IPv6 behavior provides best practices, for minimum and maximum periodic router advertisements for reduced
this document provides standard based optimization that 3GPP systems periodic mesages. Though RFC6459 describes best practices about IPv6
can follow to improve efficiency in the mobile nodes and 3GPP 3GPP systems behavior, this ND optimization standard specification
Routers. 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.
A.6. Industrial Networks A.6. Industrial Networks
RPL [RFC6550] is used for Industrial wireless 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 Authors' Addresses
Samita Chakrabarti Samita Chakrabarti
Ericsson Ericsson
San Jose, CA San Jose, CA
USA USA
Email: samita.chakrabarti@ericsson.com Email: samita.chakrabarti@ericsson.com
Erik Nordmark Erik Nordmark
Cisco Systems
San Jose, CA San Jose, CA
USA USA
Email: nordmark@cisco.com Email: nordmark@sonic.net
Pascal Thubert Pascal Thubert
Cisco Systems Cisco Systems
Email: pthubert@cisco.com Email: pthubert@cisco.com
Margaret Wasserman Margaret Wasserman
Painless Security Painless Security
Email: mrw@lilacglade.org Email: mrw@lilacglade.org
 End of changes. 62 change blocks. 
163 lines changed or deleted 222 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/