draft-ietf-dna-hosts-01.txt | draft-ietf-dna-hosts-02.txt | |
---|---|---|
DNA Working Group S. Narayanan | DNA Working Group S. Narayanan | |
Internet-Draft Panasonic | Internet-Draft Panasonic | |
Expires: December 25, 2005 G. Daley | Expires: April 27, 2006 G. Daley | |
Monash University CTIE | Monash University CTIE | |
N. Montavont | N. Montavont | |
LSIIT - ULP | LSIIT - ULP | |
June 23, 2005 | October 24, 2005 | |
Detecting Network Attachment in IPv6 - Best Current Practices for hosts. | Detecting Network Attachment in IPv6 - Best Current Practices for hosts. | |
draft-ietf-dna-hosts-01.txt | draft-ietf-dna-hosts-02.txt | |
Status of this Memo | Status of this Memo | |
By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |
applicable patent or other IPR claims of which he or she is aware | applicable patent or other IPR claims of which he or she is aware | |
have been or will be disclosed, and any of which he or she becomes | have been or will be disclosed, and any of which he or she becomes | |
aware will be disclosed, in accordance with Section 6 of BCP 79. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |
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 25, 2005. | This Internet-Draft will expire on April 27, 2006. | |
Copyright Notice | Copyright Notice | |
Copyright (C) The Internet Society (2005). | Copyright (C) The Internet Society (2005). | |
Abstract | Abstract | |
Hosts experiencing rapid link-layer changes may require efficient IP | Hosts experiencing rapid link-layer changes may require efficient IP | |
configuration change detection procedures than traditional fixed | configuration change detection procedures than traditional fixed | |
hosts. DNA is defined as the process by which a host collects | hosts. DNA is defined as the process by which a host collects | |
appropriate information and detects the identity of its currently | appropriate information and detects the identity of its currently | |
attached link to ascertains the validity of its IP configuration. | attached link to ascertain the validity of its IP configuration. | |
This document details best current practice for Detecting Network | This document details best current practice for Detecting Network | |
Attachment in IPv6 hosts using existing Neighbor Discovery | Attachment in IPv6 hosts using existing Neighbor Discovery | |
procedures. Since there is no explicit link identification mechanism | procedures. Since there is no explicit link identification mechanism | |
in the existing Neighbor Discovery for IP Version 6, the document | in the existing Neighbor Discovery for IP Version 6, the document | |
describes implicit mechanisms for identifying the current link. | describes implicit mechanisms for identifying the current link. | |
Table of Contents | Table of Contents | |
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |
1.1 Structure of this Document . . . . . . . . . . . . . . . . 5 | 1.1 Structure of this Document . . . . . . . . . . . . . . . . 4 | |
2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 5 | 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 4 | |
3. Background & Motivation for DNA . . . . . . . . . . . . . . . 6 | 3. Background & Motivation for DNA . . . . . . . . . . . . . . . 5 | |
3.1 Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 3.1 Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |
4. Detecting Network Attachment Steps . . . . . . . . . . . . . . 7 | 4. Detecting Network Attachment Steps . . . . . . . . . . . . . . 6 | |
4.1 Making use of Prior Information . . . . . . . . . . . . . 7 | 4.1 Making use of Prior Information . . . . . . . . . . . . . 7 | |
4.2 Duplicate Address Detection . . . . . . . . . . . . . . . 8 | 4.2 Link identification . . . . . . . . . . . . . . . . . . . 8 | |
4.3 Link identification . . . . . . . . . . . . . . . . . . . 9 | 4.2.1 Same link . . . . . . . . . . . . . . . . . . . . . . 8 | |
4.3.1 Same link . . . . . . . . . . . . . . . . . . . . . . 9 | 4.2.2 Link change . . . . . . . . . . . . . . . . . . . . . 8 | |
4.3.2 Link change . . . . . . . . . . . . . . . . . . . . . 10 | 4.3 IP Hosts Configuration . . . . . . . . . . . . . . . . . . 9 | |
4.4 Multicast Listener State . . . . . . . . . . . . . . . . . 10 | 4.4 Duplicate Address Detection . . . . . . . . . . . . . . . 9 | |
4.5 Reachability detection . . . . . . . . . . . . . . . . . . 10 | 4.5 Multicast Listener State . . . . . . . . . . . . . . . . . 10 | |
4.6 Reachability detection . . . . . . . . . . . . . . . . . . 10 | ||
5. Initiation of DNA Procedures . . . . . . . . . . . . . . . . . 11 | 5. Initiation of DNA Procedures . . . . . . . . . . . . . . . . . 11 | |
5.1 Actions Upon Hint Reception . . . . . . . . . . . . . . . 12 | 5.1 Actions Upon Hint Reception . . . . . . . . . . . . . . . 12 | |
5.2 Hints Due to Network Layer Messages . . . . . . . . . . . 12 | 5.2 Hints Due to Network Layer Messages . . . . . . . . . . . 12 | |
5.3 Handling Hints from Other Layers . . . . . . . . . . . . . 13 | 5.3 Handling Hints from Other Layers . . . . . . . . . . . . . 12 | |
5.4 Timer and Loss Based Hints . . . . . . . . . . . . . . . . 13 | 5.4 Timer and Loss Based Hints . . . . . . . . . . . . . . . . 13 | |
5.5 Simultaneous Hints . . . . . . . . . . . . . . . . . . . . 14 | 5.5 Simultaneous Hints . . . . . . . . . . . . . . . . . . . . 13 | |
5.6 Hint Validity and Hysteresis . . . . . . . . . . . . . . . 14 | 5.6 Hint Management for Inactive Hosts . . . . . . . . . . . . 14 | |
5.7 Hint Management for Inactive Hosts . . . . . . . . . . . . 15 | ||
6. IP Hosts Configuration . . . . . . . . . . . . . . . . . . . . 15 | ||
6.1 Router and Prefix list . . . . . . . . . . . . . . . . . . 15 | ||
6.2 IPv6 Addresses . . . . . . . . . . . . . . . . . . . . . . 16 | ||
6.2.1 Autoconfiguration . . . . . . . . . . . . . . . . . . 16 | ||
6.2.2 Dynamic Host Configuration . . . . . . . . . . . . . . 16 | ||
6.3 Neighbor cache . . . . . . . . . . . . . . . . . . . . . . 17 | ||
6.4 Mobility Management . . . . . . . . . . . . . . . . . . . 17 | ||
7. Complications to Detecting Network Attachment . . . . . . . . 18 | ||
7.1 Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 18 | ||
7.2 Router Configurations . . . . . . . . . . . . . . . . . . 18 | ||
7.3 Overlapping Coverage . . . . . . . . . . . . . . . . . . . 18 | ||
7.4 Multicast Snooping . . . . . . . . . . . . . . . . . . . . 19 | ||
7.5 Link Partition . . . . . . . . . . . . . . . . . . . . . . 19 | ||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 | 6. Complications to Detecting Network Attachment . . . . . . . . 14 | |
8.1 Authorization and Detecting Network Attachment . . . . . . 20 | 6.1 Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 14 | |
8.2 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 20 | 6.2 Router Configurations . . . . . . . . . . . . . . . . . . 15 | |
6.3 Overlapping Coverage . . . . . . . . . . . . . . . . . . . 15 | ||
6.4 Multicast Snooping . . . . . . . . . . . . . . . . . . . . 15 | ||
6.5 Link Partition . . . . . . . . . . . . . . . . . . . . . . 16 | ||
9. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 21 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 | |
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 21 | 7.1 Authorization and Detecting Network Attachment . . . . . . 16 | |
7.2 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 17 | ||
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 | 8. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 17 | |
11.1 Normative References . . . . . . . . . . . . . . . . . . . 21 | ||
11.2 Informative References . . . . . . . . . . . . . . . . . . 22 | ||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 | |
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 | ||
10.1 Normative References . . . . . . . . . . . . . . . . . . . 17 | ||
10.2 Informative References . . . . . . . . . . . . . . . . . . 18 | ||
A. Example State Transition Diagram . . . . . . . . . . . . . . . 24 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 | |
Intellectual Property and Copyright Statements . . . . . . . . 25 | Intellectual Property and Copyright Statements . . . . . . . . 21 | |
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 [15]. | for changes in the validity of a host's IP configuration [15]. | |
Changes may occur on establishment or disconnection of a link-layer. | Changes may occur on establishment or disconnection of a link-layer. | |
For newly connected interfaces, they may be on a link different from | For newly connected interfaces, they may be on a link different from | |
the existing configuration of the node. | the existing configuration of the node. | |
In these and other cases, IP addressing and default routing | In such cases, IP addressing and default routing configuration of the | |
configuration of the node may become invalid preventing packet | node may become invalid preventing packet transfer. DNA uses IPv6 | |
transfer. DNA uses IPv6 Neighbour Discovery to provide information | Neighbour Discovery to provide information about the reachability and | |
about the reachability and identity of the link. | identity of the link. | |
DNA focuses on determining whether the current configuration is | DNA focuses on determining whether the current configuration is | |
valid, leaving the actual practice of re-configuration to other | valid, leaving the actual practice of re-configuration to other | |
subsystems, if the current configuration is invalid. | subsystems, if the current configuration is invalid. | |
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 background and motivation for | Section 3 of this document provides background and motivation for | |
Detecting Network Attachment. | Detecting Network Attachment. | |
Elaboration of specific practices for hosts in detecting network | Elaboration of specific practices for hosts in detecting network | |
attachment continues in Section 4, while Section 5 discuss the | attachment continues in Section 4, while Section 5 discuss the | |
initiation of DNA procedures. | initiation of DNA procedures. | |
Section 6 describes interactions with other protocols, particularly | Section 7 provides security considerations, and details a number of | |
upon link-change, while Section 7 describes environmental challenges | ||
to detection of network attachment. | ||
Section 8 provides security considerations, and details a number of | ||
issues which arise due to wireless connectivity and the changeable | issues which arise due to wireless connectivity and the changeable | |
nature of DNA hosts' Internet connections. | nature of DNA hosts' Internet connections. | |
2. Terms and Abbreviations | 2. Terms and Abbreviations | |
Access network: A network where hosts are present. Especially, a | Access network: A network where hosts are present. Especially, a | |
network used for the support of visiting wireless hosts. | network used for the support of visiting wireless hosts. | |
Attachment: The process of entering a new cell. Attachment (and | Attachment: The process of entering a new cell. Attachment (and | |
detachment) may cause a link-change. | detachment) may cause a link-change. | |
Cell: A system constituted by the propagation range of a wireless | Cell: A system constituted by the propagation range of a wireless | |
base station and its serviced hosts. Dependent on topology, one | base station and its serviced hosts. Dependent on topology, one | |
or many cells may be part of the same link. | or many cells may be part of the same link. | |
Skipping to change at page 6, line 43: | ||
Wireless Medium: A physical layer which incorporates free space | Wireless Medium: A physical layer which incorporates free space | |
electromagnetic or optical propagation. Such media are | electromagnetic or optical propagation. Such media are | |
susceptible to mobility and interference effects, potentially | susceptible to mobility and interference effects, potentially | |
resulting in high packet loss probabilities. | resulting in high packet loss probabilities. | |
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 and are | become common that hosts have access through wireless media and are | |
mobile, and have a variety of interfaces through which internet | mobile. The frequency of configuration change for wireless and | |
connectivity is provided. The frequency of configuration change for | nomadic devices are high due to the vagaries of wireless propagation | |
wireless and nomadic devices are high due to the vagaries of wireless | or the motion of the hosts themselves. Detecting Network Attachment | |
propagation or the motion of the hosts themselves. Detecting Network | is a strategy to assist such rapid configuration changes by | |
Attachment is a strategy to assist such rapid configuration changes | determining whether they are required. | |
by determining whether they are required. | ||
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 to avoid | detection mechanism for DNA needs to be efficient and rapid to avoid | |
unnecessary configuration delays upon link-change. | unnecessary configuration delays upon link-change. | |
In an wireless environment, there will typically be a trade-off | In a wireless environment, there will typically be a trade-off | |
between configuration delays and the channel bandwidth utilized or | between configuration delays and the channel bandwidth utilized or | |
host's energy used to transmit packets. This trade-off affects | host's energy used to transmit packets. This trade-off affects | |
choices as to whether hosts probe for configuration information, or | choices as to whether hosts probe for configuration information, or | |
wait for network information. DNA seeks to assist hosts by providing | wait for network information. DNA seeks to assist hosts by providing | |
information about network state, which may allow hosts to | information about network state, which may allow hosts to | |
appropriately make decisions regarding such trade-offs. | appropriately make decisions regarding such trade-offs. | |
Even though DNA is restricted to determining whether change is | Even though DNA is restricted to determining whether change is | |
needed, in some circumstances the process of obtaining information | needed, in some circumstances the process of obtaining information | |
for the new configuration may occur simultaneously with the detection | for the new configuration may occur simultaneously with the detection | |
Skipping to change at page 7, line 38: | ||
The default router address is link-local address and hence may | The default router address is link-local address and hence may | |
only be unique within one link [1]. | only be unique within one link [1]. | |
While neighbor cache entries are valid only on a single link, | While neighbor cache entries are valid only on a single link, | |
link-local addresses may be duplicated across many links, and only | link-local addresses may be duplicated across many links, and only | |
global addressing can be used to identify if there is a link | global addressing can be used to identify if there is a link | |
change. | change. | |
4. Detecting Network Attachment Steps | 4. Detecting Network Attachment Steps | |
An IPv6 host SHOULD follow the following steps when they receive a | ||
hint (see Section 5) indicating the possibility of link change. | ||
Try making use of prior information stored related to the links | ||
the host visited in the past (see Section 4.1). | ||
If the prior information implies no link change, the host MAY | ||
conduct reachability detection (see Section 4.6) to one of the | ||
default routers it is using, otherwise no action is needed. | ||
If the prior information implies that there is a link change or | ||
there is no useful prior information available, follow the | ||
procedure below. | ||
Mark all the IPv6 addresses in use as optimistic. | ||
Conduct link identification. (See Section 4.2). | ||
If the link has changed | ||
Change the IP configuration parameters of the host (see | ||
Section 4.3). | ||
Configure new address and conduct duplicate address detection | ||
(see Section 4.4). | ||
Conduct multicast listner discovery (see Section 4.5). | ||
If the link has NOT changed | ||
Restore the address configuration state of all the IPv6 | ||
addresses known to be on the link. | ||
Conduct reachability detection to one of the default routers | ||
(see Section 4.6). | ||
4.1 Making use of Prior Information | 4.1 Making use of Prior Information | |
A device that has recently been attached to a particular wireless | A device that has recently been attached to a particular wireless | |
base station may still have state regarding the IP configuration | base station may still have state regarding the IP configuration | |
valid for use on that link. This allows a host to begin any | valid for use on that link. This allows a host to begin any | |
configuration procedures before checking the ongoing validity and | configuration procedures before checking the ongoing validity and | |
security of the parameters. | security of the parameters. | |
The experimental protocols FMIPv6 [19] and CARD [20] each provide | The experimental protocols FMIPv6 [19] and CARD [20] each provide | |
ways to generate such information using network-layer signaling, | ways to generate such information using network-layer signaling, | |
Skipping to change at page 8, line 14: | ||
A IP host MAY store L2 to L3 mapping information for the links for a | A IP host MAY store L2 to L3 mapping information for the links for a | |
period of time in order to use the information in the future. When a | period of time in order to use the information in the future. When a | |
host attaches itself to a point-of-attachment for which it has an L2 | host attaches itself to a point-of-attachment for which it has an L2 | |
to L3 mapping, if the stored record doesn't contain the prefix the | to L3 mapping, if the stored record doesn't contain the prefix the | |
host is using, the host SHOULD conclude that it has changed link and | host is using, the host SHOULD conclude that it has changed link and | |
initiate a new configuration procedure. | initiate a new configuration procedure. | |
If the host finds the prefix it is using in the stored record, a host | If the host finds the prefix it is using in the stored record, a host | |
MAY conclude that it is on the same link, but SHOULD undertake | MAY conclude that it is on the same link, but SHOULD undertake | |
reachability testing as described in Section 4.5. In this case, the | reachability testing as described in Section 4.6. In this case, the | |
host MUST undertake Duplicate Address Detection [3][8] to confirm | host MUST undertake Duplicate Address Detection [3][8] to confirm | |
that there are no duplicate addresses on the link. | that there are no duplicate addresses on the link. | |
The host MUST age this cached information based on the possibility | The host MUST age this cached information based on the possibility | |
that the link's configuration has changed and MUST NOT store | that the link's configuration has changed and MUST NOT store | |
information beyond either the remaining router or address lifetime or | information beyond either the remaining router or address lifetime or | |
(at the outside) MAC_CACHE_TIME time-units. | (at the outside) MAC_CACHE_TIME time-units. | |
If the assumptions attached to the stored configuration are incorrect | 4.2 Link identification | |
the configuration cost may be increased, or even cause 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. | ||
4.2 Duplicate Address Detection | ||
When a host connects to a new link, it needs to create a link-local | ||
address. But to ensure that the link-local address is unique on a | ||
link, Duplication Address Detection (DAD) MUST be performed [3] by | ||
sending NS targeted at the link-local address undergoing validation. | ||
Optimistic Duplicate Address Detection allows addresses to be used | ||
while they are being checked, without marking addresses as tentative. | ||
Procedures defined in optimistic DAD [8] ensure that persistent | ||
invalid neighbour cache entries are not created. This may allow | ||
faster DNA procedures, by avoiding use of unspecified source | ||
addresses in RS's and consequently allowing unicast Router | ||
Advertisements responses [8]. It is RECOMMENDED that hosts follow | ||
the recommendations of optimistic DAD [8] to reduce the DAD delay. | ||
Link-local addresses SHOULD be treated as either optimistic or | ||
tentative, and globally unique addresses SHOULD NOT be used in a way | ||
which creates neighbor cache state on their peers, while DNA | ||
procedures are underway. | ||
While hosts performing DNA do not know if they have arrived on a new | ||
link, they SHOULD treat their addresses as if they were. The | ||
different treatment of IP addressing comes from the fact that on the | ||
global addresses cannot have an address conflict if they move to a | ||
topologically incorrect network where link-local addresses may. Even | ||
though global addresses will not collide, the incorrect creation of | ||
neighbor cache entries on legacy peers may cause them some harm. | ||
In the case that the host has not changed link and if the time | ||
elapsed since the hint is less than the DAD completion time (minus a | ||
packet transmission and propagation time), the host MAY reclaim the | ||
address by sending 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. | ||
If a host has not been present on a link to defend its address, and | ||
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][8]. | ||
4.3 Link identification | ||
4.3.1 Same link | 4.2.1 Same link | |
An IP host MUST conclude that it is on the same link if any of the | An IP host MUST conclude that it is on the same link if any of the | |
following events happen. | following events happen. | |
Reception of a RA with the prefix known to be on the link from one | Reception of a RA with the prefix known to be on the link from one | |
of its default router address, even if it is the link-local | of its default router address, even if it is the link-local | |
address of the router. | address of the router. | |
Reception of a RA from a known router's global address, present in | Reception of a RA from a known router's global address, present in | |
a Prefix Information Option containing the R-"Router Address" flag | a Prefix Information Option containing the R-"Router Address" flag | |
Skipping to change at page 10, line 5: | ||
Reception of a RA with a prefix that is known to be on the current | Reception of a RA with a prefix that is known to be on the current | |
link. | link. | |
Reception of data packets addressed to its current global address | Reception of data packets addressed to its current global address | |
if the message was sent from or through a device which is known to | if the message was sent from or through a device which is known to | |
be fixed (such as a router). | be fixed (such as a router). | |
Confirmation of a global address entry with the Router 'R' flag | Confirmation of a global address entry with the Router 'R' flag | |
set in its neighbor cache[1]. | set in its neighbor cache[1]. | |
4.3.2 Link change | 4.2.2 Link change | |
A host makes use of Router Discovery messages to determine that it | A host makes use of Router Discovery messages to determine that it | |
has moved to a new link. Since the content of an existing received | has moved to a new link. Since the content of an existing received | |
RA is not sufficient to identify the absence of any other prefix, | RA is not sufficient to identify the absence of any other prefix, | |
additional inference is required for fast and accurate link-change | additional inference is required for fast and accurate link-change | |
detection. | detection. | |
Complete Prefix Lists provide a robust mechanism for link-change | Complete Prefix Lists provide a robust mechanism for link-change | |
detection with even unmodified non-DNA routers if link-layer | detection if link-layer indications are available [24][18]. These | |
indications are available [24][18]. These procedures provide | procedures provide mechanisms to build confidence that a host knows | |
mechanisms to build confidence that a host knows all of a link's | all of a link's prefixes and so may rapidly identify a newly received | |
prefixes and so may rapidly identify a newly received RA as being | RA as being from a different link. | |
from a different link. | ||
A host SHOULD maintain a complete prefix list as recommended by | A host SHOULD maintain a complete prefix list as recommended by | |
[24] to identify if the link has changed. | [24] to identify if the link has changed. | |
4.4 Multicast Listener State | 4.3 IP Hosts Configuration | |
Various protocols within IPv6 provide their own configuration | ||
processes. A host will have collected various configuration | ||
information using these protocols during its presence on a link. | ||
Following is the list of steps the host needs to take if a link- | ||
change has occured. | ||
Invalidation of router and prefix list: On determining that link- | ||
change has occurred, the host SHOULD remove entries from the | ||
default router list removed which are related to unreachable | ||
routers. Destination cache entries using information from these | ||
routers 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. | ||
Invalidation of IPv6 addresses: Addresses which relate to invalidated | ||
prefix list entries SHOULD be removed. | ||
Removing neighbor cache entries: When link change occurs, the | ||
reachability of all existing neighbor cache entries is likely to | ||
be invalidated, if link change prevents 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]). | ||
Completion of DAD for Link-Local Addresses: Link-local addresses used | ||
for DNA purposes may be tentative or optimistic at the completion | ||
of change detection procedures. Where link-change has occurred, | ||
these processes SHOULD continue to completion, as described in [3] | ||
and [8]. | ||
Initiating mobility signaling: Any signaling required to restore end- | ||
to-end communications occurs after DNA, if link-change has | ||
occurred. | ||
4.4 Duplicate Address Detection | ||
When a host connects to a new link, it needs to create a link-local | ||
address. But to ensure that the link-local address is unique on a | ||
link, Duplication Address Detection (DAD) MUST be performed [3] by | ||
sending NS targeted at the link-local address undergoing validation. | ||
Optimistic Duplicate Address Detection allows addresses to be used | ||
while they are being checked, without marking addresses as tentative. | ||
Procedures defined in optimistic DAD [8] ensure that persistent | ||
invalid neighbour cache entries are not created. This may allow | ||
faster DNA procedures, by avoiding use of unspecified source | ||
addresses in RS's and consequently allowing unicast Router | ||
Advertisements responses [8]. It is RECOMMENDED that hosts follow | ||
the recommendations of optimistic DAD [8] to reduce the DAD delay. | ||
4.5 Multicast Listener State | ||
Multicast routers on a link are aware of which groups are in use | Multicast routers on a link are aware of which groups are in use | |
within a link. This information is used to undertake initiation of | within a link. This information is used to undertake initiation of | |
multicast routing for off-link multicast sources to the link [9] | multicast routing for off-link multicast sources to the link [9] | |
[11]. | [11]. | |
When a node arrives on a link, it may need to send Multicast Listener | When a node arrives on a link, it MAY need to send Multicast Listener | |
Discovery (MLD) reports, if the multicast stream is not already being | Discovery (MLD) reports, if the multicast stream is not already being | |
received on the link. If it is an MLDv2 node it SHOULD send state | received on the link. If it is an MLDv2 node it SHOULD send state | |
change reports upon arrival on a link [11]. | change reports upon arrival on a link [11]. | |
Since the identity of the link is tied to the presence and identity | Since the identity of the link is tied to the presence and identity | |
of routers, initiation of these procedures may be undertaken when DNA | of routers, initiation of these procedures may be undertaken when DNA | |
procedures have been completed. In the absence of received data | procedures have been completed. In the absence of received data | |
packets from a multicast stream, it is unlikely that a host will be | 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 | 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 | link, and will have to send state change reports, in addition to | |
responses to periodic multicast queries [9] [11]. | responses to periodic multicast queries [9] [11]. | |
For link scoped multicast, reporting needs to be done to ensure that | For link scoped multicast, reporting needs to be done to ensure that | |
packet reception in the link is available due to multicast snoopers. | packet reception in the link is available due to multicast snoopers. | |
Some interaction is possible when sending messages for the purpose of | Some interaction is possible when sending messages for the purpose of | |
DNA on a network where multicast snooping is in use. This issue is | DNA on a network where multicast snooping is in use. This issue is | |
described in Section 7.4. | described in Section 6.4. | |
4.5 Reachability detection | 4.6 Reachability detection | |
If an IP node needs to confirm bi-directional reachability to its | If an IP node needs to confirm bi-directional reachability to its | |
default router either a NS-NA or an RS-RA message exchange can be | default router either a NS-NA or an RS-RA message exchange can be | |
used to conduct reachability testing. It is notable that the choice | used to conduct reachability testing. It is notable that the choice | |
of whether the messages are addressed to multicast or unicast address | of whether the messages are addressed to multicast or unicast address | |
will have different reachability implications. The reachability | will have different reachability implications. The reachability | |
implications from the hosts' perspective for the four different | implications from the hosts' perspective for the four different | |
message exchanges defined by RFC 2461 [1] are presented in the table | message exchanges defined by RFC 2461 [1] are presented in the table | |
below. The host can confirm bi-directional reachability from the | below. The host can confirm bi-directional reachability from the | |
neighbor discovery or router discovery message exchanges except when | neighbor discovery or router discovery message exchanges except when | |
Skipping to change at page 12, line 15: | ||
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. | |
Hosts MUST ensure that untrusted hints do not cause unnecessary | Hosts MUST ensure that untrusted hints do not cause unnecessary | |
configuration changes, or significant consumption of host resources | configuration changes, or significant consumption of host resources | |
or bandwidth. In order to achieve this aim, a host MAY implement | or bandwidth. In order to achieve this aim, a host MAY implement | |
hysteresis mechanisms such as token buckets, hint weighting or | hysteresis mechanisms such as token buckets, hint weighting or | |
holddown timers in order to limit the effect of excessive hints (see | holddown timers in order to limit the effect of excessive hints. | |
Section 5.6). | ||
5.1 Actions Upon Hint Reception | 5.1 Actions Upon Hint Reception | |
Upon reception of a hint that link change detection may have | Upon reception of a hint that link change detection may have | |
occurred, a host SHOULD send Router Solicitation messages to | occurred, a host SHOULD send Router Solicitation messages to | |
determine the routers and prefixes which exist on a link. Hosts | determine the routers and prefixes which exist on a link. Hosts | |
SHOULD apply rate limiting and/or hysteresis to this behaviour as | SHOULD apply rate limiting and/or hysteresis to this behaviour as | |
appropriate to the link technology subject to the reliability of the | appropriate to the link technology subject to the reliability of the | |
hints. | hints. | |
Skipping to change at page 12, line 43: | ||
Hint reception may be due to network-layer messages such as | Hint reception may be due to network-layer messages such as | |
unexpected Router Advertisements, multicast listener queries or | unexpected Router Advertisements, multicast listener queries or | |
ICMPv6 error messages [1][9][6]. In these cases, the authenticity of | ICMPv6 error messages [1][9][6]. In these cases, the authenticity of | |
the messages MUST be verified before expending resources to initiate | the messages MUST be verified before expending resources to initiate | |
DNA procedure. | DNA procedure. | |
When a host arrives on a new link, hints received due to external IP | When a host arrives on a new link, hints received due to external IP | |
packets will typically be due to multicast messages. Actions based | packets will typically be due to multicast messages. Actions based | |
on multicast reception from untrusted sources are dangerous due to | on multicast reception from untrusted sources are dangerous due to | |
the threat of multicast response flooding. This issue is discussed | the threat of multicast response flooding. This issue is discussed | |
further in Section 8. | further in Section 7. | |
State changes within the network-layer itself may initiate link- | State changes within the network-layer itself may initiate link- | |
change detection procedures. Existing subsystems for router and | 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. | |
5.3 Handling Hints from Other Layers | 5.3 Handling Hints from Other Layers | |
Skipping to change at page 13, line 30: | ||
While these hints come from the host's own stack, such hints may | While these hints come from the host's own stack, such hints may | |
actually be due to packet reception or non-reception events at the | actually be due to packet reception or non-reception events at the | |
originating layers. As such, it may be possible for other devices to | originating layers. As such, it may be possible for other devices to | |
instigate hint delivery on a host or multiple hosts deliberately, in | instigate hint delivery on a host or multiple hosts deliberately, in | |
order to prompt packet transmission, or configuration modification. | order to prompt packet transmission, or configuration modification. | |
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 adopt an appropriate | hints from other protocol layers. A host MAY adopt an appropriate | |
link change detection strategy based upon hints received from other | link change detection strategy based upon hints received from other | |
layers, with suitable caution and hysteresis, as described in | layers, with suitable caution and hysteresis. | |
Section 5.6. | ||
5.4 Timer and Loss Based Hints | 5.4 Timer and Loss Based Hints | |
Other hints may be received due to timer expiry, particularly In some | Other hints may be received due to timer expiry, particularly In some | |
cases the expiry of these timers may be a good hint that DNA | cases the expiry of these timers may be a good hint that DNA | |
procedures are necessary. | procedures are necessary. | |
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 the DNA initiation system. Notably, non-reception | incorporated into the DNA initiation system. Notably, non-reception | |
Skipping to change at page 14, line 29: | ||
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. | |
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]. | |
5.6 Hint Validity and Hysteresis | 5.6 Hint Management for Inactive Hosts | |
In some cases, hints can be generated by lower-layer protocols at an | ||
elevated rate, which do not reflect actual changes in IP | ||
configuration. In other cases, hints may also be received prior to | ||
the availability of the medium for network-layer packets. | ||
Additionally, since packet reception at the network and other layers | ||
are a source for hints, it is possible for traffic patterns on the | ||
link to create hints, through chance or malicious intent. Therefore, | ||
it may be necessary to classify hint sources and types for their | ||
relevance and recent behavior. | ||
When experiencing a large number of hints, a host SHOULD employ | ||
hysteresis techniques to prevent excessive use of network resources. | ||
The host MAY change the weight of particular hints, to devalue them | ||
if their accuracy has been poor, they suggest invalid configurations, | ||
or are suspicious (refer to Section 8). | ||
It is notable, that such hysteresis may cause sub-optimal change | ||
detection performance, and may themselves be used to block legitimate | ||
hint reception. | ||
5.7 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 a solicitation [5]. | Interval (plus the random delay) before sending a solicitation [5]. | |
Skipping to change at page 15, line 29: | ||
tests, the number of devices actively probing for data simultaneously | tests, the number of devices actively probing for data simultaneously | |
is reduced to those hosts which currently support active data | is reduced to those hosts which currently support active data | |
sessions. | 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. | |
6. IP Hosts Configuration | 6. Complications to Detecting Network Attachment | |
Various protocols within IPv6 provide their own configuration | ||
processes. A host will have collected various configuration | ||
information using these protocols during its presence on a link. | ||
Following is the list of steps the host needs to take if a link- | ||
change has occured. | ||
Invalidation of router and prefix list | ||
Invalidation of IPv6 addresses | ||
Removing neighbor cache entries | ||
Completion of DAD for Link-Local Addresses. | ||
Initiating mobility signaling | ||
The following sub-sections elaborate on these steps. | ||
6.1 Router and Prefix list | ||
Router Discovery is designed to provide hosts with a set of locally | ||
configurable prefixes and default routers. These may then be | ||
configured by hosts for access to the Internet [1]. | ||
It allows hosts to discover routers and manage lists of eligible next | ||
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 a 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 | ||
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. | ||
6.2 IPv6 Addresses | ||
6.2.1 Autoconfiguration | ||
Unicast source addresses are required to send all packets on the | ||
Internet, except a restricted subset of local signaling such as | ||
router and neighbor solicitations. | ||
In dynamic environments, hosts need to undertake automatic | ||
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 [13]. | ||
For any configured address, Duplicate Address Detection (DAD) MUST be | ||
performed [3]. DAD defines that an address is treated tentatively | ||
until either series of timeouts expire after probe transmissions or | ||
an address owner defends its address. Tentative addresses cannot | ||
modify peers' neighbor cache entries, nor can they receive packets. | ||
As described in Section 4.2, messages used in DNA signaling should be | ||
treated as unconfirmed, due to the chance of link change. Optimistic | ||
DAD is designed to allow use of addressing while they are being | ||
checked for validity. Careful use of these addresses may contribute | ||
to faster DNA operation [8]. | ||
6.2.2 Dynamic Host Configuration | ||
Dynamic Host Configuration Procedures for IPv6 define their own | ||
detection procedures [13]. In order to check if the current set of | ||
configuration is valid, a host can send a 'Confirm' message with a | ||
sample of its current configuration, which is able to be responded to | ||
by any DHCP relay on a link. | ||
If the replying relay knows it is not on the same link, it may | ||
respond, indicating that the host's configuration is invalid. | ||
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. | ||
Upon link change, any configuration learned from DHCP which is link | ||
or administrative domain specific may have become invalid. | ||
Subsequent operation of DHCP on the new link may therefore be | ||
necessary. | ||
6.3 Neighbor cache | ||
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. | ||
In order to determine which link-layer address a peer is at, nodes | ||
send solicitations to the link-local solicited-node multicast address | ||
of their peer. If hosts are reachable on this address, then they | ||
will respond to the solicitation with a unicast response. | ||
Information from these responses are stored in neighbour cache | ||
entries. | ||
When link change occurs, the reachability of all existing neighbor | ||
cache entries is likely to be invalidated, if link change prevents | ||
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]). | ||
Reachability of a single node may support the likelihood of reaching | ||
the rest of the link, for example if a particular access technology | ||
relays such messages through wireless base stations. | ||
6.4 Mobility Management | ||
Mobile IPv6 provides global mobility signaling for hosts wishing to | ||
preserve sessions when their configured address becomes topologically | ||
incorrect [5]. This system relies upon signaling messages and tunnel | ||
movement to provide reachability at a constant address, while | ||
directing packets to its visited network. | ||
The Mobile IPv6 RFC3775 [5] defines 'movement detection' procedures, | ||
which themselves rely upon Neighbor Discovery, to initiate mobility | ||
signaling. These procedures allow for some modification of Neighbor | ||
Discovery to enable faster change or movement detection. When a host | ||
identifies that it is on a new link, if it is Mobile-IPv6 enabled | ||
host, it MAY initiate mobility signaling with its home agent and | ||
correspondent node. | ||
7. 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. This section gives some examples | incorrect due to different factors. This section gives some examples | |
where complications may interfere with DNA processing. | where complications may interfere with DNA processing. | |
7.1 Packet Loss | 6.1 Packet Loss | |
Generally, packet loss introduces significant delays in validation of | Generally, packet loss introduces significant delays in validation of | |
current configuration or discovery of new configuration. Because | current configuration or discovery of new configuration. Because | |
most of the protocols rely on timeout to consider that a peer is not | most of the protocols rely on timeout to consider that a peer is not | |
reachable anymore, packet loss may lead to erroneous conclusions. | reachable anymore, packet loss may lead to erroneous conclusions. | |
Additionally, packet loss rates for particular transmission modes | Additionally, packet loss rates for particular transmission modes | |
(multicast or unicast) may differ, meaning that particular classes of | (multicast or unicast) may differ, meaning that particular classes of | |
DNA tests have higher chance of failure due to loss. Hosts SHOULD | DNA tests have higher chance of failure due to loss. Hosts SHOULD | |
attempt to verify tests through retransmission where packet loss is | attempt to verify tests through retransmission where packet loss is | |
prevalent. | prevalent. | |
7.2 Router Configurations | 6.2 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 its IPv6 link, the new | replying to an RS. If a host is changing its IPv6 link, the new | |
router on that link may have a different configuration and may | router on that link may have a different configuration and may | |
introduce more delay than the previous default router of the host. | introduce more delay than the previous default router of the host. | |
The time needed to discover the new link can then be longer than | The time needed to discover the new link can then be longer than | |
expected by the host. | expected by the host. | |
7.3 Overlapping Coverage | 6.3 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. | link, packet loss can be minimized. | |
Such a situation may happen in a wireless environment if the link | Such a situation may happen in a wireless environment if the link | |
layer technology allows the MN to be simultaneously attached to | layer technology allows the MN to be simultaneously attached to | |
several points of attachment and if the coverage area of access | several points of attachment and if the coverage area of access | |
points are overlapping. | points are overlapping. | |
For the purposes of DNA, it is necessary to treat each of these | For the purposes of DNA, it is necessary to treat each of these | |
points-of-attachment separately, otherwise incorrect conclusions of | points-of-attachment separately, otherwise incorrect conclusions of | |
link-change may be made even if another of the link-layer connections | link-change may be made even if another of the link-layer connections | |
is valid. | is valid. | |
7.4 Multicast Snooping | 6.4 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 [9][11] [17]. Where DNA relies upon multicast packet | been performed [9][11] [17]. 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 | |
MUST send MLD group joins (MLD reports) for solicited nodes' | MUST send MLD group joins (MLD reports) for solicited nodes' | |
addresses swiftly after starting DNA procedures. | addresses swiftly after starting DNA procedures. | |
7.5 Link Partition | 6.5 Link Partition | |
Link partitioning occurs when a link's internal switching or relaying | Link partitioning occurs when a link's internal switching or relaying | |
hardware fails, or if the internal communications within a link are | hardware fails, or if the internal communications within a link are | |
prevented due to topology changes or wireless propagation. | prevented due to topology changes or wireless propagation. | |
When a host is on a link which partitions, only a subset of the | When a host is on a link which partitions, only a subset of the | |
addresses or devices it is communicating with may still be available. | addresses or devices it is communicating with may still be available. | |
Where link partitioning is rare (for example, with wired | Where link partitioning is rare (for example, with wired | |
communication between routers on the link), existing router and | communication between routers on the link), existing router and | |
neighbor discovery procedures may be sufficient for detecting change. | neighbor discovery procedures may be sufficient for detecting change. | |
8. Security Considerations | 7. 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 IPv6 configuration | messages to change the node's belief about its IPv6 configuration | |
state. As such, it is important that the need for rapid testing of | state. As such, it is important that the need for rapid testing of | |
link change does not lead to situations where configuration is | link change does not lead to situations where configuration is | |
invalidated by malicious third parties, nor that information passed | invalidated by malicious third parties, nor that information passed | |
to configuration processes exposes the host to other attacks. | 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 [12]. | Network Attachment. These threats are described in [12]. | |
Some additional threats are outlined below. | Some additional threats are outlined below. | |
8.1 Authorization and Detecting Network Attachment | 7.1 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 [12]. Where a host wishes to configure an unsecured router, | checked [12]. Where a host wishes to configure an unsecured router, | |
Skipping to change at page 20, line 33: | ||
MUST mark the device as unsecured as described in [7]. | 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. | |
8.2 Addressing | 7.2 Addressing | |
While a DNA host is checking for link-change, and observing DAD, it | While a DNA host is checking for link-change, and observing DAD, it | |
may receive a DAD defense NA from an unsecured source. | may 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 | |
message can only be a denial-of-service attempt. | message can only be a denial-of-service attempt. | |
If a non-SEND node forges a DAD defense for an address which is still | 8. Constants | |
in peers' neighbor cache entries, a host may send a SEND protected | ||
unicast neighbor solicitation without a source link-layer address | ||
option to one of its peers (which also uses SEND). If this peer is | ||
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 | ||
host. Such an NA reception disproves the DAD defense NA's validity. | ||
Therefore, a SEND host performing DNA which receives a DAD defense | ||
from a non-SEND node SHOULD send a unicast Neighbor Solicitation to a | ||
STALE or REACHABLE secure neighbor cache entry, omitting source 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 the | ||
host responds within a RetransTimer interval, then the DAD defense | ||
was an attack, and the host SHOULD inform its systems administrator | ||
without disabling the address. | ||
9. Constants | ||
MAC_CACHE_TIME: 30 minutes | MAC_CACHE_TIME: 30 minutes | |
10. Acknowledgments | 9. Acknowledgments | |
Thanks to JinHyeock Choi and Erik Nordmark for their significant | Thanks to JinHyeock Choi and Erik Nordmark for their significant | |
contributions. Bernard Aboba's work on DNA for IPv4 strongly | contributions. Bernard Aboba's work on DNA for IPv4 strongly | |
influenced this document. | influenced this document. | |
11. References | 10. References | |
11.1 Normative References | 10.1 Normative References | |
[1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery | [1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery | |
for IP Version 6 (IPv6)", RFC 2461, December 1998. | for 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", RFC 2462, December 1998. | Autoconfiguration", RFC 2462, December 1998. | |
Skipping to change at page 22, line 5: | ||
(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., Zill, B., and P. Nikander, "SEcure | [7] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure | |
Neighbor Discovery (SEND)", RFC 3971, March 2005. | Neighbor Discovery (SEND)", RFC 3971, March 2005. | |
[8] Moore, N., "Optimistic Duplicate Address Detection for IPv6", | [8] Moore, N., "Optimistic Duplicate Address Detection for IPv6", | |
draft-ietf-ipv6-optimistic-dad-02 (work in progress), | draft-ietf-ipv6-optimistic-dad-02 (work in progress), | |
September 2004. | September 2004. | |
11.2 Informative References | 10.2 Informative References | |
[9] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener | [9] 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. | |
[10] Haberman, B., "Source Address Selection for the Multicast | [10] Haberman, B., "Source Address Selection for the Multicast | |
Listener Discovery (MLD) Protocol", RFC 3590, September 2003. | Listener Discovery (MLD) Protocol", RFC 3590, September 2003. | |
[11] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 | [11] 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 24, line 15: | ||
LSIIT - Univerity Louis Pasteur | LSIIT - Univerity Louis Pasteur | |
Pole API, bureau C444 | Pole API, bureau C444 | |
Boulevard Sebastien Brant | Boulevard Sebastien Brant | |
Illkirch 67400 | Illkirch 67400 | |
FRANCE | FRANCE | |
Phone: (33) 3 90 24 45 87 | Phone: (33) 3 90 24 45 87 | |
Email: montavont@dpt-info.u-strasbg.fr | Email: montavont@dpt-info.u-strasbg.fr | |
URI: http://www-r2.u-strasbg.fr/~montavont/ | URI: http://www-r2.u-strasbg.fr/~montavont/ | |
Appendix A. Example State Transition Diagram | ||
Below is an example state diagram which indicates relationships | ||
between the practices in this document. | ||
+---------+ +----------+ | ||
| Test |< - - - - -| Init |===> | ||
|Reachable|<-\ | Config |\ | ||
+---------+ +----------+ \ | ||
| \ New ^ \ | ||
| ID | \ | ||
V \ | | | ||
+---------+ +----------+ | | ||
| *Idle | \--| Link ID | | | ||
| |<==========| Check | | | ||
+---------+Same ID +----------+ | | ||
^ |Hint Creds^ | | ||
Timer| |Recv OK | | | ||
| | | | | ||
| | | | | ||
| V | | | ||
+----------+ Hint +----------+ | | ||
|Hysteresis| Recv | Authorize| | | ||
| |<--\ | Check | | | ||
+----------+ \-/ +----------+ | | ||
| ^ | | | ||
|Threshold RA | |Bad / | ||
| Recv| |Auth / | ||
V | V / | ||
+----------+ Solicit +----------+L | ||
| Init |=========>|Await | | ||
| DNA |<=========|Rtr Advert| | ||
+----------+ Timer +----------+ | ||
Intellectual Property Statement | Intellectual Property Statement | |
The IETF takes no position regarding the validity or scope of any | The IETF takes no position regarding the validity or scope of any | |
Intellectual Property Rights or other rights that might be claimed to | Intellectual Property Rights or other rights that might be claimed to | |
pertain to the implementation or use of the technology described in | pertain to the implementation or use of the technology described in | |
this document or the extent to which any license under such rights | this document or the extent to which any license under such rights | |
might or might not be available; nor does it represent that it has | might or might not be available; nor does it represent that it has | |
made any independent effort to identify any such rights. Information | made any independent effort to identify any such rights. Information | |
on the procedures with respect to rights in RFC documents can be | on the procedures with respect to rights in RFC documents can be | |
found in BCP 78 and BCP 79. | found in BCP 78 and BCP 79. | |
End of changes. | ||
This html diff was produced by rfcdiff v1.01, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |