< draft-chakrabarti-nordmark-6man-efficient-nd-04.txt   draft-chakrabarti-nordmark-6man-efficient-nd-05.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 Arista Networks Intended status: Standards Track Arista Networks
Expires: April 25, 2014 P. Thubert Expires: August 18, 2014 P. Thubert
Cisco Systems Cisco Systems
M. Wasserman M. Wasserman
Painless Security Painless Security
October 22, 2013 February 14, 2014
Wired and Wireless IPv6 Neighbor Discovery Optimizations IPv6 Neighbor Discovery Optimizations for Wired and Wireless Networks
draft-chakrabarti-nordmark-6man-efficient-nd-04 draft-chakrabarti-nordmark-6man-efficient-nd-05
Abstract Abstract
IPv6 Neighbor Discovery (RFC 4861) protocol has been designed for IPv6 Neighbor Discovery (RFC 4861 going back to RFC 1970) was defined
neighbor's address resolution, unreachability detection, address at a time when link-local multicast was as reliable and with the same
autoconfiguration, router advertisement and solicitation. With the network cost (send a packet on a yellow-coax Ethernet) as unicast and
progress of Internet adoption on various industries including home, where the hosts were assumed to be always on and connected.
wireless, M2M and cellular networks there is a desire for optimizing
the legacy IPv6 Neighbor Discovery protocol. This document describes Since 1996 we've seen a significant change with both an introduction
a method of optimization by reducing multicast messages and of wireless networks and battery operated devices, which poses
introducing an IPv6 address Registration mechanism. The optimization significant challenges for the old assumptions. We are also seeing
of IPv6 Neighbor Discovery protocol is useful for Wirless and low- datacenter networks where virtual machines are not always on and
power IPv6 networks and as well as Data Centers and Home Networks. connected, and scaling of multicast can be challenging.
The solution is capable of handling existing legacy IPv6 nodes in the
network with local mobility. This specification contains extensions to IPv6 Neighbor Discovery
which remove most use of multicast and make sleeping hosts more
efficient. The specification includes a default mixed mode where a
link can have an arbitrary mix of hosts and/or routers - some
implementing legacy Neighbor Discovery and some implementing the
optimizations in this specification. The optimizations provide
incremental benefits to hosts as soon as the first updated routers
are deployed on a link.
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 April 25, 2014. This Internet-Draft will expire on August 18, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Problem Areas . . . . . . . . . . . . . . . . . . . . . . 4 2. Goals and Requirements . . . . . . . . . . . . . . . . . . . . 6
1.2. Overview of the basic ND Optimization . . . . . . . . . . 5 2.1. Mixed-Mode Operations . . . . . . . . . . . . . . . . . . 7
2. Definition Of Terms . . . . . . . . . . . . . . . . . . . . . 6 3. Changes to ND state management . . . . . . . . . . . . . . . . 7
3. Assumptions for efficiency-aware Neighbor Discovery . . . . . 8 4. Definition Of Terms . . . . . . . . . . . . . . . . . . . . . 7
4. The set of Requirements for efficiency and optimization . . . 8 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9
5. Basic Operations . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Proxying to handle Mixed mode . . . . . . . . . . . . . . 11
6. Applicability Statement . . . . . . . . . . . . . . . . . . . 10 6. New Neighbor Discovery Options and Messages . . . . . . . . . 11
7. New Neighbor Discovery Options and Messages . . . . . . . . . 10 6.1. Router Advertisement flag for NEARs . . . . . . . . . . . 11
7.1. Address Registration Option . . . . . . . . . . . . . . . 10 6.2. Address Registration Option (ARO) . . . . . . . . . . . . 12
7.2. Refresh and De-registration . . . . . . . . . . . . . . . 12 6.3. Registrar Address Option (RAO) . . . . . . . . . . . . . . 14
7.3. A New Router Advertisement Flag . . . . . . . . . . . . . 13 7. Conceptual Data Structures . . . . . . . . . . . . . . . . . . 15
7.4. The Transaction Identification(TID) . . . . . . . . . . . 13 8. Host Behavior . . . . . . . . . . . . . . . . . . . . . . . . 16
8. Efficiency-aware Neighbor Discovery Messages . . . . . . . . . 14 8.1. Host and/or Interface Initialization . . . . . . . . . . . 16
9. Efficiency-aware Host Behavior . . . . . . . . . . . . . . . . 15 8.2. Host Receiving Router Advertisements . . . . . . . . . . . 16
10. The Efficiency Aware Default Router (NEAR) Behavior . . . . . 16 8.3. Timing out Registrar List entries . . . . . . . . . . . . 17
10.1. Router Configuration Modes . . . . . . . . . . . . . . . . 17 8.4. Sending AROs . . . . . . . . . . . . . . . . . . . . . . . 17
10.2. Movement Detection . . . . . . . . . . . . . . . . . . . . 17 8.5. Receiving Neighbor Advertisements . . . . . . . . . . . . 18
10.2.1. Registration ownership . . . . . . . . . . . . . . . 18 8.6. Host Management of the TID . . . . . . . . . . . . . . . . 18
11. NCE Management in efficiency-aware Routers . . . . . . . . . . 18 8.7. Refreshing a Registration . . . . . . . . . . . . . . . . 18
11.1. Handling ND DOS Attack . . . . . . . . . . . . . . . . . . 20 8.8. De-registering . . . . . . . . . . . . . . . . . . . . . . 19
12. Mixed-Mode Operations . . . . . . . . . . . . . . . . . . . . 21 8.9. Refreshing RA information . . . . . . . . . . . . . . . . 19
13. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . . 22 8.10. Sleep and Wakeup . . . . . . . . . . . . . . . . . . . . . 21
14. Handling Sleepy Nodes . . . . . . . . . . . . . . . . . . . . 23 8.11. Receiving Redirects . . . . . . . . . . . . . . . . . . . 21
15. Duplicate Address Detection . . . . . . . . . . . . . . . . . 23 8.12. Movement Detection . . . . . . . . . . . . . . . . . . . . 21
16. Mobility Considerations . . . . . . . . . . . . . . . . . . . 24 9. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 21
17. Other Considerations . . . . . . . . . . . . . . . . . . . . . 24 9.1. Router and/or Interface Initialization . . . . . . . . . . 21
17.1. Detecting Network Attachment(DNA) . . . . . . . . . . . . 24 9.2. Receiving Router Solicitations . . . . . . . . . . . . . . 22
17.2. Proxying for Efficiency-Aware hosts . . . . . . . . . . . 25 9.3. Periodic Multicast RA for legacy hosts . . . . . . . . . . 22
17.3. DHCPv6 Interaction . . . . . . . . . . . . . . . . . . . . 25 9.4. Multicast RA when new information . . . . . . . . . . . . 22
18. VRRP Interaction . . . . . . . . . . . . . . . . . . . . . . . 26 9.5. Receiving ARO . . . . . . . . . . . . . . . . . . . . . . 23
19. RPL Implications . . . . . . . . . . . . . . . . . . . . . . . 26 9.6. NCE Management in NEARs . . . . . . . . . . . . . . . . . 23
20. Updated Neighbor Discovery Constants . . . . . . . . . . . . . 26 9.7. Sending non-zero status in ARO . . . . . . . . . . . . . . 24
21. Security Considerations . . . . . . . . . . . . . . . . . . . 27 9.8. Timing out Registered NCEs . . . . . . . . . . . . . . . . 24
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 9.9. Router Advertisement Consistency . . . . . . . . . . . . . 25
23. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 27 9.10. Sending Redirects . . . . . . . . . . . . . . . . . . . . 25
24. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 9.11. Providing Information to Routing Protocols . . . . . . . . 25
25. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 9.12. Creating Legacy NCEs . . . . . . . . . . . . . . . . . . . 25
25.1. Normative References . . . . . . . . . . . . . . . . . . . 28 9.13. Proxy Address Resolution and DAD for Legacy Hosts . . . . 25
25.2. Informative References . . . . . . . . . . . . . . . . . . 28 10. Handling ND DoS Attack . . . . . . . . . . . . . . . . . . . . 26
Appendix A. Usecase Analysis . . . . . . . . . . . . . . . . . . 30 11. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . . 27
A.1. Data Center Routers on the link . . . . . . . . . . . . . 30 12. Interaction with other protocols . . . . . . . . . . . . . . . 27
A.2. Edge Routers and Home Networks . . . . . . . . . . . . . . 30 12.1. Detecting Network Attachment (DNA) . . . . . . . . . . . . 28
A.3. M2M Networks . . . . . . . . . . . . . . . . . . . . . . . 30 12.2. DHCPv6 Interaction . . . . . . . . . . . . . . . . . . . . 28
A.4. Wi-fi Networks . . . . . . . . . . . . . . . . . . . . . . 31 12.3. Other use of Multicast . . . . . . . . . . . . . . . . . . 28
A.5. 3GPP Networks . . . . . . . . . . . . . . . . . . . . . . 31 12.4. VRRP Interaction . . . . . . . . . . . . . . . . . . . . . 28
A.6. Industrial Networks . . . . . . . . . . . . . . . . . . . 31
A.7. Set and forget offline network . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
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 13. Updated Neighbor Discovery Constants . . . . . . . . . . . . . 29
switches, routers and security middle boxes) host IPv6 State 14. Security Considerations . . . . . . . . . . . . . . . . . . . 29
Maintaining Entities (SMEs) holding information such as the location 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
of an IPv6 address or its mapping with a MAC address. Such 16. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 30
intermediate devices include Wireless Controllers that terminate a 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
overlay tunnel and rapidly re-enable reachability for mobile 18. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 31
devices(L2/L3), Network edge devices performing subscriber access, 19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
network devices that protect the ownership of an IPv6 address, 19.1. Normative References . . . . . . . . . . . . . . . . . . . 32
Overlay networks in data centers, Home Networks for IPv6 clients. 19.2. Informative References . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
In general, there is a need for enhancing the IPv6 ND [ND] to make it 1. Introduction
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 IPv6 Neighbor Discovery [RFC4861] was defined at a time when local
area networks had different properties than today. A common link was
the yellow-coax shared wire Ethernet, where a link-layer multicast
and unicast worked the same - send the packet on the wire and the
interested receivers will pick it up. Thus the network cost
(ignoring any processing cost on the receivers that might not
completely filter out Ethernet multicast addresses that they did not
want) and the reliability of sending a link-layer unicast and
multicast was the same. Furthermore, the hosts at the time was
always on and connected. Powering on and off the workstation/PC
hosts at the time was slow and disruptive process.
Specifically, the following are the issues with the IPv6 deployment Under the above assumptions it was quite efficient to maintain the
in many wireless and high-density IPv6 subnets today: shared state of the link such as the prefixes and their lifetimes
o The periodic RA messages in IPv6 ND [ND], and NS/NA messages using periodic multicast Router Advertisement messages. It was also
require all IPv6 nodes in the link to be in listening mode even efficient to use multicast Neighbor Solicitations for address
when they are in idle cycle. It requires energy for the sleepy resolution as a slight improvement over the broadcast use in ARP.
nodes which may otherwise be sleeping during the idle period. And finally, checking for a potential duplicate IPv6 address using
Non-sleepy nodes also spends more energy since they are in broadcast was efficient and natural.
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.
o In a datacenter, where VM mobility and VM address reslution also Since then we've seen a tremedous change with the wide-spread
trigger storms of IPv6 ND multicast messages, which become a major deployment of WiFi and other wireless network technologies. WiFi is
hassle as the number of VM may scale to the tens of thousands in a a case in point in that it provides the same network service
large Data Center. At the IETF, a WG discusses such problems with abstraction as Ethernet and is often bridged with Ethernets, meaning
Address Resolution in Massive Datacenters (ARMD). that the Neighbor Discovery software on hosts and routers might be
unaware that WiFi is being used. Yet the performance and reliability
of multicast is quite different than for unicast on WiFi (see for
instance [I-D.vyncke-6man-mcast-not-efficient]). Similarly 3GPP and
M2M networks and devices will benefit from a standard specification
for optimized Neighbor discovery. Even wired networks have evolved
substantially with modern switch fabrics using explicit packet
replication logic to handle multicast packets.
The following paragraph elaborates the source of all the multicast The hosts and usage patterns has undergone radical changes as well.
messages in IPv6 ND. Hosts go to sleep when not in use to save on battery power [RFC6574]
or to be more energy efficient even with mains power. The
expectation is that waking up doesn't take much time and power
otherwise the benefits of sleeping are greatly reduced. Initially
sleeping hosts were esoteric sensor nodes, but this sleeping hosts
have become mainstream in smartphones.
Following power-on and initialization of the network in IPv6 Ethernet Some of the above trends were observed early (e.g., Ohta-san
networks, a node joins the solicited-node multicast address on the commented on Neighbor Discovery being inefficient on WiFi a long time
interface and then performs duplicate address detection (DAD) for the back) but the issues were not broadly understood. The issues were
acquired link-local address by sending a solicited-node multicast raised in the 6LowPAN context where the desire was to run IPv6 over
message to the link. After that it sends multicast router low-power radio networks and battery operated devices. That lead to
solicitation (RS) messages to the all-router address to solicit defining a set of optimizations [RFC6775] for that specific category
router advertisements. Once the host receives a valid router of links. However, the trends are not limited to such specific link
advertisement (RA) with the "A" flag, it autoconfigures the IPv6 types.
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 This document applies what we have learned from 6LowPAN to all link
types, by reusing existing support from base Neighbor Discovery (such
as Redirect) and from 6LowPAN (Address Registration Option) and
adding pieces to import the robustness with redundant routers.
In a nutshell, the following basic optimizations are made from the The optimizations are done in a way to provide incremental benefits.
original IPv6 Neighbor Discovery protocol [ND]: As soon as there is at least one router on a link which supports
o Adds Node Registration at the default subnet-router these optimizations, then the updated hosts on the link can sleep
o Introduces a EUI-64 identifier for identification during better.
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, 2. Goals and Requirements
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 The goal is to remove as much Neighbor Discovery multicast traffic on
total number of related signaling messages without losing generality the link as possible, and handle Duplicate Address Detection (DAD)
of Neighbor Discovery, autoconfiguration and reliable host-router without requiring the hosts to always be awake.
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 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 problems that will be addresses are:
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 Remove the use of multicast for DAD and Address Resolution (no
all the hosts and routers on a link implement the new mechanisms, multicast NS messages), and remove periodic multicast RAs. Some
which gives the maximum benefits. In another case the link has a multicast RS and RA are needed to handle the arrival of new hosts
mixture of new hosts and/or routers and legacy [RFC4861] hosts and and routers on the link since they need to bootstrap to find each
routers, operating in a mixed-mode providing some of the benefits. other.
In the following sections the document describes the basic operations Remove the need for hosts to always be awake to defend their
of registration methods, optimization of Neighbor Discovery messages, addresses by responding to any DAD probes.
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 Ensure that the protocol is robust against single points of
failure and uses soft state which is automatically rebuilt after a
state loss.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", A router which does not support legacy hosts will always maintain
a complete set of Neighbor Cache Entries (NCEs) for all hosts on
the link. Hence there is no need for it to send Neighbor
Solicitations. Thus it can avoid the problem specified in
[RFC6583].
The optimized solution SHOULD be independent of the addresses
allocation mechanism. In addition to supporting SLAAC [RFC4862]
and DHCPv6 [RFC3315] it SHOULD also work with hosts with 'Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6'[RFC4941] and with stable IPv6 private addresses
[I-D.ietf-6man-stable-privacy-addresses].
2.1. Mixed-Mode Operations
Mixed-Mode operation is the protocol behavior when the IPv6 subnet is
composed of legacy IPv6 Neighbor Discovery compliant nodes and
efficiency-aware IPv6 nodes implementing this specification.
The mixed-mode model SHOULD support arbitrary combinations of legacy
[RFC4861] hosts and/or routers with new hosts and/or routers on a
link. The introduction of one new router SHOULD provide improved
services to a new host, allowing the new host to avoid multicast and
not requring the host to be awake to defend its IPv6 addresses using
DAD.
This document assumes that an implementation will have configuration
knobs to determine whether it is running in legacy IPv6 ND [RFC4861]
or Efficiency Aware only mode (no-legacy mode) or both (Mixed mode).
3. Changes to ND state management
These optimizations change some fundamental aspects of Neighbor
Discovery. Firstly, it moves the distributed address resolution
state (each node responding to a multicast NS for its own addresses)
to a set of routers which maintain a list of Address Registrations
for the hosts. Secondly, the information distributed in Router
Advertisements changes from being periodically flooded by the routers
to explicit requests from the hosts for refreshed information using
Router Solicitations.
4. Definition Of Terms
The keywords "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: IPv6 ND-efficiency-aware Router (NEAR):
A wireless link determined by one IPv6 off-link prefix in a A router that implements the optimizations specified in this
network where in order to reach a destination with same prefix a document. This router should be able to handle both legacy IPv6
packet may have to travel through one or more 'intermediate' nodes and nodes that sends registration request.
routers which relay the packet to the next 'intermediate' router
or the host in its own. Efficiency-Aware Host (EAH):
Border Router(BR): The EAH is the host which implements the host functionality for
A border router is typically located at the junction of Internet optimized Neighbor Discovery mentioned in this document. At least
and Home Network. An IPv6 router with one interface connected to initially implementations are likely to have a fallback to legacy
an IPv6 subnet and other interface connecting to a non-classic Neighbor Discovery when no NEAR is on the link.
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: Legacy IPv6 Host:
A host in a IPv6 network is considered a IPv6 node without routing A IPv6 host that implements [RFC4861] without the extensions in
and forwarding capability and implements RFC 4861 host functions. this dociument.
Legacy IPv6 Router: Legacy IPv6 Router:
An IPv6 Router which implements RFC 4861 Neighbor Discovery A IPv6 router that implements [RFC4861] without the extensions in
protocols. this dociument.
Mixed mode
A NEAR supports both legacy hosts and EAH, with a configuration
knob to disable the support for legacy hosts. Some routers on the
link can be legacy and some can be NEAR.
No-legacy mode
A mode configured on a NEAR to not support any legacy [RFC4861]
hosts or routers. Opposite of mixed mode.
IPv6 Address Registrar
Normally the default router(s) on the link will act as IPv6
Address Registrars tracking all the EAHs. But in some cases it is
more efficient to use a different set of routers as Address
Registrars. The hosts are informed of the address registrars
using router advertisement messages, and register with the
available registrars.
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. The protocol supports EUI-64 for compatibility with
LLN: [RFC6775].
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 DUID
It is a DHCP Unique ID of a device [RFC3315]. The DUID is assumed
to be stable in a given IPv6 subnet. A device which does not have
an EUI-64 can form and use a DUID in its address registrations.
o The efficiency-aware nodes in the network carry unique interface NCE
ID in the network in order to form the auto-configured IPv6 Neighbor Cache Entry. It is a conceptual data structure
address uniquely. An EUI-64 interface ID required for global introduced in section 5.1 of [RFC4861] and further elaborated in
communication. [RFC6775].
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 TID
The Transaction ID is a device generated sequence number used for
registration. This number is used to allow a host to have
concurrent registrations with different routers, while also being
able to robustly replace a registration with a new one. It
facilitates interoperation with protocols like RPL [RFC6550] which
use a TID internally to handle host movement.
o Node Registration: Node initiated Registration and address 5. Protocol Overview
allocation is done in order to avoid periodic multicast Router
Advertisement messages and often Neighbor Address resolution can
be skipped as all packets go via the default router which now
knows about all the registered nodes. Node Registration enables
reduction of all-node and solicited-node multicast messages in the
subnet.
o Address allocation of registered nodes [ND] are performed using In a nutshell, the following basic optimizations are made from the
IPv6 Autoconfiguration [AUTOCONF]. original IPv6 Neighbor Discovery protocol [RFC4861]:
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 o Adds Node Registration with the default router(s).
In the efficient-nd IPv6 Network, the NEAR routers are the default o Address Resolution and DAD uses the registered addresses instead
routers for the efficiency-aware hosts (EAH). During the startup or of multicast Neighbor Solicitation messages for non-link-local
joining the network the host does not wait for the Router IPv6 addresses.
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 o Does not require unsolicited periodic Router Advertisements.
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
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 o Supports mixed-mode operation where legacy IPv6 hosts and routers
and NEARs and EAHs can co-exist on the same link. This support
can be configured off.
This document aims to guide implementers to choose an appropriate When a host powers on it behaves conforms to legacy ND [RFC4861] by
IPv6 neighbor discovery and Address configuration procedures suitable multicasting up to MAX_RTR_SOLICITATIONS Router Solicitations and
for any efficient IPv6 network. These optimizations are equally receives Router Advertisements. The additional information in the
useful for the energy-sensitive, non-multicast links and for Router Advertisements by the NEARs is used by the EAH to build a list
classical IPv6 networks i.e. home networks, Data-Center IPv6 overlay of IPv6 Address Registrars. As the host is forming its IPv6
networks where saving Neighbor Discovery messages will reduce cost addresses (using any of the many statless and stateful IPv6 address
and increase bandwidth availability. allocation mechanism) then, instead of using a multicast DAD message,
it unicasts an Neighbor Solicitation with the new Address
Registration Option (ARO) to the Registrars. Assuming an IPv6
addresses are not duplicate the EAH receives a Neighbor Advertisement
with the ARO option from the NEARs. The EAH refreshes the registered
addresses before they expire, thereby removing the need for the EAH
to be awake to defend its addresses using DAD as specified in
[RFC4862] as the NEARs will handle DAD.
The address registration mechanism and associated extension to the The routers on the link advertise the prefixes without setting the L
Neighbor Discovery protocol allow a low-power host to move between flag. Thus only the IPv6 link-local addresses are considered on-
the LLN and the classic IPv6 networks as well as movement from one link. Thus the hosts will send packets to a default router, and the
Border Router registration area to another while staying within the default routers maintain all the registrations. Hence a router will
same IPv6 subnet. know the link-layer addresses of all the registered hosts. This
enables the router to forward the packet (without needing any Address
Resolution with the multicast Neighbor Solicitation), and also to
send a Redirect to the originating host informing the host of the
link-layer address.
Note that the specification allows 'Mixed-mode' operation in the Instead of relying on periodic multicast RAs to refresh the lifetimes
efficiency-aware nodes for backward compatibility and transitioning of prefixes etc, the model in efficiency-aware networks is for the
to a complete efficiency-aware network of hosts and routers. Though hosts to ask for refreshed information by unicasting a Router
the efficiency-aware only nodes will minimize the ND signaling and Solicitation before the information expires.
DOS attacks in the LAN.
Applicability of this solution is limited to the legacy IPv6 nodes The periodic multicast RAs are also used to provide new information
and subnets and it optimizes the generic IPv6 signaling activities at such as additional prefixes, radical reduction in the preferred
network layer. However, further optimization at the application and/or valid lifetime for a prefix. A host does not know to ask for
layers are possible for increased efficiency based on particular use- such information. Thus a router that wishes to quickly disseminate
cases and applications. such change can resort to a few multicast RAs, or wait for the hosts
to request a refresh using a Router Solicitation.
7. New Neighbor Discovery Options and Messages The routers can crash and loose all their state, including the
Address Registrations. On router initialization the router will
multicast a few initial RAs. The protocol has a Router Epoch
mechanism which is used by the hosts to detect that the router has
lost state. In that case the hosts will immediately re-register
allowing the router to quickly rebuild its Address Registration
state.
This section will discuss the registration and de-registration Normally it is sufficient for the hosts to register with all the
procedure of the hosts in the network. default routers on the link. However, in some cases such as
simplistic VRRP deployment the hosts should register with all the
VRRP routers even though they only know of one virtual router IPv6
address. And in other cases it would be more efficient to only
register with one router even though there are multiple default
routers. The RAs can contain a Registrar Address Option to
explicitly tell the hosts where to register.
7.1. Address Registration Option 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 before the registration lifetime expiration. The
recommended procedure on wakeup is to unicast a Neighbor Solicitation
to the default router(s), which serves as DNA check [RFC6059] that
the host is on the same link, performs NUD against the router, and
includes the Address Registration Option to refresh the registration.
The Address Registration Option(ARO) is useful for avoiding Duplicate 5.1. Proxying to handle Mixed mode
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.
The routers keep track of host IP addresses that are directly When there are one or more legacy routers on the link then the
reachable and their corresponding link-layer addresses. This is recommendation is to configure those to advertise the prefixes with
useful for lossy and lowpower networks(LLN) and as well as wired IPv6 L=0 just as the NEARs. That results in the hosts sending all packets
networks. An Address Registration Option (ARO) can be included in to a default router unless/until they receive a Redirect. However,
unicast Neighbor Solicitation (NS) messages sent by hosts. Thus it the legacy routers do not maintain the address registrations. Thus
can be included in the unicast NS messages that a host sends as part even though all the hosts send the packets to the routers, the legacy
of Neighbor Unreachability Detection to determine that it can still routers might in turn need to perform Address Resolution by
reach a default router. The ARO is used by the receiving router to multicasting a Neighbor Solicitation per [RFC4861]. In addition,
reliably maintain its Neighbor Cache. The same option is included in legacy hosts and legacy routers will perform DAD as specified in
corresponding Neighbor Advertisement (NA) messages with a Status [RFC4862] that is, by sending a multicast NS and waiting for a NS or
field indicating the success or failure of the registration. This NA which indicates a conflict. A EAH will not receive and respond to
option is always host initiated. such messages.
The ARO is required for reliability and power saving. The lifetime If the NEARs have been configured to operate in mixed-mode, then they
field provides flexibility to the host to register an address which will respond to multicast NS messages from legacy nodes for both DAD
should be usable (the reachability information may be propagated to and Address Resolution. They will respond with the Target Link Layer
the routing protocols) during its intended sleep schedule of nodes Address being that of the registered host, so that subsequent
that switches to frequent sleep mode. communication will not go via the routers. (Implementations of
"Neighbor Discovery Proxies (ND Proxy)" [RFC4389] might proxy using
their own MAC address as TLLA, but that is outside of the scope of
this document.)
The sender of the NS also includes the EUI-64 of the interface it is 6. New Neighbor Discovery Options and Messages
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 [ This specification introduces a new flag in the RAs, reuses and
except for the point-to-point links (example: IP-in-IP tunnel)] and extends the ARO option from [RFC6775] and introduces a new Registrar
the target address for to-be registered node MUST be the IPv6 source Address option.
address of the Neighbor Solicitation message.
Note that a node should be able to register with a default router 6.1. Router Advertisement flag for NEARs
with multiple IPv6 addresses (including privacy addresses).
A new Router Advertisement flag is needed in order to distinguish a
router advertisement sent by a NEAR, which will trigger an EAH to
register with the NEAR. This flag is ignored by the legacy IPv6
hosts.
The current flags field in RA is reproduced here with the added 'E'
bit.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|M|O|H|Prf|P|E|R|
+-+-+-+-+-+-+-+-+
The 'E' bit is set to 1 in a RA sent by a NEAR. In all other cases
the E bit MUST be 0.
6.2. Address Registration Option (ARO)
The Address Registration Option was defined in [RFC6775] for the
purposes of 6LowPAN and this document extends it in a backwards
compatible way by using some of the reserved fields. The extensions
are to handle different unique identifiers than EUI-64 (this document
specifies how to use DHCP Unique Identifiers with the ability do use
other identifier namespaces in the future) and a Transaction Id.
The Unique Interface Identifier is used by the NEARs to distinguish
between a refresh of an existing registration and a different host
trying to register an IPv6 address which is already registered by
some other host. Thus the requirement is that the unique id is
unique per link, but due to the potential for host mobility across
links and subnets it should be globally unique. Both an EUI-64 and a
DUID satisfies that requirement.
The TID is used by the NEARs to handle the case when due to packet
loss one NEAR might have a old registration and another NEAR has a
newer registration. The TID allows them to determine which is more
recent. The TID also facilitates the interaction with RPL.
An Address Registration Option 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 the
default router(s). 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.
When the ARO is sent by a host then, for links which have link-layer
addresses, a SLLA option MUST be included. The address that is
registered is the IPv6 source address of the Neighbor Solicitation
message. Typically a host would have several addresses to register,
with each one being registered using a separate NS containing an ARO.
(This approach facilitates applying SeND [RFC3971].)
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 | Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reservd |T| TID | Registration Lifetime | | Res | IDS |T| TID | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ EUI-64 or equivalent + ~ Unique Interface Identifier (variable length) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields: Fields:
Type: 33 ( See [6LOWPAN-ND] )
Length: 8-bit unsigned integer. The length of the option in Type: 33 [RFC6775]
units of 8 bytes. Always 2.
Length: 8-bit unsigned integer. The length of the option
(including the type and lenth fields) in units of 8
bytes. The value 0 is invalid.
Status: 8-bit unsigned integer. Indicates the status of a Status: 8-bit unsigned integer. Indicates the status of a
registration in the NA response. MUST be set to 0 in registration in the NA response. MUST be set to 0 in
NS messages. See below. NS messages. See [RFC6775].
Reserved: This field is unused. It MUST be initialized to zero
by the sender and MUST be ignored by the receiver. Reserved: 8 bits. This field is unused. It MUST be initialized
to zero by the sender and MUST be ignored by the
receiver.
Res: 4 bits. This field is unused. It MUST be initialized
to zero by the sender and MUST be ignored by the
receiver.
IDS: 3 bits. Identifier name Space. Indicates whether the
Unique Interface Identifier is a DUID or or a IEEE
assigned EUI-64 with room to define additional name
spaces.
T bit: One bit flag. Set if the TID octet is valid.
TID: 8-bit integer. It is a transaction id maintained by TID: 8-bit integer. It is a transaction id maintained by
the host and incremented with each registration. it is the host and used by the NEARs to determine the most
recommended that the node maintains a persistent recent registration.
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 Registration Lifetime: 16-bit unsigned integer. The amount of time
in a unit of 60 seconds that the router should retain in a unit of 60 seconds that the router should retain
the Neighbor Cache entry for the sender of the NS that the Neighbor Cache entry for the sender of the NS that
includes this option. includes this option. A value of zero means to remove
EUI-64: 64 bits. This field is used to uniquely identify the the registration.
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: Unique Interface Identifier: Variable length in multiples of 8
bytes. If the IDS=000, then it is an 8 byte (64 bit)
unmodified EUI-64. If IDS=0011 then it is a variable
length DUID. A DUID MUST be zero padded to a multiple
of 8 bytes.
+--------+--------------------------------------------+ When a node includes ARO option in a Neighbor Solicitation it MUST,
| Status | Description | on links that have link-layer addresses, also include a SLLA option.
+--------+--------------------------------------------+ That option is needed so that the registrar can record the link-layer
| 0 | Success | address on success and send back an error if the address is a
| 1 | Duplicate Address | duplicate.
| 2 | Neighbor Cache Full |
| 3 | Registration Ownership Response |
| 4-255 | Allocated using Standards Action [RFC2434] |
+--------+--------------------------------------------+
Table 1 6.3. Registrar Address Option (RAO)
7.2. Refresh and De-registration Normally the Registrars are the Default Routers. However, there are
cases (like some approaches to handle VRRP, or coordinated separate
routers) where there is a need to have different (and either more or
less) Registrars than Default Routers. Furthermore, to robustly
handle NEAR state state loss this option carries a Router Epoch which
triggers the EAHs to re-register on a router epoch change. The RAO
contains the information for both of those.
A host SHOULD send a Registration message in order to renew its 0 1 2 3
registration before its registration lifetime expires in order to 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
continue its connectivity with the network. If anytime, the node +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
decides that it does not need the default router's service anymore, | Type | Length | Num Addresses |
it MUST send a de-registration message - i,e, a registration message +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
with lifetime being set to zero. A mobile host SHOULD first de- | Reserved | Router Epoch |
register with the default router before it moves away from the +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
subnet. | |
~ IPv6 registratr addresses ~
| (Num Addresses) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Reserved for future extensions ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7.3. A New Router Advertisement Flag Fields:
A new Router Advertisement flag [RF] is needed in order to Type: TBD (IANA)
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 Length: 8-bit unsigned integer. The length of the option
+-+-+-+-+-+-+-+-+ (including the type and lenth fields) in units of 8
|M|O|H|Prf|P|E|R| bytes. The value 0 is invalid.
+-+-+-+-+-+-+-+-+
The 'E' bit above MUST be 1 when a IPv6 router implements and Num Addresses 16-bit unsigned integer. Set to zero if there are no
configures the efficiency-aware Router behavior for Neighbor addresses i.e., when the option is used to only carry
Discovery as per this document. All other cases the E bit MUST be 0. the router epoch. NumAdressses*2 + 1 must not exceed
the Length.
The legacy IPv6 hosts will ignore the E bit in RA advertisement. All Reserved 16-bit unused field. It MUST be initialized to zero
EAH MUST look for E bit in RA in order to determine the efficiency- by the sender and MUST be ignored by the receiver.
aware support in the default router in the link.
7.4. The Transaction Identification(TID) Router epoch 16-bit integer. A router MUST pick a new epoch after
a state loss, either by keeping the epoch in stable
storage and incrementing it, or picking a good random
number.
The TID field is used together with age of a registration for IPv6 registrar addresses Zero or more IPv6 addresses, typically of
arbitration between two routers (default or backbone) to ensure link-local scope.
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 The receiver MUST silently ignore any data after the IPv6 registrar
registraton request. addresses field (such data is present when the Length is greater than
NumAdressses*2 + 1).
This document assumes that an implementation will have configuration The Registrar Addresses have their lifetime be the Default Router
knobs to determine whether it is running in classical IPv6 ND [ND] or Lifetime even when they come from the RAO (thus there is no explicit
Efficiency Aware ND (this document) mode or both(Mixed mode). lifetime in the RAO).
8. Efficiency-aware Neighbor Discovery Messages 7. Conceptual Data Structures
Router Advertisement(RA): Periodic RAs SHOULD be avoided. Only In addition to the Conceptual Data structures in [RFC4861] a EAH
solicited RAs are RECOMMENDED. An RA MUST needs to maintain the new Registrar List for each interface. The
contain the Source Link-layer Address option Registrar List contains the set of IP addresses to which the host
containing Router's link-layer address (this needs to send Address Registrations. Each IP address has a Router
is optional in [ND]. An RA MUST carry Prefix Epoch (used to determine when a router might have lost state). Also,
information option with L bit being unset, so the host MAY use this data structure to track when it needs to
that hosts do not multicast any NS messages refresh its registrations with the registrar.
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.
Same as in RFC 4861[ND] The use of explicit registrations with lifetimes plus the desire to
MTU option: As per the RFC 4861. not multicast Neighbor Solicitation messages for hosts imply that we
Address Resolution: No NS/NA are sent as the prefixes are treated manage the Neighbor Cache entries slightly differently than in
as off-link. Thus no address resolution is [RFC4861]. This results in two different types of NCEs and the types
performed at the hosts. The routers keep specify how those entries can be removed:
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 Legacy: Entries that are subject to the normal rules in
[RFC4861] that allow for garbage collection
when low on memory. Legacy entries are created
only when there is no duplicate NCE. 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 [RFC6775].
A host sends Router Solicitation at the system startup and also when Registered: Entries that have an explicit registered
it suspects that one of its default routers have become lifetime and are kept until this lifetime
unreachable(after NUD fails). The EAH MUST process the E-bit in RA expires or they are explicitly unregistered.
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 Note that the type of the NCE is orthogonal to the states specified
IPv6 prefix obtained from Router Advertisement. The host SHOULD form in [RFC4861]. There can only be one type of NCE for an IP address at
its link-local address from the EUI-64 as specified by IEEE a time.
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 8. Host Behavior
is accomplished by the routers never setting the 'L' flag in the
Prefix options.
The EAH host may register with more than one default routers in a A EAH follows [RFC4861] and applicable parts of [RFC6775] as follows
subnet but it SHOULD use one default primary router for a source IP- in this section./
address at a time.
If an EAH receives a status code 2 in response to its registration A EAH implementation MAY be able to fall back to [RFC4861] host
request from a NEAR router, the node MUST be able to choose another behavior if there is no NEAR on the link.
router to register with (when available).
The host is unable to forward routes or participate in a routing 8.1. Host and/or Interface Initialization
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. A host multicasts Router Solicitation at system startup or interface
It does not join solicited node multicast address. initialization as specified in [RFC4861] and its updates such as
[I-D.ietf-6man-resilient-rs].
If the EAH is capable of generating TID and configured for this Unlike RFC4861 the RS MUST (on link layers which have addresses)
operation, the EAH MUST use the TID field and appropriate associated include a SLLA option, which is used by the router to unicast the RA.
operation bits in the ARO message during registration and refresh.
In some cases, hosts may need to send MAX_RTR_SOLICITATIONS(3) to The host is not required to join the solicited-node multicast
receive the reply back from the default router. In a lossy link or address(es) but it MUST join the all-nodes multicast address.
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 RECOMMENDED
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 8.2. Host Receiving Router Advertisements
solicitation method may be applicable [Resilient-RS].
10. The Efficiency Aware Default Router (NEAR) Behavior The RA is validated and processed as specified in [RFC4861] with
additional behavior for RAO and the Registrar List as follows.
The main purpose of the default router in the context of this When a RA is received without a RAO (but with the E flag set), or the
document is to receive and process the registration request, forward RAO contains no Registrar Addresses, then the IPv6 source address is
packets from one neighbor to the other, informs the routing protocol added/updated in the Registrar List. When a RA is received with a
about the un-availability of the registered nodes if the routing RAO then the IPv6 Registrar Addresses in that option are added/
protocol requires this information for the purpose of mobility or updated in the data structure.
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 If those Registrar List (or entries) already exist and the Router
the nodes in a link like a regular IPv6 subnet(s) or acts as a Epoch in the RAO differs from the Router Epoch in the Registrar List
gateway between separate networks such as Internet and home networks entry, or if the entry does not exist, then the host will initiate
. The Border Router is responsible for distributing one or more /64 sending NS messages with ARO options to the new/updated Registration
prefixes to the nodes to identify a packet belonging to the List entries. Note that if the RA contains no RAO (but the E flag is
particular network. One or more of the interfaces of the Border set) then for the purposes of the epoch comparison one should use a
Router may be connected with the efficiency-aware hosts or a zero Router Epoch.
efficiency-aware router(NEAR).
The efficiency-aware default router MUST not send periodic RA unless However, if the Default Router Lifetime in the RA is zero, then any
it is configured to support both legacy IPv6 and efficiency-aware matching Registration List entry (or entries) are instead deleted
hosts. If the Router is configured for efficiency-aware hosts from the Registration List. It is OPTIONAL for the host to de-
support, it MUST send Router Advertisements with E-bit flag ON and register when an entry is deleted from the Registration List.
MUST NOT set 'L' bit in the advertisements.
The router SHOULD NOT garbage collect Registered Neighbor Cache The host can form its IPv6 address using any available mechanism -
entries since they need to retain them until the Registration SLAAC, DHCPv6, temporary addresses, etc - as the registration
Lifetime expires. If a NEAR receives a NS message from the same host mechanism is orthogonal and independent of the address allocation.
one with ARO and another without ARO then the NS message with ARO The Address Registration procedure replaces the DAD procedure in
gets the precedence and the NS without ARO is ignored. This behavior [RFC4862].
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, 8.3. Timing out Registrar List entries
created from the Address Registration processing.
The NEAR router SHOULD deny registration to a new registration The lifetime for the Registrar List entries are taken from the
request with the status code 2 when it reaches the maximum capacity Default Router Lifetime in the RA. When an entry is removed the host
for handling the neighbor cache. MAY send AROs with a zero Regisration Lifetime to the removed
Registrar Addresses.
10.1. Router Configuration Modes 8.4. Sending AROs
An efficiency-aware Router(NEAR) MUST be able to configure in When a host has formed a new IPv6 address, or when the host learns of
efficiency-aware-only mode where it will expect all hosts register a new NEAR and has existing IPv6 addresses, then it would register
with the router following RS; thus NEAR will not support legacy the new things (could be new addresses to all the existing
hosts. However, it will create legacy NCE for the routers in the Registrars, or the all the IPv6 addresses with the new Registrar.
network assuming that the routers do not register with it. This mode IPv6 link-local addresses are registered as well as the gobals and
is able to prevent ND flooding on the link. ULA.
An efficiency-aware Router(NEAR) SHOULD be able to have configuration If the EAH has a TID then it sets the T-bit and includes the TID in
knob to configure itself in Mixed-Mode where it will support both the ARO. When the host registers its addresses with multiple
efficiency-aware hosts and legacy hosts. However even in mixed-mode Registrars it uses the same TID. However, if the host has moved
the router should check for duplicate entries in the NCE before (lost its network attachment and determines it is attached to a
creating a new ones and it should rate-limit creating new NCE based different link using e.g., DNA [RFC6059]), then it will increment the
on requests from the same host MAC address. TID value and use the new value for subsequent registrations.
The RECOMMENDED default mode of operation for the efficiency-aware The host places its Unique Interface Identifier (whether it is a DUID
router is Mixed-mode. Though it cannot reap the full benefit of or EUI-64) in the ARO. This identifier is typically kept in stable
efficiency related optimization described in this document. storage so that the host can use the same identifier over time. It
MUST use the same identifer when it re-registers its address, since
otherwise all those will be returned as duplicates.
10.2. Movement Detection The NS which includes the ARO option MUST include a SLLA option on
link layers that have link-layer addresses.
The EAH retransmits NS messages with ARO as specified in [RFC6775]
until it receives a NA message from the Registrar containing an ARO.
The number of such retransmissions SHOULD be configurable.
8.5. Receiving Neighbor Advertisements
The Neighbor Advertisement are validated and processed as specified
in [RFC4861] for example to handle Neighbor Unreachability Detection
(NUD). In addition, the host processes any received ARO as follows.
If the ARO has status code 0 (Success), then the host updates the
information in the Registrar List to know when it next needs to
refresh the registered address with this Registrar. No further
processing is needed of the ARO.
If the ARO has status code 1 (Duplicate), then the host can not use
the IPv6 address. The host follows the address allocation protocol
it used to pick a new address - be that DHCPv6, tempororary
addresses, etc.
If the ARO has a status code 2 (Neighbor Cache Full) in response to
its registration request from a Registrar, then the node SHOULD
continue to register the address with other Registrars (when
available).
TBD: What about other not yet defined status code values?
8.6. Host Management of the TID
It is RECOMMENDED that the EAH MAY maintain a sequence counter (TID)
instable storage according to section 7 of [RFC6550]. The TID is
used to resolve conflicts between different registrations issues by
the same host for the same IPv6 address. Conflicts can be due to
different link-layer addresses, but it can also be due to registering
with different NEARs/Registrars and those routers connect use
protocols like RPL for routing, and RPL uses a TID to habdle movement
vs. multi-homing.
Thus the same TID should be used if the host is registering its
addresses with multiple Registrars at the same time. But if the host
might have moved to a different attachment point, then it should
increment its TID for subsequent registrations.
8.7. Refreshing a 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.
This specification does not constrain the implementation. One
possible implementation strategy is to attempt re-register at 1/3rd
of the registration lifetime, and if no response try again at 2/3rd
of the lifetime, etc. Another possible strategy is to wait until the
end of the registration lifetime and then do the same relatively
rapid retransmissions as for the initial registration [RFC6775]. In
all cases the host SHOULD apply a random factor to its re-
registration timeout to avoid self-synchronizing behavior across lots
of hosts. Sleeping hosts would re-register when they are waking up
to do other work.
8.8. De-registering
If anytime, the node decides that it does not need a particular
default router's service anymore, the it SHOULD send a de-
registration message to that NEAR/Registrar. Similarly if the host
stops using a particular IPv6 address, then it SHOULD de-register
that address with all the Registrars it had registered with. This
applies even if the host was using the IPv6 address, then went to
sleep, and then picked a different set of IPv6 addresses. In such a
case it is preferred if the host de-registers before going to sleep.
A mobile host SHOULD first de-register its addresses before it moves
away from the subnet (if the mobile host can know that in advance of
moving.)
De-registration is performed by unicasting a Neighbor Solicitation
with an ARO where the Registration Lifetime is zero to zero. Such an
ARO should have an incremented TID. De-registration AROs are
retransmitted just like other AROs as specified above.
8.9. Refreshing RA information
The EAH is responsible for asking the routers for updates to the
information contained in the Router Advertisements, since the NEARs
will not multicast such updates. That is done by sending unicast RSs
to the router(s) which will result in unicast RAs. However,
significant care is required in determining when the RSs should be
transmitted.
As part of normal operation the Default Routers, Prefixes, and other
RA information have lifetimes, and there are a few common cases:
1. The advertised lifetimes are constant i.e., the routers keep on
advancing the time when the information will expire.
2. The routers decrement the advertised lifetimes in real time i.e.,
the information is set to expire at a determined time and
subsequent RAs have lower and lower lifetimes.
3. The routers forceably expire some information by advertising it
with a zero lifetime for a while, and then stop advertising it.
4. A router crashes or is silently removed from the network and as a
result there are no more updates. For example, that default
router will expire and there is little benefit in trying to
refresh it by sending lots of RSs.
The host's logic for refreshing the information needs to be careful
to not send a large number of RSs, in particular if there is
information that is supposed to expire at a fixed time i.e., the
lifetime decrements in real time.
A host MUST NOT try to refresh information because its lifetime is
near zero, since that would cause unnecessary RSs. Instead the
refresh needs to be based on when the information was most recently
received from the router. A lifetime of 10 minutes that was heard
from the router 10 minutes ago might be normal as part of expiring
some information. But a remaining lifetime of 10 minutes for a
prefix that was last heard 24 hours ago with a lifetime of 24 hours
means that a refresh is in order.
It is RECOMMENDED that the host track the expiry time (the wall clock
time when some information will expire) and when it receives an RA
with that information check whether the expiry time is moving
forward, or appears to be frozen in time. That can tell the
difference between he first two cases above, and avoid unneccesary
RSs as some information naturally expires. Furthermore it is
RECOMMENDED that the host track which information was received from
which router, so that it can see when a router used to provide the
information no longer provides it. That helps to see if the third
case above might be in play. Finally, if a router has not responded
to a few (e.g., MAX_RTR_SOLICITATIONS) attempts to get a refresh,
then the router might be unreachable or dead, and there is little
benefit in sending further RSs to that router. When the router comes
back it will multicast a few RAs.
When the hosts determines that case 1 above is likely, then it should
pick a reasonable time to ask for refreshes. The exact refresh
behavior is not mandated by this specification, but the same
implemention strategies as for refreshing address registrations in
Section 8.7 can be considered.
If the host is unable to refresh the information and as a result ends
up with an empty default router list, or all the default routers are
marked as UNREACHABLE by NUD, then the host MAY switch to sending
initial multicast Router Solicitations as in Section 8.1.
8.10. Sleep and Wakeup
The protocol 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 related 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.
When a host wakes up it can combine movement detecting (DNA), NUD,
and refreshing its Address Registration by sending a unicast NS with
an ARO to its existing default router(s).
8.11. Receiving Redirects
An EAH handles Redirect messages as specified in [RFC4861].
8.12. 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 [RFC6059].
However, if the movement happens across different default routers in 9. Router Behavior
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 A NEAR follows [RFC4861] and applicable parts of [RFC6775] as follows
in this section.
The subnet-local-routers check their respective NCE table for the A NEAR SHOULD support legacy hosts and mixed mode as specified in
particular registration. If the registration entry exists, the NEAR this section by being able to proxy Address Resolution and DAD. The
default router then calculates the 'age' of the registration by NEAR SHOULD implement a knob to be able to disable this behavior.
subtracting the present time from the registration received time That knob can either be set to "mixed-mode" or to "no-legacy-mode".
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 The RECOMMENDED default mode of operation for the NEAR is Mixed-mode.
MAX_REG_AGE_DIFFERENCE 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 A NEAR should be configured to advertise prefixes without the on-link
(L-bit) unset. Furthermore, any legacy routers attached to the same
link as a NEAR should be configured the same way. That reduces the
cases in mixed mode when multicast NS messages are needed between
legacy hosts and routers.
The use of explicit registrations with lifetimes plus the desire to 9.1. Router and/or Interface Initialization
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 A NEAR multicasts some initial Router Advertisements at system
[ND] that allow for garbage collection when low startup or interface initialization as specified in [RFC4861] and its
on memory. Legacy entries are created only updates.
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]. The NEAR MUST join the all-nodes and all-routers multicast addresses.
Registered: Entries that have an explicit registered In mixed mode it MUST also join the solicited-node multicast
lifetime and are kept until this lifetime address(es) for its addresses and also for all the Registered NCEs.
expires or they are explicitly unregistered.
Note that the type of the NCE is orthogonal to the states specified A NEAR picks a new Router Epoch if it has lost the Registered NCEs,
in [ND]. which is typically the case for router initialization. Either the
Router Epoch can be stored in stable storage and incremented on each
router initialization, or the NEAR can pick a good random number on
router initialization. The effect of occasionally picking the same
Router Epoch as before the state loss is that it will take longer for
the router to build up its state of Registered NCEs.
9.2. Receiving Router Solicitations
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 [RFC4861]. An RA
MUST carry any 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 which the
hosts use to distinguish a NEAR from a legacy router.
Unlike [RFC4861] which suggests multicast Router Advertisements, this
specification optimizes the exchange by always unicasting RAs in
response to RSs. This is possible since the RS always includes a
SLLA option, which is used by the router to unicast the RA.
If the NEAR has been configured to send an explicit set of IPv6
Registrar Addresses, or implements a Router Epoch, then the NEAR
includes a RAO in all its RAs.
9.3. Periodic Multicast RA for legacy hosts
The NEAR MUST NOT send periodic RA in no-legacy mode. In mixed mode
the NEAR needs to send periodic multicast RAs as specified in
[RFC4861] to support legacy hosts.
9.4. Multicast RA when new information
When a router has new information to share (new prefixes, prefixes
that should be immediately deprecated, etc) it MAY multicast up to
MAX_INITIAL_RTR_ADVERTISEMENTS number of Router Advertisements. Note
that such new information is not likely to reach sleeping hosts until
those hosts refresh by sending a RS.
9.5. Receiving ARO
The NEAR follows the logic in [RFC6775] for managing the NCEs and
responding to NS messages with the ARO option. The slight
modification is that instead of using an EUI-64 as the key to check
for duplicates, the NEAR uses the IDS value plus the variable length
Unique Interface Identifier value as the key. In addition the NEAR
checks the new TID field as follows.
The TID field is used together with age of a registration for
arbitration between two routers to ensure freshness 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 TIDs are
compared as specified in section 7 of [RFC6550].
9.6. NCE Management in NEARs
When a host interacts with a router by sending Router Solicitations 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 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 NCE is first created. Once a node successfully registers with a
Router the result is a Registered NCE. As Routers send RAs to legacy Router the result is a Registered NCE. As Routers send RAs to legacy
hosts, or receive multicast NS messages from other Routers the result 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 is Legacy NCEs.
at a time.
A Router Solicitation might be received from a host that has not yet 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 registered its address with the router or from a legacy [RFC4861]
the Mixed-mode of operation. host in the Mixed-mode operation.
In the 'Efficiency-aware' only mode the router MUST NOT modify an The router MUST NOT modify an existing Registered Neighbor Cache
existing Neighbor Cache entry based on the SLLA option from the entry based on the SLLA option from the Router Solicitation. Thus, a
Router Solicitation. Thus, a router SHOULD create a tentative Legacy router SHOULD create a tentative Legacy Neighbor Cache entry based on
Neighbor Cache entry based on SLLA option when there is no match with SLLA option when there is no match with the existing NCE. Such a
the existing NCE. Such a legacy Neighbor Cache entry SHOULD be timed legacy Neighbor Cache entry SHOULD be timed out in
out in TENTATIVE_LEGACY_NCE_LIFETIME seconds unless a registration TENTATIVE_LEGACY_NCE_LIFETIME seconds unless a registration converts
converts it into a Registered NCE. it into a Registered NCE.
However, in 'Mixed-mode' operation, the router does not require to However, in 'Mixed-mode' operation, the router does not require to
keep track of TENTATIVE_LEGACY_NCE_LIFETIME as it does not know if 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. the RS request is from a legacy host or from a EAH. However, it
However, it creates the legacy type of NCE and updates it to a creates the legacy type of NCE and updates it to a registered NCE if
registered NCE if the ARO NS request arrives corresponding to the the ARO NS request arrives corresponding to the Legacy NCE.
legacy NCE. Successful processing of ARO will complete the NCE Successful processing of ARO will complete the NCE creation phase.
creation phase.
If ARO did not result in a duplicate address being detected, and the If ARO did not result in a duplicate address being detected, and the
registration life-time is non-zero, the router creates and updates registration life-time is non-zero, the router creates or updates the
the registered NCE for the IPv6 address. If the Neighbor Cache is Registered NCE for the IPv6 address. If the Neighbor Cache is full
full and new entries need to be created, then the router SHOULD and new entries need to be created, then the router SHOULD respond
respond with a NA with status field set to 2. For successful with a NA with status field set to 2. For successful creation of
creation of NCE, the router SHOULD include a copy of ARO and send NA NCE, the router SHOULD include a copy of ARO and send NA to the
to the requestor with the status field 0. A TLLA(Target Link Layer) requestor with the status field 0. A TLLA (Target Link Layer) Option
Option is not required with this NA. is not required with this NA.
Typically for efficiency-aware routers (NEAR), the registration life- Typically for efficiency-aware routers (NEAR), the Registration
time and EUI-64 are recorded in the Neighbor Cache Entry along with Lifetime and IDS plus Unique Interface Identifier are recorded in the
the existing information described in [ND]. The registered NCE are Neighbor Cache Entry along with the existing information described in
meant to be ready and reachable for communication and no address [RFC4861]. The registered NCE are meant to be ready and reachable
resolution is required in the link. The efficiency-aware hosts will for communication and no address resolution is required in the link.
renew their registration to keep maintain the state of reachability An EAH will renew its registration to Registered NCE at the router.
of the NCE at the router. However the router may do NUD to the idle However the router may perform NUD towards the EAH hosts as per
or unreachable hosts as per [ND]. [RFC4861]. Should NUD fail the NEAR MUST NOT remove the Registered
NCE. Instead it marks it as UNREACHABLE.
In addition, NEAR default routers MUST associate a record of the age 9.7. Sending non-zero status in ARO
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
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 If the Registration fails (due to it being a duplicate or the
Neighbor Cache being full), then the NEAR will send an NA with ARO
having a non-zero status. However, it needs to send that back to the
originator of the failing ARO, and that host and link-layer address
will not be present in the Neighbor Cache.
IETF community has discussed possible issues with /64 DOS attacks on The NEAR forms a NA with ARO, and then forms the link-layer address
by using the content of the SLLA option in the NS, bypassing the
Neighbor Cache to send this error.
9.8. Timing out Registered NCEs
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.
Similarly, if Neighbor Unreachability Detection on the router
determines that the host is UNREACHABLE (based on the logic in
[RFC4861]), 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.
The NEAR router SHOULD deny registration to a new registration
request with the status code 2 when it reaches the maximum capacity
for handling the neighbor cache.
9.9. Router Advertisement Consistency
The NEAR follows section 6.2.7 in [RFC4861] by receiving RAs from
other routers (NEAR and legacy) on the link. In addition to the
checks in that section it verifies that the prefixes to not have the
L flag set, and that the Registrar Address options are consistent.
Two RAOs are inconsistent if they contain the have a different Router
Epoch and have some IPv6 Registration Addresses in common.
9.10. Sending Redirects
A NEAR sends redirects (with target=destination) to inform the hosts
of the link-layer address of the nodes on the link.
This can be disabled on specific link types for instance, radio link
technologies with hidden terminal issues.
9.11. Providing Information to Routing Protocols
If there is a routing protocols like RPL which wants visibility into
the location of each IPv6 address, then this can be retrived from the
Registered NCEs on the NEAR.
9.12. Creating Legacy NCEs
In mixed-mode a NEAR will create Legacy NCEs when receiving RA, RS,
and NS messages based on the source of those packets. When not it
mixed-mode it needs to create Legacy NCEs for other routers by
looking at those packets.
9.13. Proxy Address Resolution and DAD for Legacy Hosts
This section applies in mixed mode. It does not apply in no-legacy
mode.
A NEAR in mixed mode MUST join all solicited-node for all Registered
NCEs.
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. This form of proxying is to respond with a NA that
has a TLLAO taken from the Registered NCE for the target. Thus it is
unlike ND Proxy as specified in [RFC4389].(Implementations of
"Neighbor Discovery Proxies (ND Proxy)" [RFC4389] might proxy using
their own MAC address as TLLA, but that is outside of the scope of
this document.)
In the context of this specification, proxy means:
o Responding to DAD probes for a registered NCE. A DAD probe from a
legacy host would not contain any ARO, hence the NEAR will assume
it is always a duplicate if the IPv6 target address has a
Registered NCE.
o Defending a registered address 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 IDS+Unique Interface
Id) or a older registration (when comparing the TID).
o Advertising a registered address using NA messages, asynchronously
or as a response to a Neighbor Solicitation messages.
o Looking up a destination on the link using Neighbor Solicitation
messages in order to deliver packets arriving for the EAH.
10. 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 the ND networks when an attacker host can send thousands of packets
to the router with an on-link destination address or sending RS to the router with an on-link destination address or sending RS
messages to initiate a Neighbor Solicitation from the neighboring messages to initiate a Neighbor Solicitation from the neighboring
router which will create a number of INCOMPLETE NCE entries for non- router which will create a number of INCOMPLETE NCE entries for non-
existent nodes in the network resulting in table overflow and denial existent nodes in the network resulting in table overflow and denial
of service of the existing communications. of service of the existing communications.
The efficiency-aware behavior documented in this specification avoids The efficiency-aware behavior documented in this specification avoids
the ND DOS attacks by: 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 o Having the hosts register with the default router(s).
the IPv6 link:
o The legacy IPv6 hosts and efficiency-aware-hosts in the network
and a NEAR router
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 o Having the hosts send their packets via the default router(s).
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 o Not resolving addresses for the routing solicitor by mandating
another without ARO then the NS message with ARO gets the precedence. SLLA option along with RS
An efficiency-aware Host implementation SHOULD support falling back o Checking for duplicates in NCE before the registration
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 o On-link IPv6-destinations on a particular link must be registered
movement detection based on ARO from EAH hosts. For the legacy else these packets are not resolved and extra NCEs are not created
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.[RFC 3775]
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 In order to get maximal benefits from the ND-DoS protection from
periodic unsolicited router advertisements based on the media type. Address Registrations, the hosts and routers on the link need to be
upgraded to NEARs and EAHs, respectively. With some legacy hosts the
routers will still need to create INCOMPLETE NCEs and send NSs, which
keeps the DoS opportunity open. However, with fewer legacy hosts the
lower rate limits can be applied on creation of INCOMPLETE NCEs.
13. Bootstrapping 11. Bootstrapping
The bootstrapping mechanism described here is applicable for the The bootstrapping mechanism described here is applicable for the
efficiency-aware hosts and routers. At the start, the host uses its efficiency-aware hosts and routers. At the start, the host uses its
link-local address to send Router Solicitation and then it sends the link-local address to send Router Solicitation and then it sends the
Node Registration message as described in this document in order to Address Registration Option as described in this document in order to
form the address. The Duplicate address detection process should be verify the IPv6 address.
skipped if the network is guaranteed to have unique interface
identifiers which is used to form an IPv6 address. The following step 3 and 4 SHOULD be repeated for all the IPv6
addresses that are used for communications.
Node Router Node Router
0. |[Forms LL IPv6 addr] | 0. |[Forms LL IPv6 addr] |
1. | ---------- Router Solicitation --------> | 1. | ---------- Router Solicitation --------> |
| [SLLAO] | | [SLLAO] |
2. | <-------- Router Advertisement --------- | 2. | <-------- Router Advertisement --------- |
skipping to change at page 22, line 46 skipping to change at page 27, line 43
| [ARO + SLLAO] | | [ARO + SLLAO] |
4. | <-------- Neighbor Advertisement ------- | 4. | <-------- Neighbor Advertisement ------- |
| [ARO with Status code] | | [ARO with Status code] |
5. ====> Address Assignment Complete 5. ====> Address Assignment Complete
Figure 1: Neighbor Discovery Address Registration and bootstrapping Figure 1: Neighbor Discovery Address Registration and bootstrapping
In the mixed mode operation, it is expected that logically there will 12. Interaction with other protocols
be at least one legacy IPv6 router and another NEAR router present in 12.1. Detecting Network Attachment (DNA)
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.
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.
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 IPv6 DNA [RFC6059] uses unicast NS probes and link-layer indications
detect movement of its network attachments. Upon detecting link- to detect movement of its network attachments. That is consistent
layer indication, it sends a all-routers Solicitation message. When with the mechanism in this specification to unicast a NS when a host
the node implements this document along with DNA, it MUST send ARO wakes up - this document recommends adding the ARO to that NS
option with its Neighbor Solicitation unicast message if the message.
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 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 12.2. DHCPv6 Interaction
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).
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 The protocol mechanisms in this document are orthogonal to the
address assignment mechanism in use. If DHCPv6 is used for address
assignment by an EAH then, if there are one or more NEARs on the
subnet, the EAH will replace the DAD check specified in [RFC3315]
with Address Registration as specified in this document.
Co-existence with DHCP: For classical IPv6, if DHCPv6 or central 12.3. Other use of Multicast
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 Although the solution described in this document prevents unnecesary
multicast messages in the IPv6 ND procedure, it does not affect multicast messages in the IPv6 ND procedure, it does not affect
normal IPv6 multicast packets and ability of nodes to join and leave normal IPv6 multicast packets nor the ability of nodes to join and
the multicast group or forwarding multicast traffic or responding to leave the multicast group or forwarding multicast traffic or
multicast queries. responding to multicast queries.
18. VRRP Interaction 12.4. VRRP Interaction
TBD: This section will discuss if efficient ND mixed mode and A VRRP set of routers can operate with efficient-nd in two different
efficiency mode require any special consideration with VRRP function. ways:
19. RPL Implications o Provide the illusion to hosts that they are a single router for
the purposes of registrations. No RAO is needed in that case.
But the pair needs some mechanism to synchronize their neighbor
caches. Such a mechanism is out of scope of this document.
RPL [RFC6550] does not provide means for duplicate address detection o Have the hosts register with each router independently. In that
and in particular does not have a concept of unique identifier. On case the VRRP router includes the RAO with the individual IP
the other hand, RPL is designed to discover and resolve conflicts addresses of the routers in the pair. No synchronization of the
that arise when a mobile device changes its point of attachment, with neighbor caches are needed in that case.
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
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.
20. Updated Neighbor Discovery Constants 13. Updated Neighbor Discovery Constants
This section discusses the updated default values of ND constants This section discusses the updated default values of ND constants
based on [ND] section 10. New and changed constants are listed only based on [RFC4861] section 10. New and changed constants are listed
for efficiency-aware-nd implementation. These values SHOULD be only for efficiency-aware-nd implementation. These values SHOULD be
configurable and tunable to fit implementations and deployment. configurable and tunable to fit implementations and deployment.
Router Constants: Router Constants:
MAX_RTR_ADVERTISEMENTS(NEW) 3 transmissions MAX_RTR_ADVERTISEMENTS(NEW) 3 transmissions
MIN_DELAY_BETWEEN_RAS(CHANGED) 1 second MIN_DELAY_BETWEEN_RAS(CHANGED) 1 second
TENTATIVE_LEGACY_NCE_LIFETIME(NEW) 30 seconds TENTATIVE_LEGACY_NCE_LIFETIME(NEW) 30 seconds
MAX_REG_AGE_DIFFERENCE(NEW) 50 mseconds
Host Constants: Host Constants:
MAX_RTR_SOLICITATION_INTERVAL(NEW) 60 seconds MAX_RTR_SOLICITATION_INTERVAL(NEW) 60 seconds
Also refer to [ENH-ND] , [IMPAT-ND] and [6LOWPAN-ND] for further Also refer to [RFC6583] , [RFC7048] and [RFC6775] for further tuning
tuning of ND constants. of ND constants.
21. Security Considerations 14. Security Considerations
These optimizations are not known to introduce any new threats These optimizations are not known to introduce any new threats
against Neighbor Discovery beyond what is already documented for IPv6 against Neighbor Discovery beyond what is already documented for IPv6
[RFC 3756]. [RFC3756].
Section 11.2 of [ND] applies to this document as well. Section 11.2 of [RFC4861] applies to this document as well.
This mechanism minimizes the possibility of ND /64 DOS attacks in This mechanism minimizes the possibility of ND /64 DoS attacks in
efficiency-aware mode. See Section 11.1. efficiency-aware mode. See Section 10.
22. IANA Considerations The mechanisms in this document work with SeND [RFC3971] in the no-
legacy mode. In the mixed mode operation when a NEAR needs to
respond to a legacy host sending a NS for a EAH, then SeND would not
automatically fit. Potentially proxy SeND [RFC6496] could be used,
but that would require explicit awareness and setup between the proxy
and the proxied EAHs which seems impractical.
The mechanisms in this specification are orthogonal to the address
allocation thus works as well with SLAAC and DHCPv6 as the various
privacy-enhanced address allocation specifications. In particular,
using an EUI-64 for the Unique Interface Identifier in this protocol
does not require or assume that the IPv6 addresses will be formed
using the modified EUI-64 format.
The mechanism uses a Unique Interface Identifier for the purposes of
telling apart a re-registration from the same host and a duplicate/
conflicting registration from a different host. That unique ID is
not globally visible. Currently the protocol supports DHCPv6 DUID
and EUI-64 format for this I-D, but other formats which facilitate
non-linkability (such as strong random numbers large enough to be
unlikely to cause collisions) can be defined.
15. 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.
23. Changelog This document needs a new Neighbor Discovery option type for the RAO.
Changes from draft-chakrabarti-nordmark-energy-aware-nd-02: 16. Changelog
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.
24. Acknowledgements Changes from draft-chakrabarti-nordmark-energy-aware-nd-04:
o Significantly simplified the description of the protocol.
o Added clarification on problem statement
o Clarified that privacy and temporary addresses will be supported
o Added an IDS field in the ARO to allow a DHCP Unique ID (DUID) as
an alternative to EUI-64, with room to define other (pseudo)
unique identifiers.
o Allowed router redirects for NEAR.
o Addressed some of comments made in the 6man list.
o Added RAO to handle VRRP and similar cases when the default router
list and registrar list needs to be different.
o Added Router Epoch to cause re-registration on NEAR state loss.
o Specified considerations for when to refresh address
registrations.
o Specified considerations for when to refresh RA information.
17. 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 [RFC6775] and the discussions from the 6lowpan working group
group members, chairs Carsten Bormann and Geoff Mulligan and through members, chairs Carsten Bormann and Geoff Mulligan and through our
our discussions with Zach Shelby, editor of the [6LOWPAN-ND]. discussions with Zach Shelby, editor of the [RFC6775].
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 discussion in this
document.
The authors like to thank Dave Thaler, Stuart Cheshire, Jari Arkko, The authors like to thank Dave Thaler, Stuart Cheshire, Jari Arkko,
Ylva Jading, Niklas J. Johnsson, Reda Nedjar, Purvi Shah, Jaume Rius Ylva Jading, Niklas J. Johnsson, Reda Nedjar, Purvi Shah, Jaume Rius
Riu, Fredrik Garneij, Andrew Yourtchenko, Jouni Korhonen, Suresh Riu, Fredrik Garneij, Andrew Yourtchenko, Jouni Korhonen, Suresh
Krishnan, Brian Haberman, Anders Brandt, Mark Smith, Lorenzo Colitti, Krishnan, Brian Haberman, Anders Brandt, Mark Smith, Lorenzo Colitti,
David Miles and Carsten Bormann for their useful comments and David Miles, Eric Vyncke, Mark ZZZ Smith, Mikael Abrahammsson, Eric
Levy-Abignoli, and Carsten Bormann for their useful comments and
suggestions on this work. suggestions on this work.
25. References 18. Open Issues
25.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.
[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 The known open issues are:
Packets over IEEE 802.15.4 networks", RFC 4944,
September 2007.
[LOWPANG] Kushalnagar, N. and G. Montenegro, "6LoWPAN: Overview, o IPv6 link-local addresses are always on-link and in this version
Assumptions, Problem Statement and Goals", RFC 4919, of the document that results in multicast NS messages. The
August 2007. techique used in 6LowPAN-ND is too restrictive (extract the link-
layer address from the IID). Should we send link-locals to
routers and depend on Redirect?
25.2. Informative References o If the Router Epoch is critical then we will see a RAO in all the
RAs sent by NEARs. In such a case we don't need the E-bit in the
RA.
[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 o Editorial: Add Comparison with 6lowpan-nd and 4861?
(IPv6), Specification", RFC 2460, December 1998.
[DNA] Krishnan, S. and G. Daley, "Simple Procedures for o When a router has new information for the RA, currently it takes a
Detecting Network Attachments in IPv6", RFC 6059, while to dissemitate that to sleeping nodes as this depends on
November 2010. when the hosts send a RS. We could potentially improve this is we
could have an "information epoch number" in the ARO sent in the
NA. But that only helps if the registrations are refreshed more
frequently that the RA information.
[RFC6550] "RPL: IPv6 Routing Protocol for Low-Power and Lossy o Future? Currently if a router changes its information, a sleeping
Networks", RFC 6550, March 2012. host would not find out when it wakes up and sends the NS with
ARO. That could be improved if we fit the Router Epoch in NA/ARO.
But there is no room for 16 bits.
[AUTOCONF] o A separate but related problem is with unused NCEs due to frequent
Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless IPv6 address change e.g., hosts which pick a different set of
Autoconfiguration", RFC 4862, September 2007. addresses each time they wake up. This document recommends that
they be de-registered by the host. That could be made simpler by
introducing some Host Epoch counter in the NS/ARO.
[SEND] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "Secure 19. References
Neighbor Discovery", RFC 3971, March 2005.
[AUTOADHOC] 19.1. Normative References
Baccelli, E. and M. Townsley, "IP Addressing Model in
Adhoc Networks", RFC 5889, September 2010.
[NDDOS-halpern] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Halpern, J., "IP Addressing Model in Adhoc Networks", Requirement Levels", BCP 14, RFC 2119, March 1997.
draft-halpern-6man-nddos-mitigation-00.txt (work in
progress), October 2011.
[ENH-ND] Kumari, W., Gashinsky, I., Jaeggli, J., and K. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
Chittimaneni, "Neighbor Discovery Enhancement for DOS IANA Considerations Section in RFCs", BCP 26, RFC 2434,
mitigation", draft-gashinsky-6man-v6nd-enhance-02 (work in October 1998.
progress), October 2012.
[IMPAT-ND] [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
Nordmark, E. and I. Gashinsky, "Neighbor Unreachability and M. Carney, "Dynamic Host Configuration Protocol for
Detection is too impatient", IPv6 (DHCPv6)", RFC 3315, July 2003.
draft-ietf-6man-impatient-nud-05 (work in progress),
October 2012.
[IEEE] IEEE Computer Society, "IEEE Std. 802.15.4-2003", , [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
October 2003. "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[PD] Miwakawya, S., "Requirements for Prefix Delegation", [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
RFC 3769, June 2004. "Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007.
[RF] Haberman, B. and B. Hinden, "IPv6 Router Advertisement [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann,
Flags option", RFC 5175, March 2008. "Neighbor Discovery Optimization for IPv6 over Low-Power
Wireless Personal Area Networks (6LoWPANs)", RFC 6775,
November 2012.
[ULA] "Unique Local IPv6 Addresses", RFC 4193. 19.2. Informative References
[Resilient-RS] [I-D.ietf-6man-resilient-rs]
Krishnan, S., Anipko, D., and D. Thaler, "Packet loss Krishnan, S., Anipko, D., and D. Thaler, "Packet loss
resiliency for Router Solicitations", resiliency for Router Solicitations",
draft-ietf-6man-resilient-rs-01 (work in progress), draft-ietf-6man-resilient-rs-02 (work in progress),
May 2013. October 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 [I-D.ietf-6man-stable-privacy-addresses]
Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)",
draft-ietf-6man-stable-privacy-addresses-17 (work in
progress), January 2014.
Efficiency-aware Routers and hosts are useful in IPv6 networks in the [I-D.vyncke-6man-mcast-not-efficient]
Data Center as they produce less signaling and also provides ways to Vyncke, E., Thubert, P., Levy-Abegnoli, E., and A.
minimize the ND flood of messages. Moreover, this mechanism will Yourtchenko, "Why Network-Layer Multicast is Not Always
work with data-center nodes which are deliberately in sleep mode for Efficient At Datalink Layer",
saving energy. draft-vyncke-6man-mcast-not-efficient-01 (work in
progress), February 2014.
This solution will work well in Data Center Virtual network and VM [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
scenarios where number of VLANs are very high and ND signalings are (IPv6) Specification", RFC 2460, December 1998.
undesirably high due the multicast messaging and periodic Router
Advertisments and Neighbor Unreachability detections.
A.2. Edge Routers and Home Networks [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756,
May 2004.
An Edge Router in the network will also benefit implementing the [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
efficiency-aware Neighbor Discovery behavior in order to save the Neighbor Discovery (SEND)", RFC 3971, March 2005.
signaling and keeping track of the registered nodes in its domain. A
BNG sits at the operator's edge network and often the BNG has to
handle a large number of home CPEs. If a BNG runs Neighbor Discovery
protocol and acts as the default router for the CPE at home, this
solution will be helpful for reducing the control messages and
improving network performances.
The same solution can be run on CPE or Home Residential Gateways to [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
assign IPv6 addresses to the wired and wireless home devices without Addresses", RFC 4193, October 2005.
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 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
Proxies (ND Proxy)", RFC 4389, April 2006.
Any Machine-to-machine(M2M) networks such as IPv6 surveilance [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
networks, wireless monitoring networks and other m2m networks desire Address Autoconfiguration", RFC 4862, September 2007.
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 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007.
In Wi-fi networks, a multicast message will consume the wireless link [RFC5175] Haberman, B. and R. Hinden, "IPv6 Router Advertisement
on all Access Points around a switched fabric and will be transmitted Flags Option", RFC 5175, March 2008.
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 [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for
with their nearest default router with NEAR behavior. This method Detecting Network Attachment in IPv6", RFC 6059,
reduces multicast operations in the wireless access points or routers November 2010.
by using this optimization.
A.5. 3GPP Networks [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.
Section 9.2.1.1 of TS23.060 allows periodic RA and TS 123.401 stays [RFC6496] Krishnan, S., Laganier, J., Bonola, M., and A. Garcia-
silent about periodic RA while 3GPP TS29.061 recommends large values Martinez, "Secure Proxy ND Support for SEcure Neighbor
for minimum and maximum periodic router advertisements for reduced Discovery (SEND)", RFC 6496, February 2012.
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.
A.6. Industrial Networks [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
Lossy Networks", RFC 6550, March 2012.
RPL [RFC6550] is used for Industrial wireless networks. [RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object
Workshop", RFC 6574, April 2012.
A.7. Set and forget offline network [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational
Neighbor Discovery Problems", RFC 6583, March 2012.
Home control modules designed for networked environments may be [RFC7048] Nordmark, E. and I. Gashinsky, "Neighbor Unreachability
deployed in very simple settings like garden path lighting controlled Detection Is Too Impatient", RFC 7048, January 2014.
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
Arista Networks Arista Networks
San Jose, CA Santa Clara, CA
USA USA
Email: nordmark@sonic.net 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. 193 change blocks. 
1087 lines changed or deleted 1165 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/