< draft-chakrabarti-nordmark-6man-efficient-nd-00.txt   draft-chakrabarti-nordmark-6man-efficient-nd-01.txt >
INTAREA WG S. Chakrabarti INTAREA 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 Cisco Systems
Expires: April 15, 2013 M. Wasserman Expires: May 25, 2013 M. Wasserman
Painless Security Painless Security
October 12, 2012 November 21, 2012
Efficiency aware IPv6 Neighbor Discovery Optimizations Efficiency aware IPv6 Neighbor Discovery Optimizations
draft-chakrabarti-nordmark-6man-efficient-nd-00 draft-chakrabarti-nordmark-6man-efficient-nd-01
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(LTE) networks, there is a desire for
optimizing legacy IPv6 Neighbor Discovery protocol to be more optimizing the legacy IPv6 Neighbor Discovery protocol. This
efficient in terms of number of signaling messages in the network. document describes a method of optimization by reducing multicast
This document describes a method of optimization by reducing periodic messages and introducing an IPv6 address Registration mechanism.
multicast messages, frequent Neighbor Solicitation messages and
supports interoperability with legacy IPv6 nodes and avoids Duplicate
Address Detection by introducing an address Registration mechanism.
Efficient IPv6 Neighbor Discovery protocol is useful for energy- Efficient IPv6 Neighbor Discovery protocol is useful for energy-
efficient IPv6 networks as well as Data Center and Home Networks. efficient IPv6 networks and as well as Data Center and Home Networks.
The solution is capable of handling existing legacy IPv6 nodes in the
network.
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 15, 2013. This Internet-Draft will expire on May 25, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . 6 2. Definition Of Terms . . . . . . . . . . . . . . . . . . . . . 5
3. Assumptions for efficiency-aware Neighbor Discovery . . . . . 7 3. Assumptions for efficiency-aware Neighbor Discovery . . . . . 7
4. The set of Requirements for efficiency and optimization . . . 7 4. The set of Requirements for efficiency and optimization . . . 7
5. Basic Operations . . . . . . . . . . . . . . . . . . . . . . . 8 5. Basic Operations . . . . . . . . . . . . . . . . . . . . . . . 7
6. Applicability Statement . . . . . . . . . . . . . . . . . . . 8 6. Applicability Statement . . . . . . . . . . . . . . . . . . . 8
7. New Neighbor Discovery Options and Messages . . . . . . . . . 9 7. New Neighbor Discovery Options and Messages . . . . . . . . . 9
7.1. Address Registration Option . . . . . . . . . . . . . . . 9 7.1. Address Registration Option . . . . . . . . . . . . . . . 9
7.2. Refresh and De-registration . . . . . . . . . . . . . . . 11 7.2. Refresh and De-registration . . . . . . . . . . . . . . . 10
7.3. A New Router Advertisement Flag . . . . . . . . . . . . . 11 7.3. A New Router Advertisement Flag . . . . . . . . . . . . . 11
8. efficiency-aware Neighbor Discovery Messages . . . . . . . . . 12 8. Efficiency-aware Neighbor Discovery Messages . . . . . . . . . 11
9. efficiency-aware Host Behavior . . . . . . . . . . . . . . . . 13 9. Efficiency-aware Host Behavior . . . . . . . . . . . . . . . . 13
10. The Energy Aware Default Router (NEAR) Behavior . . . . . . . 14 10. The Energy Aware Default Router (NEAR) Behavior . . . . . . . 13
10.1. Router Configuration Modes . . . . . . . . . . . . . . . . 14 10.1. Router Configuration Modes . . . . . . . . . . . . . . . . 14
11. NCE Management in efficiency-aware Routers . . . . . . . . . . 15 11. NCE Management in efficiency-aware Routers . . . . . . . . . . 15
11.1. Handling ND DOS Attack . . . . . . . . . . . . . . . . . . 16 11.1. Handling ND DOS Attack . . . . . . . . . . . . . . . . . . 16
12. Mixed-Mode Operations . . . . . . . . . . . . . . . . . . . . 17 12. Mixed-Mode Operations . . . . . . . . . . . . . . . . . . . . 17
13. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . . 18 13. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . . 18
14. Handling Sleepy Nodes . . . . . . . . . . . . . . . . . . . . 19 14. Handling Sleepy Nodes . . . . . . . . . . . . . . . . . . . . 19
15. Duplicate Address Detection . . . . . . . . . . . . . . . . . 20 15. Duplicate Address Detection . . . . . . . . . . . . . . . . . 19
16. Use Case Analysis . . . . . . . . . . . . . . . . . . . . . . 20 16. Use Case Analysis . . . . . . . . . . . . . . . . . . . . . . 19
16.1. Data Center Routers on the link . . . . . . . . . . . . . 20 16.1. Data Center Routers on the link . . . . . . . . . . . . . 19
16.2. Edge Routers and Home Networks . . . . . . . . . . . . . . 20 16.2. Edge Routers and Home Networks . . . . . . . . . . . . . . 20
16.3. M2M Networks . . . . . . . . . . . . . . . . . . . . . . . 21 16.3. M2M Networks . . . . . . . . . . . . . . . . . . . . . . . 20
16.4. Cellular and Wi-fi Networks . . . . . . . . . . . . . . . 21 16.4. Cellular and Wi-fi Networks . . . . . . . . . . . . . . . 20
17. Mobility Considerations . . . . . . . . . . . . . . . . . . . 21 17. Mobility Considerations . . . . . . . . . . . . . . . . . . . 20
18. Other Considerations . . . . . . . . . . . . . . . . . . . . . 21 18. Other Considerations . . . . . . . . . . . . . . . . . . . . . 21
18.1. Detecting Network Attachment(DNA) . . . . . . . . . . . . 21 18.1. Detecting Network Attachment(DNA) . . . . . . . . . . . . 21
18.2. ND-Proxy . . . . . . . . . . . . . . . . . . . . . . . . . 22 18.2. Proxying for Efficiency-Aware hosts . . . . . . . . . . . 21
18.3. DHCPv6 Interaction . . . . . . . . . . . . . . . . . . . . 22 18.3. DHCPv6 Interaction . . . . . . . . . . . . . . . . . . . . 21
19. Updated Neighbor Discovery Constants . . . . . . . . . . . . . 22 19. Updated Neighbor Discovery Constants . . . . . . . . . . . . . 22
20. Security Considerations . . . . . . . . . . . . . . . . . . . 23 20. Security Considerations . . . . . . . . . . . . . . . . . . . 22
21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
22. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 23 22. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 22
23. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 23. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
24. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 24. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
24.1. Normative References . . . . . . . . . . . . . . . . . . . 24 24.1. Normative References . . . . . . . . . . . . . . . . . . . 23
24.2. Informative References . . . . . . . . . . . . . . . . . . 24 24.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
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-
skipping to change at page 4, line 35 skipping to change at page 4, line 35
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- save energy if instead of continuous listening, they actually pro-
actively synchronize their states with one or two entities in the actively synchronize their states with one or two entities in the
network. With the explosion of Internet-of-things and machine to network. With the explosion of Internet-of-things and machine to
machine communication, more and more devices would be using IPv6 machine communication, more and more devices would be using IPv6
addresses in the near future. Today, most electricity usage in addresses in the near future.
United States and in developing countries are in the home buildings
and commercial buildings; the electronic Internet appliances/tablets
etc. are gaining popularities in the modern home networks. These
network of nodes must be conscious about saving energy in order to
reduce user-cost. This will eventually reduce stress on electrical
grids and carbon foot-print.
IPv6 Neighbor Discovery Optimization for 6LoWPAN [6LOWPAN-ND] 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
skipping to change at page 5, line 4 skipping to change at page 4, line 47
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 efficient IPv6 networks such as
Home, Enterprise networks, Data Centers and Operator's radio Home, Enterprise networks, Data Centers and Operator's Cellular/
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
indicates that often networked- nodes require more energy than stand- indicates that often networked-nodes require more energy than stand-
alone nodes because a node's energy usage depends on network messages alone nodes because a node's energy usage depends on network messages
it receives and responds. While reducing energy consumption is it receives and responds. While reducing energy consumption is
essential for battery operated nodes in some machines, saving energy essential for battery operated nodes in some machines, saving energy
actually a cost factor in business in general as the explosion of actually a cost factor in business in general as the explosion of
more device usage is leading to usage of more servers and network more device usage is leading to usage of more servers and network
infrastructure in all sectors of the society and business. Thus this infrastructure in all sectors of the society and business. Thus this
document introduces the node registration concept discussed in document introduces the node registration concept discussed in
6LoWPAN [LOWPAN], without handling the 'multi-level subnets' 6LoWPAN [LOWPAN], without handling the 'multi-level subnets'
scenarios that are not the typical usecases in classic IPv6 subnets. scenarios that are not the typical usecases in classic IPv6 subnets.
skipping to change at page 10, line 27 skipping to change at page 10, line 18
| Type | Length = 2 | Status | Reserved | | Type | Length = 2 | Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Registration Lifetime | | Reserved | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ EUI-64 or equivalent + + EUI-64 or equivalent +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields: Fields:
Type: TBD1 ( 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.
Registration Lifetime: 16-bit unsigned integer. The amount of time Registration Lifetime: 16-bit unsigned integer. The amount of time
in a unit of 10 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.
The Status values used in Neighbor Advertisements are: The Status values used in Neighbor Advertisements are:
+--------+--------------------------------------------+ +--------+--------------------------------------------+
| Status | Description | | Status | Description |
skipping to change at page 12, line 6 skipping to change at page 11, line 35
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.
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
is optional in [ND]. An RA MUST carry Prefix is optional in [ND]. An RA MUST carry Prefix
information option with L bit being unset, so information option with L bit being unset, so
that hosts do not multicast any NS messages that hosts do not multicast any NS messages
as part of address resolution. A new flag as part of address resolution. A new flag
(E-flag) is introduced in the RA in order to (E-flag) is introduced in the RA in order to
skipping to change at page 13, line 17 skipping to change at page 13, line 4
Address Resolution: No NS/NA are sent as the prefixes are treated Address Resolution: No NS/NA are sent as the prefixes are treated
as off-link. Thus no address resolution is as off-link. Thus no address resolution is
performed at the hosts. The routers keep performed at the hosts. The routers keep
track of Neighbor Solicitations with Address track of Neighbor Solicitations with Address
Registration options(ARO) and create an Registration options(ARO) and create an
extended neighbor cache of reachable extended neighbor cache of reachable
addresses. The router also knows the nexthop addresses. The router also knows the nexthop
link-local address and corresponding link- link-local address and corresponding link-
layer address when it wants to route a layer address when it wants to route a
packet. packet.
Neighbor Unreachability Detection(NUD): NUD is performed in Neighbor Unreachability Detection(NUD): NUD is performed in
"forward-progress" fashion as described in "forward-progress" fashion as described in
section 7.3.1 of RFC 4861[ND]. However, if section 7.3.1 of RFC 4861[ND]. However, if
Address Registration Option is used, the NUD Address Registration Option is used, the NUD
SHOULD be combined with the Re-registration SHOULD be combined with the Re-registration
of the node. This way no extra message for of the node. This way no extra message for
NUD is required. NUD is required.
9. efficiency-aware Host Behavior 9. Efficiency-aware Host Behavior
A host sends Router Solicitation at the system startup and also when A host sends Router Solicitation at the system startup and also when
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
skipping to change at page 18, line 32 skipping to change at page 18, line 16
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 mechansim 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 the IPv6 address. identifiers which is used to form an IPv6 address.
Node Router Node Router
| | 0. |[Forms LL IPv6 addr] |
1. | ---------- Router Solicitation --------> | 1. | ---------- Router Solicitation --------> |
| [SLLAO] | | [SLLAO] |
2. | <-------- Router Advertisement --------- | 2. | <-------- Router Advertisement --------- |
| [PIO + SLLAO] | | [PIO + SLLAO] |
| | | |
skipping to change at page 20, line 28 skipping to change at page 19, line 43
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 16. Use Case Analysis
This section provides applicability scenarios where the efficiency- This section provides applicability scenarios where the efficiency-
aware Neighbor Discovery will be most beneficial. aware Neighbor Discovery will be most beneficial.
16.1. Data Center Routers on the link 16.1. Data Center Routers on the link
efficiency-aware Routers and hosts are useful in IPv6 networks in the Efficiency-aware Routers and hosts are useful in IPv6 networks in the
Data Center as they produce less signaling and also provides ways to Data Center as they produce less signaling and also provides ways to
minimize the ND flood of messages. Moreover, this mechanism will minimize the ND flood of messages. Moreover, this mechanism will
work with data-center nodes which are deliberately in sleep mode for work with data-center nodes which are deliberately in sleep mode for
saving energy. saving energy.
This solution will work well in Data Center Virtual network and VM This solution will work well in Data Center Virtual network and VM
scenarios where number of VLANs are very high and ND signalings are scenarios where number of VLANs are very high and ND signalings are
undesirably high due the multicast messaging and periodic Router undesirably high due the multicast messaging and periodic Router
Advertisments and Neighbor Unreachability detections. Advertisments and Neighbor Unreachability detections.
skipping to change at page 21, line 32 skipping to change at page 20, line 48
The cellular and Wi-fi IPv6 devices can act as efficiency-aware hosts The cellular and Wi-fi IPv6 devices can act as efficiency-aware hosts
and register with their nearest default router. This will reduce and register with their nearest default router. This will reduce
number of signalings and the registration method(ARO) will provide number of signalings and the registration method(ARO) will provide
operators a mechanism for tracking the nodes in the default router. operators a mechanism for tracking the nodes in the default router.
17. Mobility Considerations 17. 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.
Otherwise, the regular IPv6 Mobility [IPV6M]behavior applies. 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.
18. Other Considerations 18. Other Considerations
18.1. Detecting Network Attachment(DNA) 18.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. layer indication, it sends a all-routers Solicitation message. When
However DNA [DNA] optimizes the IPv6 address operability while a node the node implements this document along with DNA, it MUST send ARO
is moving and its network attachments are changing with respect to option with its Neighbor Solicitation unicast message if the
the neighboring routers. This document does not expect Router candidate router advertisement indicates that the router is a NEAR
Advertisements from the neighboring routers, thus this solution will router. If the candiate router is a legacy router then and it is the
rely on the ND probes for movement detection and as well as link- only choice then the EAH host adapt to the legacy behavior. However
layer indication. When the node implements this document along with if EAH node implements DNA host capability as well, then it SHOULD
DNA, it MUST send ARO option with its Neighbor Solicitation unicast give preference to the NEAR routers in its candidate list of routers.
message if the candidate router advertisement indicates that the
router is a NEAR router. If the candiate router is a legacy router
then and it is the only choice then the EAH host 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.
18.2. ND-Proxy Thus the ND optimization solution will work seamlessly with DNA
implementations and no change is required in DNA solution because of
Neighbor Discovery updates. It is a deployment and configuration
consideration as to run the network in mixed mode or efficient-mode.
ND proxy support in mixed-mode operation: The ND Proxy will continue 18.2. Proxying for Efficiency-Aware hosts
to support the legacy IPv6 Neighbor Solicitation requests in the
mixed mode. The NEAR router SHOULD act as the ND proxy on behalf of The efficient-ND SHOULD continue to support the legacy IPv6 Neighbor
EAH hosts for the legacy nodes' NS requests for EAH. 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.
18.3. DHCPv6 Interaction 18.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
skipping to change at page 22, line 40 skipping to change at page 22, line 11
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.
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. for efficiency-aware-nd implementation. These values SHOULD be
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
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
tuning of ND constants.
20. Security Considerations 20. 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]. [RFC 3756].
Section 11.2 of [ND] applies to this document as well. Section 11.2 of [ND] 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 11.1.
skipping to change at page 24, line 7 skipping to change at page 23, line 28
The inspiration of such a IPv6 generic document came from Margaret The inspiration of such a IPv6 generic document came from Margaret
Wasserman who saw a need for such a document at the IOT workshop at Wasserman who saw a need for such a document at the IOT workshop at
Prague IETF. Prague IETF.
The authors acknowledge the ND denial of service issues and key The authors acknowledge the ND denial of service issues and key
causes mentioned in the draft-halpern-6man-nddos-mitigation document causes mentioned in the draft-halpern-6man-nddos-mitigation document
by Joel Halpern. Thanks to Joel Halpern for pinpointing the problems by Joel Halpern. Thanks to Joel Halpern for pinpointing the problems
that are now addressed in the NCE management section. that are now addressed in the NCE management section.
The authors like to thank Dave Thaler, Jari Arkko, Ylva Jading, The authors like to thank Dave Thaler, Jari Arkko, Ylva Jading,
Niklas J. Johnsson for their useful comments on this work. Niklas J. Johnsson, Reda Nedjar, Purvi Shah, Jaume Rius Riu, Fredrik
Garneij for their useful comments on this work.
24. References 24. References
24.1. Normative References 24.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[6LOWPAN-ND] [6LOWPAN-ND]
Shelby, Z., Chakrabarti, S., and E. Nordmark, "ND Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann,
Optimizations for 6LoWPAN", draft-ietf-6lowpan-nd-17.txt "ND Optimizations for 6LoWPAN", RFC 6775, November 2012.
(work in progress), June 2011.
[ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6", RFC 4861, "Neighbor Discovery for IP version 6", RFC 4861,
September 2007. September 2007.
[LOWPAN] Montenegro, G. and N. Kushalnagar, "Transmission of IPv6 [LOWPAN] Montenegro, G. and N. Kushalnagar, "Transmission of IPv6
Packets over IEEE 802.15.4 networks", RFC 4944, Packets over IEEE 802.15.4 networks", RFC 4944,
September 2007. September 2007.
[LOWPANG] Kushalnagar, N. and G. Montenegro, "6LoWPAN: Overview, [LOWPANG] Kushalnagar, N. and G. Montenegro, "6LoWPAN: Overview,
skipping to change at page 25, line 15 skipping to change at page 24, line 38
[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.
[NDDOS-halpern] [NDDOS-halpern]
Halpern, J., "IP Addressing Model in Adhoc Networks", Halpern, J., "IP Addressing Model in Adhoc Networks",
draft-halpern-6man-nddos-mitigation-00.txt (work in draft-halpern-6man-nddos-mitigation-00.txt (work in
progress), October 2011. progress), October 2011.
[ENH-ND] Kumari, W., Gashinsky, I., Jaeggli, J., and K.
Chittimaneni, "Neighbor Discovery Enhancement for DOS
mitigation", draft-gashinsky-6man-v6nd-enhance-02 (work in
progress), October 2012.
[IMPAT-ND]
Nordmark, E. and I. Gashinsky, "Neighbor Unreachability
Detection is too impatient",
draft-ietf-6man-impatient-nud-05 (work in progress),
October 2012.
[IEEE] IEEE Computer Society, "IEEE Std. 802.15.4-2003", , [IEEE] IEEE Computer Society, "IEEE Std. 802.15.4-2003", ,
October 2003. October 2003.
[PD] Miwakawya, S., "Requirements for Prefix Delegation", [PD] Miwakawya, S., "Requirements for Prefix Delegation",
RFC 3769, June 2004. RFC 3769, June 2004.
[RF] Haberman, B. and B. Hinden, "IPv6 Router Advertisement [RF] Haberman, B. and B. Hinden, "IPv6 Router Advertisement
Flags option", RFC 5175, March 2008. Flags option", RFC 5175, March 2008.
[ULA] "Unique Local IPv6 Addresses", RFC 4193. [ULA] "Unique Local IPv6 Addresses", RFC 4193.
 End of changes. 37 change blocks. 
74 lines changed or deleted 84 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/