draft-narayanan-dna-bcp-00.txt   draft-narayanan-dna-bcp-01.txt 
DNA Working Group S. Narayanan DNA Working Group S. Narayanan
Internet-Draft Panasonic Internet-Draft Panasonic
Expires: December 21, 2004 G. Daley Expires: April 12, 2005 G. Daley
Monash University CTIE Monash University CTIE
N. Montavont N. Montavont
LSIIT - ULP LSIIT - ULP
June 22, 2004 October 12, 2004
Detecting Network Attachment in IPv6 - Best Current Practices Detecting Network Attachment in IPv6 - Best Current Practices
draft-narayanan-dna-bcp-00.txt draft-narayanan-dna-bcp-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with and any of which I become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
  Skipping to change at page 1, line 37:
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 21, 2004. This Internet-Draft will expire on April 12, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
Hosts experiencing rapid link-layer changes may require further Hosts experiencing rapid link-layer changes may require further
configuration change detection procedures than more traditional fixed configuration change detection procedures than more traditional fixed
hosts. Detecting Network Attachment is a set of strategies for hosts. Detecting Network Attachment is a set of strategies for
determining configuration validity in wireless or rapidly changing determining configuration validity in wireless or rapidly changing
environments. This document details best current practice for environments. This document details best current practice for
Detecting Network Attachment in IPv6 hosts using Neighbor Discovery Detecting Network Attachment in IPv6 hosts using Neighbor Discovery
procedures. procedures.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Structure of this Document . . . . . . . . . . . . . . . . 4 1.1 Structure of this Document . . . . . . . . . . . . . . . . 5
2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 5 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 6
3. Background & Motivation for DNA . . . . . . . . . . . . . . . 5 3. Background & Motivation for DNA . . . . . . . . . . . . . . . 6
4. Current Practice for Hosts Supporting DNA . . . . . . . . . . 6 4. Detecting Network Attachment Steps . . . . . . . . . . . . . . 7
4.1 IP configurations relevant to DNA . . . . . . . . . . . . 6 4.1 Validation of current configuration . . . . . . . . . . . 7
4.1.1 Router and Prefix Discovery . . . . . . . . . . . . . 6 4.2 Reachability detection . . . . . . . . . . . . . . . . . . 8
4.1.2 Address Configuration . . . . . . . . . . . . . . . . 7
4.1.3 Neighbor Caches . . . . . . . . . . . . . . . . . . . 8
4.1.4 Multicast Listener State . . . . . . . . . . . . . . . 10
4.1.5 Mobility Management . . . . . . . . . . . . . . . . . 10
4.1.6 Other Configuration . . . . . . . . . . . . . . . . . 11
4.2 Validation using Neighbor Discovery . . . . . . . . . . . 11
4.3 Further Procedures on Detection of Network Attachment . . 12
5. Detecting Network Attachment Steps . . . . . . . . . . . . . . 12 5. Validation of current configuration . . . . . . . . . . . . . 8
5.1 Validity of configuration . . . . . . . . . . . . . . . . 12 5.1 Current protocols . . . . . . . . . . . . . . . . . . . . 8
5.2 Reachability detection . . . . . . . . . . . . . . . . . . 13 5.1.1 Link Change and Router Discovery . . . . . . . . . . . 8
5.1.2 Complete Prefix list . . . . . . . . . . . . . . . . . 9
5.1.3 Router advertisement Timers . . . . . . . . . . . . . 9
5.2 Additional information . . . . . . . . . . . . . . . . . . 10
5.2.1 Making use of Prior Information . . . . . . . . . . . 10
5.2.2 Transient Link Availability . . . . . . . . . . . . . 10
5.2.3 Further Procedures on Detection of Network
Attachment . . . . . . . . . . . . . . . . . . . . . . 11
5.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . 11
6. Initiation of DNA Procedures . . . . . . . . . . . . . . . . . 15 6. Reachability Detection . . . . . . . . . . . . . . . . . . . . 11
6.1 Hint Reception and Processing . . . . . . . . . . . . . . 17 6.1 Current protocols . . . . . . . . . . . . . . . . . . . . 13
6.2 Handling Hints from Other Layers . . . . . . . . . . . . . 17 6.1.1 Specific (Neighbor Solicitation) Tests . . . . . . . . 13
6.3 Timer Based Hints . . . . . . . . . . . . . . . . . . . . 17 6.1.2 Non-Specific (Router Solicitation) Tests . . . . . . . 13
6.4 Simultaneous Hints . . . . . . . . . . . . . . . . . . . . 18 6.1.3 Trade-offs in Reachability Testing . . . . . . . . . . 14
6.5 Hint Validity and Hysteresis . . . . . . . . . . . . . . . 19 6.1.4 Hybrid mechanism . . . . . . . . . . . . . . . . . . . 15
6.6 Hint Management for Inactive Hosts . . . . . . . . . . . . 19 6.1.5 Authorization for using the router . . . . . . . . . . 15
6.2 Additional information . . . . . . . . . . . . . . . . . . 15
6.2.1 Wireless propagation . . . . . . . . . . . . . . . . . 15
6.2.2 Asymmetric Reachability . . . . . . . . . . . . . . . 16
6.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . 16
7. Validation of configuration . . . . . . . . . . . . . . . . . 20 7. Initiation of DNA Procedures . . . . . . . . . . . . . . . . . 16
7.1 Making use of Prior Information . . . . . . . . . . . . . 20 7.1 Hint Reception and Processing . . . . . . . . . . . . . . 17
7.2 Transient Link Availability . . . . . . . . . . . . . . . 21 7.2 Handling Hints from Other Layers . . . . . . . . . . . . . 17
7.3 Link Change and Router Discovery . . . . . . . . . . . . . 21 7.3 Timer Based Hints . . . . . . . . . . . . . . . . . . . . 18
7.4 Validating configuration in Constrained Topologies . . . . 22 7.4 Simultaneous Hints . . . . . . . . . . . . . . . . . . . . 18
7.5 Validating configuration in Arbitrary Topologies . . . . . 23 7.5 Hint Validity and Hysteresis . . . . . . . . . . . . . . . 19
7.6 Dealing with Incomplete Information . . . . . . . . . . . 23 7.6 Hint Management for Inactive Hosts . . . . . . . . . . . . 19
7.7 Configuration Algorithms . . . . . . . . . . . . . . . . . 24
8. Reachability Detection . . . . . . . . . . . . . . . . . . . . 27 8. Current Practice for Configuration Change Detection on
8.1 Wireless propagation . . . . . . . . . . . . . . . . . . . 28 Hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.2 Asymmetric Reachability . . . . . . . . . . . . . . . . . 28 8.1 Router and Prefix Discovery . . . . . . . . . . . . . . . 21
8.3 Specific (Neighbor Solicitation) Tests . . . . . . . . . . 28 8.2 Address Autoconfiguration . . . . . . . . . . . . . . . . 21
8.4 Non-Specific (Router Solicitation) Tests . . . . . . . . . 29 8.3 Neighbor Discovery . . . . . . . . . . . . . . . . . . . . 21
8.5 Trade-offs in Reachability Testing . . . . . . . . . . . . 29 8.4 Dynamic Host Configuration . . . . . . . . . . . . . . . . 22
8.5 Multicast Listener State . . . . . . . . . . . . . . . . . 23
8.6 Mobility Management . . . . . . . . . . . . . . . . . . . 23
8.7 Other Configuration . . . . . . . . . . . . . . . . . . . 24
9. Complications to Detecting Network Attachment . . . . . . . . 30 9. Current Practice for Routers supporting DNA . . . . . . . . . 24
9.1 Tentative Addressing . . . . . . . . . . . . . . . . . . . 30 9.1 Router Advertisement Intervals . . . . . . . . . . . . . . 24
9.2 Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 31 9.2 Unicast Response Transmission . . . . . . . . . . . . . . 26
9.3 Router Configurations . . . . . . . . . . . . . . . . . . 31 9.3 Point-to-Point Links . . . . . . . . . . . . . . . . . . . 27
9.4 Overlapping Coverage . . . . . . . . . . . . . . . . . . . 31 9.4 Prefix Advertisement . . . . . . . . . . . . . . . . . . . 27
9.5 Multicast Snooping . . . . . . . . . . . . . . . . . . . . 32 9.5 Secured Neighbor Discovery . . . . . . . . . . . . . . . . 27
10. Current Practice for Routers supporting DNA . . . . . . . . 32 10. Analysis of Configuration Algorithms . . . . . . . . . . . . 28
10.1 Router Advertisement Intervals . . . . . . . . . . . . . . 32
10.2 Unicast Response Transmission . . . . . . . . . . . . . . 34
10.3 Point-to-Point Links . . . . . . . . . . . . . . . . . . . 34
10.4 Prefix Advertisement . . . . . . . . . . . . . . . . . . . 34
10.5 Secured Neighbor Discovery . . . . . . . . . . . . . . . . 35
11. Security Considerations . . . . . . . . . . . . . . . . . . 35 11. Complications to Detecting Network Attachment . . . . . . . 30
11.1 Replay or impersonation of messages. . . . . . . . . . . . 35 11.1 Tentative Addressing . . . . . . . . . . . . . . . . . . . 30
11.2 Authorization and Detecting Network Attachment . . . . . . 36 11.2 Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 31
11.3 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 36 11.3 Router Configurations . . . . . . . . . . . . . . . . . . 31
11.4 Overlapping Coverage . . . . . . . . . . . . . . . . . . . 32
11.5 Multicast Snooping . . . . . . . . . . . . . . . . . . . . 32
11.6 Link Partition . . . . . . . . . . . . . . . . . . . . . . 32
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 37 12. Security Considerations . . . . . . . . . . . . . . . . . . 32
12.1 Securing Router Discovery . . . . . . . . . . . . . . . . 33
12.2 Replay or impersonation of messages. . . . . . . . . . . . 33
12.3 Authorization and Detecting Network Attachment . . . . . . 34
12.4 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 34
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 35
13.1 Normative References . . . . . . . . . . . . . . . . . . . . 37
13.2 Informative References . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 39 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
14.1 Normative References . . . . . . . . . . . . . . . . . . . . 35
14.2 Informative References . . . . . . . . . . . . . . . . . . . 35
A. Summary of Recommendations . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 37
B. Example State Transition Diagram . . . . . . . . . . . . . . . 43 A. Summary of Recommendations . . . . . . . . . . . . . . . . . . 37
C. DNA With Fast Handovers for Mobile IPv6 . . . . . . . . . . . 43 B. Example State Transition Diagram . . . . . . . . . . . . . . . 41
D. DNA with Candidate Access Router Discovery . . . . . . . . . . 43 C. DNA With Fast Handovers for Mobile IPv6 . . . . . . . . . . . 41
Intellectual Property and Copyright Statements . . . . . . . . 44 D. DNA with Candidate Access Router Discovery . . . . . . . . . . 41
Intellectual Property and Copyright Statements . . . . . . . . 42
1. Introduction 1. Introduction
When operating in changing environments, IPv6 hosts may experience When operating in changing environments, IPv6 hosts may experience
variations in reachability or configuration state over time. For variations in reachability or configuration state over time. For
hosts accessing the Internet over wireless media, such changes may be hosts accessing the Internet over wireless media, such changes may be
caused by changes in wireless propagation or host motion. caused by changes in wireless propagation or host motion.
Detecting Network Attachment (DNA) in IPv6 is the task of checking Detecting Network Attachment (DNA) in IPv6 is the task of checking
for changes in the validity of a host's IP configuration. Changes for changes in the validity of a host's IP configuration. Changes
  Skipping to change at page 4, line 32:
invalid, leaving the actual practice of re-configuration to other invalid, leaving the actual practice of re-configuration to other
subsystems. subsystems.
This document presents the best current practices for IPv6 hosts to This document presents the best current practices for IPv6 hosts to
address the task of Detecting Network Attachment in changing and address the task of Detecting Network Attachment in changing and
wireless environments. wireless environments.
1.1 Structure of this Document 1.1 Structure of this Document
Section 3 of this document provides a background and motivation for Section 3 of this document provides a background and motivation for
Detecting Network Attachment. Section 4 provides an overview of DNA Detecting Network Attachment.
practices for hosts, and their place within the change detection and
configuration cycle.
Elaboration of specific practices for hosts continues in Section 5,
Section 6, Section 7, and Section 8. These sections describe how to
safely determine network attachment with minimal signaling, across a
range of environments.
Topological and host-based challenges which govern the operation of Elaboration of specific practices for hosts in detecting network
DNA procedures are detailed in Section 9. attachment continues in Section 4, Section 5, Section 6, and Section
7. These sections describe how to safely determine network
attachment with minimal signaling, across a range of environments.
Router based configurations which assist hosts' ability to detect While the primary focus of this document is the operation of
network attachment are described in Section 10. intermittently connected hosts, the best current practices for
operation of routers supporting these hosts is defined in Section 9 .
Section 11 Provides security considerations, and details a number of A brief analysis of two known configuration algorithms LCS (Lazy
issues which arise due to wireless connectivity and the changeable Configuration Switching) and ECS (Eager Configuration Switching) is
nature of DNA hosts' internet connections. presented in Section 10. Section 12 Provides security
considerations, and details a number of issues which arise due to
wireless connectivity and the changeable nature of DNA hosts'
internet connections.
This document has a number of appendixes. This document has a number of appendixes.
Appendix A lists the recommendations for systems wishing to support Appendix A lists the recommendations for systems wishing to support
Best Current Practice. Appendix B provides an example state machine Best Current Practice. Appendix B provides an example state machine
for DNA describing knowledge and belief based on the prior listed for DNA describing knowledge and belief based on the prior listed
recommendations. The final two (Appendix C and Appendix D) look at recommendations. The final two (Appendix C and Appendix D) look at
existing experimental protocols that may be used to provide DNA existing experimental protocols that may be used to provide DNA
processes with access network information before arrival on a new processes with access network information before arrival on a new
link. link.
  Skipping to change at page 5, line 27:
