< draft-chakrabarti-nordmark-6man-efficient-nd-01.txt   draft-chakrabarti-nordmark-6man-efficient-nd-02.txt >
INTAREA 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 Cisco Systems Intended status: Standards Track P. Thubert
Expires: May 25, 2013 M. Wasserman Expires: January 16, 2014 Cisco Systems
M. Wasserman
Painless Security Painless Security
November 21, 2012 July 15, 2013
Efficiency aware IPv6 Neighbor Discovery Optimizations Efficiency aware IPv6 Neighbor Discovery Optimizations
draft-chakrabarti-nordmark-6man-efficient-nd-01 draft-chakrabarti-nordmark-6man-efficient-nd-02
Abstract Abstract
IPv6 Neighbor Discovery (RFC 4861) protocol has been designed for IPv6 Neighbor Discovery (RFC 4861) protocol has been designed for
neighbor's address resolution, unreachability detection, address neighbor's address resolution, unreachability detection, address
autoconfiguration, router advertisement and solicitation. With the autoconfiguration, router advertisement and solicitation. With the
progress of Internet adoption on various industries including home, progress of Internet adoption on various industries including home,
wireless, m2m and Cellular(LTE) networks, there is a desire for wireless, M2M and cellular networks there is a desire for optimizing
optimizing the legacy IPv6 Neighbor Discovery protocol. This the legacy IPv6 Neighbor Discovery protocol. This document describes
document describes a method of optimization by reducing multicast a method of optimization by reducing multicast messages and
messages and introducing an IPv6 address Registration mechanism. introducing an IPv6 address Registration mechanism. Efficient IPv6
Efficient IPv6 Neighbor Discovery protocol is useful for energy- Neighbor Discovery protocol is useful for energy-efficient and low-
efficient IPv6 networks and as well as Data Center and Home Networks. power IPv6 networks and as well as Data Center and Home Networks.
The solution is capable of handling existing legacy IPv6 nodes in the The solution is capable of handling existing legacy IPv6 nodes in the
network. network with local mobility.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 25, 2013. This Internet-Draft will expire on January 16, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definition Of Terms . . . . . . . . . . . . . . . . . . . . . 5 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Assumptions for efficiency-aware Neighbor Discovery . . . . . 7 1.2. Overview of the ND Optimization . . . . . . . . . . . . . 5
4. The set of Requirements for efficiency and optimization . . . 7 2. Definition Of Terms . . . . . . . . . . . . . . . . . . . . . 6
5. Basic Operations . . . . . . . . . . . . . . . . . . . . . . . 7 3. Assumptions for efficiency-aware Neighbor Discovery . . . . . 8
6. Applicability Statement . . . . . . . . . . . . . . . . . . . 8 4. The set of Requirements for efficiency and optimization . . . 8
7. New Neighbor Discovery Options and Messages . . . . . . . . . 9 5. Basic Operations . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Address Registration Option . . . . . . . . . . . . . . . 9 6. Applicability Statement . . . . . . . . . . . . . . . . . . . 9
7.2. Refresh and De-registration . . . . . . . . . . . . . . . 10 7. New Neighbor Discovery Options and Messages . . . . . . . . . 10
7.3. A New Router Advertisement Flag . . . . . . . . . . . . . 11 7.1. Address Registration Option . . . . . . . . . . . . . . . 10
8. Efficiency-aware Neighbor Discovery Messages . . . . . . . . . 11 7.2. Refresh and De-registration . . . . . . . . . . . . . . . 12
9. Efficiency-aware Host Behavior . . . . . . . . . . . . . . . . 13 7.3. A New Router Advertisement Flag . . . . . . . . . . . . . 12
10. The Energy Aware Default Router (NEAR) Behavior . . . . . . . 13 7.4. The Transaction Identification(TID) . . . . . . . . . . . 13
10.1. Router Configuration Modes . . . . . . . . . . . . . . . . 14 8. Efficiency-aware Neighbor Discovery Messages . . . . . . . . . 13
11. NCE Management in efficiency-aware Routers . . . . . . . . . . 15 9. Efficiency-aware Host Behavior . . . . . . . . . . . . . . . . 15
11.1. Handling ND DOS Attack . . . . . . . . . . . . . . . . . . 16 10. The Energy Aware Default Router (NEAR) Behavior . . . . . . . 15
12. Mixed-Mode Operations . . . . . . . . . . . . . . . . . . . . 17 10.1. Router Configuration Modes . . . . . . . . . . . . . . . . 16
13. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . . 18 10.2. Movement Detection . . . . . . . . . . . . . . . . . . . . 17
14. Handling Sleepy Nodes . . . . . . . . . . . . . . . . . . . . 19 10.2.1. Registration ownership . . . . . . . . . . . . . . . 17
15. Duplicate Address Detection . . . . . . . . . . . . . . . . . 19 11. NCE Management in efficiency-aware Routers . . . . . . . . . . 17
16. Use Case Analysis . . . . . . . . . . . . . . . . . . . . . . 19 11.1. Handling ND DOS Attack . . . . . . . . . . . . . . . . . . 19
16.1. Data Center Routers on the link . . . . . . . . . . . . . 19 12. Mixed-Mode Operations . . . . . . . . . . . . . . . . . . . . 20
16.2. Edge Routers and Home Networks . . . . . . . . . . . . . . 20 13. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . . 21
16.3. M2M Networks . . . . . . . . . . . . . . . . . . . . . . . 20 14. Handling Sleepy Nodes . . . . . . . . . . . . . . . . . . . . 22
16.4. Cellular and Wi-fi Networks . . . . . . . . . . . . . . . 20 15. Duplicate Address Detection . . . . . . . . . . . . . . . . . 23
17. Mobility Considerations . . . . . . . . . . . . . . . . . . . 20 16. Mobility Considerations . . . . . . . . . . . . . . . . . . . 23
18. Other Considerations . . . . . . . . . . . . . . . . . . . . . 21 17. Other Considerations . . . . . . . . . . . . . . . . . . . . . 24
18.1. Detecting Network Attachment(DNA) . . . . . . . . . . . . 21 17.1. Detecting Network Attachment(DNA) . . . . . . . . . . . . 24
18.2. Proxying for Efficiency-Aware hosts . . . . . . . . . . . 21 17.2. Proxying for Efficiency-Aware hosts . . . . . . . . . . . 24
18.3. DHCPv6 Interaction . . . . . . . . . . . . . . . . . . . . 21 17.3. DHCPv6 Interaction . . . . . . . . . . . . . . . . . . . . 25
19. Updated Neighbor Discovery Constants . . . . . . . . . . . . . 22 18. RPL Implications . . . . . . . . . . . . . . . . . . . . . . . 25
20. Security Considerations . . . . . . . . . . . . . . . . . . . 22 19. Updated Neighbor Discovery Constants . . . . . . . . . . . . . 26
21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 20. Security Considerations . . . . . . . . . . . . . . . . . . . 26
22. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 22 21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
23. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 22. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 26
24. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 23. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
24.1. Normative References . . . . . . . . . . . . . . . . . . . 23 24. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
24.2. Informative References . . . . . . . . . . . . . . . . . . 24 24.1. Normative References . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 24.2. Informative References . . . . . . . . . . . . . . . . . . 28
Appendix A. Usecase Analysis . . . . . . . . . . . . . . . . . . 29
A.1. Data Center Routers on the link . . . . . . . . . . . . . 29
A.2. Edge Routers and Home Networks . . . . . . . . . . . . . . 29
A.3. M2M Networks . . . . . . . . . . . . . . . . . . . . . . . 29
A.4. Wi-fi Networks . . . . . . . . . . . . . . . . . . . . . . 30
A.5. 3GPP Networks . . . . . . . . . . . . . . . . . . . . . . 30
A.6. Industrial Networks . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
Conceptually, IPv6 multicast messages are supposed to avoid broadcast
messages, but in practice, the multicast operation at the link level
is that of a broadcast nevertheless. This did not matter much at the
time ND [ND] was originally designed, when an Ethernet network was
more or less a single shared wire, but since then, large scale switch
fabrics, low power sleeping devices, mobile wireless/cellular devices
and virtual machines have changed the landscape dramatically.
In a modern switch fabric, a number of intermediate devices (such as
switches, routers and security middle boxes) host IPv6 State
Maintaining Entities (SMEs) holding information such as the location
of an IPv6 address or its mapping with a MAC address. Such
intermediate devices include Wireless Controllers that terminate a
overlay tunnel and rapidly re-enable reachability for mobile
devices(L2/L3), Network edge devices performing subscriber access,
network devices that protect the ownership of an IPv6 address,
Overlay networks in data centers, Home Networks for IPv6 clients.
In general, there is a need for enhancing the IPv6 ND [ND] to make it
less chatty and flexible to work with different types of networking
elements, physical and virtual networks and at the same time
maintaining the IPv6 states to avoid duplicates or denial of
services.
1.1. Background
IPv6 ND [ND] is based on multicast signaling messages on the local IPv6 ND [ND] is based on multicast signaling messages on the local
link in order to avoid broadcast messages. Following power-on and link in order to avoid broadcast messages. Following power-on and
initialization of the network in IPv6 Ethernet networks, a node joins initialization of the network in IPv6 Ethernet networks, a node joins
the solicited-node multicast address on the interface and then the solicited-node multicast address on the interface and then
performs duplicate address detection (DAD) for the acquired link- performs duplicate address detection (DAD) for the acquired link-
local address by sending a solicited-node multicast message to the local address by sending a solicited-node multicast message to the
link. After that it sends multicast router solicitation (RS) link. After that it sends multicast router solicitation (RS)
messages to the all-router address to solicit router advertisements. messages to the all-router address to solicit router advertisements.
Once the host receives a valid router advertisement (RA) with the "A" Once the host receives a valid router advertisement (RA) with the "A"
flag, it autoconfigures the IPv6 address with the advertised prefix flag, it autoconfigures the IPv6 address with the advertised prefix
skipping to change at page 4, line 31 skipping to change at page 5, line 9
Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages
to resolve the IPv6 address of the destination on the link. These to resolve the IPv6 address of the destination on the link. These
NS/NA messages are also often multicast messages and it is assumed 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 that the node is on the same link and relies on the fact that the
destination node is always powered and generally available. destination node is always powered and generally available.
The periodic RA messages in IPv6 ND [ND], and NS/NA messages require The periodic RA messages in IPv6 ND [ND], and NS/NA messages require
all IPv6 nodes in the link to be in listening mode even when they are all IPv6 nodes in the link to be in listening mode even when they are
in idle cycle. It requires energy for the sleepy nodes which may in idle cycle. It requires energy for the sleepy nodes which may
otherwise be sleeping during the idle period. Non-sleepy nodes also otherwise be sleeping during the idle period. Non-sleepy nodes also
save energy if instead of continuous listening, they actually pro- spends more energy since they are in continuous listening mode. With
actively synchronize their states with one or two entities in the the explosion of Internet-of-things and machine to machine
network. With the explosion of Internet-of-things and machine to communication, more and more devices would be using IPv6 addresses in
machine communication, more and more devices would be using IPv6 the near future. Since Neighbor Discovery is at the heart of IPv6
addresses in the near future. protocol, there is a need to make this protocol more efficient.
1.2. Overview of the ND Optimization
IPv6 Neighbor Discovery Optimization for 6LoWPAN [6LOWPAN-ND] IPv6 Neighbor Discovery Optimization for 6LoWPAN [6LOWPAN-ND]
addresses many of the concerns described above by optimizing the addresses many of the concerns described above by optimizing the
Router advertisement, minimizing periodic multicast packets in the Router advertisement, minimizing periodic multicast packets in the
network and introducing two new options - one for node registration network and introducing two new options - one for node registration
and another for prefix dissemination in a network where all nodes in and another for prefix dissemination in a network where all nodes in
the network are uniquely identified by their 64-bit Interface the network are uniquely identified by their 64-bit Interface
Identifier. EUI-64 identifiers are recommended as unique Interface Identifier. EUI-64 identifiers are recommended as unique Interface
Identifiers, however if the network is isolated from the Internet, Identifiers, however if the network is isolated from the Internet,
uniqueness of the identifiers may be obtained by other mechanisms uniqueness of the identifiers may be obtained by other mechanisms
such as a random number generator with lowest collision rate. such as a random number generator with lowest collision rate.
Although, the ND optimization [6LOWPAN-ND] applies to 6LoWPAN Although, the ND optimization [6LOWPAN-ND] applies to 6LoWPAN
[LOWPAN] network, the concept is mostly applicable to a power-aware [LOWPAN] network, the concept is mostly applicable to a power-aware
IPv6 network. Therefore, this document generalizes the address IPv6 network. Therefore, this document generalizes the address
registration and multicast reduction in [6LOWPAN-ND] to all IPv6 registration and multicast reduction in [6LOWPAN-ND] to all IPv6
links. links.
Thus optimizing the regular IPv6 Neighbor Discovery [ND] to minimize Thus optimizing the regular IPv6 Neighbor Discovery [ND] to minimize
total number of related signaling messages without losing generality total number of related signaling messages without losing generality
of Neighbor Discovery, autoconfiguration and reliable host-router of Neighbor Discovery, autoconfiguration and reliable host-router
communication, are desirable in any efficient IPv6 networks such as communication, are desirable in any modern IPv6 networks such as
Home, Enterprise networks, Data Centers and Operator's Cellular/ Home, Enterprise networks, Data Centers and Operator's Cellular/
Wireless networks. Wireless networks.
The optimization will be highly effective for links and nodes which The optimization will be highly effective for links and nodes which
do not support multicast and as well as for a multicast network do not support multicast and as well as for a multicast network
without MLD snooping switches. Moreover, in the MLD-snooping without MLD snooping switches. Moreover, in the MLD-snooping
networks the MLD switches will deal with less number of multicasts. networks the MLD switches will deal with less number of multicasts.
The goal of this document is to provide an efficient Neighbor The goal of this document is to provide an efficient Neighbor
Discovery Protocol in classic IPv6 subnets and links. Research Discovery Protocol in classic IPv6 subnets and links. Research
skipping to change at page 5, line 44 skipping to change at page 6, line 23
The proposed changes can be used in two different ways. In one case The proposed changes can be used in two different ways. In one case
all the hosts and routers on a link implement the new mechanisms, all the hosts and routers on a link implement the new mechanisms,
which gives the maximum benefits. In another case the link has a which gives the maximum benefits. In another case the link has a
mixture of new hosts and/or routers and legacy [RFC4861] hosts and mixture of new hosts and/or routers and legacy [RFC4861] hosts and
routers, operating in a mixed-mode providing some of the benefits. routers, operating in a mixed-mode providing some of the benefits.
In the following sections the document describes the basic operations In the following sections the document describes the basic operations
of registration methods, optimization of Neighbor Discovery messages, of registration methods, optimization of Neighbor Discovery messages,
interoperability with legacy IPv6 implementations and provides a interoperability with legacy IPv6 implementations and provides a
section on use-case scenarios where it can be typically applicable. section on use-case scenarios where it can be typically applicable.
This document also describes an optional feature for node mobility in
the LLN network using backbone routers(BBR) or multiple default
subnet routers. This optional feature in generating a sequence ID by
the host in the registration message will be helpful for deploying
RPL[RFC6550] with reliability in the LLN.
2. Definition Of Terms 2. Definition Of Terms
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
multi-level Subnets: multi-level Subnets:
It is a wireless link determined by one IPv6 off-link prefix in a It is a wireless link determined by one IPv6 off-link prefix in a
network where in order to reach a destination with same prefix a network where in order to reach a destination with same prefix a
packet may have to travel throguh one more 'intermediate' routers packet may have to travel through one more 'intermediate' routers
which relays the packet to the next 'intermediate' router or the which relays the packet to the next 'intermediate' router or the
host in its own. host in its own.
Border Rotuer(BR): Border Router(BR):
A border router is typically located at the junction Internet and A border router is typically located at the junction Internet and
Home Network. An IPv6 router with one interface connected to IPv6 Home Network. An IPv6 router with one interface connected to IPv6
subnet and other interface connecting to a non-classic IPv6 subnet and other interface connecting to a non-classic IPv6
interface such as 6LoWPAN interface. Border router is usually the interface such as 6LoWPAN interface. Border router is usually the
gateway to the IPv6 network or Internet. gateway to the IPv6 network or 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.
Backbone Router:
An IPv6 router that federates the LLN using a transit link as a
backbone. A BBR acts as a 6LoWPAN Border Routers (6LBR) and an
Energy Aware Default Router (NEAR).
Efficiency-Aware Network: Efficiency-Aware Network:
An Efficiency-Aware network is composed of network elements that An Efficiency-Aware network is composed of network elements that
are sensitive to energy usage or number of signalling messages in are sensitive to energy usage or number of signaling messages in
the network. An efficiency-aware network may also contain links the network. An efficiency-aware network may also contain links
that do not support multicast or it does not have MLD snooping that do not support multicast or it does not have MLD snooping
capabilities and yet the network likes to communicate most capabilities and yet the network likes to communicate most
efficiently with minimum number of signaling messages. Data efficiently with minimum number of signaling messages. Data
center networks with virtual machines, cellular IPv6 networks, any center networks with virtual machines, cellular IPv6 networks, any
IPv6 networks with energy-sensitive nodes are examples of IPv6 networks with energy-sensitive nodes are examples of
Efficiency-Aware networks. Efficiency-Aware networks.
IPv6 ND-efficiency-aware Rotuer(NEAR): IPv6 ND-efficiency-aware Router(NEAR):
It is the default Router of the single hop IPv6 subnet. This It is the default Router of the single hop IPv6 subnet. This
router implements the optimizations specified in this document. router implements the optimizations specified in this document.
This router should be able to handle both legacy IPv6 nodes and This router should be able to handle both legacy IPv6 nodes and
nodes that sends registration request. nodes that sends registration request.
Efficiency-Aware Host(EAH): Efficiency-Aware Host(EAH):
A host in a IPv6 network is considered a IPv6 node without routing A host in a IPv6 network is considered a IPv6 node without routing
and forwarding capability. The EAH is the host which implements and forwarding capability. The EAH is the host which implements
the host functionality for optimized Neighbor Discovery mentioned the host functionality for optimized Neighbor Discovery mentioned
in this document. in this document.
Legacy IPv6 Host: Legacy IPv6 Host:
skipping to change at page 7, line 4 skipping to change at page 7, line 48
Legacy IPv6 Router: Legacy IPv6 Router:
An IPv6 Router which implements RFC 4861 Neighbor Discovery An IPv6 Router which implements RFC 4861 Neighbor Discovery
protocols. protocols.
EUI-64: EUI-64:
It is the IEEE defined 64-bit extended unique identifier formed by It is the IEEE defined 64-bit extended unique identifier formed by
concatenation of 24-bit or 36-bit company id value by IEEE concatenation of 24-bit or 36-bit company id value by IEEE
Registration Authority and the extension identifier within that Registration Authority and the extension identifier within that
company-id assignment. The extension identifiers are 40-bit (for company-id assignment. The extension identifiers are 40-bit (for
24-bit company-id) or 28-bit (for the 36-bit company-id) 24-bit company-id) or 28-bit (for the 36-bit company-id)
respectively. respectively.
LLN:
It is a low power and lossy network where nodes are typically
constrained in system resources and energy, for instance battery
powered nodes. Alternately LLN could be a network of line-powered
nodes with radio links with lossy characteristics. Wifi, ZigBee,
Celular networks are examples of such a network.
Extended LLN:
This is the aggregation of multiple LLNs as defined in [RFC4919]
interconnected by a Backbone Link via Backbone Routers and forming
a single IPv6 link.
3. Assumptions for efficiency-aware Neighbor Discovery 3. Assumptions for efficiency-aware Neighbor Discovery
o The efficiency-aware nodes in the network carry unique interface o The efficiency-aware nodes in the network carry unique interface
ID in the network in order to form the auto-configured IPv6 ID in the network in order to form the auto-configured IPv6
address uniquely. An EUI-64 interface ID required for global address uniquely. An EUI-64 interface ID required for global
communication. communication.
o All nodes are single IPv6-hop away from their default router in o All nodes are single IPv6-hop away from their default router in
the subnet. the subnet.
o /64-bit IPv6 prefix is used for Stateless Auto-address o /64-bit IPv6 prefix is used for Stateless Auto-address
configuration (SLAAC). The IPv6 Prefix may be distributed with configuration (SLAAC). The IPv6 Prefix may be distributed with
Router Advertisement (RA) from the default router to all the nodes Router Advertisement (RA) from the default router to all the nodes
in that link. 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 4. The set of Requirements for efficiency and optimization
o Node Registration: Node initiated Registration and address o Node Registration: Node initiated Registration and address
allocation is done in order to avoid periodic multicast Router allocation is done in order to avoid periodic multicast Router
Advertisement messages and often Neighbor Address resolution can Advertisement messages and often Neighbor Address resolution can
be skipped as all packets go via the default router which now be skipped as all packets go via the default router which now
knows about all the registered nodes. Node Registration enables knows about all the registered nodes. Node Registration enables
reduction of all-node and solicited-node multicast messages in the reduction of all-node and solicited-node multicast messages in the
subnet. subnet.
o Address allocation of registered nodes [ND] are performed using o Address allocation of registered nodes [ND] are performed using
IPv6 Autoconfiguration [AUTOCONF]. IPv6 Autoconfiguration [AUTOCONF].
o Host initiated Registration and Refresh is done by sending a o Host initiated Registration and Refresh is done by sending a
Router Solicitation and then a Neighbor Solicitation Messge using Router Solicitation and then a Neighbor Solicitation Message using
Address Registration Option (described below). Address Registration Option (described below).
o The node registration may replace the requirement of doing o The node registration may replace the requirement of doing
Duplicate Address Detection. Duplicate Address Detection.
o Sleepy hosts are supported by this Neighbor Discovery procedures o Sleepy hosts are supported by this Neighbor Discovery procedures
as they are not woken up periodically by Router Advertisement as they are not woken up periodically by Router Advertisement
multicast messages or Neighbor Solicitation multicast messages. multicast messages or Neighbor Solicitation multicast messages.
Sleepy nodes may wake up in its own schedule and send unicast Sleepy nodes may wake up in its own schedule and send unicast
registration refresh messages when needed. registration refresh messages when needed.
o Since this document requires formation of an IPv6 address with an o Since this document requires formation of an IPv6 address with an
unique 64-bit Interface ID(EUI-64) is required for global IPv6 unique 64-bit Interface ID(EUI-64) is required for global IPv6
skipping to change at page 8, line 24 skipping to change at page 9, line 32
option in order to register itself with the default router. The EAH option in order to register itself with the default router. The EAH
does not do Duplicate Address Detection or NS Resolution of does not do Duplicate Address Detection or NS Resolution of
addresses. NEAR maintains a binding of registered nodes and addresses. NEAR maintains a binding of registered nodes and
registration life-time information along with the neighbor Cache registration life-time information along with the neighbor Cache
information. The NEAR is responsible for forwarding all the messages information. The NEAR is responsible for forwarding all the messages
from its EAH including on-link messages from one EAH to another. For from its EAH including on-link messages from one EAH to another. For
details of protocol operations please see the sections below. details of protocol operations please see the sections below.
When a IPv6 network consists of both legacy hosts and EAH, and if the When a IPv6 network consists of both legacy hosts and EAH, and if the
NEAR is configured for 'mixed mode' operation, it should be able to NEAR is configured for 'mixed mode' operation, it should be able to
handle ARO requests and send periodic RA. Thus it should be able to handle Address Registration Option(ARO) requests and send periodic
serve both efficiency-aware hosts and legacy hosts. Similarly, a RA. Thus it should be able to serve both efficiency-aware hosts and
legacy host compatible EAH falls back to RFC 4861 host behavior if a legacy hosts. Similarly, a legacy host compatible EAH falls back to
NEAR is not present in the link. See the section on 'Mixed Mode RFC 4861 host behavior if a NEAR is not present in the link. See the
Operations' for details below. section on 'Mixed Mode Operations' for details below.
6. Applicability Statement 6. Applicability Statement
This document aims to guide the implementors to choose an appropriate This document aims to guide the implementers to choose an appropriate
IPv6 neighbor discovery and Address configuration procedures suitable IPv6 neighbor discovery and Address configuration procedures suitable
for any efficient IPv6 network. These optimization is equally useful for any efficient IPv6 network. These optimization is equally useful
for the energy-sensitive, non-multicast links and for classical IPv6 for the energy-sensitive, non-multicast links and for classical IPv6
networks i.e home networks, Data-Center IPv6 overlay networks where networks i.e. home networks, Data-Center IPv6 overlay networks where
saving Neighbor Discovery messages will reduce cost and increase saving Neighbor Discovery messages will reduce cost and increase
bandwidth availability. See use cases towards the end of the bandwidth availability.
document.
The address registration mechanism and associated extension on
Neighbor Discovery protocol allow a low-power host to move between
the LLN and the classic IPv6 networks as well as movement from one
Border Router registration area to another while staying within the
same IPv6 subnet.
Note that the specification allows 'Mixed-mode' operation in the Note that the specification allows 'Mixed-mode' operation in the
efficiency-aware nodes for backward compatibility and transitioning efficiency-aware nodes for backward compatibility and transitioning
to a complete efficiency-aware network of hosts and routers. Though to a complete efficiency-aware network of hosts and routers. Though
the efficiency-aware only nodes will minimize the ND signalling and the efficiency-aware only nodes will minimize the ND signaling and
DOS attacks in the LAN. DOS attacks in the LAN.
Applicability of this solution is limited to the legacy IPv6 nodes Applicability of this solution is limited to the legacy IPv6 nodes
and subnets and it optimizes the generic IPv6 siganling activities at and subnets and it optimizes the generic IPv6 signaling activities at
network layer. However, further optimization at the application network layer. However, further optimization at the application
layers are possible for increased efficiency based on particular layers are possible for increased efficiency based on particular use-
usecases and applications. cases and applications.
7. New Neighbor Discovery Options and Messages 7. New Neighbor Discovery Options and Messages
This section will discuss the registration and de-registration This section will discuss the registration and de-registration
procedure of the hosts in the network. procedure of the hosts in the network.
7.1. Address Registration Option 7.1. Address Registration Option
The Address Registration Option(ARO) is useful for avoiding Duplicate The Address Registration Option(ARO) is useful for avoiding Duplicate
Address Detection messages since it requires a unique ID for Address Detection messages since it requires a unique EUI-64 ID for
registration. The address registration is used for maintaining registration. The address registration is used for maintaining
reachability of the node or host by the router. This option is reachability of the node or host by the router. This option is
exactly the same as in [6LOWPAN-ND] which is reproduced here for the exactly the same as in [6LOWPAN-ND] which is reproduced here for the
benefits of the readers. benefits of the readers. Additionally 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 The routers keep track of host IP addresses that are directly
reachable and their corresponding link-layer addresses. This is reachable and their corresponding link-layer addresses. This is
useful for lossy and lowpower networks and as well as wired networks. useful for lossy and lowpower networks(LLN) and as well as wired
An Address Registration Option (ARO) can be included in unicast networks. An Address Registration Option (ARO) can be included in
Neighbor Solicitation (NS) messages sent by hosts. Thus it can be unicast Neighbor Solicitation (NS) messages sent by hosts. Thus it
included in the unicast NS messages that a host sends as part of can be included in the unicast NS messages that a host sends as part
Neighbor Unreachability Detection to determine that it can still of Neighbor Unreachability Detection to determine that it can still
reach a default router. The ARO is used by the receiving router to reach a default router. The ARO is used by the receiving router to
reliably maintain its Neighbor Cache. The same option is included in reliably maintain its Neighbor Cache. The same option is included in
corresponding Neighbor Advertisement (NA) messages with a Status corresponding Neighbor Advertisement (NA) messages with a Status
field indicating the success or failure of the registration. This field indicating the success or failure of the registration. This
option is always host initiated. option is always host initiated.
The ARO is required for reliability and power saving. The lifetime The ARO is required for reliability and power saving. The lifetime
field provides flexibility to the host to register an address which field provides flexibility to the host to register an address which
should be usable (the reachability information may be propagated to should be usable (the reachability information may be propagated to
the routing protocols) during its intended sleep schedule of nodes the routing protocols) during its intended sleep schedule of nodes
skipping to change at page 10, line 10 skipping to change at page 11, line 26
When the ARO is used by hosts an SLLA option MUST be included and the When the ARO is used by hosts an SLLA option MUST be included and the
address that is to be registered MUST be the IPv6 source address of address that is to be registered MUST be the IPv6 source address of
the Neighbor Solicitation message. the Neighbor Solicitation message.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length = 2 | Status | Reserved | | Type | Length = 2 | Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Registration Lifetime | | Reservd |T| TID | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ EUI-64 or equivalent + + EUI-64 or equivalent +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields: Fields:
Type: 33 ( See [6LOWPAN-ND] ) Type: 33 ( See [6LOWPAN-ND] )
Length: 8-bit unsigned integer. The length of the option in Length: 8-bit unsigned integer. The length of the option in
units of 8 bytes. Always 2. units of 8 bytes. Always 2.
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 below.
Reserved: This field is unused. It MUST be initialized to zero Reserved: This field is unused. It MUST be initialized to zero
by the sender and MUST be ignored by the receiver. by the sender and MUST be ignored by the receiver.
TID: 8-bit integer. It is a transaction id maintained by
the host and incremented with each registration. it is
recommended that the node maintains a persistent
storage for TID. TID is used as a sequence counter to
detect the most recent registration request from a
host and its mobility within the same subnet across
multiple default Border Routers. Its operation
follows section 7 of RPL [RFC6550] for sequence
counters.
Registration Lifetime: 16-bit unsigned integer. The amount of time 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.
EUI-64: 64 bits. This field is used to uniquely identify the EUI-64: 64 bits. This field is used to uniquely identify the
interface of the registered address by including the interface of the registered address by including the
EUI-64 identifier assigned to it unmodified. 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: The Status values used in Neighbor Advertisements are:
+--------+--------------------------------------------+ +--------+--------------------------------------------+
| Status | Description | | Status | Description |
+--------+--------------------------------------------+ +--------+--------------------------------------------+
| 0 | Success | | 0 | Success |
| 1 | Duplicate Address | | 1 | Duplicate Address |
| 2 | Neighbor Cache Full | | 2 | Neighbor Cache Full |
| 3-255 | Allocated using Standards Action [RFC2434] | | 3 | Registration Ownership Response |
| 4-255 | Allocated using Standards Action [RFC2434] |
+--------+--------------------------------------------+ +--------+--------------------------------------------+
Table 1 Table 1
7.2. Refresh and De-registration 7.2. Refresh and De-registration
A host SHOULD send a Registration messge in order to renew its A host SHOULD send a Registration message in order to renew its
registration before its registration lifetime expires in order to registration before its registration lifetime expires in order to
continue its connectivity with the network. If anytime, the node continue its connectivity with the network. If anytime, the node
decides that it does not need the default router's service anymore, decides that it does not need the default router's service anymore,
it MUST send a de-registration message - i,e, a registration message it MUST send a de-registration message - i,e, a registration message
with lifetime being set to zero. A mobile host SHOULD first de- with lifetime being set to zero. A mobile host SHOULD first de-
register with the default router before it moves away from the register with the default router before it moves away from the
subnet. subnet.
7.3. A New Router Advertisement Flag 7.3. A New Router Advertisement Flag
A new Router Advertisment flag [RF] is needed in order to distnguish A new Router Advertisement flag [RF] is needed in order to
a router advertisement from a efficiency-aware default router or a distinguish a router advertisement from a efficiency-aware default
legacy IPv6 router. This flag is ignored by the legacy IPv6 hosts. router or a legacy IPv6 router. This flag is ignored by the legacy
EAH hosts use this flag in oder to discover a NEAR router if it IPv6 hosts. EAH hosts use this flag in order to discover a NEAR
receives multiple RA from both legacy and NEAR routers. router if it receives multiple RA from both legacy and NEAR routers.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|M|O|H|Prf|P|E|R| |M|O|H|Prf|P|E|R|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
The 'E' bit above MUST be 1 when a IPv6 router implements and The 'E' bit above MUST be 1 when a IPv6 router implements and
configures the efficiency-aware Router behavior for Neighbor configures the efficiency-aware Router behavior for Neighbor
Discovery as per this document. All other cases E bit is 0. Discovery as per this document. All other cases E bit is 0.
The legacy IPv6 hosts will ignore the E bit in RA advertisement. All The legacy IPv6 hosts will ignore the E bit in RA advertisement. All
EAH MUST look for E bit in RA in order to determine the efficiency- EAH MUST look for E bit in RA in order to determine the efficiency-
aware support in the default router in the link. aware support in the default router in the link.
7.4. The Transaction Identification(TID)
The TID field is used together with age of a registration for
arbitration between two routers (default or backbone) to ensure
freshness and ownership of the registration of a given target
address. Same value of TID indicates that both states of
registration are valid. In case of a mismatch between comparable
TIDs, the most recent TID wins. The TID definition used in section
6.4.1 of RFC 6550 for DAOSequence number would be applicable for here
for TID in ARO message.
It is 8 bit field. TID is generated by the host at the time of a new
registraton request.
This document assumes that an implementation will have configuration This document assumes that an implementation will have configuration
knobs to determine whether it is running in classical IPv6 ND [ND] or knobs to determine whether it is running in classical IPv6 ND [ND] or
Optimized Energy Aware ND (this document) mode or both(Mixed mode). Optimized Energy Aware ND (this document) mode or both(Mixed mode).
8. Efficiency-aware Neighbor Discovery Messages 8. Efficiency-aware Neighbor Discovery Messages
Router Advertisement(RA): Periodic RAs SHOULD be avoided. Only Router Advertisement(RA): Periodic RAs SHOULD be avoided. Only
solicited RAs are RECOMMENDED. An RA MUST solicited RAs are RECOMMENDED. An RA MUST
contain the Source Link-layer Address option contain the Source Link-layer Address option
containing Router's link-layer address (this containing Router's link-layer address (this
skipping to change at page 13, line 26 skipping to change at page 15, line 18
it suspects that one of its default routers have become it suspects that one of its default routers have become
unreachable(after NUD fails). The EAH MUST process the E-bit in RA unreachable(after NUD fails). The EAH MUST process the E-bit in RA
as described in this document. The EAH MUST use ARO option to as described in this document. The EAH MUST use ARO option to
register with the neighboring NEAR router. register with the neighboring NEAR router.
A host SHOULD be able to autoconfigure its IPv6 addresses using the A host SHOULD be able to autoconfigure its IPv6 addresses using the
IPv6 prefix obtained from Router Advertisement. The host SHOULD form IPv6 prefix obtained from Router Advertisement. The host SHOULD form
its link-local address from the EUI-64 as specified by IEEE its link-local address from the EUI-64 as specified by IEEE
Registration Authority and RFC 2373. If this draft feature is Registration Authority and RFC 2373. If this draft feature is
implemented and configured, the host MUST NOT re-direct Neighbor implemented and configured, the host MUST NOT re-direct Neighbor
Discovery messages. The host does not require to join solicited-node Discovery messages. The host is not required to join the solicited-
multicast address but it MUST join the all-node multicast address. 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 A host always sends packets to (one of) its default router(s). This
is accomplished by the routers never setting the 'L' flag in the is accomplished by the routers never setting the 'L' flag in the
Prefix options. Prefix options.
The host is unable to forward routes or participate in a routing The host is unable to forward routes or participate in a routing
protocol. A legacy IPv6 Host compliant EAH SHOULD be able to fall protocol. A legacy IPv6 Host compliant EAH SHOULD be able to fall
back to RFC 4861 host behavior if there is no efficiency-aware router back to RFC 4861 host behavior if there is no efficiency-aware router
(NEAR) in the link. (NEAR) in the link.
The efficiency-aware host MUST NOT send or accept re-direct messages. The efficiency-aware host MUST NOT send or accept re-direct messages.
It does not join solicited node multicast address. It does not join solicited node multicast address.
If the EAH is capable of generating TID and configured for this
operation, the EAH MUST use the TID field and appropriate associated
operation bits in the ARO message during registration and refresh.
10. The Energy Aware Default Router (NEAR) Behavior 10. The Energy Aware Default Router (NEAR) Behavior
The main purpose of the default router in the context of this The main purpose of the default router in the context of this
document is to receive and process the registration request, forward document is to receive and process the registration request, forward
packets from one neighbor to the other, informs the routing protocol packets from one neighbor to the other, informs the routing protocol
about the un-availability of the registered nodes if the routing about the un-availability of the registered nodes if the routing
protocol requires this information for the purpose of mobility or protocol requires this information for the purpose of mobility or
fast convergence. A default router (NEAR) behavior may be observed fast convergence. A default router (NEAR) behavior may be observed
in one or more interfaces of a Border Router(BR). in one or more interfaces of a Border Router(BR).
skipping to change at page 14, line 17 skipping to change at page 16, line 12
gateway between separate networks such as Internet and home networks gateway between separate networks such as Internet and home networks
. The Border Router is responsible for distributing one or more /64 . The Border Router is responsible for distributing one or more /64
prefixes to the nodes to identify a packet belonging to the prefixes to the nodes to identify a packet belonging to the
particular network. One or more of the interfaces of the Border particular network. One or more of the interfaces of the Border
Router may be connected with the efficiency-aware hosts or a Router may be connected with the efficiency-aware hosts or a
efficiency-aware router(NEAR). efficiency-aware router(NEAR).
The efficiency-aware default router MUST not send periodic RA unless The efficiency-aware default router MUST not send periodic RA unless
it is configured to support both legacy IPv6 and efficiency-aware it is configured to support both legacy IPv6 and efficiency-aware
hosts. If the Router is configured for efficiency-aware hosts hosts. If the Router is configured for efficiency-aware hosts
support, it MUST send Router Advertisments with E-bit flag ON and support, it MUST send Router Advertisements with E-bit flag ON and
MUST NOT set 'L' bit in the advertisements. MUST NOT set 'L' bit in the advertisements.
The router SHOULD NOT garbage collect Registered Neighbor Cache The router SHOULD NOT garbage collect Registered Neighbor Cache
entries since they need to retain them until the Registration entries since they need to retain them until the Registration
Lifetime expires. If a NEAR receives a NS message from the same host 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 one with ARO and another without ARO then the NS message with ARO
gets the precedence and the NS without ARO is ignored. This behavior gets the precedence and the NS without ARO is ignored. This behavior
protects the router from Denial Of Service attacks. Similarly, if protects the router from Denial Of Service attacks. Similarly, if
Neighbor Unreachability Detection on the router determines that the Neighbor Unreachability Detection on the router determines that the
host is UNREACHABLE (based on the logic in [ND]), the Neighbor Cache host is UNREACHABLE (based on the logic in [ND]), the Neighbor Cache
skipping to change at page 14, line 52 skipping to change at page 16, line 47
link. link.
An efficiency-aware Router(NEAR) SHOULD be able to have configuration An efficiency-aware Router(NEAR) SHOULD be able to have configuration
knob to configure itself in Mixed-Mode where it will support both knob to configure itself in Mixed-Mode where it will support both
efficiency-aware hosts and legacy hosts. However even in mixed-mode efficiency-aware hosts and legacy hosts. However even in mixed-mode
the router should check for duplicate entries in the NCE before the router should check for duplicate entries in the NCE before
creating a new ones and it should rate-limit creating new NCE based creating a new ones and it should rate-limit creating new NCE based
on requests from the same host MAC address. on requests from the same host MAC address.
The RECOMMENDED default mode of operation for the efficiency-aware The RECOMMENDED default mode of operation for the efficiency-aware
router is Mixed-mode. router is Mixed-mode. Though it cannot reap the full benefit of
efficiency related optimization described in this document.
10.2. Movement Detection
When a host moves from one subnet to another its IPv6 prefix changes
and the movement detection is determined according to the existing
IPv6 movement detection described in [DNA].
However, if the movement happens across different default routers in
the subnet and the node likes to register with one of the default
routers closest to its present location, it must send another
registration request to the new default router. The new default
router then first send an NS to its peers with a link scope multicast
message to IPv6 address ff02::2 with the ARO option.
10.2.1. Registration ownership
The subnet-local-routers check their respective NCE table for the
particular registration. If the registration entry exists, the NEAR
default router then calculates the 'age' of the registration by
subtracting the present time from the registration received time
recorded at the NCE. The NEAR router then responds with a NA with
ARO option Status being equal to 3 and replaces the 'registration
lifetime' field with the 'age' of registration. Upon receiving the
NA from the neighboring routers the prospective default router
determines its registration ownership. If the other router
registration age is higher than its own registration age, then the
current router is considered to have the most recent registration
ownership.
If both routers registration age are zero or within a 50msec window,
then the TID field is used to determine the ownership. The higher
value of TID wins. Note that the registration ownership and local
movement detection behavior in NEAR router MUST be optionally
configured. The NEAR routers MAY implement this feature.
Configuring this option is needed when the NEAR routers are used in a
low power and lossy network environment.
11. NCE Management in efficiency-aware Routers 11. NCE Management in efficiency-aware Routers
The use of explicit registrations with lifetimes plus the desire to The use of explicit registrations with lifetimes plus the desire to
not multicast Neighbor Solicitation messages for hosts imply that we not multicast Neighbor Solicitation messages for hosts imply that we
manage the Neighbor Cache entries slightly differently than in [ND]. manage the Neighbor Cache entries slightly differently than in [ND].
This results in two different types of NCEs and the types specify how This results in two different types of NCEs and the types specify how
those entries can be removed: those entries can be removed:
Legacy: Entries that are subject to the normal rules in Legacy: Entries that are subject to the normal rules in
skipping to change at page 16, line 4 skipping to change at page 18, line 45
existing Neighbor Cache entry based on the SLLA option from the existing Neighbor Cache entry based on the SLLA option from the
Router Solicitation. Thus, a router SHOULD create a tentative Legacy Router Solicitation. Thus, a router SHOULD create a tentative Legacy
Neighbor Cache entry based on SLLA option when there is no match with Neighbor Cache entry based on SLLA option when there is no match with
the existing NCE. Such a legacy Neighbor Cache entry SHOULD be timed the existing NCE. Such a legacy Neighbor Cache entry SHOULD be timed
out in TENTATIVE_LEGACY_NCE_LIFETIME seconds unless a registration out in TENTATIVE_LEGACY_NCE_LIFETIME seconds unless a registration
converts it into a Registered NCE. converts 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 the efficiency-aware hosts.
However, it creates the legacy type of NCE and updates it to a However, it creates the legacy type of NCE and updates it to a
registered NCE if the ARO NS request arrives corresponding to the registered NCE if the ARO NS request arrives corresponding to the
legacy NCE. Successful processing of ARO will complete the NCE legacy 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 and updates
the registered NCE for the IPv6 address. if the Neighbor Cache is the registered NCE for the IPv6 address. If the Neighbor Cache is
full and new entries need to be created, then the router SHOULD full and new entries need to be created, then the router SHOULD
respond with a NA with status field set to 2. For successful respond with a NA with status field set to 2. For successful
creation of NCE, the router SHOULD include a copy of ARO and send NA creation of NCE, the router SHOULD include a copy of ARO and send NA
to the requestor with the status field 0. A TLLA(Target Link Layer) to the requestor with the status field 0. A TLLA(Target Link Layer)
Option is not required with this NA. Option is not required with this NA.
Typically for efficiency-aware routers (NEAR), the registration life- Typically for efficiency-aware routers (NEAR), the registration life-
time and EUI-64 are recorded in the Neighbor Cache Entry along with time and EUI-64 are recorded in the Neighbor Cache Entry along with
the existing information described in [ND]. The registered NCE are the existing information described in [ND]. The registered NCE are
meant to be ready and reachable for communication and no address meant to be ready and reachable for communication and no address
resolution is required in the link. The efficiency-aware hosts will resolution is required in the link. The efficiency-aware hosts will
renew their registration to keep maintain the state of reachability renew their registration to keep maintain the state of reachability
of the NCE at the router. However the router may do NUD to the idle of the NCE at the router. However the router may do NUD to the idle
or unreachable hosts as per [ND]. or unreachable hosts as per [ND].
In addition, NEAR default routers MUST associate a record of the age
of the registration. 'Age' is a simple way to detect movement of a
node from local default router to another. 'Age' information SHOULD
contain System-time when the registration is first created or last
refreshed. This system-time is deducted from the current system-time
to determine the "age" of the registration and it is used for age
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 11.1. Handling ND DOS Attack
IETF community has discussed possible issues with /64 DOS attacks on IETF community has discussed possible issues with /64 DOS attacks on
the ND networks when a attacker host can send thousands of packets to the ND networks when an attacker host can send thousands of packets
the router with a on-link destination address or sending RS messages to the router with an on-link destination address or sending RS
to initiate a Neighbor Solicitation from the neighboring router which messages to initiate a Neighbor Solicitation from the neighboring
will create a number of INCOMPLETE NCE entries for non-existent nodes router which will create a number of INCOMPLETE NCE entries for non-
in the network resulting in table overflow and denial of service of existent nodes in the network resulting in table overflow and denial
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 register with the default router
o Having the hosts send their packets via the default router o Having the hosts send their packets via the default router
o Not resolving addresses for the Routing Solicitor by mandating o Not resolving addresses for the Routing Solicitor by mandating
SLLA option along with RS SLLA option along with RS
o Checking for duplicates in NCE before the registration o Checking for duplicates in NCE before the registration
o Checking against the MAC-address and EUI-64 id is possible now for o Checking against the MAC-address and EUI-64 id is possible now for
skipping to change at page 16, line 48 skipping to change at page 20, line 4
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 register with the default router
o Having the hosts send their packets via the default router o Having the hosts send their packets via the default router
o Not resolving addresses for the Routing Solicitor by mandating o Not resolving addresses for the Routing Solicitor by mandating
SLLA option along with RS SLLA option along with RS
o Checking for duplicates in NCE before the registration o Checking for duplicates in NCE before the registration
o Checking against the MAC-address and EUI-64 id is possible now for o Checking against the MAC-address and EUI-64 id is possible now for
NCE matches NCE matches
o On-link IPv6-destinations on a particular link must be registered o On-link IPv6-destinations on a particular link must be registered
else these packets are not resolved and extra NCEs are not created else these packets are not resolved and extra NCEs are not created
It is recomended that Mixed-mode operation and legacy hosts SHOULD It is RECOMMENDED that Mixed-mode operation and legacy hosts SHOULD
NOT be used in the IPv6 link in order to avoid the ND DOS attacks. 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 For the general case of Mixed-mode the router does not create
INCOMPLETE NCEs for the registered hosts, but it follows the [ND] INCOMPLETE NCEs for the registered hosts, but it follows the [ND]
steps of NCE states for legacy hosts. steps of NCE states for legacy hosts.
12. Mixed-Mode Operations 12. Mixed-Mode Operations
Mixed-Mode operation discusses the protocol behavior where the IPv6 Mixed-Mode operation discusses the protocol behavior where the IPv6
subnet is composed with legacy IPv6 Neighbor Discovery compliant subnet is composed with legacy IPv6 Neighbor Discovery compliant
nodes and efficiency-aware IPv6 nodes implementing this nodes and efficiency-aware IPv6 nodes implementing this
specification. specification.
skipping to change at page 17, line 47 skipping to change at page 21, line 4
If a NEAR receives NS message from the same host one with ARO and If a NEAR receives NS message from the same host one with ARO and
another without ARO then the NS message with ARO gets the precedence. another without ARO then the NS message with ARO gets the precedence.
An efficiency-aware Host implementation SHOULD support falling back An efficiency-aware Host implementation SHOULD support falling back
to legacy IPv6 node behavior when no efficiency-aware routers are to legacy IPv6 node behavior when no efficiency-aware routers are
available in the network during the startup. If the EAH was available in the network during the startup. If the EAH was
operational in efficiency-aware mode and it determines that the NEAR operational in efficiency-aware mode and it determines that the NEAR
is no longer available, then it should send a RS and find an is no longer available, then it should send a RS and find an
alternate default router in the link. If no efficiency-aware router 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 is indicated from the RA, then the EAH SHOULD fall back into RFC 4861
behavior. On the otherhand, in the efficiency-aware mode EAH SHOULD behavior. On the other hand, in the efficiency-aware mode EAH SHOULD
ignore multicast Router Advertisements(RA) sent by the legacy and ignore multicast Router Advertisements(RA) sent by the legacy and
Mixed-mode routers in the link. Mixed-mode routers in the link.
In mixed mode operation, the Router SHOULD be able to do local
movement detection based on ARO if it is configured for that
operation for EAH hosts. For the legacy hosts, the mixed-mode router
MAY follow classical IPv6 methods of movement detection and MAY act
as ND proxy by sending NA with 'O' bit.[ Reference??]
The routers that are running on efficiency-aware mode or legacy mode The routers that are running on efficiency-aware mode or legacy mode
SHOULD NOT dynamically switch the mode without flushing the Neighbor SHOULD NOT dynamically switch the mode without flushing the Neighbor
Cache Entries. Cache Entries.
13. Bootstrapping 13. Bootstrapping
If the network is a efficiency-aware IPv6 subnet, and the efficiency- If the network is a efficiency-aware IPv6 subnet, and the efficiency-
aware Neighbor Discovery mechansim is used by the hosts and routers aware Neighbor Discovery mechanism is used by the hosts and routers
as described in this document. At the start, the node uses its link- as described in this document. At the start, the node uses its link-
local address to send Router Solicitation and then it sends the Node local address to send Router Solicitation and then it sends the Node
Registration message as described in this document in order to form Registration message as described in this document in order to form
the address. The Duplicate address detection process should be the address. The Duplicate address detection process should be
skipped if the network is guaranteed to have unique interface skipped if the network is guaranteed to have unique interface
identifiers which is used to form an IPv6 address. identifiers which is used to form an IPv6 address.
Node Router Node Router
0. |[Forms LL IPv6 addr] | 0. |[Forms LL IPv6 addr] |
skipping to change at page 19, line 36 skipping to change at page 23, line 21
In efficiency-aware mode, there is no need for Duplicate Address In efficiency-aware mode, there is no need for Duplicate Address
Detection(DAD) assuming that the deployment ensures unique 64bit Detection(DAD) assuming that the deployment ensures unique 64bit
identification availability for each registered host. In the event identification availability for each registered host. In the event
of collision of EUI64 field of ARO by two registration requests, the 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 later request is denied if the first one is a valid request. The
denied EAH node SHOULD pick another alternative IPv6 address to denied EAH node SHOULD pick another alternative IPv6 address to
register to prevent further registration denial. The method of register to prevent further registration denial. The method of
assignment of alternate IPv6 address is out of scope of this assignment of alternate IPv6 address is out of scope of this
document. document.
16. Use Case Analysis In some networks there are multiple default routers and the
registering node may move from one default router (where it was
This section provides applicability scenarios where the efficiency- registered before) to another default router in the same subnet.
aware Neighbor Discovery will be most beneficial. Thus in order to differentiate between the duplicate request and the
movement, the router checks the 64-bit MAC address and 'age' of the
16.1. Data Center Routers on the link 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
Efficiency-aware Routers and hosts are useful in IPv6 networks in the the new request is same with TID of the new request, it is a
Data Center as they produce less signaling and also provides ways to duplicate.
minimize the ND flood of messages. Moreover, this mechanism will
work with data-center nodes which are deliberately in sleep mode for
saving energy.
This solution will work well in Data Center Virtual network and VM
scenarios where number of VLANs are very high and ND signalings are
undesirably high due the multicast messaging and periodic Router
Advertisments and Neighbor Unreachability detections.
16.2. Edge Routers and Home Networks
An Edge Router in the network will also benefit implementing the
efficiency-aware Neighbor Discovery behavior in order to save the
signaling and keeping track of the registered nodes in its domain. A
BNG sits at the operator's edge network and often the BNG has to
handle a large number of home CPEs. If a BNG runs Neighbor Discovery
protocol and acts as the default router for the CPE at home, this
solution will be helpful for reducing the control messages and
improving network performances.
The same solution can be run on CPE or Home Residential Gateways to
assign IPv6 addresses to the wired and wireless home devices without
the problem of ND flooding issues and consuming less power. It
provides mechanism for the sleepy nodes to adjust their registration
lifetime according to their sleep schedules.
16.3. M2M Networks
Any Machine-to-machine(M2M) networks such as IPv6 surveilance
networks, wireless monitoring networks and other m2m networks desire
for efficiency-aware control protocols and dynamic address
allocation. The in-built address allocation and autoconfiguration
mechanism in IPv6 along with the default router capability will be
useful for the simple small-scale networks without having the burden
of DHCPv6 service and Routing Protocols.
16.4. Cellular and Wi-fi Networks
The cellular and Wi-fi IPv6 devices can act as efficiency-aware hosts If the default router does not have a registered entry for this host,
and register with their nearest default router. This will reduce it should check whether it is a local movement. Please see 'Mobility
number of signalings and the registration method(ARO) will provide Consideration section' for details.
operators a mechanism for tracking the nodes in the default router.
17. Mobility Considerations 16. Mobility Considerations
If the hosts move from one subnet to another, they MUST first de- If the hosts move from one subnet to another, they MUST first de-
register and then register themselves in the new subnet or network. register and then register themselves in the new subnet or network.
If a node moves away without de-registration and returns to the If a node moves away without de-registration and returns to the
network before the registration lifetime expires, its registration is network before the registration lifetime expires, its registration is
still considered valid. For run-away nodes the registration expires still considered valid. For run-away nodes the registration expires
after the lifetime expiry or due to unreachablity whichever comes after the lifetime expiry or due to unreachablity whichever comes
first. Otherwise, the regular IPv6 Mobility [IPV6M]behavior applies. first. Otherwise, the regular IPv6 Mobility [IPV6M]behavior applies.
18. Other Considerations 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.
18.1. Detecting Network Attachment(DNA) 17. Other Considerations
17.1. Detecting Network Attachment(DNA)
IPv6 DNA[DNA] uses unicast ND probes and link-layer indications to IPv6 DNA[DNA] uses unicast ND probes and link-layer indications to
detect movement of its network attachments. Upon detecting link- detect movement of its network attachments. Upon detecting link-
layer indication, it sends a all-routers Solicitation message. When layer indication, it sends a all-routers Solicitation message. When
the node implements this document along with DNA, it MUST send ARO the node implements this document along with DNA, it MUST send ARO
option with its Neighbor Solicitation unicast message if the option with its Neighbor Solicitation unicast message if the
candidate router advertisement indicates that the router is a NEAR candidate router advertisement indicates that the router is a NEAR
router. If the candiate router is a legacy router then and it is the router. If the candiate router is a legacy router then and it is the
only choice then the EAH host adapt to the legacy behavior. However only choice then the EAH host adapt to the legacy behavior. However
if EAH node implements DNA host capability as well, then it SHOULD if EAH node implements DNA host capability as well, then it SHOULD
give preference to the NEAR routers in its candidate list of routers. 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.
18.2. Proxying for Efficiency-Aware hosts 17.2. Proxying for Efficiency-Aware hosts
The efficient-ND SHOULD continue to support the legacy IPv6 Neighbor The efficient-ND SHOULD continue to support the legacy IPv6 Neighbor
Solicitation requests in the mixed mode. The NEAR router SHOULD act Solicitation requests in the mixed mode. The NEAR router SHOULD act
as the ND proxy on behalf of EAH hosts for the legacy nodes' NS as the ND proxy on behalf of EAH hosts for the legacy nodes' NS
requests for EAH. requests for EAH.
18.3. DHCPv6 Interaction 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
Co-existence with DHCP: For classical IPv6, if DHCPv6 or central Co-existence with DHCP: For classical IPv6, if DHCPv6 or central
address allocation mechanism is used, then Neighbor Discovery address allocation mechanism is used, then Neighbor Discovery
autoconfiguration is not used for global address allocation. autoconfiguration is not used for global address allocation.
However, link-local duplicate address detection, Neighbor However, link-local duplicate address detection, Neighbor
solicitation, Neighbor unreachability detection are still used. Upon solicitation, Neighbor unreachability detection are still used. Upon
assignment of the IPv6-address from DHCPv6, a EAH node SHOULD then assignment of the IPv6-address from DHCPv6, a EAH node SHOULD then
register the IP-address with the default router for avoiding register the IP-address with the default router for avoiding
Duplicate address detection and Address Resolution. For Legacy Duplicate address detection and Address Resolution. For Legacy
DHCPv6 nodes there is no change in behavior. NOTE: DHCPv6 Server DHCPv6 nodes there is no change in behavior. NOTE: DHCPv6 Server
MUST be notified by NEAR for its efficiency-aware service interfaces. MUST be notified by NEAR for its efficiency-aware service interfaces.
DHCPv6 server then SHOULD inform the DHCP requestor node about the DHCPv6 server then SHOULD inform the DHCP requestor node about the
default-rotuer capability during the address assignment period. 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 and ability of nodes to join and leave
the multicast group or forwarding multicast traffic or responding to the multicast group or forwarding multicast traffic or responding to
multicast queries. multicast queries.
18. RPL Implications
RPL [RFC6550] does not provide means for duplicate address detection
and in particular does not have a concept of unique identifier. On
the other hand, RPL is designed to discover and resolve conflicts
that arise when a mobile device changes its point of attachment, with
a sequence counter that is owned by the device and incremented at
each new registration, called a DAOSequence. As we extend 6LoWPAN ND
operation over a backbone and scale, there is a similar need to
resolve the latest point of attachment of a device, whether this
device moves at layer 2 over a WIFI infrastructure, or at layer 3
within a RPL DODAG or from a DODAG to another one attached to the
same backbone. In order to cover all cases in a consistent fashion,
this document requires that a sequence counter call TID for
Transaction ID and with the similar rules as the RPL DAOSequence is
added to the ND registration. This document defines the TID
operations and RPL may use the reserved fields for their purpose
inside the LLN.
19. Updated Neighbor Discovery Constants 19. 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 [ND] section 10. New and changed constants are listed only
for efficiency-aware-nd implementation. These values SHOULD be 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
skipping to change at page 24, line 22 skipping to change at page 28, line 18
24.2. Informative References 24.2. Informative References
[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6), Specification", RFC 2460, December 1998. (IPv6), Specification", RFC 2460, December 1998.
[DNA] Krishnan, S. and G. Daley, "Simple Procedures for [DNA] Krishnan, S. and G. Daley, "Simple Procedures for
Detecting Network Attachments in IPv6", RFC 6059, Detecting Network Attachments in IPv6", RFC 6059,
November 2010. November 2010.
[RFC6550] "RPL: IPv6 Routing Protocol for Low-Power and Lossy
Networks", RFC 6550, March 2012.
[AUTOCONF] [AUTOCONF]
Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Autoconfiguration", RFC 4862, September 2007. Autoconfiguration", RFC 4862, September 2007.
[SEND] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "Secure [SEND] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "Secure
Neighbor Discovery", RFC 3971, March 2005. Neighbor Discovery", RFC 3971, March 2005.
[AUTOADHOC] [AUTOADHOC]
Baccelli, E. and M. Townsley, "IP Addressing Model in Baccelli, E. and M. Townsley, "IP Addressing Model in
Adhoc Networks", RFC 5889, September 2010. Adhoc Networks", RFC 5889, September 2010.
skipping to change at page 25, line 14 skipping to change at page 29, line 13
RFC 3769, June 2004. RFC 3769, June 2004.
[RF] Haberman, B. and B. Hinden, "IPv6 Router Advertisement [RF] Haberman, B. and B. Hinden, "IPv6 Router Advertisement
Flags option", RFC 5175, March 2008. Flags option", RFC 5175, March 2008.
[ULA] "Unique Local IPv6 Addresses", RFC 4193. [ULA] "Unique Local IPv6 Addresses", RFC 4193.
[IPV6M] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [IPV6M] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011. in IPv6", RFC 6275, July 2011.
Appendix A. Usecase Analysis
This section provides applicability scenarios where the efficiency-
aware Neighbor Discovery will be most beneficial.
A.1. Data Center Routers on the link
Efficiency-aware Routers and hosts are useful in IPv6 networks in the
Data Center as they produce less signaling and also provides ways to
minimize the ND flood of messages. Moreover, this mechanism will
work with data-center nodes which are deliberately in sleep mode for
saving energy.
This solution will work well in Data Center Virtual network and VM
scenarios where number of VLANs are very high and ND signalings are
undesirably high due the multicast messaging and periodic Router
Advertisments and Neighbor Unreachability detections.
A.2. Edge Routers and Home Networks
An Edge Router in the network will also benefit implementing the
efficiency-aware Neighbor Discovery behavior in order to save the
signaling and keeping track of the registered nodes in its domain. A
BNG sits at the operator's edge network and often the BNG has to
handle a large number of home CPEs. If a BNG runs Neighbor Discovery
protocol and acts as the default router for the CPE at home, this
solution will be helpful for reducing the control messages and
improving network performances.
The same solution can be run on CPE or Home Residential Gateways to
assign IPv6 addresses to the wired and wireless home devices without
the problem of ND flooding issues and consuming less power. It
provides mechanism for the sleepy nodes to adjust their registration
lifetime according to their sleep schedules.
A.3. M2M Networks
Any Machine-to-machine(M2M) networks such as IPv6 surveilance
networks, wireless monitoring networks and other m2m networks desire
for efficiency-aware control protocols and dynamic address
allocation. The in-built address allocation and autoconfiguration
mechanism in IPv6 along with the default router capability will be
useful for the simple small-scale networks without having the burden
of DHCPv6 service and Routing Protocols.
A.4. Wi-fi Networks
In Wi-fi networks, a multicast message will consume the wireless link
on all Access Points around a switched fabric and will be transmitted
at the lowest speed possible in order to ensure the maximum reception
by all wireless nodes. This means that in an environment where
bandwidth is scarce, a single multicast packet may consume the
bandwidth for hundreds of unicast packets.
The Wi-fi IPv6 hosts can act as efficiency-aware hosts and register
with their nearest default router with NEAR behavior. This method
reduces multicast operations in the wireless access points or routers
by using this optimization.
A.5. 3GPP Networks
Section 9.2.1.1 of TS23.060 allows periodic RA and TS 123.401 stays
silent about periodic RA. Though the informational drafts and
RFC6459 about 3GPP systems IPv6 behavior provides best practices,
this document provides standard based optimization that 3GPP systems
can follow to improve efficiency in the mobile nodes and 3GPP
Routers.
A.6. Industrial Networks
RPL [RFC6550] is used for Industrial wireless networks.
Authors' Addresses Authors' Addresses
Samita Chakrabarti Samita Chakrabarti
Ericsson Ericsson
San Jose, CA San Jose, CA
USA USA
Email: samita.chakrabarti@ericsson.com Email: samita.chakrabarti@ericsson.com
Erik Nordmark Erik Nordmark
Cisco Systems Cisco Systems
San Jose, CA San Jose, CA
USA USA
Email: nordmark@cisco.com Email: nordmark@cisco.com
Pascal Thubert
Cisco Systems
Email: pthubert@cisco.com
Margaret Wasserman Margaret Wasserman
Painless Security Painless Security
Email: mrw@lilacglade.org Email: mrw@lilacglade.org
 End of changes. 63 change blocks. 
164 lines changed or deleted 415 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/