< draft-chakrabarti-nordmark-6man-efficient-nd-05.txt   draft-chakrabarti-nordmark-6man-efficient-nd-06.txt >
6man WG S. Chakrabarti 6man WG S. Chakrabarti
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: 4861 (if approved) E. Nordmark Updates: 4861 (if approved) E. Nordmark
Intended status: Standards Track Arista Networks Intended status: Standards Track Arista Networks
Expires: August 18, 2014 P. Thubert Expires: January 5, 2015 P. Thubert
Cisco Systems Cisco Systems
M. Wasserman M. Wasserman
Painless Security Painless Security
February 14, 2014 July 4, 2014
IPv6 Neighbor Discovery Optimizations for Wired and Wireless Networks IPv6 Neighbor Discovery Optimizations for Wired and Wireless Networks
draft-chakrabarti-nordmark-6man-efficient-nd-05 draft-chakrabarti-nordmark-6man-efficient-nd-06
Abstract Abstract
IPv6 Neighbor Discovery (RFC 4861 going back to RFC 1970) was defined IPv6 Neighbor Discovery (RFC 4861 going back to RFC 1970) was defined
at a time when link-local multicast was as reliable and with the same at a time when link-local multicast was as reliable and with the same
network cost (send a packet on a yellow-coax Ethernet) as unicast and network cost (send a packet on a yellow-coax Ethernet) as unicast and
where the hosts were assumed to be always on and connected. where the hosts were assumed to be always on and connected.
Since 1996 we've seen a significant change with both an introduction Since 1996 we've seen a significant change with both an introduction
of wireless networks and battery operated devices, which poses of wireless networks and battery operated devices, which poses
skipping to change at page 1, line 38 skipping to change at page 1, line 38
This specification contains extensions to IPv6 Neighbor Discovery This specification contains extensions to IPv6 Neighbor Discovery
which remove most use of multicast and make sleeping hosts more which remove most use of multicast and make sleeping hosts more
efficient. The specification includes a default mixed mode where a efficient. The specification includes a default mixed mode where a
link can have an arbitrary mix of hosts and/or routers - some link can have an arbitrary mix of hosts and/or routers - some
implementing legacy Neighbor Discovery and some implementing the implementing legacy Neighbor Discovery and some implementing the
optimizations in this specification. The optimizations provide optimizations in this specification. The optimizations provide
incremental benefits to hosts as soon as the first updated routers incremental benefits to hosts as soon as the first updated routers
are deployed on a link. are deployed on a link.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 18, 2014. This Internet-Draft will expire on January 5, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Goals and Requirements . . . . . . . . . . . . . . . . . . . . 6 2. Goals and Requirements . . . . . . . . . . . . . . . . . . . 5
2.1. Mixed-Mode Operations . . . . . . . . . . . . . . . . . . 7 2.1. Mixed-Mode Operations . . . . . . . . . . . . . . . . . . 5
3. Changes to ND state management . . . . . . . . . . . . . . . . 7 3. Changes to ND state management . . . . . . . . . . . . . . . 6
4. Definition Of Terms . . . . . . . . . . . . . . . . . . . . . 7 4. Definition Of Terms . . . . . . . . . . . . . . . . . . . . . 6
5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Proxying to handle Mixed mode . . . . . . . . . . . . . . 11 5.1. Proxying to handle Mixed mode . . . . . . . . . . . . . . 9
6. New Neighbor Discovery Options and Messages . . . . . . . . . 11 6. New Neighbor Discovery Options and Messages . . . . . . . . . 10
6.1. Router Advertisement flag for NEARs . . . . . . . . . . . 11 6.1. Router Advertisement flag for NEARs . . . . . . . . . . . 10
6.2. Address Registration Option (ARO) . . . . . . . . . . . . 12 6.2. Address Registration Option (ARO) . . . . . . . . . . . . 10
6.3. Registrar Address Option (RAO) . . . . . . . . . . . . . . 14 6.3. Registrar Address Option (RAO) . . . . . . . . . . . . . 12
7. Conceptual Data Structures . . . . . . . . . . . . . . . . . . 15 7. Conceptual Data Structures . . . . . . . . . . . . . . . . . 14
8. Host Behavior . . . . . . . . . . . . . . . . . . . . . . . . 16 8. Host Behavior . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Host and/or Interface Initialization . . . . . . . . . . . 16 8.1. Host and/or Interface Initialization . . . . . . . . . . 14
8.2. Host Receiving Router Advertisements . . . . . . . . . . . 16 8.2. Host Receiving Router Advertisements . . . . . . . . . . 15
8.3. Timing out Registrar List entries . . . . . . . . . . . . 17 8.3. Timing out Registrar List entries . . . . . . . . . . . . 15
8.4. Sending AROs . . . . . . . . . . . . . . . . . . . . . . . 17 8.4. Sending AROs . . . . . . . . . . . . . . . . . . . . . . 16
8.5. Receiving Neighbor Advertisements . . . . . . . . . . . . 18 8.5. Receiving Neighbor Advertisements . . . . . . . . . . . . 16
8.6. Host Management of the TID . . . . . . . . . . . . . . . . 18 8.6. Host Management of the TID . . . . . . . . . . . . . . . 17
8.7. Refreshing a Registration . . . . . . . . . . . . . . . . 18 8.7. Refreshing a Registration . . . . . . . . . . . . . . . . 17
8.8. De-registering . . . . . . . . . . . . . . . . . . . . . . 19 8.8. De-registering . . . . . . . . . . . . . . . . . . . . . 17
8.9. Refreshing RA information . . . . . . . . . . . . . . . . 19 8.9. Refreshing RA information . . . . . . . . . . . . . . . . 18
8.10. Sleep and Wakeup . . . . . . . . . . . . . . . . . . . . . 21 8.10. Sleep and Wakeup . . . . . . . . . . . . . . . . . . . . 19
8.11. Receiving Redirects . . . . . . . . . . . . . . . . . . . 21 8.11. Receiving Redirects . . . . . . . . . . . . . . . . . . . 20
8.12. Movement Detection . . . . . . . . . . . . . . . . . . . . 21 8.12. Movement Detection . . . . . . . . . . . . . . . . . . . 20
9. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 21 9. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Router and/or Interface Initialization . . . . . . . . . . 21 9.1. Router and/or Interface Initialization . . . . . . . . . 20
9.2. Receiving Router Solicitations . . . . . . . . . . . . . . 22 9.2. Receiving Router Solicitations . . . . . . . . . . . . . 21
9.3. Periodic Multicast RA for legacy hosts . . . . . . . . . . 22 9.3. Periodic Multicast RA for legacy hosts . . . . . . . . . 21
9.4. Multicast RA when new information . . . . . . . . . . . . 22 9.4. Multicast RA when new information . . . . . . . . . . . . 21
9.5. Receiving ARO . . . . . . . . . . . . . . . . . . . . . . 23 9.5. Receiving ARO . . . . . . . . . . . . . . . . . . . . . . 21
9.6. NCE Management in NEARs . . . . . . . . . . . . . . . . . 23 9.6. NCE Management in NEARs . . . . . . . . . . . . . . . . . 22
9.7. Sending non-zero status in ARO . . . . . . . . . . . . . . 24 9.7. Sending non-zero status in ARO . . . . . . . . . . . . . 23
9.8. Timing out Registered NCEs . . . . . . . . . . . . . . . . 24 9.8. Timing out Registered NCEs . . . . . . . . . . . . . . . 23
9.9. Router Advertisement Consistency . . . . . . . . . . . . . 25 9.9. Router Advertisement Consistency . . . . . . . . . . . . 23
9.10. Sending Redirects . . . . . . . . . . . . . . . . . . . . 25 9.10. Sending Redirects . . . . . . . . . . . . . . . . . . . . 24
9.11. Providing Information to Routing Protocols . . . . . . . . 25 9.11. Providing Information to Routing Protocols . . . . . . . 24
9.12. Creating Legacy NCEs . . . . . . . . . . . . . . . . . . . 25 9.12. Creating Legacy NCEs . . . . . . . . . . . . . . . . . . 24
9.13. Proxy Address Resolution and DAD for Legacy Hosts . . . . 25 9.13. Proxy Address Resolution and DAD for Legacy Hosts . . . . 24
10. Handling ND DoS Attack . . . . . . . . . . . . . . . . . . . . 26 10. Handling ND DoS Attack . . . . . . . . . . . . . . . . . . . 25
11. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . . 27 11. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . . 26
12. Interaction with other protocols . . . . . . . . . . . . . . . 27 12. Interaction with other protocols . . . . . . . . . . . . . . 26
12.1. Detecting Network Attachment (DNA) . . . . . . . . . . . . 28 12.1. Detecting Network Attachment (DNA) . . . . . . . . . . . 26
12.2. DHCPv6 Interaction . . . . . . . . . . . . . . . . . . . . 28 12.2. DHCPv6 Interaction . . . . . . . . . . . . . . . . . . . 27
12.3. Other use of Multicast . . . . . . . . . . . . . . . . . . 28 12.3. Other use of Multicast . . . . . . . . . . . . . . . . . 27
12.4. VRRP Interaction . . . . . . . . . . . . . . . . . . . . . 28 12.4. VRRP Interaction . . . . . . . . . . . . . . . . . . . . 27
13. Updated Neighbor Discovery Constants . . . . . . . . . . . . 27
13. Updated Neighbor Discovery Constants . . . . . . . . . . . . . 29 14. Security Considerations . . . . . . . . . . . . . . . . . . . 28
14. Security Considerations . . . . . . . . . . . . . . . . . . . 29 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 16. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 29
16. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 30 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 18. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 30
18. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 31 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 19.1. Normative References . . . . . . . . . . . . . . . . . . 31
19.1. Normative References . . . . . . . . . . . . . . . . . . . 32 19.2. Informative References . . . . . . . . . . . . . . . . . 31
19.2. Informative References . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction 1. Introduction
IPv6 Neighbor Discovery [RFC4861] was defined at a time when local IPv6 Neighbor Discovery [RFC4861] was defined at a time when local
area networks had different properties than today. A common link was area networks had different properties than today. A common link was
the yellow-coax shared wire Ethernet, where a link-layer multicast the yellow-coax shared wire Ethernet, where a link-layer multicast
and unicast worked the same - send the packet on the wire and the and unicast worked the same - send the packet on the wire and the
interested receivers will pick it up. Thus the network cost interested receivers will pick it up. Thus the network cost
(ignoring any processing cost on the receivers that might not (ignoring any processing cost on the receivers that might not
completely filter out Ethernet multicast addresses that they did not completely filter out Ethernet multicast addresses that they did not
skipping to change at page 5, line 27 skipping to change at page 4, line 9
hosts at the time was slow and disruptive process. hosts at the time was slow and disruptive process.
Under the above assumptions it was quite efficient to maintain the Under the above assumptions it was quite efficient to maintain the
shared state of the link such as the prefixes and their lifetimes shared state of the link such as the prefixes and their lifetimes
using periodic multicast Router Advertisement messages. It was also using periodic multicast Router Advertisement messages. It was also
efficient to use multicast Neighbor Solicitations for address efficient to use multicast Neighbor Solicitations for address
resolution as a slight improvement over the broadcast use in ARP. resolution as a slight improvement over the broadcast use in ARP.
And finally, checking for a potential duplicate IPv6 address using And finally, checking for a potential duplicate IPv6 address using
broadcast was efficient and natural. broadcast was efficient and natural.
Since then we've seen a tremedous change with the wide-spread Since then we've seen a tremendous change with the wide-spread
deployment of WiFi and other wireless network technologies. WiFi is deployment of WiFi and other wireless network technologies. WiFi is
a case in point in that it provides the same network service a case in point in that it provides the same network service
abstraction as Ethernet and is often bridged with Ethernets, meaning abstraction as Ethernet and is often bridged with Ethernets, meaning
that the Neighbor Discovery software on hosts and routers might be that the Neighbor Discovery software on hosts and routers might be
unaware that WiFi is being used. Yet the performance and reliability unaware that WiFi is being used. Yet the performance and reliability
of multicast is quite different than for unicast on WiFi (see for of multicast is quite different than for unicast on WiFi (see for
instance [I-D.vyncke-6man-mcast-not-efficient]). Similarly 3GPP and instance [I-D.vyncke-6man-mcast-not-efficient]). Similarly 3GPP and
M2M networks and devices will benefit from a standard specification M2M networks and devices will benefit from a standard specification
for optimized Neighbor discovery. Even wired networks have evolved for optimized Neighbor discovery. Even wired networks have evolved
substantially with modern switch fabrics using explicit packet substantially with modern switch fabrics using explicit packet
skipping to change at page 6, line 9 skipping to change at page 4, line 40
Some of the above trends were observed early (e.g., Ohta-san Some of the above trends were observed early (e.g., Ohta-san
commented on Neighbor Discovery being inefficient on WiFi a long time commented on Neighbor Discovery being inefficient on WiFi a long time
back) but the issues were not broadly understood. The issues were back) but the issues were not broadly understood. The issues were
raised in the 6LowPAN context where the desire was to run IPv6 over raised in the 6LowPAN context where the desire was to run IPv6 over
low-power radio networks and battery operated devices. That lead to low-power radio networks and battery operated devices. That lead to
defining a set of optimizations [RFC6775] for that specific category defining a set of optimizations [RFC6775] for that specific category
of links. However, the trends are not limited to such specific link of links. However, the trends are not limited to such specific link
types. types.
This document applies what we have learned from 6LowPAN to all link This document applies what we have learned from 6LowPAN to all link
types, by reusing existing support from base Neighbor Discovery (such types. That includes reusing existing support from base Neighbor
as Redirect) and from 6LowPAN (Address Registration Option) and Discovery (such as Redirect messages) and reusing from 6LowPAN-ND
adding pieces to import the robustness with redundant routers. (Address Registration Option). There are additions above and beyond
that to improve the robustness with redundant routers and to support
mixed mode.
The optimizations are done in a way to provide incremental benefits. The optimizations are done in a way to provide incremental benefits.
As soon as there is at least one router on a link which supports As soon as there is at least one router on a link which supports
these optimizations, then the updated hosts on the link can sleep these optimizations, then the updated hosts on the link can sleep
better. better, while co-existing on the same link with unmodified hosts.
2. Goals and Requirements 2. Goals and Requirements
The goal is to remove as much Neighbor Discovery multicast traffic on The goal is to remove as much Neighbor Discovery multicast traffic on
the link as possible, and handle Duplicate Address Detection (DAD) the link as possible, and handle Duplicate Address Detection (DAD)
without requiring the hosts to always be awake. without requiring the hosts to always be awake.
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 for multicast networks without MLD
without MLD snooping switches. Moreover, in the MLD-snooping snooping switches. Moreover, in the MLD-snooping networks the MLD
networks the MLD switches will deal with less number of multicasts. switches will deal with less number of multicasts.
The problems that will be addresses are: The requirements handle are:
Remove the use of multicast for DAD and Address Resolution (no Remove the use of multicast for DAD and Address Resolution (no
multicast NS messages), and remove periodic multicast RAs. Some multicast NS messages), and remove periodic multicast RAs. Some
multicast RS and RA are needed to handle the arrival of new hosts multicast RS and RA are needed to handle the arrival of new hosts
and routers on the link since they need to bootstrap to find each and routers on the link since they need to bootstrap to find each
other. other.
Remove the need for hosts to always be awake to defend their Remove the need for hosts to always be awake to defend their
addresses by responding to any DAD probes. addresses by responding to any DAD probes.
skipping to change at page 7, line 10 skipping to change at page 5, line 42
a complete set of Neighbor Cache Entries (NCEs) for all hosts on a complete set of Neighbor Cache Entries (NCEs) for all hosts on
the link. Hence there is no need for it to send Neighbor the link. Hence there is no need for it to send Neighbor
Solicitations. Thus it can avoid the problem specified in Solicitations. Thus it can avoid the problem specified in
[RFC6583]. [RFC6583].
The optimized solution SHOULD be independent of the addresses The optimized solution SHOULD be independent of the addresses
allocation mechanism. In addition to supporting SLAAC [RFC4862] allocation mechanism. In addition to supporting SLAAC [RFC4862]
and DHCPv6 [RFC3315] it SHOULD also work with hosts with 'Privacy and DHCPv6 [RFC3315] it SHOULD also work with hosts with 'Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6'[RFC4941] and with stable IPv6 private addresses IPv6'[RFC4941] and with stable IPv6 private addresses
[I-D.ietf-6man-stable-privacy-addresses]. [I-D.ietf-6man-stable-privacy-addresses] thus it handles the
recommendations in [I-D.ietf-6man-default-iids].
2.1. Mixed-Mode Operations 2.1. Mixed-Mode Operations
Mixed-Mode operation is the protocol behavior when the IPv6 subnet is Mixed-Mode operation is the protocol behavior when the IPv6 subnet is
composed of legacy IPv6 Neighbor Discovery compliant nodes and composed of legacy IPv6 Neighbor Discovery compliant nodes and
efficiency-aware IPv6 nodes implementing this specification. efficiency-aware IPv6 nodes implementing this specification.
The mixed-mode model SHOULD support arbitrary combinations of legacy The mixed-mode model SHOULD support arbitrary combinations of legacy
[RFC4861] hosts and/or routers with new hosts and/or routers on a [RFC4861] hosts and/or routers with new hosts and/or routers on a
link. The introduction of one new router SHOULD provide improved link. The introduction of one new router SHOULD provide improved
services to a new host, allowing the new host to avoid multicast and services to a new host, allowing the new host to avoid multicast and
not requring the host to be awake to defend its IPv6 addresses using not requiring the host to be awake to defend its IPv6 addresses using
DAD. DAD.
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 legacy IPv6 ND [RFC4861] knobs to determine whether it is running in legacy IPv6 ND [RFC4861]
or Efficiency Aware only mode (no-legacy mode) or both (Mixed mode). or Efficiency Aware only mode (no-legacy mode) or both (Mixed mode).
3. Changes to ND state management 3. Changes to ND state management
These optimizations change some fundamental aspects of Neighbor These optimizations change some fundamental aspects of Neighbor
Discovery. Firstly, it moves the distributed address resolution Discovery. Firstly, it moves the distributed address resolution
state (each node responding to a multicast NS for its own addresses) state (each node responding to a multicast NS for its own addresses)
to a set of routers which maintain a list of Address Registrations to a set of routers which maintain a list of Address Registrations
for the hosts. Secondly, the information distributed in Router for the hosts. Secondly, the information distributed in Router
Advertisements changes from being periodically flooded by the routers Advertisements changes from being periodically flooded by the routers
to explicit requests from the hosts for refreshed information using to explicit requests from the hosts for refreshed information using
Router Solicitations. unicast Router Solicitations.
4. Definition Of Terms 4. Definition Of Terms
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
IPv6 ND-efficiency-aware Router (NEAR): IPv6 ND-efficiency-aware Router (NEAR):
A router that implements the optimizations specified in this A router that implements the optimizations specified in this
document. This router should be able to handle both legacy IPv6 document. This router should be able to handle both legacy IPv6
nodes and nodes that sends registration request. nodes and nodes that sends registration request.
Efficiency-Aware Host (EAH): Efficiency-Aware Host (EAH):
The EAH is the host which implements the host functionality for The EAH is the host which implements the host functionality for
optimized Neighbor Discovery mentioned in this document. At least optimized Neighbor Discovery mentioned in this document. At least
initially implementations are likely to have a fallback to legacy initially implementations are likely to have a fallback to legacy
Neighbor Discovery when no NEAR is on the link. Neighbor Discovery when no NEAR is on the link.
Legacy IPv6 Host: Legacy IPv6 Host:
A IPv6 host that implements [RFC4861] without the extensions in A IPv6 host that implements [RFC4861] without the extensions in
this dociument. this document.
Legacy IPv6 Router: Legacy IPv6 Router:
A IPv6 router that implements [RFC4861] without the extensions in A IPv6 router that implements [RFC4861] without the extensions in
this dociument. this document.
Mixed mode Mixed mode
A NEAR supports both legacy hosts and EAH, with a configuration A NEAR supports both legacy hosts and EAH, with a configuration
knob to disable the support for legacy hosts. Some routers on the knob to disable the support for legacy hosts. Some routers on the
link can be legacy and some can be NEAR. link can be legacy and some can be NEAR.
No-legacy mode No-legacy mode
A mode configured on a NEAR to not support any legacy [RFC4861] A mode configured on a NEAR to not support any legacy [RFC4861]
hosts or routers. Opposite of mixed mode. hosts or routers. Opposite of mixed mode.
skipping to change at page 9, line 15 skipping to change at page 7, line 44
NCE NCE
Neighbor Cache Entry. It is a conceptual data structure Neighbor Cache Entry. It is a conceptual data structure
introduced in section 5.1 of [RFC4861] and further elaborated in introduced in section 5.1 of [RFC4861] and further elaborated in
[RFC6775]. [RFC6775].
TID TID
The Transaction ID is a device generated sequence number used for The Transaction ID is a device generated sequence number used for
registration. This number is used to allow a host to have registration. This number is used to allow a host to have
concurrent registrations with different routers, while also being concurrent registrations with different routers, while also being
able to robustly replace a registration with a new one. It able to robustly replace a registration with a new one. It
facilitates interoperation with protocols like RPL [RFC6550] which facilitates interoperability with protocols like RPL [RFC6550]
use a TID internally to handle host movement. which use a TID internally to handle host movement.
5. Protocol Overview 5. Protocol Overview
In a nutshell, the following basic optimizations are made from the In a nutshell, the following basic optimizations are made from the
original IPv6 Neighbor Discovery protocol [RFC4861]: original IPv6 Neighbor Discovery protocol [RFC4861]:
o Adds Node Registration with the default router(s). o Adds Node Registration with the default router(s).
o Address Resolution and DAD uses the registered addresses instead o Address Resolution and DAD uses the registered addresses instead
of multicast Neighbor Solicitation messages for non-link-local of multicast Neighbor Solicitation messages for non-link-local
skipping to change at page 9, line 40 skipping to change at page 8, line 22
o Supports mixed-mode operation where legacy IPv6 hosts and routers o Supports mixed-mode operation where legacy IPv6 hosts and routers
and NEARs and EAHs can co-exist on the same link. This support and NEARs and EAHs can co-exist on the same link. This support
can be configured off. can be configured off.
When a host powers on it behaves conforms to legacy ND [RFC4861] by When a host powers on it behaves conforms to legacy ND [RFC4861] by
multicasting up to MAX_RTR_SOLICITATIONS Router Solicitations and multicasting up to MAX_RTR_SOLICITATIONS Router Solicitations and
receives Router Advertisements. The additional information in the receives Router Advertisements. The additional information in the
Router Advertisements by the NEARs is used by the EAH to build a list Router Advertisements by the NEARs is used by the EAH to build a list
of IPv6 Address Registrars. As the host is forming its IPv6 of IPv6 Address Registrars. As the host is forming its IPv6
addresses (using any of the many statless and stateful IPv6 address addresses (using any of the many stateless and stateful IPv6 address
allocation mechanism) then, instead of using a multicast DAD message, allocation mechanism) then, instead of using a multicast DAD message,
it unicasts an Neighbor Solicitation with the new Address it unicasts an Neighbor Solicitation with the new Address
Registration Option (ARO) to the Registrars. Assuming an IPv6 Registration Option (ARO) to the Registrars. Assuming an IPv6
addresses are not duplicate the EAH receives a Neighbor Advertisement addresses are not duplicate the EAH receives a Neighbor Advertisement
with the ARO option from the NEARs. The EAH refreshes the registered with the ARO option from the NEARs. The EAH refreshes the registered
addresses before they expire, thereby removing the need for the EAH addresses before they expire, thereby removing the need for the EAH
to be awake to defend its addresses using DAD as specified in to be awake to defend its addresses using DAD as specified in
[RFC4862] as the NEARs will handle DAD. [RFC4862] as the NEARs will handle DAD.
The routers on the link advertise the prefixes without setting the L The routers on the link advertise the prefixes without setting the L
flag. Thus only the IPv6 link-local addresses are considered on- flag. Thus only the IPv6 link-local addresses are considered on-
link. Thus the hosts will send packets to a default router, and the link. Thus the hosts will send packets to a default router, and the
default routers maintain all the registrations. Hence a router will default routers maintain all the registrations. Hence a router will
know the link-layer addresses of all the registered hosts. This know the link-layer addresses of all the registered hosts. This
enables the router to forward the packet (without needing any Address enables the router to forward the packet (without needing any Address
Resolution with the multicast Neighbor Solicitation), and also to Resolution with the multicast Neighbor Solicitation), and also to
send a Redirect to the originating host informing the host of the send a Redirect to the originating host informing the host of the
link-layer address. link-layer address.
Instead of relying on periodic multicast RAs to refresh the lifetimes Instead of relying on periodic multicast RAs to refresh the lifetimes
of prefixes etc, the model in efficiency-aware networks is for the of prefixes etc., the hosts ask for refreshed information by
hosts to ask for refreshed information by unicasting a Router unicasting a Router Solicitation before the information expires.
Solicitation before the information expires.
The periodic multicast RAs are also used to provide new information The periodic multicast RAs may be used to provide new information
such as additional prefixes, radical reduction in the preferred such as additional prefixes, radical reduction in the preferred and/
and/or valid lifetime for a prefix. A host does not know to ask for or valid lifetime for a prefix. A host does not know to ask for such
such information. Thus a router that wishes to quickly disseminate information. Thus a router that wishes to quickly disseminate such
such change can resort to a few multicast RAs, or wait for the hosts change can resort to a few multicast RAs, or wait for the hosts to
to request a refresh using a Router Solicitation. request a refresh using a Router Solicitation.
The routers can crash and loose all their state, including the The routers can crash and loose all their state, including the
Address Registrations. On router initialization the router will Address Registrations. On router initialization the router will
multicast a few initial RAs. The protocol has a Router Epoch multicast a few initial RAs. The protocol has a Router Epoch
mechanism which is used by the hosts to detect that the router has mechanism which is used by the hosts to detect that the router has
lost state. In that case the hosts will immediately re-register lost state. In that case the hosts will immediately re-register
allowing the router to quickly rebuild its Address Registration allowing the router to quickly rebuild its Address Registration
state. state.
Normally it is sufficient for the hosts to register with all the Normally it is sufficient for the hosts to register with all the
skipping to change at page 12, line 28 skipping to change at page 11, line 5
between a refresh of an existing registration and a different host between a refresh of an existing registration and a different host
trying to register an IPv6 address which is already registered by trying to register an IPv6 address which is already registered by
some other host. Thus the requirement is that the unique id is some other host. Thus the requirement is that the unique id is
unique per link, but due to the potential for host mobility across unique per link, but due to the potential for host mobility across
links and subnets it should be globally unique. Both an EUI-64 and a links and subnets it should be globally unique. Both an EUI-64 and a
DUID satisfies that requirement. DUID satisfies that requirement.
The TID is used by the NEARs to handle the case when due to packet The TID is used by the NEARs to handle the case when due to packet
loss one NEAR might have a old registration and another NEAR has a loss one NEAR might have a old registration and another NEAR has a
newer registration. The TID allows them to determine which is more newer registration. The TID allows them to determine which is more
recent. The TID also facilitates the interaction with RPL. recent. The TID also facilitates the interaction with RPL [RFC6550].
An Address Registration Option can be included in unicast Neighbor An Address Registration Option can be included in unicast Neighbor
Solicitation (NS) messages sent by hosts. Thus it can be included in Solicitation (NS) messages sent by hosts. Thus it can be included in
the unicast NS messages that a host sends as part of Neighbor the unicast NS messages that a host sends as part of Neighbor
Unreachability Detection to determine that it can still reach the Unreachability Detection to determine that it can still reach the
default router(s). The ARO is used by the receiving router to default router(s). 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. field indicating the success or failure of the registration.
skipping to change at page 13, line 4 skipping to change at page 11, line 22
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. field indicating the success or failure of the registration.
When the ARO is sent by a host then, for links which have link-layer When the ARO is sent by a host then, for links which have link-layer
addresses, a SLLA option MUST be included. The address that is addresses, a SLLA option MUST be included. The address that is
registered is the IPv6 source address of the Neighbor Solicitation registered is the IPv6 source address of the Neighbor Solicitation
message. Typically a host would have several addresses to register, message. Typically a host would have several addresses to register,
with each one being registered using a separate NS containing an ARO. with each one being registered using a separate NS containing an ARO.
(This approach facilitates applying SeND [RFC3971].) (This approach facilitates applying SeND [RFC3971].)
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Status | Reserved | | Type | Length | Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Res | IDS |T| TID | Registration Lifetime | | Res | IDS |T| TID | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Unique Interface Identifier (variable length) ~ ~ Unique Interface Identifier (variable length) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields: Fields:
Type: 33 [RFC6775] Type: 33 [RFC6775]
Length: 8-bit unsigned integer. The length of the option Length: 8-bit unsigned integer. The length of the option
(including the type and lenth fields) in units of 8 (including the type and length fields) in units of 8
bytes. The value 0 is invalid. bytes. The value 0 is invalid.
Status: 8-bit unsigned integer. Indicates the status of a Status: 8-bit unsigned integer. Indicates the status of a
registration in the NA response. MUST be set to 0 in registration in the NA response. MUST be set to 0 in
NS messages. See [RFC6775]. NS messages. See [RFC6775].
Reserved: 8 bits. This field is unused. It MUST be initialized Reserved: 8 bits. This field is unused. It MUST be initialized
to zero by the sender and MUST be ignored by the to zero by the sender and MUST be ignored by the
receiver. receiver.
skipping to change at page 14, line 36 skipping to change at page 13, line 13
contains the information for both of those. contains the information for both of those.
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 | Num Addresses | | Type | Length | Num Addresses |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Router Epoch | | Reserved | Router Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ IPv6 registratr addresses ~ ~ IPv6 registrar addresses ~
| (Num Addresses) | | (Num Addresses) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Reserved for future extensions ~ ~ Reserved for future extensions ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields: Fields:
Type: TBD (IANA) Type: TBD (IANA)
Length: 8-bit unsigned integer. The length of the option Length: 8-bit unsigned integer. The length of the option
(including the type and lenth fields) in units of 8 (including the type and length fields) in units of 8
bytes. The value 0 is invalid. bytes. The value 0 is invalid.
Num Addresses 16-bit unsigned integer. Set to zero if there are no Num Addresses 16-bit unsigned integer. Set to zero if there are no
addresses i.e., when the option is used to only carry addresses i.e., when the option is used to only carry
the router epoch. NumAdressses*2 + 1 must not exceed the router epoch. NumAdressses*2 + 1 must not exceed
the Length. the Length.
Reserved 16-bit unused field. It MUST be initialized to zero Reserved 16-bit unused field. 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.
skipping to change at page 15, line 25 skipping to change at page 13, line 49
storage and incrementing it, or picking a good random storage and incrementing it, or picking a good random
number. number.
IPv6 registrar addresses Zero or more IPv6 addresses, typically of IPv6 registrar addresses Zero or more IPv6 addresses, typically of
link-local scope. link-local scope.
The receiver MUST silently ignore any data after the IPv6 registrar The receiver MUST silently ignore any data after the IPv6 registrar
addresses field (such data is present when the Length is greater than addresses field (such data is present when the Length is greater than
NumAdressses*2 + 1). NumAdressses*2 + 1).
The Registrar Addresses have their lifetime be the Default Router The Registrar Addresses are subject to the same lifetime as the
Lifetime even when they come from the RAO (thus there is no explicit Default Router Lifetime (thus there is no explicit lifetime field in
lifetime in the RAO). the RAO).
7. Conceptual Data Structures 7. Conceptual Data Structures
In addition to the Conceptual Data structures in [RFC4861] a EAH In addition to the Conceptual Data structures in [RFC4861] a EAH
needs to maintain the new Registrar List for each interface. The needs to maintain the new Registrar List for each interface. The
Registrar List contains the set of IP addresses to which the host Registrar List contains the set of IP addresses to which the host
needs to send Address Registrations. Each IP address has a Router needs to send Address Registrations. Each IP address has a Router
Epoch (used to determine when a router might have lost state). Also, Epoch (used to determine when a router might have lost state). Also,
the host MAY use this data structure to track when it needs to the host MAY use this data structure to track when it needs to
refresh its registrations with the registrar. refresh its registrations with the registrar.
skipping to change at page 16, line 17 skipping to change at page 14, line 41
Registered: Entries that have an explicit registered Registered: Entries that have an explicit registered
lifetime and are kept until this lifetime lifetime and are kept until this lifetime
expires or they are explicitly unregistered. expires or they are explicitly unregistered.
Note that the type of the NCE is orthogonal to the states specified Note that the type of the NCE is orthogonal to the states specified
in [RFC4861]. There can only be one type of NCE for an IP address at in [RFC4861]. There can only be one type of NCE for an IP address at
a time. a time.
8. Host Behavior 8. Host Behavior
A EAH follows [RFC4861] and applicable parts of [RFC6775] as follows A EAH follows [RFC4861] and applicable parts of [RFC6775] as
in this section./ specified in this section./
A EAH implementation MAY be able to fall back to [RFC4861] host A EAH implementation MAY be able to fall back to [RFC4861] host
behavior if there is no NEAR on the link. behavior if there is no NEAR on the link.
8.1. Host and/or Interface Initialization 8.1. Host and/or Interface Initialization
A host multicasts Router Solicitation at system startup or interface A host multicasts Router Solicitation at system startup or interface
initialization as specified in [RFC4861] and its updates such as initialization as specified in [RFC4861] and its updates such as
[I-D.ietf-6man-resilient-rs]. [I-D.ietf-6man-resilient-rs]. If the interface initialization is due
to potential host movement or a wakeup from sleep then the host
initially sends a unicast Neighbor Solicitation to the default
router(s).
Unlike RFC4861 the RS MUST (on link layers which have addresses) Unlike RFC4861 the RS MUST (on link layers which have addresses)
include a SLLA option, which is used by the router to unicast the RA. include a SLLA option, which is used by the router to unicast the RA.
The host is not required to join the solicited-node multicast The host is not required to join the solicited-node multicast
address(es) but it MUST join the all-nodes multicast address. address(es) but it MUST join the all-nodes multicast address.
8.2. Host Receiving Router Advertisements 8.2. Host Receiving Router Advertisements
The RA is validated and processed as specified in [RFC4861] with The RA is validated and processed as specified in [RFC4861] with
skipping to change at page 17, line 22 skipping to change at page 15, line 47
The host can form its IPv6 address using any available mechanism - The host can form its IPv6 address using any available mechanism -
SLAAC, DHCPv6, temporary addresses, etc - as the registration SLAAC, DHCPv6, temporary addresses, etc - as the registration
mechanism is orthogonal and independent of the address allocation. mechanism is orthogonal and independent of the address allocation.
The Address Registration procedure replaces the DAD procedure in The Address Registration procedure replaces the DAD procedure in
[RFC4862]. [RFC4862].
8.3. Timing out Registrar List entries 8.3. Timing out Registrar List entries
The lifetime for the Registrar List entries are taken from the The lifetime for the Registrar List entries are taken from the
Default Router Lifetime in the RA. When an entry is removed the host Default Router Lifetime in the RA. When an entry is removed the host
MAY send AROs with a zero Regisration Lifetime to the removed MAY send AROs with a zero Registration Lifetime to the removed
Registrar Addresses. Registrar Addresses.
8.4. Sending AROs 8.4. Sending AROs
When a host has formed a new IPv6 address, or when the host learns of When a host has formed a new IPv6 address, or when the host learns of
a new NEAR and has existing IPv6 addresses, then it would register a new NEAR and has existing IPv6 addresses, then it would register
the new things (could be new addresses to all the existing the new things (could be new addresses to all the existing
Registrars, or the all the IPv6 addresses with the new Registrar. Registrars, or the all the IPv6 addresses with the new Registrar.
IPv6 link-local addresses are registered as well as the gobals and IPv6 link-local addresses are registered as well as the global
ULA. addresses and ULAs.
If the EAH has a TID then it sets the T-bit and includes the TID in If the EAH has a TID then it sets the T-bit and includes the TID in
the ARO. When the host registers its addresses with multiple the ARO. When the host registers its addresses with multiple
Registrars it uses the same TID. However, if the host has moved Registrars it uses the same TID. However, if the host has moved
(lost its network attachment and determines it is attached to a (lost its network attachment and determines it is attached to a
different link using e.g., DNA [RFC6059]), then it will increment the different link using e.g., DNA [RFC6059]), then it will increment the
TID value and use the new value for subsequent registrations. TID value and use the new value for subsequent registrations.
The host places its Unique Interface Identifier (whether it is a DUID The host places its Unique Interface Identifier (whether it is a DUID
or EUI-64) in the ARO. This identifier is typically kept in stable or EUI-64) in the ARO. This identifier is typically kept in stable
storage so that the host can use the same identifier over time. It storage so that the host can use the same identifier over time. It
MUST use the same identifer when it re-registers its address, since MUST use the same identifier when it re-registers its address, since
otherwise all those will be returned as duplicates. otherwise all those will be returned as duplicates.
The NS which includes the ARO option MUST include a SLLA option on The NS which includes the ARO option MUST include a SLLA option on
link layers that have link-layer addresses. link layers that have link-layer addresses.
The EAH retransmits NS messages with ARO as specified in [RFC6775] The EAH retransmits NS messages with ARO as specified in [RFC6775]
until it receives a NA message from the Registrar containing an ARO. until it receives a NA message from the Registrar containing an ARO.
The number of such retransmissions SHOULD be configurable. The number of such retransmissions SHOULD be configurable.
8.5. Receiving Neighbor Advertisements 8.5. Receiving Neighbor Advertisements
The Neighbor Advertisement are validated and processed as specified The Neighbor Advertisement are validated and processed as specified
in [RFC4861] for example to handle Neighbor Unreachability Detection in [RFC4861] for example to handle Neighbor Unreachability Detection
(NUD). In addition, the host processes any received ARO as follows. (NUD). In addition, the host processes any received ARO as follows.
If the ARO has status code 0 (Success), then the host updates the If the ARO has status code 0 (Success), then the host updates the
information in the Registrar List to know when it next needs to information in the Registrar List to know when it next needs to
refresh the registered address with this Registrar. No further refresh the registered address with this Registrar. No further
processing is needed of the ARO. processing is needed of the ARO.
If the ARO has status code 1 (Duplicate), then the host can not use If the ARO has status code 1 (Duplicate), then the host can not use
the IPv6 address. The host follows the address allocation protocol the IPv6 address. The host follows the address allocation protocol
it used to pick a new address - be that DHCPv6, tempororary it used to pick a new address - be that DHCPv6, temporary addresses,
addresses, etc. etc.
If the ARO has a status code 2 (Neighbor Cache Full) in response to If the ARO has a status code 2 (Neighbor Cache Full) in response to
its registration request from a Registrar, then the node SHOULD its registration request from a Registrar, then the node SHOULD
continue to register the address with other Registrars (when continue to register the address with other Registrars (when
available). available).
TBD: What about other not yet defined status code values? TBD: What about other not yet defined status code values?
8.6. Host Management of the TID 8.6. Host Management of the TID
It is RECOMMENDED that the EAH MAY maintain a sequence counter (TID) It is RECOMMENDED that the EAH MAY maintain a sequence counter (TID)
instable storage according to section 7 of [RFC6550]. The TID is in stable storage according to section 7 of [RFC6550]. The TID is
used to resolve conflicts between different registrations issues by used to resolve conflicts between different registrations issues by
the same host for the same IPv6 address. Conflicts can be due to the same host for the same IPv6 address. Conflicts can be due to
different link-layer addresses, but it can also be due to registering different link-layer addresses, but it can also be due to registering
with different NEARs/Registrars and those routers connect use with different NEARs/Registrars and those routers connect use
protocols like RPL for routing, and RPL uses a TID to habdle movement protocols like RPL for routing, and RPL uses a TID to handle movement
vs. multi-homing. vs. multi-homing.
Thus the same TID should be used if the host is registering its Thus the same TID should be used if the host is registering its
addresses with multiple Registrars at the same time. But if the host addresses with multiple Registrars at the same time. But if the host
might have moved to a different attachment point, then it should might have moved to a different attachment point, then it should
increment its TID for subsequent registrations. increment its TID for subsequent registrations.
8.7. Refreshing a Registration 8.7. Refreshing a Registration
A host SHOULD send a Registration message in order to renew its A host SHOULD send a Registration message in order to renew its
skipping to change at page 19, line 24 skipping to change at page 18, line 4
8.8. De-registering 8.8. De-registering
If anytime, the node decides that it does not need a particular If anytime, the node decides that it does not need a particular
default router's service anymore, the it SHOULD send a de- default router's service anymore, the it SHOULD send a de-
registration message to that NEAR/Registrar. Similarly if the host registration message to that NEAR/Registrar. Similarly if the host
stops using a particular IPv6 address, then it SHOULD de-register stops using a particular IPv6 address, then it SHOULD de-register
that address with all the Registrars it had registered with. This that address with all the Registrars it had registered with. This
applies even if the host was using the IPv6 address, then went to applies even if the host was using the IPv6 address, then went to
sleep, and then picked a different set of IPv6 addresses. In such a sleep, and then picked a different set of IPv6 addresses. In such a
case it is preferred if the host de-registers before going to sleep. case it is preferred if the host de-registers before going to sleep.
A mobile host SHOULD first de-register its addresses before it moves A mobile host SHOULD first de-register its addresses before it moves
away from the subnet (if the mobile host can know that in advance of away from the subnet (if the mobile host can know that in advance of
moving.) moving.)
De-registration is performed by unicasting a Neighbor Solicitation De-registration is performed by unicasting a Neighbor Solicitation
with an ARO where the Registration Lifetime is zero to zero. Such an with an ARO where the Registration Lifetime is set to zero. Such an
ARO should have an incremented TID. De-registration AROs are ARO should have an incremented TID. De-registration AROs are
retransmitted just like other AROs as specified above. retransmitted just like other AROs as specified above.
8.9. Refreshing RA information 8.9. Refreshing RA information
The EAH is responsible for asking the routers for updates to the The EAH is responsible for asking the routers for updates to the
information contained in the Router Advertisements, since the NEARs information contained in the Router Advertisements, since the NEARs
will not multicast such updates. That is done by sending unicast RSs will not multicast such updates. That is done by sending unicast RSs
to the router(s) which will result in unicast RAs. However, to the router(s) which will result in unicast RAs. However,
significant care is required in determining when the RSs should be significant care is required in determining when the RSs should be
skipping to change at page 20, line 5 skipping to change at page 18, line 33
As part of normal operation the Default Routers, Prefixes, and other As part of normal operation the Default Routers, Prefixes, and other
RA information have lifetimes, and there are a few common cases: RA information have lifetimes, and there are a few common cases:
1. The advertised lifetimes are constant i.e., the routers keep on 1. The advertised lifetimes are constant i.e., the routers keep on
advancing the time when the information will expire. advancing the time when the information will expire.
2. The routers decrement the advertised lifetimes in real time i.e., 2. The routers decrement the advertised lifetimes in real time i.e.,
the information is set to expire at a determined time and the information is set to expire at a determined time and
subsequent RAs have lower and lower lifetimes. subsequent RAs have lower and lower lifetimes.
3. The routers forceably expire some information by advertising it 3. The routers forcibly expire some information by advertising it
with a zero lifetime for a while, and then stop advertising it. with a zero lifetime for a while, and then stop advertising it.
4. A router crashes or is silently removed from the network and as a 4. A router crashes or is silently removed from the network and as a
result there are no more updates. For example, that default result there are no more updates. For example, that default
router will expire and there is little benefit in trying to router will expire and there is little benefit in trying to
refresh it by sending lots of RSs. refresh it by sending lots of RSs.
The host's logic for refreshing the information needs to be careful The host's logic for refreshing the information needs to be careful
to not send a large number of RSs, in particular if there is to not send a large number of RSs, in particular if there is
information that is supposed to expire at a fixed time i.e., the information that is supposed to expire at a fixed time i.e., the
skipping to change at page 20, line 29 skipping to change at page 19, line 9
near zero, since that would cause unnecessary RSs. Instead the near zero, since that would cause unnecessary RSs. Instead the
refresh needs to be based on when the information was most recently refresh needs to be based on when the information was most recently
received from the router. A lifetime of 10 minutes that was heard received from the router. A lifetime of 10 minutes that was heard
from the router 10 minutes ago might be normal as part of expiring from the router 10 minutes ago might be normal as part of expiring
some information. But a remaining lifetime of 10 minutes for a some information. But a remaining lifetime of 10 minutes for a
prefix that was last heard 24 hours ago with a lifetime of 24 hours prefix that was last heard 24 hours ago with a lifetime of 24 hours
means that a refresh is in order. means that a refresh is in order.
It is RECOMMENDED that the host track the expiry time (the wall clock It is RECOMMENDED that the host track the expiry time (the wall clock
time when some information will expire) and when it receives an RA time when some information will expire) and when it receives an RA
with that information check whether the expiry time is moving with that information it SHOULD check whether the expiry time is
forward, or appears to be frozen in time. That can tell the moving forward, or appears to be frozen in time. That can tell the
difference between he first two cases above, and avoid unneccesary difference between he first two cases above, and avoid unnecessary
RSs as some information naturally expires. Furthermore it is RSs as some information naturally expires. Furthermore it is
RECOMMENDED that the host track which information was received from RECOMMENDED that the host track which information was received from
which router, so that it can see when a router used to provide the which router, so that it can see when a router used to provide the
information no longer provides it. That helps to see if the third information no longer provides it. That helps to see if the third
case above might be in play. Finally, if a router has not responded case above might be in play. Finally, if a router has not responded
to a few (e.g., MAX_RTR_SOLICITATIONS) attempts to get a refresh, to a few (e.g., MAX_RTR_SOLICITATIONS) attempts to get a refresh,
then the router might be unreachable or dead, and there is little then the router might be unreachable or dead, and there is little
benefit in sending further RSs to that router. When the router comes benefit in sending further RSs to that router. When the router comes
back it will multicast a few RAs. back it will multicast a few RAs.
When the hosts determines that case 1 above is likely, then it should When the hosts determines that case 1 above is likely, then it should
pick a reasonable time to ask for refreshes. The exact refresh pick a reasonable time to ask for refreshes. The exact refresh
behavior is not mandated by this specification, but the same behavior is not mandated by this specification, but the same
implemention strategies as for refreshing address registrations in implementation strategies as for refreshing address registrations in
Section 8.7 can be considered. Section 8.7 can be considered.
A example simple implementation approach is to only base the
refreshing on the default router lifetime (thus ignore prefix and
other lifetime), and pick a refresh time which is 1/3 of the default
router lifetime. If no RA is received, a subsequent refresh can be
done at 2/3 of the default router lifetime. If that does not result
in a RA, then MAX_INITIAL_RTR_ADVERTISEMENTS can be sent as the
router lifetime is about to expire. Note that a default router
lifetime of zero MUST NOT result in sending a RS refresh based on a
timeout of zero.
If the host is unable to refresh the information and as a result ends If the host is unable to refresh the information and as a result ends
up with an empty default router list, or all the default routers are up with an empty default router list, or all the default routers are
marked as UNREACHABLE by NUD, then the host MAY switch to sending marked as UNREACHABLE by NUD, then the host MAY switch to sending
initial multicast Router Solicitations as in Section 8.1. initial multicast Router Solicitations as in Section 8.1.
8.10. Sleep and Wakeup 8.10. Sleep and Wakeup
The protocol allows the sleepy nodes to complete its sleep schedule The protocol allows the sleepy nodes to complete its sleep schedule
without waking up due to periodic Router Advertisement messages or without waking up due to periodic Router Advertisement messages or
due to Multicast Neighbor Solicitation for address resolution. The due to Multicast Neighbor Solicitation for address resolution. The
skipping to change at page 21, line 50 skipping to change at page 20, line 41
The RECOMMENDED default mode of operation for the NEAR is Mixed-mode. The RECOMMENDED default mode of operation for the NEAR is Mixed-mode.
A NEAR should be configured to advertise prefixes without the on-link A NEAR should be configured to advertise prefixes without the on-link
(L-bit) unset. Furthermore, any legacy routers attached to the same (L-bit) unset. Furthermore, any legacy routers attached to the same
link as a NEAR should be configured the same way. That reduces the link as a NEAR should be configured the same way. That reduces the
cases in mixed mode when multicast NS messages are needed between cases in mixed mode when multicast NS messages are needed between
legacy hosts and routers. legacy hosts and routers.
9.1. Router and/or Interface Initialization 9.1. Router and/or Interface Initialization
A NEAR multicasts some initial Router Advertisements at system A NEAR multicasts some initial Router Advertisements
startup or interface initialization as specified in [RFC4861] and its (MAX_INITIAL_RTR_ADVERTISEMENTS) at system startup or interface
updates. initialization as specified in [RFC4861] and its updates.
The NEAR MUST join the all-nodes and all-routers multicast addresses. The NEAR MUST join the all-nodes and all-routers multicast addresses.
In mixed mode it MUST also join the solicited-node multicast In mixed mode it MUST also join the solicited-node multicast
address(es) for its addresses and also for all the Registered NCEs. address(es) for its addresses and also for all the Registered NCEs.
A NEAR picks a new Router Epoch if it has lost the Registered NCEs, A NEAR picks a new Router Epoch if it has lost the Registered NCEs,
which is typically the case for router initialization. Either the which is typically the case for router initialization. Either the
Router Epoch can be stored in stable storage and incremented on each Router Epoch can be stored in stable storage and incremented on each
router initialization, or the NEAR can pick a good random number on router initialization, or the NEAR can pick a good random number on
router initialization. The effect of occasionally picking the same router initialization. The effect of occasionally picking the same
skipping to change at page 24, line 6 skipping to change at page 22, line 46
creates the legacy type of NCE and updates it to a registered NCE if creates the legacy type of NCE and updates it to a registered NCE if
the ARO NS request arrives corresponding to the Legacy NCE. the ARO NS request arrives corresponding to the Legacy NCE.
Successful processing of ARO will complete the NCE creation phase. Successful processing of ARO will complete the NCE 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 or updates the registration life-time is non-zero, the router creates or updates the
Registered NCE for the IPv6 address. If the Neighbor Cache is full Registered NCE for the IPv6 address. If the Neighbor Cache is full
and new entries need to be created, then the router SHOULD respond and new entries need to be created, then the router SHOULD respond
with a NA with status field set to 2. For successful creation of with a NA with status field set to 2. For successful creation of
NCE, the router SHOULD include a copy of ARO and send NA to the NCE, the router SHOULD include a copy of ARO and send NA to the
requestor with the status field 0. A TLLA (Target Link Layer) Option requester with the status field 0. A TLLA (Target Link Layer) Option
is not required with this NA. is not required with this NA.
Typically for efficiency-aware routers (NEAR), the Registration Typically for efficiency-aware routers (NEAR), the Registration
Lifetime and IDS plus Unique Interface Identifier are recorded in the Lifetime and IDS plus Unique Interface Identifier are recorded in the
Neighbor Cache Entry along with the existing information described in Neighbor Cache Entry along with the existing information described in
[RFC4861]. The registered NCE are meant to be ready and reachable [RFC4861]. The registered NCE are meant to be ready and reachable
for communication and no address resolution is required in the link. for communication and no address resolution is required in the link.
An EAH will renew its registration to Registered NCE at the router. An EAH will renew its registration to Registered NCE at the router.
However the router may perform NUD towards the EAH hosts as per However the router may perform NUD towards the EAH hosts as per
[RFC4861]. Should NUD fail the NEAR MUST NOT remove the Registered [RFC4861]. Should NUD fail the NEAR MUST NOT remove the Registered
skipping to change at page 24, line 43 skipping to change at page 23, line 34
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. gets the precedence and the NS without ARO is ignored.
Similarly, if Neighbor Unreachability Detection on the router Similarly, if Neighbor Unreachability Detection on the router
determines that the host is UNREACHABLE (based on the logic in determines that the host is UNREACHABLE (based on the logic in
[RFC4861]), the Neighbor Cache entry SHOULD NOT be deleted but be [RFC4861]), the Neighbor Cache entry SHOULD NOT be deleted but be
retained until the Registration Lifetime expires. If an ARO arrives retained until the Registration Lifetime expires. If an ARO arrives
for an NCE that is in UNCREACHABLE state, that NCE should be marked for an NCE that is in UNREACHABLE state, that NCE should be marked as
as STALE. STALE.
The NEAR router SHOULD deny registration to a new registration The NEAR router SHOULD deny registration to a new registration
request with the status code 2 when it reaches the maximum capacity request with the status code 2 when it reaches the maximum capacity
for handling the neighbor cache. for handling the neighbor cache.
9.9. Router Advertisement Consistency 9.9. Router Advertisement Consistency
The NEAR follows section 6.2.7 in [RFC4861] by receiving RAs from The NEAR follows section 6.2.7 in [RFC4861] by receiving RAs from
other routers (NEAR and legacy) on the link. In addition to the other routers (NEAR and legacy) on the link. In addition to the
checks in that section it verifies that the prefixes to not have the checks in that section it verifies that the prefixes to not have the
skipping to change at page 25, line 25 skipping to change at page 24, line 16
A NEAR sends redirects (with target=destination) to inform the hosts A NEAR sends redirects (with target=destination) to inform the hosts
of the link-layer address of the nodes on the link. of the link-layer address of the nodes on the link.
This can be disabled on specific link types for instance, radio link This can be disabled on specific link types for instance, radio link
technologies with hidden terminal issues. technologies with hidden terminal issues.
9.11. Providing Information to Routing Protocols 9.11. Providing Information to Routing Protocols
If there is a routing protocols like RPL which wants visibility into If there is a routing protocols like RPL which wants visibility into
the location of each IPv6 address, then this can be retrived from the the location of each IPv6 address, then this can be retrieved from
Registered NCEs on the NEAR. the Registered NCEs on the NEAR.
9.12. Creating Legacy NCEs 9.12. Creating Legacy NCEs
In mixed-mode a NEAR will create Legacy NCEs when receiving RA, RS, In mixed-mode a NEAR will create Legacy NCEs when receiving RA, RS,
and NS messages based on the source of those packets. When not it and NS messages based on the source of those packets. When not it
mixed-mode it needs to create Legacy NCEs for other routers by mixed-mode it needs to create Legacy NCEs for other routers by
looking at those packets. looking at those packets.
9.13. Proxy Address Resolution and DAD for Legacy Hosts 9.13. Proxy Address Resolution and DAD for Legacy Hosts
This section applies in mixed mode. It does not apply in no-legacy This section applies in mixed mode. It does not apply in no-legacy
mode. mode.
A NEAR in mixed mode MUST join all solicited-node for all Registered A NEAR in mixed mode MUST join all solicited-node for all Registered
NCEs. NCEs.
The efficient-ND SHOULD continue to support the legacy IPv6 Neighbor The NEAR 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. This form of proxying is to respond with a NA that requests for EAH. This form of proxying is to respond with a NA that
has a TLLAO taken from the Registered NCE for the target. Thus it is has a TLLAO taken from the Registered NCE for the target. Thus it is
unlike ND Proxy as specified in [RFC4389].(Implementations of unlike ND Proxy as specified in [RFC4389].(Implementations of
"Neighbor Discovery Proxies (ND Proxy)" [RFC4389] might proxy using "Neighbor Discovery Proxies (ND Proxy)" [RFC4389] might proxy using
their own MAC address as TLLA, but that is outside of the scope of their own MAC address as TLLA, but that is outside of the scope of
this document.) this document.)
In the context of this specification, proxy means: In the context of this specification, proxy means:
o Responding to DAD probes for a registered NCE. A DAD probe from a o Responding to DAD probes for a registered NCE. A DAD probe from a
legacy host would not contain any ARO, hence the NEAR will assume legacy host would not contain any ARO, hence the NEAR will assume
it is always a duplicate if the IPv6 target address has a it is always a duplicate if the IPv6 target address has a
Registered NCE. Registered NCE.
o Defending a registered address using NA messages with and ARO o Defending a registered address using NA messages with and ARO
option and the Override bit set if the ARO option in the NS option and the Override bit set if the ARO option in the NS
indicates either a different node (different IDS+Unique Interface indicates either a different node (different IDS+Unique Interface
Id) or a older registration (when comparing the TID). Id) or a older registration (when comparing the TID).
o Advertising a registered address using NA messages, asynchronously o Advertising a registered address using NA messages, asynchronously
or as a response to a Neighbor Solicitation messages. or as a response to a Neighbor Solicitation messages.
o Looking up a destination on the link using Neighbor Solicitation o Looking up a destination on the link using Neighbor Solicitation
messages in order to deliver packets arriving for the EAH. messages in order to deliver packets arriving for the EAH.
The NEAR SHOULD also support DAD from a EAH for IPv6 address that
might be in use by a legacy node. Thus when a NEAR in mixed-mode
received an ARO for a new address it SHOULD perform DAD as specified
in [RFC4862] by sending a multicast DAD message. Once that times out
the NEAR can respond to the ARO. If a legacy host responds to the
DAD probe, then the NEAR will respond to the ARO with Status=1
(Duplicate Address).
10. Handling ND DoS Attack 10. 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 an attacker host can send thousands of packets the ND networks when an attacker host can send thousands of packets
to the router with an on-link destination address or sending RS to the router with an on-link destination address or sending RS
messages to initiate a Neighbor Solicitation from the neighboring messages to initiate a Neighbor Solicitation from the neighboring
router which will create a number of INCOMPLETE NCE entries for non- router which will create a number of INCOMPLETE NCE entries for non-
existent nodes in the network resulting in table overflow and denial existent nodes in the network resulting in table overflow and denial
of service of the existing communications. of service of the existing communications.
skipping to change at page 27, line 13 skipping to change at page 26, line 11
routers will still need to create INCOMPLETE NCEs and send NSs, which routers will still need to create INCOMPLETE NCEs and send NSs, which
keeps the DoS opportunity open. However, with fewer legacy hosts the keeps the DoS opportunity open. However, with fewer legacy hosts the
lower rate limits can be applied on creation of INCOMPLETE NCEs. lower rate limits can be applied on creation of INCOMPLETE NCEs.
11. Bootstrapping 11. Bootstrapping
The bootstrapping mechanism described here is applicable for the The bootstrapping mechanism described here is applicable for the
efficiency-aware hosts and routers. At the start, the host uses its efficiency-aware hosts and routers. At the start, the host uses its
link-local address to send Router Solicitation and then it sends the link-local address to send Router Solicitation and then it sends the
Address Registration Option as described in this document in order to Address Registration Option as described in this document in order to
verify the IPv6 address. verify the IPv6 address. Note that on wakeup from sleep and after
potential movement to a different link the host initially sends a
unicast Neighbor Solicitation to the default router(s).
The following step 3 and 4 SHOULD be repeated for all the IPv6 The following step 3 and 4 SHOULD be repeated for all the IPv6
addresses that are used for communications. addresses that are used for communications.
Node Router Node Router
0. |[Forms LL IPv6 addr] | 0. |[Forms LL IPv6 addr] |
1. | ---------- Router Solicitation --------> | 1. | ---------- Router Solicitation --------> |
skipping to change at page 28, line 27 skipping to change at page 27, line 22
12.2. DHCPv6 Interaction 12.2. DHCPv6 Interaction
The protocol mechanisms in this document are orthogonal to the The protocol mechanisms in this document are orthogonal to the
address assignment mechanism in use. If DHCPv6 is used for address address assignment mechanism in use. If DHCPv6 is used for address
assignment by an EAH then, if there are one or more NEARs on the assignment by an EAH then, if there are one or more NEARs on the
subnet, the EAH will replace the DAD check specified in [RFC3315] subnet, the EAH will replace the DAD check specified in [RFC3315]
with Address Registration as specified in this document. with Address Registration as specified in this document.
12.3. Other use of Multicast 12.3. Other use of Multicast
Although the solution described in this document prevents unnecesary Although the solution described in this document prevents unnecessary
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 nor the ability of nodes to join and normal IPv6 multicast packets nor the ability of nodes to join and
leave the multicast group or forwarding multicast traffic or leave the multicast group or forwarding multicast traffic or
responding to multicast queries. responding to multicast queries.
12.4. VRRP Interaction 12.4. VRRP Interaction
A VRRP set of routers can operate with efficient-nd in two different A VRRP set of routers can operate with efficient-nd in two different
ways: ways:
skipping to change at page 29, line 8 skipping to change at page 27, line 46
caches. Such a mechanism is out of scope of this document. caches. Such a mechanism is out of scope of this document.
o Have the hosts register with each router independently. In that o Have the hosts register with each router independently. In that
case the VRRP router includes the RAO with the individual IP case the VRRP router includes the RAO with the individual IP
addresses of the routers in the pair. No synchronization of the addresses of the routers in the pair. No synchronization of the
neighbor caches are needed in that case. neighbor caches are needed in that case.
13. Updated Neighbor Discovery Constants 13. Updated Neighbor Discovery Constants
This section discusses the updated default values of ND constants This section discusses the updated default values of ND constants
based on [RFC4861] section 10. New and changed constants are listed based on [RFC4861] section 10. New and changed constants are listed
only for efficiency-aware-nd implementation. These values SHOULD be only for efficiency-aware-nd implementation. These values SHOULD be
configurable and tunable to fit implementations and deployment. configurable and tunable to fit implementations and deployment.
Router Constants: Router Constants:
MAX_RTR_ADVERTISEMENTS(NEW) 3 transmissions MAX_RTR_ADVERTISEMENTS(NEW) 3 transmissions
MIN_DELAY_BETWEEN_RAS(CHANGED) 1 second MIN_DELAY_BETWEEN_RAS(CHANGED) 1 second
TENTATIVE_LEGACY_NCE_LIFETIME(NEW) 30 seconds TENTATIVE_LEGACY_NCE_LIFETIME(NEW) 30 seconds
skipping to change at page 30, line 22 skipping to change at page 29, line 14
15. IANA Considerations 15. IANA Considerations
A new flag (E-bit) in RA has been introduced. IANA assignment of the A new flag (E-bit) in RA has been introduced. IANA assignment of the
E-bit flag is required upon approval of this document. E-bit flag is required upon approval of this document.
This document needs a new Neighbor Discovery option type for the RAO. This document needs a new Neighbor Discovery option type for the RAO.
16. Changelog 16. Changelog
Changes from draft-chakrabarti-nordmark-energy-aware-nd-05:
o Fixed typos.
o Clarified that on interface initialization after sleep or
potential movement the host unicasts a NS to the default
router(s).
o Simplified the example timer handling for refreshing RA
information.
o Added handling of DAD from EAH to legacy node that was included in
-04 and lost in the -05 edits.
Changes from draft-chakrabarti-nordmark-energy-aware-nd-04: Changes from draft-chakrabarti-nordmark-energy-aware-nd-04:
o Significantly simplified the description of the protocol. o Significantly simplified the description of the protocol.
o Added clarification on problem statement o Added clarification on problem statement
o Clarified that privacy and temporary addresses will be supported o Clarified that privacy and temporary addresses will be supported
o Added an IDS field in the ARO to allow a DHCP Unique ID (DUID) as o Added an IDS field in the ARO to allow a DHCP Unique ID (DUID) as
an alternative to EUI-64, with room to define other (pseudo) an alternative to EUI-64, with room to define other (pseudo)
skipping to change at page 31, line 23 skipping to change at page 30, line 23
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 discussion in this that are now addressed in the NCE management discussion in this
document. document.
The authors like to thank Dave Thaler, Stuart Cheshire, Jari Arkko, The authors like to thank Dave Thaler, Stuart Cheshire, Jari Arkko,
Ylva Jading, Niklas J. Johnsson, Reda Nedjar, Purvi Shah, Jaume Rius Ylva Jading, Niklas J. Johnsson, Reda Nedjar, Purvi Shah, Jaume Rius
Riu, Fredrik Garneij, Andrew Yourtchenko, Jouni Korhonen, Suresh Riu, Fredrik Garneij, Andrew Yourtchenko, Jouni Korhonen, Suresh
Krishnan, Brian Haberman, Anders Brandt, Mark Smith, Lorenzo Colitti, Krishnan, Brian Haberman, Anders Brandt, Mark Smith, Lorenzo Colitti,
David Miles, Eric Vyncke, Mark ZZZ Smith, Mikael Abrahammsson, Eric David Miles, Eric Vyncke, Mark ZZZ Smith, Mikael Abrahammsson, Eric
Levy-Abignoli, and Carsten Bormann for their useful comments and Levy-Abignoli, and Carsten Bormann for their useful comments and
suggestions on this work. suggestions on this work.
18. Open Issues 18. Open Issues
The known open issues are: The known open issues are:
o IPv6 link-local addresses are always on-link and in this version o IPv6 link-local addresses are always on-link and in this version
of the document that results in multicast NS messages. The of the document that results in multicast NS messages. The
techique used in 6LowPAN-ND is too restrictive (extract the link- technique used in 6LowPAN-ND is too restrictive (extract the link-
layer address from the IID). Should we send link-locals to layer address from the IID). Should we send link-locals to
routers and depend on Redirect? routers and depend on Redirect?
o If the Router Epoch is critical then we will see a RAO in all the o If the Router Epoch is critical then we will see a RAO in all the
RAs sent by NEARs. In such a case we don't need the E-bit in the RAs sent by NEARs. In such a case we don't need the E-bit in the
RA. RA.
o Editorial: Add Comparison with 6lowpan-nd and 4861? o Editorial: Add Comparison with 6lowpan-nd and 4861?
o Editorial: Verify and update the description in this document to
make it complete removing the need to read 6LowPAN-ND.
o When a router has new information for the RA, currently it takes a o When a router has new information for the RA, currently it takes a
while to dissemitate that to sleeping nodes as this depends on while to disseminate that to sleeping nodes as this depends on
when the hosts send a RS. We could potentially improve this is we when the hosts send a RS. We could potentially improve this is we
could have an "information epoch number" in the ARO sent in the could have an "information epoch number" in the ARO sent in the
NA. But that only helps if the registrations are refreshed more NA. But that only helps if the registrations are refreshed more
frequently that the RA information. frequently that the RA information.
o Future? Currently if a router changes its information, a sleeping o Future? Currently if a router changes its information, a sleeping
host would not find out when it wakes up and sends the NS with host would not find out when it wakes up and sends the NS with
ARO. That could be improved if we fit the Router Epoch in NA/ARO. ARO. That could be improved if we fit the Router Epoch in NA/ARO.
But there is no room for 16 bits. But there is no room for 16 bits.
skipping to change at page 32, line 46 skipping to change at page 32, line 5
"Transmission of IPv6 Packets over IEEE 802.15.4 "Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007. Networks", RFC 4944, September 2007.
[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann,
"Neighbor Discovery Optimization for IPv6 over Low-Power "Neighbor Discovery Optimization for IPv6 over Low-Power
Wireless Personal Area Networks (6LoWPANs)", RFC 6775, Wireless Personal Area Networks (6LoWPANs)", RFC 6775,
November 2012. November 2012.
19.2. Informative References 19.2. Informative References
[I-D.ietf-6man-default-iids]
Gont, F., Cooper, A., Thaler, D., and W. Will,
"Recommendation on Stable IPv6 Interface Identifiers",
draft-ietf-6man-default-iids-00 (work in progress),
January 2014.
[I-D.ietf-6man-resilient-rs] [I-D.ietf-6man-resilient-rs]
Krishnan, S., Anipko, D., and D. Thaler, "Packet loss Krishnan, S., Anipko, D., and D. Thaler, "Packet loss
resiliency for Router Solicitations", resiliency for Router Solicitations", draft-ietf-6man-
draft-ietf-6man-resilient-rs-02 (work in progress), resilient-rs-03 (work in progress), April 2014.
October 2013.
[I-D.ietf-6man-stable-privacy-addresses] [I-D.ietf-6man-stable-privacy-addresses]
Gont, F., "A Method for Generating Semantically Opaque Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", Autoconfiguration (SLAAC)", draft-ietf-6man-stable-
draft-ietf-6man-stable-privacy-addresses-17 (work in privacy-addresses-17 (work in progress), January 2014.
progress), January 2014.
[I-D.vyncke-6man-mcast-not-efficient] [I-D.vyncke-6man-mcast-not-efficient]
Vyncke, E., Thubert, P., Levy-Abegnoli, E., and A. Vyncke, E., Thubert, P., Levy-Abegnoli, E., and A.
Yourtchenko, "Why Network-Layer Multicast is Not Always Yourtchenko, "Why Network-Layer Multicast is Not Always
Efficient At Datalink Layer", Efficient At Datalink Layer", draft-vyncke-6man-mcast-not-
draft-vyncke-6man-mcast-not-efficient-01 (work in efficient-01 (work in progress), February 2014.
progress), February 2014.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756, Discovery (ND) Trust Models and Threats", RFC 3756, May
May 2004. 2004.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005. Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
Proxies (ND Proxy)", RFC 4389, April 2006. Proxies (ND Proxy)", RFC 4389, April 2006.
skipping to change at page 33, line 46 skipping to change at page 33, line 6
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007. IPv6", RFC 4941, September 2007.
[RFC5175] Haberman, B. and R. Hinden, "IPv6 Router Advertisement [RFC5175] Haberman, B. and R. Hinden, "IPv6 Router Advertisement
Flags Option", RFC 5175, March 2008. Flags Option", RFC 5175, March 2008.
[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for
Detecting Network Attachment in IPv6", RFC 6059, Detecting Network Attachment in IPv6", RFC 6059, November
November 2010. 2010.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011. in IPv6", RFC 6275, July 2011.
[RFC6496] Krishnan, S., Laganier, J., Bonola, M., and A. Garcia- [RFC6496] Krishnan, S., Laganier, J., Bonola, M., and A. Garcia-
Martinez, "Secure Proxy ND Support for SEcure Neighbor Martinez, "Secure Proxy ND Support for SEcure Neighbor
Discovery (SEND)", RFC 6496, February 2012. Discovery (SEND)", RFC 6496, February 2012.
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
 End of changes. 62 change blocks. 
141 lines changed or deleted 187 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/