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/ |