to be referenced, or specific terms need to be placed in this to be referenced, or specific terms need to be placed in this
document. document.
While the mobility terminology draft may be applicable, the focus of While the mobility terminology draft may be applicable, the focus of
this draft upon mobile hosts may be distracting for DNA. Comments on this draft upon mobile hosts may be distracting for DNA. Comments on
this issue are welcome. this issue are welcome.
3. Background & Motivation for DNA 3. Background & Motivation for DNA
Hosts on the Internet may be connected by various media. It has Hosts on the Internet may be connected by various media. It has
become common that hosts have access through wireless media or are become common that hosts have access through wireless media and are
mobile, and have a variety of interfaces, which may be used to mobile, and have a variety of interfaces, which may be used to
provide internet connectivity. The frequency of configuration change provide internet connectivity. The frequency of configuration change
for wireless and nomadic devices are elevated, due to the vagaries of for wireless and nomadic devices are elevated, due to the vagaries of
wireless propagation or the motion of the hosts themselves. wireless propagation or the motion of the hosts themselves.
Detecting Network Attachment is a strategy to assist such rapid Detecting Network Attachment is a strategy to assist such rapid
configuration changes by determining when they are required, or not. configuration changes by determining whether they are required.
While DNA has applicability to wireless and wireline access networks, While DNA has applicability to both wireless and wireline access
these two sets of networks bring different sets of requirements to networks, these two sets of networks bring different sets of
the problem. requirements to the problem.
Verifying the validity of current IP configuration is needed when Verifying the validity of current IP configuration is needed when
either a wireless or wireline link-layer is in use. Conversely, either a wireless or wireline link-layer is in use, but wireless
wireless hosts are more likely to change their link-layer hosts are more likely to change their link-layer connection than
connections. wireline hosts.
Due to these frequent link-layer changes, an IP configuration change Due to these frequent link-layer changes, an IP configuration change
detection mechanism for DNA needs to be efficient and rapid. detection mechanism for DNA needs to be efficient and rapid. Making
such detection procedures rapid helps to avoid unnecessary
Making such detection procedures rapid helps to avoid unnecessary
configuration delays upon link-change. configuration delays upon link-change.
For wireless devices, there will typically be a trade-off between In an wireless environment, there will typically be a trade-off
configuration delays and the energy or bandwidth required to transmit between configuration delays and the energy of the devices or channel
for configuration validity tests or re-configuration. DNA seeks to bandwidth utilized to transmit configuration validity tests or
assist hosts by providing information about network state, which may re-configuration. DNA seeks to assist hosts by providing information
allow hosts to appropriately make decisions regarding such tradeoffs. about network state, which may allow hosts to appropriately make
decisions regarding such tradeoffs.
Even though DNA is restricted to determining whether change is Even though DNA is restricted to determining whether change is
needed, the process of obtaining information for the new needed, in some circumstances the process of obtaining information
configuration may occur simultaneously with the detection to improve for the new configuration may occur simultaneously with the detection
the efficiency of these two steps. to improve the efficiency of these two steps.
4. Current Practice for Hosts Supporting DNA
Various protocols within IPv6 provide their own configuration 4. Detecting Network Attachment Steps
processes. While Detecting Network Attachment seeks to provide
efficient change detection without undertaking configuration, it is
necessary to describe these protocols and their relationship to each
other.
Each of the protocols has a role to play in configuration of hosts, Two different situations may lead a node to engage a network
but many maintain their own change discovery mechanisms. In rapidly attachment detection procedure. Either a node receives an indication
changing and wireless environments it is necessary to rationalize the that its link may have changed or it may detect that is configuration
discovery techniques on a minimal subset of procedures and messages, is not valid any more.
sufficient to determine change validity and authorization.
This section aims to allow appropriate background for discussing the If a host receives an indication (such as a link-layer hint) that its
best existing procedures for use in Detecting Network Attachment. link may have changed, it has to verify the validity of its current
configuration and confirm the reachability with its default router.
If one of these two actions do not succeed, initiation of new
configuration is required.
The following discussion describes how these discovery processes If the host detects that its configuration is not valid any more, for
interrelate, and indicates how IPv6 Neighbor Discovery can be used example because a timer has expired, the node should engage in
not only to detect link-change, but assist in determining detection of its network attachment in order to determine if it needs
requirements for other configuration. to create a new configuration.
4.1 IP configurations relevant to DNA While the initiation of the DNA procedures is described in Section 7,
the different steps involved in detecting network attachment are
described below. Once the DNA procedure is engaged, two major tasks
are to be done: check the validity of the current configuration and
confirm the reachability with the default router. Depending on the
method used, these two steps could be performed independently or
during the same procedure.
Each of the following subsystems is described in terms of the 4.1 Validation of current configuration
configuration detection or change detection mechanisms which they
support, the reliance of the service on other configuration and a
summary of the relevant configuration procedures undertaken upon
change discovery.
Indications are provided as to their performance and applicability to When link change occurs, an IPv6 host is likely to have one or more
DNA. IPv6 configurations for the interface in its internal cache. Upon
initiation of DNA procedures (as specified in Section 7), the first
step for the host would be to verify if any of these configurations
is still valid.
This discussion continues in Section 4.2. The validity of a host's configuration can be inferred by determining
its presence on a particular link. The host can verify presence on a
particular link by learning the ranges of valid addresses and routers
associated with that link and comparing this information with its
cached configuration. Learning the routers available on the link and
the prefixes supported by them can be done either passively by
listening to the Router Advertisements (RA) periodically sent by
routers, or actively by sending Router Solicitation (RS) [1].
Checking the validity of current configuration is discussed is more
detail in Section 5.
4.1.1 Router and Prefix Discovery 4.2 Reachability detection
Router Discovery is designed to provide hosts with a set of locally Reachability state usually relies on timers associated with received
configurable prefixes and default routers. These may then be information. Reachability detection can be triggered when a host has
configured by hosts for access to the Internet [1]. some indications that the link might have changed or when a timer is
expired. Reachability detection is very critical, since if the peer,
e.g. the current default router, is not reachable anymore, the host
will have to change its IP configuration to be able to communicate.
As we will see, reachability detection can be very fast if the peer
is still reachable. However, when the peer is not reachable anymore,
the unreachability detection relies on timeout after transmission of
solicitations. These timeouts introduce important delays.Section
Section 6 discusses reachability detection.
It allows hosts to discover routers and manage lists of eligible next 5. Validation of current configuration
hop gateways, and is based on IPv6 Neighbor Discovery. When one of
the routers in the router list is determined to be no longer
reachable, its destination cache entry is removed, and new router is
selected from the list.
As indicated below in Section 4.1.3, router reachability is 5.1 Current protocols
principally managed through the validity of the neighbor cache entry
and the advertised ValidLifetime of the router. Before the router is
actively used, though, a router advertisement can place a router into
the default router list for 30 days after being received [1].
Clearly, if router reachability is to be used for the purposes of Detecting changes in IP configuration requires either knowledge
link change detection in volatile environments, practical and fast gathered from the network upon attachment using such methods as
means for determining reachability and unreachability need to be used Router Discovery, or that known from prior information.
(see Section 8).
As described in Section 6, detection of network attachment may be The current focus of work in DNA Working Group are procedures
initiated by such events as missed Router Advertisements (see Section subsequent to attachment. Some procedures that describe how
4.1.5) or lack of expected response packets passing through a router. information may be gathered prior to arrival are summarized below.
If the currently configured router is unreachable, it is quite likely
that other devices on the same link are no longer reachable.
On determining that link-change has occurred, the default router list 5.1.1 Link Change and Router Discovery
SHOULD have entries removed which are related to unreachable routers,
and consequently these routers' destination cache entries SHOULD be
removed [1]. If no eligible default routers are in the default
router list, Router Solicitations may be sent, in order to discover
new routers.
4.1.2 Address Configuration Determining the identity of a link in IPv6 relies upon Router
Discovery. A link contains a set of mutually reachable interfaces on
routers, and media connecting them between which there is no
forwarding hop.
Unicast addresses are required to send all packets on the Internet, Monitoring the link-local source address of the Router Advertisement
except a restricted subset of local signaling such as router and is insufficient to prove that a device is still on an IP link, since
neighbor solicitations. a router may share a single link-local address across multiple
interfaces.
Reception of packets at a global address, which have been received Therefore the identity of the link may be determined by monitoring
from off-link are likely to be an indication of router reachability. the set of routers and IPv6 prefixes advertised on the link. Any
On broadcast media where packets interpreted by all nodes though, a router advertising one of the prefixes previously received within an
host may receive incorrectly believe it has a valid address if it advertisement may be assumed to belong to the same link, if the new
arrives on a link where the packets from this data stream are in advertisement was received within the Valid Lifetime of the prefix
transit. This may happen for example if there is no unique [1].
link-layer addressing in a network.
In such cases, hosts MUST NOT assume that they are receiving packets Reception of Router Advertisements that do not contain any prefixes
at a topologically correct address unless they can uniquely identify in common with the previously advertised set MAY be an indicator that
the last hop transmitter of the packets as a configured router. link change has occurred. IPv6 Neighbor Discovery [1] explicitly
allows such configurations to exist though, and additionally allows
omission of prefix information options in unsolicited Router
Advertisements. This leads to the fact that the non-presence of the
current default router should be determined before considering that
the link has changed. This is even more important with mobile hosts,
which update their location according to their position in the
Internet. Considering that the current default router/prefix has
changed upon the reception of a new IPv6 prefix may lead to excessive
Binding Update transmission.
As indicated below (in Section 4.1.3), where such information feeds In order to determine validity of configuration in such topologies,
into neighbor cache reachability state, even packets which don't pass reachability testing MAY be required. Additionally, during reception
through a router may indicate validity of an address, through of unsolicited Router Advertisements some heuristic SHOULD be used,
indication that a set of neighbors is present (including appropriate where possible, to ensure that complete prefix information is
routers). received by the host (see Section 5.1.2). This may limit the false
detection of link change due to omitted prefixes.
In dynamic environments, hosts need to undertake automatic 5.1.2 Complete Prefix list
configuration of addresses, and select which addresses to use based
on prefix information advertised in Router Advertisements. Such
configurations may be based on either Stateless Address
Autoconfiguration [3] or DHCPv6 [12].
For any configured address, Duplicate Address Detection (DAD) MUST be Each link can be uniquely identified by the set of prefixes assigned
performed [3]. DAD defines that an address is treated tentatively to it. [22] proposes that, at each attached link, the host generates
until either series of timeouts expire after probe transmissions or the complete prefix list, that is, the prefix list containing all the
an address owner defends its address. Tentative addresses cannot prefixes on the link, and when it receives a hint that indicates a
modify peers' neighbor cache entries, nor can they receive packets. possible link change, it detects the identity of the link by
comparing a the prefix in a new received RA with the existing prefix
list. [22] describes how to generate the complete prefix list and to
robustly check for link change even in the presence of packet losses.
Additionally, IPv6 requires configuration of link-local addresses 5.1.3 Router advertisement Timers
which are to be used for signaling within a link. Possession of a
non-tentative link-local address allows transmission of all neighbor
and router discovery messages, as well as unicast reception of
configuration data. It is notable that while Stateless Address
Autoconfiguration needs only DAD, DHCPv6 relies upon having a
non-tentative link-local address to send its messages.
IPv6 routing assumes that IP subnets are available at a single Presence of the current router can be validated by an unsolicited
location, for any particular global prefix [13]. When a host leaves Router Advertisement (RA) received on the link. To send RAs, a
a link, it therefore leaves its global prefix behind and cannot router uses three main timers : MaxRtrAdvInterval, MinRtrAdvInterval
receive packets on the link using that address. Link-local and MIN_DELAY_BETWEEN_RAS [1]. By default, MinRtrAdvinterval is 0.33
addresses, while being available on every link also may change if a times MaxRtrAdvInterval (i.e. 200 sec. if MaxRtrAdvInterval is 600
link changes. This is because the scope of the individual address's sec.). A host can send a Router Solicitation if it detects that it
uniqueness is confined to a single link, and tests for uniqueness didn't get an RA during 3 times MaxRtrAdvInterval. So, if we
MUST be undertaken for each link upon which a host arrives. consider default values, a host might wait for 30 minutes before
sending an RS. We can also notice that by default, the AR can not
send a new multicast RA within 3 seconds after having sent one. The
reply of a RS must also be delayed for a random time between 0 and
MaxRADelayTime (0.5 sec by default). The specification of Mobile
IPv6 [5] identified that these defaults are too long to support
mobility of host and allows the reduction of the RA transmission
between 30 and 70ms and to allow a host to send a RS if it didn't
receive a RA within the last second.
When undertaking DNA procedures, the host may suspect that it doesn't 5.2 Additional information
have valid configuration. In this case, it SHOULD undertake
Duplicate Address Detection (DAD) for the link-local address, or
treat it as tentative until the host determines if its configuration
is valid or not (or the DAD procedure completes).
The motivations and implications for this practice are described in 5.2.1 Making use of Prior Information
Section 9.1.
4.1.3 Neighbor Caches A device that has recently been attached to a particular wireless
base station may still have state regarding the IP configuration
valid for use on that link. This allows a host to begin any
configuration procedures before checking the ongoing validity and
security of the parameters. The experimental protocols FMIPv6 [17]
and CARD [18] each provide ways to generate such information using
network-layer signaling, before arrival on a link. These are
respectively described in Appendix C and Appendix D. Additionally,
the issue is the same when a host disconnects from one L2 Access
Point and returns to it immediately, or movement occurs between a
pair of access points (the ping-pong effect).
Neighbor caches allow for delivery of packets to peers on the same Extreme care must be taken in making use of existing prior
link. Neighbor cache entries are created by router or neighbor information. If the assumptions attached to the stored configuration
discovery signaling, and may be updated either by upper-layer are incorrect the configuration cost may be increased, or even cause
reachability confirmations or explicit neighbor discovery exchanges. disruption of services to other devices. Hosts MUST NOT cause any
disruption of the IP connectivity to other devices due to the
invalidity or staleness of their configuration.
In order to determine which link-layer address a peer is at, nodes In the case that the host arrives back on the same link in time less
send solicitations to the link-local solicited-node multicast address than the DAD completion time (minus a packet transmission and
of their peer. If hosts are reachable on this address, then they propagation time), the host MAY reclaim the address by sending
will respond to the solicitation with a unicast response. Neighbor Advertisement messages as if another host had attempted DAD
while the host was away. This will prevent DAD completion by another
node upon NA reception.
This reliance on multicast packet delivery may mean that MLD If a host has not been present on a link to defend its address, and
(Multicast Listener Discovery) reporting needs to be completed before has been absent for a full DAD delay (minus transmission time) the
solicited-node's packet reception can occur (see Section 4.1.4), if host MUST undertake the full DAD procedure for each address from that
multicast delivery within a link requires group signaling. link it wishes to configure [3].
By default, neighbor cache entries exist for at least 30 seconds 5.2.2 Transient Link Availability
after reachability confirmation, before becoming STALE. They may
exist for a number for any length of time in the STALE state until
they are used, and then a Neighbor Unreachability Detection test is
performed (taking up to 8 seconds). After this, a neighbor cache
entry is deleted.
When link change occurs, the reachability of all existing neighbor Wireless Internet hosts can experience connectivity changes that may
cache entries is likely to be invalidated, if link change prevents or may not be associated with IP configuration change.
packet reception from an old link. For these links, the neighbor
cache entries SHOULD be removed when a host moves to a new link
(although it MAY be possible to keep keying and authorization
information for such hosts cached on a least-recently-used basis
[7]).
For some wireless media, it may be possible to reach all the nodes on While some wireless base-station transitions are almost
two different access networks simultaneously. In this case, neighbor instantaneous, other cell change procedures take hundreds of
cache entries for a link entries MAY be removed when routers on the milliseconds. In the interval between disconnection at one cell and
link are no-longer directly reachable. attachment at another, packets sent by the host may be discarded or
delayed.
In both forms of networks, the reachability of the set of routers on In some cases, upper layer data with addressing incorrect for the new
a link is a good indicator for reachability to the rest of the link. link may remain queued for transmission in the link-layer. Any
Hosts communicating using a particular medium SHOULD be aware of the signaling packets queued behind these packets will be delayed and
reachability conditions which prevail for a particular medium, and such delays could cause timer expiry and affect the successful
make decisions accordingly. completion of reachability confirmation procedures. Also if
signaling packets are sent when the link is unavailable, the packet
may be discarded. This will lead to timer expiry in the case a
solicitation is sent.
Detecting that link change has occurred can be performed by actively If a host knows that connectivity has been lost at the link-layer, it
probing reachability with neighboring nodes or routers. (This is SHOULD pause transmission of upper-layer packets to the lower-layer,
detailed in Section 8). until general data frames can be send on the new cell. This may help
to avoid packet loss or the queuing of signaling packets for change
detection behind data frames. A host SHOULD also stop sending
signaling for the purpose of DNA to a link-layer it has been reliably
informed is unavailable. It is suggested that implementers utilize
possible prioritization of the DNA signaling packets over other data
packets while queuing them to the link-layer.
Reachability of a single node may support the likelihood of reaching 5.2.3 Further Procedures on Detection of Network Attachment
the rest of the link, for example if a particular access technology
relays such messages through wireless base stations.
Even for such networks, link partitions may still cause router Detection of network attachment does not define or prescribe
unreachability, and hosts SHOULD check for router unreachability in configuration procedures. The actual configuration is therefore left
the case that they lack expected packet receptions through or from a to the procedures which are invoked upon arrival on a new link.
router.
4.1.4 Multicast Listener State While DNA does not undertake configuration, it does learn about the
state of the network using neighbor and router discovery. Where it
is safe to do so, such state SHOULD be made available to
configuration processes. Particularly, state gained from change
detection procedures for DNA SHOULD NOT be discarded.
Multicast routers on a link are aware of which groups are in use 5.3 Conclusions
within a link. This information is used to undertake initiation of
multicast routing for off-link multicast sources to the link [8][10].
When a node arrives on a link, it may need to send Multicast Listener The first step in DNA Procedure SHOULD be to validate the current
Discovery (MLD) reports, if the multicast stream is not already being configuration by identifying the current link and comparing it to the
received on the link. If it is an MLDv2 node it SHOULD send state identity of the link to which the current configuration belongs. If
change reports upon arrival on a link [10]. the current link is reliably identified to be different from the link
to which the current configuration belongs the IP host MUST initiate
configuration procedure to update its configuration. After
attachment to a new link, it is RECOMMENDED that the IP host confirms
reachability with the default router as discussed in Section 6.
Since the identity of the link is tied to the presence and identity 6. Reachability Detection
of routers, initiation of these procedures may be undertaken when DNA
procedures have been completed. In the absence of received data
packets from a multicast stream, it is unlikely that a host will be
able to determine if the multicast stream is being received on a new
link, and will have to send state change reports, in addition to
responses to periodic multicast queries [8][10].
For link scoped multicast, reporting needs to be done to ensure that An IP node needs to confirm bi-directional rechability to its default
packet reception in the link is available due to multicast snoopers. router before it can start communicating with hosts outside its local
Some interaction is possible when sending messages for the purpose of link. Either a NS-NA or an RS-RA message exchange can be used to
DNA on a network where multicast snooping is in use. This issue is conduct rechability testing. But, whether the messages are addressed
described in Section 9.5. to multicast or unicast address will have different reachability
implications. The reachability implications from the hosts'
perspective for the four different message exchanges defined by RFC
2461 [1] are presented in the table below. The host can confirm
bi-directional reachability from the neighbor discovery or router
discovery message exchanges except when a multicast RA is received at
the host for its RS message. In this case, the host cannot know
whether the multicast RA is in response to its solicitation message
or whether it is a periodic un-solicited transmission from the
router.
While [8] specifies that routers may ignore messages from unspecified +-----------------+----+----+----+-----+
source addresses [9] indicates that for the benefit of snooping | Exchanges: |Upstream |Downstream|
switches such messages MAY be transmitted. +-----------------+----+----+----+-----+
| multicast NS/NA | Y | Y |
+-----------------+----+----+----+-----+
| unicast NS/NA | Y | Y |
+-----------------+----+----+----+-----+
| RS/multicast RA | | Y |
+-----------------+----+----+----+-----+
| RS/unicast RA | Y | Y |
+-----------------+----+----+----+-----+
Since DNA procedures are likely to force link-local addresses to be Successful exchange of the messages listed in the table indicate the
tentative, this means MLD messages may need to be transmitted with corresponding links to be operational. Lack of reception of response
unspecified source addresses while link-locals are tentative, in from the router may indicate that reachability is broken for one or
order to complete DNA. This is discussed further in Section 9.5 both of the transmission directions or it may indicate an ordinary
packet loss event in either direction.
4.1.5 Mobility Management Three different methods for verifying bi-directional reachability
with the current router and at the same time receive new
configuration information if the current router is not available is
presented in Section 6.1.1, Section 6.1.2 and Section 6.1.4.
Mobile IPv6 provides global mobility signaling for hosts wishing to If bi-directional reachability can not be confirmed using one of the
preserve sessions when their configured address becomes topologically three message exchanges, the host SHOULD attempt to find a better
incorrect [5]. This system relies upon signaling messages and tunnel connection with possibly another router in the link. Due to the
movement to provide reachability at a constant address, while transient nature of the wireless link, the reachability may change
directing packets to its visited network. during communication after reachability is verified. If multiple
routers were available, the host MAY defer test of reachability until
the interface is to be actively used for transmission and reception.
[5] defines 'movement detection' procedures, which themselves rely Hosts should also be aware of particular issues regarding their own
upon Neighbor Discovery, to initiate mobility signaling. These wireless access technology which impinge on the reliability of
procedures allow for some modification of Neighbor Discovery to reachability tests. Particularly, where unicast and multicast
enable faster change or movement detection. While this document will propagation behaviors are significantly different, hosts SHOULD
reference parameters defined in [5], hosts are not required to attempt to test both multicast and unicast reachability, to ensure
undertake global mobility signaling or tunneling in order to benefit that each works. Hosts MAY defer such additional tests where either
from detecting network attachment. communications method is not likely to be used soon.
Of benefit is an option which allows routers to advertise the 6.1 Current protocols
regularity of their unsolicited advertisements. This can be used to
determine if multiple advertisements have been missed by a host. In
these circumstances, DNA procedures may be initiated as described in
Section 6.
After change detection occurs, a MIPv6 mobile node still needs to 6.1.1 Specific (Neighbor Solicitation) Tests
undertake global address configuration, and then mobility signaling
as specified in [5].
4.1.6 Other Configuration Bi-directional reachability can be verified using the Neighbor
Discovery test to the current access router. Since ND may involve
the use of two unicast messages exchanged between the host and the
access router, a successful ND procedure verifies bi-directional
reachability.
When attempting to access the Internet, several other configuration The IP node sends NS message to the default router and waits for the
services may be required, dependent on the requirements of the access NA from the router. This mechanism is efficient if the current
networks. default router is still reachable : only a round trip time between
the host and the router is needed to confirm reachability.
Conversely, if the default router is not available, the host will
timeout without receiving a NA. By default, the host can send three
NS (one every second) before considering that the router is not
reachable. However, if the host has indication that the link may
have changed, this delay may be reduced without significant damage
for the network by reducing the number of retries. If the current
router is considered unreachable (timeout on NS message), the host
will have to execute router discovery procedure to obtain new
configuration and reachability information. The host will send a RS
message to the All-Routers multicast address.
In this case, it is likely that configuration parameters can be In summary, this method works well both when the current default
passed to hosts using DHCPv6 [12]. The availability of such router is available and when the current default router is not
additional configuration information can be advertised using Router available. When the current default router is not available though,
Advertisements [1]. the delay introduced in doing ND before switching to RD could become
a problem in deploying real time applications in wireless networks.
Reducing the timer associated with the unreachability testing through
the exchange of NS/NA might be an issue. Sometimes this method is
referred to as Lazy Configuration Switching.
IPv6 Stateless Address Autoconfiguration [3] describes an 6.1.2 Non-Specific (Router Solicitation) Tests
OtherConfigFlag which is set when either the 'O' or the 'M' flags are
set in the Router Advertisement header. Hosts use the
OtherConfigFlag to determine if they need to undertake further
(non-addressing related) DHCPv6 procedures.
If the Advertisement's 'O' flag was set, but not the 'M' flag, the Initiating Router Discovery procedure can sometimes lead to
host sends a DHCPv6 Information-Request message asking for such verification of the bi-directional reachability. It does not always
configuration. confirm bi-directional reachability because if the router responds
for the RS with a multicast RA message, there is no way for the host
to identify whether the RA is in response to the RS or whether it is
a periodic unsolicited RA transmission. Even with multicast RA
response, if SEND is used, bi-directional reachability can confirmed
because SEND uses a unique nonce to match request and response
messages [7]. If the router chooses to respond to a RS with a
unicast RA message, again, the host will be able to match the RS and
RA and hence confirm bi-directional reachability.
This signaling may occur after completion of DNA procedures. Send a RS message to the All-Routers multicast address. A RA message
in response to the RS will be received from one of the available
routers on the link. This method will lead to quick configuration of
the interface because if the current default router is not
accessible, new configuration information can be received from the
responding router. However, this can lead to erroneous
re-configuration of the interface because a response from a new
router doesn't necessarily mean that the current router is not
accessible. Based on RFC2461 [1], the node may have to wait for 3
times MAX_RA_DELAY_TIME to confirm that the current default router is
not serving the default IPv6 prefix. By considering the default
values of RFC2461, 3 times MAX_RA_DELAY_TIME is 30 minutes, while
with the values defined in MIPv6, this time is 1 second (due to the
shorter Router Advertisement frequency).
4.2 Validation using Neighbor Discovery 6.1.3 Trade-offs in Reachability Testing
Most of the procedures required for detection of network attachment There are unique advantages and dis-advantages in using either the
(router reachability, prefix validity) are provided in [1]. Specific or the Non-specific test to confirm reachability.
Handling rapid change may require specific initiation and Specific tests:
interpretation of message exchange procedures, but may be achieved
without new messages or options.
Timing of messages and performance constraints will be described in Advantages:
this document, and explicit indications of practical differences
between particular settings for these timers will be provided.
4.3 Further Procedures on Detection of Network Attachment Confirmation of bi-directional reachability.
Detection of network attachment does not define or prescribe Dis-advantages:
configuration procedures. The actual configuration is therefore left
to the procedures which are invoked upon arrival on a new link.
While DNA does not undertake configuration, it does learn about the If the ND test fails, the host has no potential configuration
state of the network using neighbor and router discovery. Where it information it can use.
is safe to do so, such state SHOULD be made available to
configuration processes.
Particularly, state gained from change detection procedures SHOULD Non-Specific tests:
NOT be discarded, such that discovery processes need to be undertaken
for each configuration protocol used.
5. Detecting Network Attachment Steps Advantages:
Two different situations may lead a node to engage a network Even when the current access router is not reachable, an RA message
attachment detection procedure. Either a node receives an indication from any available router will provide information that can used to
that its link may have changed or it may detect that is configuration configure the host.
is not valid any more.
If a host receives an indication (such as a link-layer hint) that its Confirmation of bi-directional reachability if SEND is used or if the
link may have changed, it has to verify the validity of its current router chooses to respond with an unicast RA message.
configuration and confirm the reachability with its default router.
If one of these two actions do not succeed, initiation of new
configuration is required.
If the host detects that its configuration is not valid any more, for Dis-advantages:
example because a timer has expired, the node should engage in
detection of its network attachment in order determine to what extent
it needs to create a new configuration.
While the initiation of the DNA procedures is described in the next If multicast RA response is received, the host may have to execute an
section, the different steps involved in detecting network attachment ND test to confirm bi-directional reachability. Such a test may be
are described below. Once the DNA procedure is engaged, two major avoided if upper layer confirmations are received within the DELAY
steps are to be done: check the validity of the current configuration period prescribed by IPv6 Neighbor Discovery [1].
and confirm the reachability with the default router. Depending on
the method used, these two steps could be performed independently or
during the same procedure.
5.1 Validity of configuration Even when the current access router is reachable, the response may
arrive from a different access router leading to erroneous
re-configuration of the host.
When link change occurs, an IPv6 host is likely to have one or more 6.1.4 Hybrid mechanism
IPv6 configurations for the interface in its internal cache. Upon
initiation of DNA procedures (as specified in Section 6), the first
step for the host would be to verify if any of these configurations
is still valid.
The validity of a host's configuration can be inferred by determining Send a NS to the current default router and a RS to the All-Routers
its presence on a particular link. The host can verify presence on a multicast address in parallel. If the response to the NS is received
particular link by learning the ranges of valid addresses and routers within the timeout period, any response to the RS can be ignored. If
associated with that link and comparing this information with its no NA is received, the RA received in response to the RS will be used
cached configuration. Learning the routers available on the link and to configure the IP interface. The method works well in both cases
the prefix supported by them can be done either passively by when the current router is still available and when not, and avoids
listening to the Router Advertisements (RA) periodically sent by the delay of exchanging RS and RA after the ND timeouts. When the
routers, or actively by sending Router Solicitation (RS) [1]. current default router is available, the RS and RA messages are
Otherwise, the host may send Neighbor Solicitation (NS) in order to unnecessarily transmitted, wasting network resources.
check if its current default router is still reachable [1].
Router Discovery is used initially to begin gathering a set of 6.1.5 Authorization for using the router
prefixes associated with a link, and determine the preference and
authorization of default routers [1], [7]. Neighbor Solicitations in
this case provide only a confirmation of reachability of a currently
configured router, as detailed in Section 8.
In addition to reachability information, routing authorization needs In addition to reachability information, routing authorization needs
to be determined for each router. In SEND [7], routing authorization to be determined for each router. In SEND [7], routing authorization
is delegated by certification authorities. Certificate authorities is delegated by certification authorities. Certificate authorities
delegate a portion of their routing authority to the router, tying delegate a portion of their routing authority to the router, tying
them to a public/private key-pair. While SEND Router Advertisement them to a public/private key-pair. While SEND Router Advertisement
packets contain the public key used to sign the message, the routing packets contain the public key used to sign the message. Hosts need
certificate is not present in that message. Hosts need to test the to test the router's authority to provide routing for the prefixes
router's authority to provide routing for the source addresses
advertised in its Router Advertisement in order to ensure safe advertised in its Router Advertisement in order to ensure safe
configuration. configuration.
It might be noticed that the reception of a new Router Advertisement 6.2 Additional information
on a link does not necessarily mean that the current default prefix
of a host is not valid anymore. Several prefixes as well as several
routers might be present on a link. This leads to the fact that the
non-presence of the current default router should be determined
before considering that the link has changed. This is even more
important with mobile hosts, which update their localization
according to their position in the Internet. Considering that the
current default router/prefix has changed upon the reception of a new
IPv6 prefix may lead to excessive Binding Update transmission.
Reachability detection is discussed in the next subsection.
5.2 Reachability detection
Reachability information usually relies on timers associated with
received information. Reachability detection can be triggered when a
host has some indications that the link might have changed or when a
timer is expired. Reachability detection is very critical, since if
the peer, e.g. the current default router, is not reachable anymore,
the host will have to change its IP configuration to be able to
communicate. As we will see, reachability detection can be very fast
if the peer is still reachable. However, when the peer is not
reachable anymore, the unreachability detection relies on timeout
after transmission of solicitations. These timeouts introduce
important delays.
Presence of the current router can be validated by an unsolicited
Router Advertisement (RA) received on the link. To send RAs, a
router uses three main timers : MaxRtrAdvInterval, MinRtrAdvInterval
and MIN_DELAY_BETWEEN_RAS [1]. By default, MinRtrAdvinterval is 0.33
times MaxRtrAdvInterval (i.e. 200 sec. if MaxRtrAdvInterval is 600
sec.). A host can send a Router Solicitation if it detects that it
didn't get an RA during 3 times MaxRtrAdvInterval. So, if we
consider default values, a host might wait for 30 minutes before
sending an RS. We can also notice that by default, the AR can not
send a new multicast RA within 3 seconds after having sent one. The
reply of a RS must also be delayed for a random time between 0 and
MaxRADelayTime (0.5 sec by default). The specification of Mobile
IPv6 [5] identified that these defaults are too long to support
mobility of host and proposes to reduce the RA transmission between
30 and 70ms and to allow a host to send a RS if it didn't receive a
RA within the last second.
Absence of RA from the current default router MAY require 6.2.1 Wireless propagation
verification and acquisition of configuration using one of the active
mechanisms listed below. Non-presence will be detected either when
RA from the router is not received for a period of time or by
neighbor reachability test. Three different possible message
exchanges can be used to test reachability and actively learn about
the on-link information and they are presented below.
1. Neighbor Discovery: Wireless channel characteristics change both in space and time. Even
when a wireless host is not moving, its connectivity to the access
router can change due to factors like interference from other
objects, temperature etc. When the host is moving, the changes can
be more pronounced because of change in distance, introduction of new
objects in the LOS (line of sight) etc. The change to the
connectivity may affect both directions or it can be only in either
one of the directions. Hence, in wireless links, reachability in one
direction does not guarantee reachability in the other. Also, these
variations in the wireless channel can be very short lived, creating
rapid hints about the status of the link-layer. It is important to
consider the transient nature of the wireless links in design the DNA
mechanism for such channels.
The IP node sends NS message to the default router and waits for the 6.2.2 Asymmetric Reachability
NA from the router. This mechanism is efficient if the current
default router is still reachable : only a round trip time between
the host and the router is needed to validate the configuration.
This method will allow the node to find out whether the current
configuration information is valid. Conversely, if the default
router is not available, the host will timeout without receiving a
NA. By default, the host can send three NS (one every second) before
considering that the pair is not reachable. However, if the host has
indication that the link may have changed, this delay may be reduced
without significant damage for the network. If the current router is
considered unreachable (timeout on NS message), the host will have to
execute router discovery procedure to obtain new configuration and
reachability information. The host will send a RS message to the
All-Routers multicast address. In summary, this method works well
both when the current default router is available and when the
current default router is not available. When the current default
router is not available though, the delay introduced in doing ND
before switching RD could become a problem in deploying real time
applications in wireless networks. Reducing the timer associated
with the unreachability testing through the exchange of NS/NA might
be an issue.
2. Router Discovery: As mentioned in the previous section, wireless channels can provide
asymmetric reachability that requires reachability testing on both
directions. Even previously verified bi-directional reachability can
not guaranteed at a later time if there are other (higher layer or
link-layer) hints implying the loss of bi-directional reachability.
Send a RS message to the All-Routers multicast address. A RA message The frequency of initiation of reachability testing MUST be
in response to the RS will be received from one of the available controlled in order to avoid flooding of the network. Implementers
routers on the link. This method will lead to quick configuration of are advised to build in rate-limiting mechanisms in responding to the
the interface because if the current default router is not hints to avoid switching IP configuration frequently when the quality
accessible, new configuration information can be received from the of the wireless channel is fluctuating (see Section 7.5).
responding router. But, this can lead to erroneous re-configuration
of the interface because a response from a new router doesn't
necessarily mean that the current router is not accessible. In
RFC2461 [1], the node may have to wait for 3 times MAX_RA_DELAY_TIME
to confirm that the current default router is not serving the default
IPv6 prefix. By considering the default values of RFC2461, 3 times
MAX_RA_DELAY_TIME is 30 minutes, while with the values defined in
MIPv6, this time is 1 second (due to the shorter Router Advertisement
frequency).
3. Neighbor Discovery and Router Discovery in parallel: 6.3 Conclusions
Send a NS to the current default router and a RS to the All-Routers During bi-directional reachability verification procedure, it is also
multicast address in parallel. If the response to the NS is received possible to collect information for the re-configuration of the
within the timeout period, any response to the RS can be ignored. If interface if the rechability verification fails. Hosts SHOULD make
no NA is received, the RA received in response to the RS will be used best effort to validate the current configuration, verify
to configure the IP interface. The method works well in both cases bi-direction rechability and collect configuration information with
when the current router is still available and when not, and avoids minimal use of signaling messages.
the delay of exchanging RS and RA after the ND timeouts. When the
current default router is available, the RS and RA messages are
unnecessarily transmitted, wasting network resources.
6. Initiation of DNA Procedures 7. Initiation of DNA Procedures
Link change detection procedures are initiated when information is Link change detection procedures are initiated when information is
received either directly from the network or from other protocol received either directly from the network or from other protocol
layers within the host. This information indicates that network layers within the host. This information indicates that network
reachability or configuration is suspect and is called a hint. reachability or configuration is suspect and is called a hint.
Hints MAY be used to update a wireless host's timers or probing Hints MAY be used to update a wireless host's timers or probing
behavior in such a way as to assist detection of network attachment. behavior in such a way as to assist detection of network attachment.
Hints SHOULD NOT be considered to be authoritative for detecting IP Hints SHOULD NOT be considered to be authoritative for detecting IP
configuration change by themselves. configuration change by themselves.
In some cases, hints will carry significant information (for example In some cases, hints will carry significant information (for example
a hint indicating PPP IPv6CP open state [4]), although details of the a hint indicating PPP IPv6CP open state [4]), although details of the
configuration parameters may be available only after other IP configuration parameters may be available only after other IP
configuration procedures. Implementers are encouraged to treat hints configuration procedures. Implementers are encouraged to treat hints
as though they may be incorrect, and require confirmation. as though they may be incorrect, and require confirmation.
The signaling which causes a hint may be due to network-layer The signaling which causes a hint may be due to network-layer
  Skipping to change at page 16, line 20:
In some cases, hints will carry significant information (for example In some cases, hints will carry significant information (for example
a hint indicating PPP IPv6CP open state [4]), although details of the a hint indicating PPP IPv6CP open state [4]), although details of the
configuration parameters may be available only after other IP configuration parameters may be available only after other IP
configuration procedures. Implementers are encouraged to treat hints configuration procedures. Implementers are encouraged to treat hints
as though they may be incorrect, and require confirmation. as though they may be incorrect, and require confirmation.
The signaling which causes a hint may be due to network-layer The signaling which causes a hint may be due to network-layer
messages such as unexpected Router Advertisements, multicast listener messages such as unexpected Router Advertisements, multicast listener
queries or ICMPv6 error messages [1][8][6]. In these cases, caution queries or ICMPv6 error messages [1][8][6]. In these cases, caution
must be exerted. must be exerted to verify the authenticity of the messages before
expending resources to initiate DNA procedure.
Hosts MUST ensure that untrusted messages do not cause unnecessary Hosts MUST ensure that untrusted messages do not cause unnecessary
configuration changes, or significant consumption of host resources configuration changes, or significant consumption of host resources
or bandwidth. or bandwidth. In order to achieve this aim, a host MAY implement
hysteresis mechanisms such as token buckets, hint weighting or
In order to achieve this aim, a host MAY implement hysteresis holddown timers in order to limit the effect of excessive hints (see
mechanisms such as token buckets, hint weighting or holddown timers Section 7.5).
in order to limit the effect of excessive hints (see Section 6.5).
Transport and Link-Layers may also provide hints, caused by state
change in their own layer. Two examples of such state change are TCP
retransmission timeout and completion of link-layer access
procedures.
While hints from other protocol layers originate from within the 7.1 Hint Reception and Processing
host's own stack, the network layer SHOULD NOT treat hints from other
protocol layers as authoritative indications of link change.
This is because state changes within other protocol layers may be When a host arrives on a new link, hints received due to external IP
triggered by untrusted messages, come from compromised sources (for packets will typically be due to multicast messages. A delay before
example 802.11 WEP Encryption [19]) or be inaccurate with regard to receiving these messages is likely as in most cases intervals between
network-layer state. In most cases, additional procedures such as All-Hosts multicast messages are tightly controlled [1][6].
those defined in Section 7.3 and Section 8 will be required to Regardless of this, actions based on multicast reception from
confirm changes in network layer configuration. untrusted sources are dangerous due to the threat of transmitter
impersonation. This issue is discussed further in Section 12.
State changes within the network-layer itself may initiate State changes within the network-layer itself may initiate
link-change detection procedures. Existing subsystems for router and link-change detection procedures. Existing subsystems for router and
neighbor discovery, address leasing and multicast reception maintain neighbor discovery, address leasing and multicast reception maintain
their own timers and state variables. Changes to the state of one or their own timers and state variables. Changes to the state of one or
more of these mechanisms may hint that link change has occurred, and more of these mechanisms may hint that link change has occurred, and
initiate detection of network attachment. initiate detection of network attachment.
6.1 Hint Reception and Processing 7.2 Handling Hints from Other Layers
Hints received due to external IP packets will typically be due to
multicast messages, when a host has arrived on a new link. A delay
before receiving these messages is likely as in most cases intervals
between All-Hosts multicast messages are tightly controlled [1][6].
Regardless of this, actions based on multicast reception from
untrusted sources are dangerous due to the threat of transmitter
impersonation. This issue is discussed further in Section 11.
6.2 Handling Hints from Other Layers
Timeouts and state change at other protocol layers may provide hints Timeouts and state change at other protocol layers may provide hints
of link change to detection of network attachment. While the hints of link change to detection of network attachment. Two examples of
come from the host's own stack, the causes for such hints may be due such state change are TCP retransmission timeout and completion of
to packet reception or non-reception events at the originating link-layer access procedures. While hints from other protocol layers
layers. originate from within the host's own stack, the network layer SHOULD
NOT treat hints from other protocol layers as authoritative
indications of link change. This is because state changes within
other protocol layers may be triggered by untrusted messages, come
from compromised sources (for example 802.11 WEP Encryption [19]) or
be inaccurate with regard to network-layer state.
As such, it may be possible for other devices to instigate hint While these hints come from the host's own stack, the causes for such
delivery on a host or multiple hosts deliberately, in order to prompt hints may be due to packet reception or non-reception events at the
packet transmission, or configuration modification. This ability to originating layers. As such, it may be possible for other devices to
create hints may even extend to the parameters supplied with a hint instigate hint delivery on a host or multiple hosts deliberately, in
that give indications of the network's status. order to prompt packet transmission, or configuration modification.
This ability to create hints may even extend to the parameters
supplied with a hint that give indications of the network's status.
Therefore, hosts SHOULD NOT change their configuration state based on Therefore, hosts SHOULD NOT change their configuration state based on
hints from other protocol layers. A host MAY choose to adopt an hints from other protocol layers. A host MAY choose to adopt an
appropriate link change detection strategy based upon hints received appropriate link change detection strategy based upon hints received
from other layers, with suitable caution and hysteresis, as described from other layers, with suitable caution and hysteresis, as described
in Section 6.5. in Section 7.5.
6.3 Timer Based Hints 7.3 Timer Based Hints
When receiving messages from upper and lower layers, or when When receiving messages from upper and lower layers, or when
maintaining reachability information for routers or hosts, timers may maintaining reachability information for routers or hosts, timers may
expire due to non-reception of messages. In some cases the expiry of expire due to non-reception of messages. In some cases the expiry of
these timers may be a good hint that DNA procedures are necessary. these timers may be a good hint that DNA procedures are necessary.
Hosts SHOULD NOT start DNA procedures simply because a data link is Hosts SHOULD NOT start DNA procedures simply because a data link is
idle, in accordance with [1]. Hosts MAY act on hints associated with idle, in accordance with [1]. Hosts MAY act on hints associated with
non-reception of expected signaling or data. non-reception of expected signaling or data.
Since DNA is likely to be used when communicating with devices over Since DNA is likely to be used when communicating with devices over
wireless links, suitable resilience to packet loss SHOULD be wireless links, suitable resilience to packet loss SHOULD be
incorporated into either the hinting mechanism, or the DNA initiation incorporated into either the hinting mechanism, or the DNA initiation
system. system. Notably, non-reception of data associated with end-to-end
Notably, non-reception of data associated with end-to-end
communication over the Internet may be caused by reception errors at communication over the Internet may be caused by reception errors at
either end or because of network congestion. Hosts SHOULD NOT act either end or because of network congestion. Hosts SHOULD NOT act
immediately on packet loss indications, delaying until it is clear immediately on packet loss indications, delaying until it is clear
that the packet losses aren't caused by transient events. that the packet losses aren't caused by transient events.
Use of the Advertisement Interval Option specified in [5] follows Use of the Advertisement Interval Option specified in [5] follows
these principles. Routers sending this option indicate the maximum these principles. Routers sending this option indicate the maximum
interval between successive router advertisements. Hosts receiving interval between successive router advertisements. Hosts receiving
this option monitor for multiple successive packet losses and this option monitor for multiple successive packet losses and
initiate change discovery. initiate change discovery.
6.4 Simultaneous Hints 7.4 Simultaneous Hints
It is possible that hints arrive synchronously on multiple hosts at While some link-layer hints may be generated by individual actions,
the same time. As described in [1][6] , a host SHOULD delay randomly other events which generate hints may affect a number of devices
before acting on a widely receivable advertisement, in order to avoid simultaneously. It is possible that hints arrive synchronously on
response implosion. multiple hosts at the same time. For example, if a wireless base
station goes down, all the hosts on that base station are likely to
initiate link-layer configuration strategies after losing track of
the last beacon or pilot signal from the base station. As described
in [1][6] , a host SHOULD delay randomly before acting on a widely
receivable advertisement, in order to avoid response implosion.
Since a host's detection of network attachment may include Router Since a host's detection of network attachment may include Router
Solicitations sent to multicast addresses, a host may receive Solicitations sent to multicast addresses, a host may receive
responses from each of multiple routers on a link. Therefore, Router responses from each of multiple routers on a link. Therefore, Router
Solicitations may eventually cause additional bandwidth consumption, Solicitations may eventually cause additional bandwidth consumption,
and require additional constraint. and require additional constraint.
Where a host considers it may be on a new link and learns this from a Where a host considers it may be on a new link and learns this from a
hint generated by a multicast message, the host SHOULD defer 0-1000ms hint generated by a multicast message, the host SHOULD defer 0-1000ms
in accordance with [1][3]. Please note though that a single in accordance with [1][3]. Please note though that a single
desynchronization is required for any number of transmissions desynchronization is required for any number of transmissions
subsequent to a hint, regardless of which messages need to be sent. subsequent to a hint, regardless of which messages need to be sent.
Additional delays are only required if in response to messages Additional delays are only required if in response to messages
received from the network which are themselves multicast, and it is received from the network which are themselves multicast, and it is
not possible to identify which of the receivers the packet is in not possible to identify which of the receivers the packet is in
response to. response to.
While some link-layer hints may be generated by individual actions,
other events which generate hints may affect a number of devices
simultaneously.
For example, if a wireless base station goes down, all the hosts on
that base station are likely to initiate link-layer configuration
strategies after losing track of the last beacon or pilot signal from
the base station.
Hence there is some chance of network layer message synchronization,
if each device attempts the same link-layer procedures. Such
synchronization effects are reliant upon the nature of the particular
link-layer technology.
In link-layers where sufficient serialization occurs after an event In link-layers where sufficient serialization occurs after an event
experienced by multiple hosts, each host MAY avoid the random delays experienced by multiple hosts, each host MAY avoid the random delays
before sending solicitations specified in [1]. before sending solicitations specified in [1].
6.5 Hint Validity and Hysteresis 7.5 Hint Validity and Hysteresis
Anecdotal evidence from the initial Detecting Network Attachment BoF Anecdotal evidence from the initial Detecting Network Attachment BoF
indicated that hints received at the network layer often did not indicated that hints received at the network layer often did not
correspond to changes in IP connectivity [16]. correspond to changes in IP connectivity [16].
In some cases, hints could be generated at an elevated rate, which In some cases, hints could be generated at an elevated rate, which
didn't reflect actual changes in IP configuration. In other cases, didn't reflect actual changes in IP configuration. In other cases,
hints were received prior to the availability of the medium for hints were received prior to the availability of the medium for
network-layer packets. network-layer packets.
Additionally, since packet reception at the network and other layers Additionally, since packet reception at the network and other layers
are a source for hints, it is possible for traffic patterns on the are a source for hints, it is possible for traffic patterns on the
link to create hints, through chance or malicious intent. link to create hints, through chance or malicious intent. Therefore,
it may be necessary to classify hint sources and types for their
Therefore, it may be necessary to classify hint sources and types for relevance and recent behavior.
their relevance and recent behavior.
When experiencing a large number of hints, a host SHOULD employ When experiencing a large number of hints, a host SHOULD employ
hysteresis techniques to prevent excessive use of network resources. hysteresis techniques to prevent excessive use of network resources.
The host MAY change the weight of particular hints, to devalue them The host MAY change the weight of particular hints, to devalue them
if their accuracy has been poor, suggests invalid configurations, or if their accuracy has been poor, suggests invalid configurations, or
are suspicious (refer to Section 11). are suspicious (refer to Section 12).
It is notable, that such hysteresis may cause sub-optimal change It is notable, that such hysteresis may cause sub-optimal change
detection performance, and may themselves be used to block legitimate detection performance, and may themselves be used to block legitimate
hint reception. It is notable that mechanisms that cause hints to hint reception.
not be acted upon may affect the timeliness of detection of network
attachment, in the case that they subsequently work correctly.
6.6 Hint Management for Inactive Hosts 7.6 Hint Management for Inactive Hosts
If a host does not expect to send or receive packets soon, it MAY If a host does not expect to send or receive packets soon, it MAY
choose to defer detection of network attachment. This may preserve choose to defer detection of network attachment. This may preserve
resources on latent hosts, by removing any need for packet resources on latent hosts, by removing any need for packet
transmission when a hint is received. transmission when a hint is received.
These hosts SHOULD delay 0-1000ms before sending a solicitation, and These hosts SHOULD delay 0-1000ms before sending a solicitation, and
MAY choose to wait up to twice the advertised Router Advertisement MAY choose to wait up to twice the advertised Router Advertisement
Interval (plus the random delay) before sending [5]. Interval (plus the random delay) before sending a solicitation [5].
When deferring this signaling, the host therefore relies upon the When deferring this signaling, the host therefore relies upon the
regular transmission of unsolicited advertisements for timely regular transmission of unsolicited advertisements for timely
detection of link change. It is notable that when hosts take this detection of link change.
approach the effect of simultaneous configuration is limited to those
hosts actively polling for information. One benefit of inactive hosts' deferral of DNA procedures is that
herd-like host configuration testing is mitigated when base-station
failure or simultaneous motion occur. When latent hosts defer DNA
tests, the number of devices actively probing for data simultaneously
is reduced to those hosts which currently support existing data
sessions.
When a device begins sending packets, it will be necessary to test When a device begins sending packets, it will be necessary to test
bidirectional reachability with the router (whose current Neighbor bidirectional reachability with the router (whose current Neighbor
Cache state is STALE). As described in [1], the host will delay Cache state is STALE). As described in [1], the host will delay
before probing to allow for the probability that upper layer packet before probing to allow for the probability that upper layer packet
reception confirms reachability. reception confirms reachability.
SN: The following paragraph needs to be clarified - re-written.
If no packet transmission on the wireless link has occurred, before If no packet transmission on the wireless link has occurred, before
the new IP configuration is used for upper layer protocols, hosts MAY the new IP configuration is used for upper layer protocols, hosts MAY
choose not to delay the reachability probe to the router, if the choose not to delay the reachability probe to the router, if the
transmission time is unrelated to received multicast packets. transmission time is unrelated to received multicast packets. This
is because the initial delay is unlikely to be synchronized with
This is because the initial delay is unlikely to be synchronized with
other devices on this link, and timely liveness detection for the other devices on this link, and timely liveness detection for the
configuration may then be required. configuration may then be required.
7. Validation of configuration 8. Current Practice for Configuration Change Detection on Hosts
Detecting changes in IP configuration requires either knowledge Various protocols within IPv6 provide their own configuration
gathered from the network upon attachment using such methods as processes. While Detecting Network Attachment seeks to provide
Router Discovery, or that known from prior information. efficient change detection without undertaking configuration, it is
necessary to describe these protocols and their relationship to each
other.
The current foci of work in DNA Working Group are procedures Each of the protocols has a role to play in configuration of hosts,
subsequent to attachment. Some procedures that describe how but many maintain their own change discovery mechanisms.In rapidly
information may be gathered prior to arrival are summarized below. changing and wireless environments it is necessary to rationalize the
discovery techniques on a minimal subset of procedures and messages,
sufficient to determine change validity and authorization.
7.1 Making use of Prior Information This section aims provide a non-exhaustive list of configuration
detection mechanisms used in IPv6.
A device that has recently been attached to a particular wireless 8.1 Router and Prefix Discovery
base station may still have state regarding the IP configuration
valid for use on that link. This allows a host to begin any
configuration procedures before checking the ongoing validity and
security of the parameters. The experimental protocols FMIPv6 [17]
and CARD [18] each provide ways to generate such information using
network-layer signaling, before arrival on a link. These are
respectively described in Appendix C and Appendix D. Additionally,
the issue is the same when you disconnect from one L2 Access Point
and return to it immediately, or movement between a pair of access
points (the ping-pong effect).
Care must be taken when there is a chance of an error or change in Router Discovery is designed to provide hosts with a set of locally
the configuration. Otherwise, if the assumptions due to the stored configurable prefixes and default routers. These may then be
configuration are incorrect the configuration cost may be increased, configured by hosts for access to the Internet [1].
or even harm to other devices.
Hosts MUST ensure that they will cause no harm to other devices due It allows hosts to discover routers and manage lists of eligible next
to the invalidity or staleness of their configuration. hop gateways, and is based on IPv6 Neighbor Discovery. When one of
the routers in the router list is determined to be no longer
reachable, its destination cache entry is removed, and new router is
selected from the list. If the currently configured router is
unreachable, it is quite likely that other devices on the same link
are no longer reachable.
In the case that the host arrives back on the same link in time less On determining that link-change has occurred, the default router list
than the DAD completion time (minus a packet transmission and SHOULD have entries removed which are related to unreachable routers,
propagation time), the host MAY reclaim the address by sending and consequently these routers' destination cache entries SHOULD be
Neighbor Advertisement messages as if another host had attempted DAD removed [1]. If no eligible default routers are in the default
while the host was away. This will prevent DAD completion by another router list, Router Solicitations MAY be sent, in order to discover
node upon NA reception. new routers.
If a host has not been present on a link to defend its address, and 8.2 Address Autoconfiguration
has been absent for a full DAD delay (minus transmission time) the
host MUST undertake the full DAD procedure for each address from that
link it wishes to configure [3].
7.2 Transient Link Availability Unicast addresses are required to send all packets on the Internet,
except a restricted subset of local signaling such as router and
neighbor solicitations.
Wireless Internet hosts can experience connectivity changes that may In dynamic environments, hosts need to undertake automatic
or may not be associated with IP configuration change. configuration of addresses, and select which addresses to use based
on prefix information advertised in Router Advertisements. Such
configurations may be based on either Stateless Address
Autoconfiguration [3] or DHCPv6 [12].
While some wireless base-station transitions are almost For any configured address, Duplicate Address Detection (DAD) MUST be
instantaneous, other cell change procedures take hundreds of performed [3]. DAD defines that an address is treated tentatively
milliseconds. In the interval between disconnection at one cell and until either series of timeouts expire after probe transmissions or
attachment at another, packets sent by the host may be discarded or an address owner defends its address. Tentative addresses cannot
delayed. modify peers' neighbor cache entries, nor can they receive packets.
In some cases, upper layer data with addressing incorrect for the new Additionally, IPv6 requires configuration of link-local addresses
link may remain queued for transmission in the link-layer. The which are to be used for signaling within a link. Possession of a
subsequent queuing of signaling packets can affect timers, and non-tentative link-local address allows transmission of all neighbor
therefore the success of reachability confirmation procedures if DNA and router discovery messages, as well as unicast reception of
procedures are aware of link-detachment and attachment. Also if configuration data.
signaling packets are sent when the link is unavailable, the packet
may be discarded. This will lead to timer expiry in the case a
solicitation is sent.
If a host knows that connectivity has been lost at the link-layer, it 8.3 Neighbor Discovery
SHOULD pause transmission of upper-layer packets to the lower-layer,
until general data frames can be send on the new cell. This may help
to avoid packet loss or the queuing of signaling packets for change
detection behind data frames. A host SHOULD also stop sending
signaling for the purpose of DNA to a link-layer it has been reliably
informed is unavailable. It is suggested that implementers utilize
possible prioritization of the DNA signaling packets over other data
packets while queuing them to the link-layer.
7.3 Link Change and Router Discovery Neighbor caches allow for delivery of packets to peers on the same
link. Neighbor cache entries are created by router or neighbor
discovery signaling, and may be updated either by upper-layer
reachability confirmations or explicit neighbor discovery exchanges.
Determining the identity of a link in IPv6 relies upon Router In order to determine which link-layer address a peer is at, nodes
Discovery. A link contains a set of mutually reachable interfaces on send solicitations to the link-local solicited-node multicast address
routers, and media connecting them between which there is no of their peer. If hosts are reachable on this address, then they
forwarding hop. will respond to the solicitation with a unicast response.
Monitoring the link-local source address of the Router Advertisement This reliance on multicast packet delivery may mean that MLD
is insufficient to prove that a device is still on an IP link, since (Multicast Listener Discovery) reporting needs to be completed before
a router may share a single link-local address across multiple solicited-node's packet reception can occur (see Section 11.5).
interfaces.
Therefore the identity of the link may be determined by monitoring By default, neighbor cache entries exist for at least 30 seconds
the set of routers and IPv6 prefixes advertised on the link. Any after reachability confirmation, before becoming STALE. They may
router advertising one of the prefixes previously received within an exist for any length of time in the STALE state until they are used,
advertisement may be assumed to belong to the same link, if the new and then a Neighbor Unreachability Detection test is performed
advertisement was received within the Valid Lifetime of the prefix (taking up to 8 seconds). After this, a neighbor cache entry is
[1]. deleted.
Reception of Router Advertisements that do not contain any prefixes When link change occurs, the reachability of all existing neighbor
in common with the previously advertised set MAY be an indicator that cache entries is likely to be invalidated, if link change prevents
link change has occurred. IPv6 Neighbor Discovery [1] explicitly packet reception from an old link. For these links, the neighbor
allows such configurations to exist though, and additionally allows cache entries SHOULD be removed when a host moves to a new link
omission of prefix information options in unsolicited Router (although it MAY be possible to keep keying and authorization
Advertisements. information for such hosts cached on a least-recently-used basis
[7]).
In order to determine validity of configuration in such topologies, Reachability of a single node may support the likelihood of reaching
reachability testing MAY be required. Additionally, during reception the rest of the link, for example if a particular access technology
of unsolicited Router Advertisements some heuristic SHOULD be used, relays such messages through wireless base stations.
where possible, to ensure that complete prefix information is
received by the host. This may limit the false detection of link
change due to omitted prefixes.
7.4 Validating configuration in Constrained Topologies 8.4 Dynamic Host Configuration
In environments where only one router may exist within an IP link, Dynamic Host Configuration Procedures for IPv6 define their own
changed router and prefix advertisement implies link change. A detection procedures [12]. In order to check if the current set of
mobile host implementation MAY use the knowledge of such environment, configuration is valid, a host can send a 'Confirm' message with a
for example when it is on a PPP link or on a base-station/router, to sample of its current configuration, which is able to be responded to
infer link change every time a new prefix advertisement is received. by any DHCP relay on a link.
If a host has recently received a solicited Router Advertisement from
the configured router, it SHOULD see all prefixes configured on the
router's interface at the time [1]. Subsequent reception of a Router
Advertisement with a prefix not in the set MAY mean that the current
IP configuration is invalid, and addressing and routing configuration
procedures MAY be started.
Also, some networks enforce IP address changes when link-layer change If the replying relay knows it is not on the same link, it may
occurs. Devices that are aware of such procedures SHOULD start IP respond, indicating that the host's configuration is invalid.
configuration immediately on attachment to a new link-layer. Current use of this technique is hampered by the lack of wide scale
deployment of DHCPv6 and hence the detection mechanism doesn't work
when the host moves to a link which doesn't contain DHCP relays or
servers.
7.5 Validating configuration in Arbitrary Topologies When used for address configuration, It is notable that while
Stateless Address Autoconfiguration can operate with tentative
addresses, DHCP hosts require a non-tentative link-local address to
undertake DHCPv6 configuration.
Many multi-access LAN-like media in the Internet may be bridged into 8.5 Multicast Listener State
arbitrary topologies on the wired network. For these environments,
many wireless cells may be on the same IP hop, and multiple routers
may be reachable from each cell.
While most wireless access networks today contain one advertising Multicast routers on a link are aware of which groups are in use
router, hosts SHOULD NOT immediately assume that only one router is within a link. This information is used to undertake initiation of
on a link. multicast routing for off-link multicast sources to the link [8][10].
Importantly, a host SHOULD NOT change its configuration if a new When a node arrives on a link, it may need to send Multicast Listener
router advertises a prefix known to be used by another router on the Discovery (MLD) reports, if the multicast stream is not already being
same IP link. For such cases, hosts SHOULD undertake reachability received on the link. If it is an MLDv2 node it SHOULD send state
testing with the previously configured router before updating their change reports upon arrival on a link [10].
routing configuration [1].
7.6 Dealing with Incomplete Information Since the identity of the link is tied to the presence and identity
of routers, initiation of these procedures may be undertaken when DNA
procedures have been completed. In the absence of received data
packets from a multicast stream, it is unlikely that a host will be
able to determine if the multicast stream is being received on a new
link, and will have to send state change reports, in addition to
responses to periodic multicast queries [8][10].
When determining if network attachment has occurred, it may be For link scoped multicast, reporting needs to be done to ensure that
difficult to determine if a received multicast Router Advertisement packet reception in the link is available due to multicast snoopers.
is in response to a solicitation, or not. Some interaction is possible when sending messages for the purpose of
DNA on a network where multicast snooping is in use. This issue is
described in Section 11.5.
In this case it is also difficult for Router Advertisement receivers While RFC2710 [8] specifies that routers may ignore messages from
to determine which solicitation caused transmission of the RA. unspecified source addresses RFC 3590 [9] indicates that for the
Timing issues before Router Advertisement responses and between benefit of snooping switches such messages MAY be transmitted.
multicast advertisements may make it difficult to match Router
Solicitations and Advertisements using timing.
These issues are only relevant if Secured Neighbor Discovery (SEND) Since DNA procedures are likely to force link-local addresses to be
is not in use, since SEND provides explicit copies of Nonces, which tentative, this means MLD messages may need to be transmitted with
allow response matching [7]. unspecified source addresses while link-locals are tentative, in
order to complete DNA. This is discussed further in Section 11.5
The delays between Router Advertisements on each router depend on 8.6 Mobility Management
random delays and the recentness of advertisement by the routers.
Therefore, it is difficult for a device that is newly arrived on a
link to determine if more routers are present on a link when it
receives the first advertisement.
When the host still has to wait for other packet reception and Mobile IPv6 provides global mobility signaling for hosts wishing to
processing to complete (such as for the router's delegation chain preserve sessions when their configured address becomes topologically
authorization [7]), it is useful to continue monitoring Router incorrect [5]. This system relies upon signaling messages and tunnel
Advertisement packets in case the next responding router is one movement to provide reachability at a constant address, while
currently known to the host. directing packets to its visited network.
A host SHOULD accept a response from a previously known and The Mobile IPv6 RFC3775 [5] defines 'movement detection' procedures,
authorized router if it is received while awaiting completion of which themselves rely upon Neighbor Discovery, to initiate mobility
authorization checks for a new router. Note that previously known signaling. These procedures allow for some modification of Neighbor
but unsecured routers MUST NOT override routers whose authorization Discovery to enable faster change or movement detection. While this
is being assessed, as their advertisement may constitute a denial of document references parameters defined in [5], hosts are not required
service attack. to undertake global mobility signaling or tunneling in order to
benefit from detecting network attachment.
7.7 Configuration Algorithms After change detection occurs, a Mobile IPv6 mobile node still needs
to undertake global address configuration, and then mobility
signaling as specified in [5].
8.7 Other Configuration
When attempting to access the Internet, several other configuration
services may be required, dependent on the requirements of the access
networks.
In this case, it is likely that configuration parameters can be
passed to hosts using DHCPv6 [12]. The availability of such
additional configuration information can be advertised using Router
Advertisements [1].
IPv6 Stateless Address Autoconfiguration [3] describes an
OtherConfigFlag which is set when either the 'O' or the 'M' flags are
set in the Router Advertisement header. Hosts use the
OtherConfigFlag to determine if they need to undertake further
(non-addressing related) DHCPv6 procedures.
If the Advertisement's 'O' flag was set, but not the 'M' flag, the
host sends a DHCPv6 Information-Request message asking for such
configuration. This signaling may occur after completion of DNA
procedures.
9. Current Practice for Routers supporting DNA
This section provides guidance for those routers which wish to
support hosts undertaking detection of network attachment using
existing router and neighbor discovery techniques.
It should be noted that many deployed routers will not support these
recommendations, and that hosts SHOULD NOT rely on their being in
place, unless they have particular reason to do so.
9.1 Router Advertisement Intervals
The router discovery mechanism defined in RFC 2461 [1] recommends a
set of interval timers that affect the performance of the router
discovery procedure. The following table summarizes the values and
their effect.
+-----------------------+----+----+----+-----+----+-----+
| Timer |Maximum |Default |Minimum |
+-----------------------+----+----+----+-----+----+-----+
| MaxRtrAdvInterval | 1800 | 600 | 4 |
+-----------------------+----+----+----+-----+----+-----+
| MinRtrAdvInterval | 594 | 198 | 3 |
+-----------------------+----+----+----+-----+----+-----+
|Avg. Multicast RA time | 1197 | 399 | 3.5 |
+-----------------------+----+----+----+-----+----+-----+
|RA MCast response time | 3.5 | NA | 0 |
+-----------------------+----+----+----+-----+----+-----+
|RA Ucast response time | 0.5 | NA | 0 |
+-----------------------+----+----+----+-----+----+-----+
Assuming Poisson arrival of router solicitation messages at the rate
of 0.05 messages per second, the average multicast RA response time
can be calculated as follows
Probability of at least one arrival in MIN_DELAY_BETWEEN_RAS time is:
(p) = 1 - exp (lambda * t) (i.e. 1 - P[X(t) == 0])
where lambda is the arrival rate of RS messages and t is
MIN_DELAY_BETWEEN_RAS
Given a Poisson occurrences in an interval, these occurrences are
uniformly located in that interval. Hence the delay introduced by
arrival in MIN_DELAY_BETWEEN_RAS time is p * t/2. Adding 0.250 for
the random delay introduced, the average multicast RA response time
is 0.458938 seconds.
The average unicast RA response time of course is 0.250 seconds.
The table gets modified as follows based on the recommendation of RFC
3775 [5]
+-----------------------+----+----+----+-----+----+-----+
| Timer |Maximum |Default |Minimum |
+-----------------------+----+----+----+-----+----+-----+
| MaxRtrAdvInterval | 1800 | 600 | 0.07 |
+-----------------------+----+----+----+-----+----+-----+
| MinRtrAdvInterval | 594 | 198 | 0.03 |
+-----------------------+----+----+----+-----+----+-----+
|Avg. Multicast RA time | 1197 | 399 | 0.05 |
+-----------------------+----+----+----+-----+----+-----+
|RA MCast response time | 0.5 | NA | 0 |
+-----------------------+----+----+----+-----+----+-----+
|RA UCast response time | 0.5 | NA | 0 |
+-----------------------+----+----+----+-----+----+-----+
Assuming Poisson arrival of router solicitation messages at the rate
of 0.05 messages per second, the average multicast RA response time =
0.250022 seconds. The average unicast RA response time is the same
0.250 seconds. Changing the minimum values for these protocol
constants as recommended by RFC 3775 [5] reduces the average time
delay introduced by both solicited and un-solicited Router
Advertisements. Adopting these values for the unsolicited Router
Advertisements will increase the bandwidth overhead for these RA
messages. With the minimum allowed average for un-solicited Router
Advertisements there would be 20 message per second, assuming the
minimum packet size for an RA with one prefix as 88 bytes, the
bandwidth used the RAs alone will be 14 kbps. If SEND packets are
used for these Router Advertisements, with the keys and certificates
the average packet size and hence the bandwidth used will increase
dramatically. The increased packet size because of SEND is not
present always, as the certificate transport is initiated only when
needed and will not affect ping-pong situations.
9.2 Unicast Response Transmission
The IPv6 Router Discovery allows the routers to respond to RS message
with a unicast RA, but does not mandate it [1]. The advantage in
responding with an unicast RA message is to allow the IP host to
infer bi-directional reachability from the RS-RA exchange. The
dis-advantage is that the router will not be able to aggregate its
response for multiple RS messages received during the wait period and
incorporate.
It is important to note that the MIN_DELAY_BETWEEN_RAS restriction
required by the Router Discovery is applicable only to multicast RAs
[1]. Routers MAY choose to respond to RS messages with a unicast RA
response to reduce the response delay if it sent a multicast RA
within the last MIN_DELAY_BETWEEN_RAS seconds. This difference may
not be very high if the value (0.03) suggested in Mobile IPv6 is
implemented [5].
9.3 Point-to-Point Links
IPv6 Router Discovery mandates the delay of RA responses by stating
(in section 6.2.6 of [1]):
"In all cases, Router Advertisements sent in response to a
Router Solicitation MUST be delayed by a random time
between 0 and MAX_RA_DELAY_TIME seconds."
Cases where the router is on a point-to-point link, this restriction
is too stringent as the router in question will be the only router on
the link. Routers on such point-to-point links MAY avoid the delay
by not waiting for the prescribed random time before responding for
the Router Solicitation message.
9.4 Prefix Advertisement
A router MAY choose to split the options in the RA and send multiple
RAs to reduce bandwidth overhead or to reduce the size of the RA to
below the link MTU (see section 6.2.3 of [1]).
If such a choice is made, average multicast RA time discussed in
Section 9.1 increases for each subset of the prefixes included in the
split RA messages. Routers SHOULD consistently include one of the
prefixes in each of its RA messages to provide the host with a unique
identifier based on the combination of link-local address and the
constant prefix, to identify the router every time a RA message is
received from the router.
9.5 Secured Neighbor Discovery
Routers supporting DNA SHOULD provide secured router discovery
services [7].
This requires not only digitally signed messaging from hosts to
provide immutability of neighbor discovery messages on the access
link, but delegated authority from the network infrastructure to
route particular prefixes.
This delegation chain is transmitted and received in Certification
Path Solicitation and Certification Path Advertisement Messages.
These messages are rate limited in a similar fashion to Router
Advertisements and RS/RA exchanges [7].
The certificates can be used by hosts to identify routers and their
owner organizations, as well as to determine their authorization to
route for the advertised prefixes.
10. Analysis of Configuration Algorithms
Hosts that travel in wireless IPv6 networks of unknown topology must Hosts that travel in wireless IPv6 networks of unknown topology must
determine appropriate procedures in order to minimize detection determine appropriate procedures in order to minimize detection
latency or preserve energy resources. If a host is prepared to latency or preserve energy resources. If a host is prepared to
accept any received Router Advertisement for configuring a default accept any received Router Advertisement for configuring a default
router, then it will complete link change detection more quickly than router, then it will complete link change detection more quickly than
a device that explicitly checks for the current router's a device that explicitly checks for the current router's
unreachability. unreachability.
This mechanism is called Eager Configuration Switching [14]. It may This mechanism is called Eager Configuration Switching [14]. It may
  Skipping to change at page 24, line 46:
An alternative mechanism is called Lazy Configuration Switching [14]. An alternative mechanism is called Lazy Configuration Switching [14].
This algorithm checks that the currently configured router is This algorithm checks that the currently configured router is
reachable before indicating configuration change. In this case, new reachable before indicating configuration change. In this case, new
configuration will be delayed until a timeout occurs, if the configuration will be delayed until a timeout occurs, if the
currently configured router is unreachable. currently configured router is unreachable.
Since the duration of such a timeout will significantly extend the Since the duration of such a timeout will significantly extend the
duration to detect link change, this procedure is best used if the duration to detect link change, this procedure is best used if the
cell change to link change ratio is very low. cell change to link change ratio is very low.
For example: For example, if the expected time to:
If the expected time to:
Successfully test reachability (with NS/NA) is N Successfully test reachability (with NS/NA) is N
Test unreachability with a timeout is T Test unreachability with a timeout is T
Receive a Router Advertisement is R Receive a Router Advertisement is R
Reconfigure the host is C Reconfigure the host is C
The probability of link change is Then the probability of L3 link change given a L2 point of attachment
has changed is
p = (# of L3 links)/(# of L2 Point of attachment) p = (Number of L3 links)/(Number of L2 Point of attachment)
The probability of received RA being from a router different from the The probability of received RA being from a router different from the
current access router is current access router is
p1 = (sum of all (nr - 1)/ NR) p1 = (sum of all (nr - 1)/ NR)
Where nr is the number of routers in each L3 link and NR is the total Where nr is the number of routers in each L3 link and NR is the total
number of routers. number of routers in the whole network under study.
Note that if you don't have multiple routers in the same L3 link, Note that if you don't have multiple routers in the same L3 link,
then all the (nr - 1) will be zero leading to then all the (nr - 1) will be zero leading to
p1 = 0 p1 = 0
Then the mean cost of Eager Configuration switching is: Then the mean cost of Eager Configuration switching is:
Cost(ECS)= R + ( (p + p1) * C ) Cost(ECS)= (R + C) * (p + p1)
And the cost of Lazy switching is: And the cost of Lazy switching is:
Cost(LCS)= (T + R + C) * p + (1 - p) * N Cost(LCS)= (T + R + C) * p + (1 - p) * N
The mean cost due to Lazy Configuration Switching is lower than that The mean cost due to Lazy Configuration Switching is lower than that
of Eager Configuration Switching if: of Eager Configuration Switching if:
( T + R + C ) * p + (1 - p) * N < R + C * (p + p1) ( T + R + C ) * p + (1 - p) * N < (R + C) * (p + p1)
Using the indicative figures: Using the indicative figures:
N=100ms N=100ms
T=1000ms T=1000ms
R=250ms R=100ms
C=100ms C=500ms
The values for p where LCS is better than ECS are: The values for p where LCS is better than ECS are:
p * (1000 + 250 + 100)ms + < 250ms + p * (1000 + 100 + 500 )ms + < (500 + 100)ms *
(1 - p)*100ms (p + p1)*100ms (1 - p)*100ms (p + p1)
1350ms * p + 100ms - 100ms * p < 250ms + 100 * (p + p1)
1250ms * p - 100 * (p + p1) < 150ms 1600ms * p + 100ms - 100ms * p < 600ms * (p + p1)
when p1 = 0 900ms * p + 100 ms < 600ms * p1
when p1 = 30%
1150 ms * p < 150 900 * p + 100 < 180
p < 150/1150
p < 0.131
p ~< 0.125 (=0.130)
when p1 = 20% 900 * p < 80
1250 * p - 100 * p - 20 < 150 p < 0.0888
1150 * p < 170
p < 170/1150
p < 0.147
For these parameters, the Lazy Configuration Switching has better For these parameters, the Lazy Configuration Switching has better
performance if the mean number of cells a device resides in before it performance if the mean number of cells a device resides in before it
has a link change is > 8. has a link change is > 11.
It may be noted that these costs are indicative of a system which It may be noted that these costs are indicative of a system which
requires a retransmission timeout of 1000ms to test unreachability, requires a retransmission timeout of 1000ms to test unreachability,
routers respond with unicast Router Advertisements, and DAD is routers respond with unicast Router Advertisements, and DAD is
neglected or has only 100ms of cost. neglected or has only 100ms of cost.
If the reconfiguration cost is C=1000ms you will have If the reconfiguration cost is C=1000ms you will have
2150 * p - 1000 * (p + p1) < 150 900 * p + 100 ms < 1100 * p1
if p1 = 20 % if p1 = 30 %
1150 * p - 200 < 150
1150 * p < 350 900 * p < 230
p < 0.304 p < 0.2555
For these parameters, the Lazy Configuration Switching has better For these parameters, the Lazy Configuration Switching has better
performance if the mean number of cells a device resides in before it performance if the mean number of cells a device resides in before it
has a link change is between 3 & 4. has a link change is between 3 & 4. This system describes a similar
one to that above, except that in this case, the delays due to DAD or
This system describes a similar one to that above, except that in configuration are the default value of 1000ms.
this case, the delays due to DAD or configuration are the default
value of 1000ms.
8. Reachability Detection
The three different methods suggested for validating current
configuration have implied reachability confirmations in the messages
exchanged. This section identifies the reachability implications
from the hosts' perspective for the four different message exchanges
that are possible. The table below presents this implication for the
two directions involved, upstream referring to the direction from the
host to the router and downstream from the router to the host. The
host can confirm bi-directional reachability from any of the three
message exchanges except when a multicast RA is received at the host
for its RS message. In this case, the host cannot know whether the
multicast RA is in response to its solicitation message or whether it
is a periodic un-solicited transmission from the router.
+-----------------+----+----+----+-----+
| Exchanges: |Upstream |Downstream|
+-----------------+----+----+----+-----+
| multicast NS/NA | Y | Y |
+-----------------+----+----+----+-----+
| unicast NS/NA | Y | Y |
+-----------------+----+----+----+-----+
| RS/multicast RA | | Y |
+-----------------+----+----+----+-----+
| RS/unicast RA | Y | Y |
+-----------------+----+----+----+-----+
Successful exchange of the messages listed in the table indicate the
corresponding links to be operational. Lack of reception of response
from the router may indicate that reachability is broken for one or
both of the transmission directions or it may indicate ordinary
packet loss event in either direction.
If bi-directional reachability can not be confirmed using one of the
three message exchanges, the host SHOULD attempt to find a better
connection with possibly another router in the link. Because of the
transient nature of the wireless link, the reachability may change
during communication after reachability is verified. If multiple
routers were available, the host MAY defer test of reachability until
the interface is to be actively used for transmission and reception.
Hosts should also be aware of particular issues regarding their own
wireless access technology which impinge on the reliability of
reachability tests. Particularly, where unicast and multicast
propagation behaviors are significantly different, hosts SHOULD
attempt to test both multicast and unicast reachability, to ensure
that each works. Hosts MAY defer such additional tests where either
communications method is not likely to be used soon.
8.1 Wireless propagation
Wireless channel characteristics change both in space and time. Even
when a wireless host is not moving, its connectivity to the access
router can change due to factors like interference from other
objects, temperature etc. When the host is moving, the changes can
be more pronounced because of change in distance, introduction of new
objects in the LOS (line of sight) etc. The change to the
connectivity may affect both directions or it can be only in either
one of the directions. Hence, in wireless links, reachability in one
direction does not guarantee reachability in the other. Also, these
variations in the wireless channel can be very short lived, creating
rapid hints about the status of the link-layer. It is important to
consider the transient nature of the wireless links in design the DNA
mechanism for such channels.
8.2 Asymmetric Reachability
As mentioned in the previous section, wireless channels can provide
asymmetric reachability that requires reachability testing on both
directions. Even previously verified bi-directional reachability can
not guaranteed at a later time if there are other (higher layer or
link-layer) hints implying the loss of bi-directional reachability.
The frequency of initiation of reachability testing MUST be
controlled in order to avoid flooding of the network. Implementers
are advised to build in rate-limiting mechanisms to responding to the
hints to avoid switching IP configuration frequently when the quality
of the wireless channel is fluctuating (see Section 6.5).
8.3 Specific (Neighbor Solicitation) Tests
Bi-directional reachability can be verified using the Neighbor
Discovery test to the current access router. Since ND involves the
use of two unicast messages exchanged between the host and the access
router, a successful ND procedure verifies bi-directional
reachability.
8.4 Non-Specific (Router Solicitation) Tests
Initiating Router Discovery procedure can sometimes lead to
verification of the bi-directional reachability. It does not always
confirm bi-directional reachability because if the router responds
for the RS with a multicast RA message, there is no way for the host
to identify whether the RA is in response to the RS or whether it is
a periodic RA transmission. Even with multicast RA response, if SEND
is used, bi-directional reachability can confirmed because SEND uses
a unique NONCE to match request and response messages [7]. If the
router chooses to respond to a RS with a unicast RA message, again,
the host will be able to match the RS and RA and hence confirm
bi-directional reachability.
8.5 Trade-offs in Reachability Testing
There unique advantages and dis-advantages in using either the
Specific or the Non-specific test to confirm reachability.
Specific tests:
Advantages:
Confirmation of bi-directional reachability.
Dis-advantages:
If the ND test fails, the host has no potential configuration
information it can use.
Non-Specific tests:
Advantages:
Even when the current access router is not reachable, an RA message
from any available router will provide information that can used to
configure the host.
Confirmation of bi-directional reachability if SEND is used or if the
router chooses to respond with an unicast RA message.
Dis-advantages:
If multicast RA response is received, the host may have to execute an
ND test to confirm bi-directional reachability. Such a test may be
avoided if upper layer confirmations are received within the DELAY
period prescribed by IPv6 Neighbor Discovery [1].
Even when the current access router is reachable, the response may
arrive from a different access router leading to erroneous
re-configuration of the host.
9. Complications to Detecting Network Attachment 11. Complications to Detecting Network Attachment
Detection of network attachment procedures can be delayed or may be Detection of network attachment procedures can be delayed or may be
incorrect due to different factors. As the reachability testing incorrect due to different factors. As the reachability testing
mainly relies on timeout, packet loss or different router mainly relies on timeout, packet loss or different router
configurations may lead to erroneous conclusions. This section gives configurations may lead to erroneous conclusions. This section gives
some examples where complications may interfere with DNA processing. some examples where complications may interfere with DNA processing.
9.1 Tentative Addressing 11.1 Tentative Addressing
When a host connects to a new link, it needs to create a link-local When a host connects to a new link, it needs to create a link-local
address. But as the link-local address must be unique on a link, address. But as the link-local address must be unique on a link,
Duplication Address Detection (DAD) must be performed [3] by sending Duplication Address Detection (DAD) must be performed [3] by sending
NS to the target link-local address. An address that is being NS targeted at the link-local address undergoing validation. An
validated is said to be a tentative address. The host that only has address that is being validated is said to be a tentative address.
a tentative address must not accept packets intended to this The host that only has a tentative address must not accept packets
destination, neither may they send packets with it. If the host does intended to this destination, neither may send packets with it. If
not get any reply to its DAD Neighbor Solicitations, the tentative the host does not get any reply to its DAD Neighbor Solicitations,
link-local address can be allocated to the interface of the host. the tentative link-local address can be allocated to the interface of
From that point, the link-local address can be used and the prefix the host. From that point, the link-local address can be used and
and router discovery can then take place. the prefix and router discovery can then take place.
Several NS's can be sent to perform DAD on a tentative link local Several NS's can be sent to perform DAD on a tentative link local
address. However, the default number of transmissions of Neighbor address. However, the default number of transmissions of Neighbor
Solicitations is 1. If an NA is not received within one second after Solicitations is 1. If an NA is not received within one second after
the NS transmission, the tentative address is considered as unique. the NS transmission, the tentative address is considered as unique.
However, if the NS or NA are lost for some reason, the tentative However, if the NS or NA are lost for some reason, the tentative
address will be considered as unique while another node might have address will be considered as unique while another node might have
the same address. Notably though, each additional transmission of an the same address. Notably though, each additional transmission of an
NS introduces a delay of one second in the configuration NS introduces a delay of one second in the configuration
establishment, which has an important impact on IP configuration establishment, which has an important impact on IP configuration
  Skipping to change at page 31, line 8:
that link-local addresses SHOULD be treated as tentative, and that link-local addresses SHOULD be treated as tentative, and
globally unique addresses SHOULD NOT be used in a way which creates globally unique addresses SHOULD NOT be used in a way which creates
neighbor cache state on their peers, while DNA procedures are neighbor cache state on their peers, while DNA procedures are
underway. The different treatment of IP addressing comes from the underway. The different treatment of IP addressing comes from the
fact that on the global addresses cannot have an address conflict if fact that on the global addresses cannot have an address conflict if
they move to a topologically incorrect network where link-local they move to a topologically incorrect network where link-local
addresses may. Even though global addresses will not collide, the addresses may. Even though global addresses will not collide, the
incorrect creation of neighbor cache entries on legacy peers may incorrect creation of neighbor cache entries on legacy peers may
cause them some harm. cause them some harm.
9.2 Packet Loss 11.2 Packet Loss
Generally, packet loss while a host is validating or discovering an Generally, packet loss introduces significant delays in validation of
IP configuration introduces significant delays. Because most of the current configuration or discovery of new configuration. Because
protocols rely on timeout to consider that a peer is not reachable most of the protocols rely on timeout to consider that a peer is not
anymore, packet loss may lead to erroneous conclusions. Assume a reachable anymore, packet loss may lead to erroneous conclusions.
wireless host that connects to a new access point attached to the
same IPv6 subnet. The connexion establishment with the new access
point generates a link-layer hint trigger which tells the mobile node
that it may have moved to a new IPv6 link. Upon the reception of
this trigger, the mobile node may want to check reachability with its
current router and sends a NS. If the NS or the NA in response is
lost, the mobile node could conclude that it has changed link and
that its current default router is unreachable.
9.3 Router Configurations 11.3 Router Configurations
Each router can have its own configuration with respect to sending Each router can have its own configuration with respect to sending
RA, and the treatment of router and neighbor solicitations. RA, and the treatment of router and neighbor solicitations.
Different timers and constants might be used by different routers, Different timers and constants might be used by different routers,
such as the delay between Router Advertisements or delay before such as the delay between Router Advertisements or delay before
replying to an RS. If a host is changing is IPv6 link, new router on replying to an RS. If a host is changing is IPv6 link, new router on
that link may have a different configuration and may introduce more that link may have a different configuration and may introduce more
delay than the previous default router of the host. The time needed delay than the previous default router of the host. The time needed
to discover the new link can then be longer than expected by the to discover the new link can then be longer than expected by the
host. host.
9.4 Overlapping Coverage 11.4 Overlapping Coverage
If a host can be attached to different links at the same time with If a host can be attached to different links at the same time with
the same interface, the host will probably listen to different the same interface, the host will probably listen to different
routers, at least one on each link. To be simultaneously attached to routers, at least one on each link. To be simultaneously attached to
several links may be very valuable for a MN when it moves from one several links may be very valuable for a MN when it moves from one
access network to another. If the node can still be reachable access network to another. If the node can still be reachable
through its old link while configuring the interface for its new through its old link while configuring the interface for its new
link, packet loss can be minimized. Such a situation may happen in a link, packet loss can be minimized. Such a situation may happen in a
wireless environment if the link layer technology allows the MN to be wireless environment if the link layer technology allows the MN to be
simultaneously attached to several points of attachment and if the simultaneously attached to several points of attachment and if the
coverage area of access points are overlapping. For the DNA purpose, coverage area of access points are overlapping. For the purposes of
the different links should not be classified as a unique link. DNA, the different links should not be classified as a unique link.
Because if one router or an entire link where the node is attached Because if one router or an entire link where the node is attached
comes down, it doesn't mean that the other link are also down. In comes down doesn't mean that the other link is also down.
particular, the routers on the other links might still be reachable
for the host.
9.5 Multicast Snooping 11.5 Multicast Snooping
When a host is participating in DNA on a link where multicast When a host is participating in DNA on a link where multicast
snooping is in use, multicast packets may not be delivered to the snooping is in use, multicast packets may not be delivered to the
LAN-segment to which the host is attached until MLD signaling has LAN-segment to which the host is attached until MLD signaling has
been performed [8][10][15]. Where DNA relies upon multicast packet been performed [8][10][15]. Where DNA relies upon multicast packet
delivery (for example, if a router needs to send a Neighbor delivery (for example, if a router needs to send a Neighbor
Solicitation to the host), its function will be degraded until after Solicitation to the host), its function will be degraded until after
an MLD report is sent. an MLD report is sent.
Where it is possible that multicast snooping is in operation, hosts Where it is possible that multicast snooping is in operation, hosts
should consider sending MLD group joins (MLD reports) for solicited MUST send MLD group joins (MLD reports) for solicited nodes'
nodes' addresses swiftly after starting DNA procedures. addresses swiftly after starting DNA procedures.
10. Current Practice for Routers supporting DNA
This section provides guidance for those routers which wish to
support hosts undertaking detection of network attachment using
existing router and neighbor discovery techniques.
It should be noted that many deployed routers will not support these
recommendations, and that hosts SHOULD NOT rely on their being in
place, unless they have particular reason to do so.
10.1 Router Advertisement Intervals
The router discovery mechanism defined in RFC 2461 [1] recommends a
set of interval timers that affect the performance of the router
discovery procedure. The following table summarizes the values and
their effect.
+-----------------------+----+----+----+-----+----+-----+
| Timer |Maximum |Default |Minimum |
+-----------------------+----+----+----+-----+----+-----+
| MaxRtrAdvInterval | 1800 | 600 | 4 |
+-----------------------+----+----+----+-----+----+-----+
| MinRtrAdvInterval | 594 | 198 | 3 |
+-----------------------+----+----+----+-----+----+-----+
|Avg. Multicast RA time | 1197 | 399 | 3.5 |
+-----------------------+----+----+----+-----+----+-----+
|RA MCast response time | 3.5 | NA | 0 |
+-----------------------+----+----+----+-----+----+-----+
|RA Ucast response time | 0.5 | NA | 0 |
+-----------------------+----+----+----+-----+----+-----+
Assuming Poisson arrival of router solicitation messages at the rate
of 0.05 messages per second, the average multicast RA response time
can be calculated as follows
Probability of at least one arrival in MIN_DELAY_BETWEEN_RAS time is:
(p) = 1 - exp (lambda * t) (i.e. 1 - P[X(t) == 0])
where lambda is the arrival rate of RS messages and t is
MIN_DELAY_BETWEEN_RAS
Given a Poisson occurrences in an interval, these occurrences are
uniformly located in that interval. Hence the delay introduced by
arrival in MIN_DELAY_BETWEEN_RAS time is p * t/2. Adding 0.250 for
the random delay introduced, the average multicast RA response time
is 0.458938 seconds.
The average unicast RA response time of course is 0.250 seconds.
The table gets modified as follows based on the recommendation of RFC
3775 [5]
+-----------------------+----+----+----+-----+----+-----+
| Timer |Maximum |Default |Minimum |
+-----------------------+----+----+----+-----+----+-----+
| MaxRtrAdvInterval | 1800 | 600 | 0.07 |
+-----------------------+----+----+----+-----+----+-----+
| MinRtrAdvInterval | 594 | 198 | 0.03 |
+-----------------------+----+----+----+-----+----+-----+
|Avg. Multicast RA time | 1197 | 399 | 0.05 |
+-----------------------+----+----+----+-----+----+-----+
|RA MCast response time | 0.5 | NA | 0 |
+-----------------------+----+----+----+-----+----+-----+
|RA UCast response time | 0.5 | NA | 0 |
+-----------------------+----+----+----+-----+----+-----+
Assuming Poisson arrival of router solicitation messages at the rate
of 0.05 messages per second, the average multicast RA response time =
0.250022 seconds. The average unicast RA response time is the same
0.250 seconds. Changing the minimum values for these protocol
constants as recommended by RFC 3775 [5] reduces the average time
delay introduced by both solicited and un-solicited Router
Advertisements. But, adopting these values for the unsolicited
Router Advertisements will increase the bandwidth overhead for these
RA messages. With the minimum allowed average for un-solicited
Router Advertisements there would be 20 message per second, assuming
the minimum packet size for an RA with one prefix as 88 bytes, the
bandwidth used the RAs alone will be 14 kbps. If SEND packets are
used for these Router Advertisements, with the keys and certificates
the average packet size and hence the bandwidth used will increase
dramatically.
10.2 Unicast Response Transmission
The IPv6 Neighbor Discovery RFC allows the routers to respond to RS
message with a unicast RA, but does not mandate it [1]. The
advantage in responding with an unicast RA message is to allow the IP
host to infer bi-directional reachability from the RS-RA exchange.
The dis-advantage is that the router will not be able to aggregate
its response for multiple RS messages received during the wait
period.
It is important to note that the MIN_DELAY_BETWEEN_RAS restriction
required by the Neighbor Discovery RFC is applicable only to
multicast RAs [1]. Routers MAY choose to respond to RS messages with
a unicast RA response to reduce the response delay if it sent a
multicast RA within the last MIN_DELAY_BETWEEN_RAS seconds. This
difference may not be very high if the value (0.03) suggested in
Mobile IPv6 is implemented [5].
10.3 Point-to-Point Links
IPv6 Neighbor Discovery RFC mandates the delay of RA responses by
stating (in section 6.2.6 of [1]):
"In all cases, Router Advertisements sent in response to a
Router Solicitation MUST be delayed by a random time
between 0 and MAX_RA_DELAY_TIME seconds."
Cases where the router is on a point-to-point link, this restriction
is too stringent as the router in question will be the only router on
the link. Routers on such point-to-point links MAY avoid the delay
by not waiting for the prescribed random time before responding for
the Router Solicitation message.
10.4 Prefix Advertisement
A router MAY choose to split the options in the RA and send multiple
RAs to reduce bandwidth overhead or to reduce the size of the RA to
below the link MTU (see section 6.2.3 of [1]).
If such a choice is made, average multicast RA time discussed in
Section 10.1 increases for each subset of the prefixes included in
the split RA messages. Routers SHOULD consistently include one of
the prefixes in each of its RA messages to provide the host with a
unique identifier based on the combination of link-local address and
the constant prefix, to identify the router every time a RA message
is received from the router.
TBD: Checking for consistency?
10.5 Secured Neighbor Discovery
Routers supporting DNA SHOULD provide secured router discovery
services [7].
This requires not only digitally signed messaging from hosts to 11.6 Link Partition
provide immutability of neighbour discovery messages on the access
link, but delegated authority from the network infrastructure to
route particular prefixes.
This delegation chain is transmitted and received in Delegation Chain Link partitioning occurs when a link's internal switching or relaying
Solicitation and Delegation Chain Advertisement Messages. These hardware fails, or if the internal communications within a link are
messages are rate limited in a similar fashion to Router prevented due to topology changes or wireless propagation.
Advertisements and RS/RA exchanges [7].
The certificates can be used by hosts to identify routers and their When a host is on a link which partitions, only a subset of the
owner organizations, as well as to determine their authorization to addresses or devices it is communicating with may still be available.
route for the advertised prefixes. Where link partitioning is rare (for example, with wired
communication between routers on the link), existing router and
neighbor discovery procedures may be sufficient for detecting change.
11. Security Considerations 12. Security Considerations
Detecting Network Attachment is a mechanism which allows network Detecting Network Attachment is a mechanism which allows network
messages to change the node's belief about its configuration state. messages to change the node's belief about its IPv6 configuration
As such, it is important that the need for rapid testing of link state. As such, it is important that the need for rapid testing of
change does not lead to situations where configuration is invalidated link change does not lead to situations where configuration is
by malicious third parties, nor that information passed to invalidated by malicious third parties, nor that information passed
configuration processes exposes the host to attack. to configuration processes exposes the host to other attacks.
Since DNA relies heavily upon IPv6 Neighbor Discovery, the threats Since DNA relies heavily upon IPv6 Neighbor Discovery, the threats
which are applicable to those procedures also affect Detecting which are applicable to those procedures also affect Detecting
Network Attachment. These threats are described in [11]. Network Attachment. These threats are described in [11].
Some additional threats are outlined below. Some additional threats are outlined below.
11.1 Replay or impersonation of messages. 12.1 Securing Router Discovery
DNA relies particularly heavily upon router discovery in order to
test the validity of routing and addressing configuration. In
addition to reachability and configuration parameters,routing
authorization needs to be determined for each router.In SEND [7],
routing authorization is delegated by certificate authorities.
SEND Router Advertisement packets contain the router's public key
from a key pair used to sign the message. Certificate authorities
delegate a portion of their routing authority to the router, tying
them to the public key of the router. Hosts need to test the
router's authority to provide routing for the prefixes advertised in
its RAs in order to ensure safe configuration.
12.2 Replay or impersonation of messages.
If a host receives a series of messages which authenticate the If a host receives a series of messages which authenticate the
transmission of Router Advertisements, but aren't sent in response to transmission of Router Advertisements, but aren't sent in response to
the host's own solicitation, there is no guarantee that the router is the host's own solicitation, there is no guarantee that the router is
actually present on the link. actually present on the link.
If an attacking device can replay advertisements elsewhere, such a If an attacking device can replay advertisements elsewhere, such a
router may be accepted based on the freshness of its timestamps in router may be accepted based on the freshness of its timestamps in
accordance with [7], until the host attempts bidirectional accordance with [7], until the host attempts bidirectional
reachability tests with the false router. reachability tests with the false router.
  Skipping to change at page 36, line 28:
determining if a host has a delayed clock, and replaying signaling determining if a host has a delayed clock, and replaying signaling
messages. messages.
Additionally, if hosts' clocks can be made to slow down or speed up, Additionally, if hosts' clocks can be made to slow down or speed up,
secured neighbor discovery messages can be forced outside the valid secured neighbor discovery messages can be forced outside the valid
window, and prevent correctly configured SEND messages from being window, and prevent correctly configured SEND messages from being
processed. In this case, it may be possible to bid down the host to processed. In this case, it may be possible to bid down the host to
choose an unsecured Router Advertisement that doesn't perform SEND to choose an unsecured Router Advertisement that doesn't perform SEND to
a valid router that does. a valid router that does.
11.2 Authorization and Detecting Network Attachment 12.3 Authorization and Detecting Network Attachment
Hosts connecting to the Internet over wireless media may be exposed Hosts connecting to the Internet over wireless media may be exposed
to a variety of network configurations with differing robustness, to a variety of network configurations with differing robustness,
controls and security. controls and security.
When a host is determining if link change has occurred, it may When a host is determining if link change has occurred, it may
receive messages from devices with no advertised security mechanisms receive messages from devices with no advertised security mechanisms
purporting to be routers, nodes sending signed router advertisements purporting to be routers, nodes sending signed router advertisements
but with unknown delegation, or routers whose credentials need to be but with unknown delegation, or routers whose credentials need to be
checked [11]. Where a host wishes to configure an unsecured router, checked [11]. Where a host wishes to configure an unsecured router,
  Skipping to change at page 36, line 50:
device, and it MUST mark the device as unsecured as described in [7]. device, and it MUST mark the device as unsecured as described in [7].
In any case, a secured router SHOULD be preferred over an unsecured In any case, a secured router SHOULD be preferred over an unsecured
one, except where other factors (unreachability) make the router one, except where other factors (unreachability) make the router
unsuitable. Since secured routers' advertisement services may be unsuitable. Since secured routers' advertisement services may be
subject to attack, alternative (secured) reachability mechanisms from subject to attack, alternative (secured) reachability mechanisms from
upper layers, or secured reachability of other devices known to be on upper layers, or secured reachability of other devices known to be on
the same link may be used to check reachability in the first the same link may be used to check reachability in the first
instance. instance.
11.3 Addressing 12.4 Addressing
While a DNA host is checking attachment, and observing DAD, it may While a DNA host is checking attachment, and observing DAD, it may
receive a DAD defense NA from an unsecured source. receive a DAD defense NA from an unsecured source.
SEND says that DAD defenses MAY be accepted even from non SEND nodes SEND says that DAD defenses MAY be accepted even from non SEND nodes
for the first configured address [7]. for the first configured address [7].
While this is a valid action in the case where a host collides with While this is a valid action in the case where a host collides with
another address owner after arrival on a new link, In the case that another address owner after arrival on a new link, In the case that
the host returns immediately to the same link, such a DAD defense NA the host returns immediately to the same link, such a DAD defense NA
  Skipping to change at page 37, line 24:
If a non-SEND node forges a DAD defense for an address which is still If a non-SEND node forges a DAD defense for an address which is still
in peers' neighbor cache entries, a host may send a SEND protected in peers' neighbor cache entries, a host may send a SEND protected
unicast neighbor solicitation without a source link-layer address unicast neighbor solicitation without a source link-layer address
option to one its peers (which also uses SEND). If this peer is option to one its peers (which also uses SEND). If this peer is
reachable, it will not have registered the non-SEND DAD defense NA in reachable, it will not have registered the non-SEND DAD defense NA in
its neighbor cache, and will send a direct NA back to the soliciting its neighbor cache, and will send a direct NA back to the soliciting
host. Such an NA reception disproves the DAD defense NA's validity. host. Such an NA reception disproves the DAD defense NA's validity.
Therefore, a SEND host performing DNA which receives a DAD defense Therefore, a SEND host performing DNA which receives a DAD defense
from a non-SEND node SHOULD send a unicast Neighbor Solicitation to a from a non-SEND node SHOULD send a unicast Neighbor Solicitation to a
STALE or REACHABLE secured neighbor cache entry, omitting source STALE or REACHABLE secure neighbor cache entry, omitting source
link-layer address options. In this case, the host should pick an link-layer address options. In this case, the host should pick an
entry which is likely to have a corresponding entry on the peer. If entry which is likely to have a corresponding entry on the peer. If
the host responds within a RetransTimer interval, then the DAD the host responds within a RetransTimer interval, then the DAD
defense was an attack, and the host SHOULD inform its systems defense was an attack, and the host SHOULD inform its systems
administrator without disabling the address. administrator without disabling the address.
12. Acknowledgments 13. Acknowledgments
JinHyeock Choi has done lots of work regarding inference of link JinHyeock Choi and Erik Nordmark have done lots of work regarding
identity through sets of prefixes. Bernard Aboba's work on DNA for inference of link identity through sets of prefixes. Bernard Aboba's
IPv4 significantly influenced this document. work on DNA for IPv4 significantly influenced this document.
13. References 14. References
13.1 Normative References 14.1 Normative References
[1] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for [1] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for
IP Version 6 (IPv6)", RFC 2461, December 1998. IP Version 6 (IPv6)", RFC 2461, December 1998.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[3] Thomson, S. and T. Narten, "IPv6 Stateless Address [3] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC2462 2462, December 1998. Autoconfiguration", RFC2462 2462, December 1998.
  Skipping to change at page 38, line 16:
IPv6", RFC 3775, June 2004. IPv6", RFC 3775, June 2004.
[6] Conta, A. and S. Deering, "Internet Control Message Protocol [6] Conta, A. and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6) (ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC2463 2463, December 1998. Specification", RFC2463 2463, December 1998.
[7] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander, [7] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander,
"SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-05 "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-05
(work in progress), April 2004. (work in progress), April 2004.
13.2 Informative References 14.2 Informative References
[8] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener [8] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener
Discovery (MLD) for IPv6", RFC 2710, October 1999. Discovery (MLD) for IPv6", RFC 2710, October 1999.
[9] Haberman, B., "Source Address Selection for the Multicast [9] Haberman, B., "Source Address Selection for the Multicast
Listener Discovery (MLD) Protocol", RFC 3590, September 2003. Listener Discovery (MLD) Protocol", RFC 3590, September 2003.
[10] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 [10] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", RFC 3810, June 2004. (MLDv2) for IPv6", RFC 3810, June 2004.
  Skipping to change at page 39, line 22:
(MAC) and Physical Layer (PHY) Specifications", ANSI/IEEE Std (MAC) and Physical Layer (PHY) Specifications", ANSI/IEEE Std
802.11, 1999. 802.11, 1999.
[20] Yamamoto, S., "Detecting Network Attachment Terminology", [20] Yamamoto, S., "Detecting Network Attachment Terminology",
draft-yamamoto-dna-term-00 (work in progress), February 2004. draft-yamamoto-dna-term-00 (work in progress), February 2004.
[21] Manner, J. and M. Kojo, "Mobility Related Terminology", [21] Manner, J. and M. Kojo, "Mobility Related Terminology",
draft-ietf-seamoby-mobility-terminology-06 (work in progress), draft-ietf-seamoby-mobility-terminology-06 (work in progress),
February 2004. February 2004.
[22] Choi, J. and E. Nordmark, "DNA with unmodified routers: Prefix
list based approach", draft-jinchor-dna-cpl-00.txt (work in
progress), June 2004.
Authors' Addresses Authors' Addresses
Sathya Narayanan Sathya Narayanan
Panasonic Digital Networking Lab Panasonic Digital Networking Lab
Two Research Way, 3rd Floor Two Research Way, 3rd Floor
Princeton, NJ 08536 Princeton, NJ 08536
USA USA
Phone: 609 734 7599 Phone: 609 734 7599
EMail: sathya@Research.Panasonic.COM EMail: sathya@Research.Panasonic.COM
 End of changes. 

This html diff was produced by rfcdiff v1.01, available from http://www.levkowetz.com/ietf/tools/rfcdiff/