draft-ietf-dna-routers-00.txt | draft-ietf-dna-hosts-01.txt | |
---|---|---|
DNA Working Group S. Narayanan | DNA Working Group S. Narayanan | |
Internet-Draft Panasonic | Internet-Draft Panasonic | |
Expires: December 25, 2005 G. Daley | Expires: December 25, 2005 G. Daley | |
Monash University CTIE | Monash University CTIE | |
N. Montavont | N. Montavont | |
LSIIT - ULP | LSIIT - ULP | |
June 23, 2005 | June 23, 2005 | |
Detecting Network Attachment in IPv6 - Best Current Practices for | Detecting Network Attachment in IPv6 - Best Current Practices for hosts. | |
Routers | draft-ietf-dna-hosts-01.txt | |
draft-ietf-dna-routers-00.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 46: | ||
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 December 25, 2005. | |
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 to do | Hosts experiencing rapid link-layer changes may require efficient IP | |
configuration change detection procedures more frequently than | configuration change detection procedures than traditional fixed | |
traditional fixed hosts. This document describes practices available | hosts. DNA is defined as the process by which a host collects | |
to network deployers in order to support such hosts in Detecting | appropriate information and detects the identity of its currently | |
Network Attachment in IPv6 networks. | attached link to ascertains the validity of its IP configuration. | |
This document details best current practice for Detecting Network | ||
Attachment in IPv6 hosts using existing Neighbor Discovery | ||
procedures. Since there is no explicit link identification mechanism | ||
in the existing Neighbor Discovery for IP Version 6, the document | ||
describes implicit mechanisms for identifying the current link. | ||
Table of Contents | Table of Contents | |
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |
1.1 Terms and Abbreviations . . . . . . . . . . . . . . . . . 3 | 1.1 Structure of this Document . . . . . . . . . . . . . . . . 5 | |
1.2 Relevant Host Issues . . . . . . . . . . . . . . . . . . . 4 | ||
1.3 Relevant Router Issues . . . . . . . . . . . . . . . . . . 4 | ||
1.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . 5 | ||
2. Configuration Practices for DNAv6 Routers . . . . . . . . . . 5 | 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 5 | |
2.1 Multicast and Unicast RA Responses . . . . . . . . . . . . 5 | ||
2.1.1 Recommendations . . . . . . . . . . . . . . . . . . . 7 | ||
2.2 Router Advertisement Parameters . . . . . . . . . . . . . 7 | ||
2.2.1 Recommendations . . . . . . . . . . . . . . . . . . . 8 | ||
2.3 Router Advertisement Options . . . . . . . . . . . . . . . 8 | ||
2.3.1 Recommendations . . . . . . . . . . . . . . . . . . . 9 | ||
2.4 Triggered Router Advertisements . . . . . . . . . . . . . 9 | ||
2.5 Split Advertisements . . . . . . . . . . . . . . . . . . . 9 | ||
2.6 Router Configurations . . . . . . . . . . . . . . . . . . 10 | ||
3. Topological Practices for DNAv6 Networks . . . . . . . . . . . 10 | 3. Background & Motivation for DNA . . . . . . . . . . . . . . . 6 | |
3.1 Link Extent and Composition . . . . . . . . . . . . . . . 10 | 3.1 Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |
3.2 Wireless cell coverage . . . . . . . . . . . . . . . . . . 10 | ||
3.3 Multiple Router Links . . . . . . . . . . . . . . . . . . 11 | ||
3.4 Point-to-point Links . . . . . . . . . . . . . . . . . . . 12 | ||
3.5 Disjoint Administration . . . . . . . . . . . . . . . . . 12 | ||
4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | 4. Detecting Network Attachment Steps . . . . . . . . . . . . . . 7 | |
4.1 Supporting host security . . . . . . . . . . . . . . . . . 12 | 4.1 Making use of Prior Information . . . . . . . . . . . . . 7 | |
4.2 Providing Router Authorization . . . . . . . . . . . . . . 13 | 4.2 Duplicate Address Detection . . . . . . . . . . . . . . . 8 | |
4.3 Link identification . . . . . . . . . . . . . . . . . . . 9 | ||
4.3.1 Same link . . . . . . . . . . . . . . . . . . . . . . 9 | ||
4.3.2 Link change . . . . . . . . . . . . . . . . . . . . . 10 | ||
4.4 Multicast Listener State . . . . . . . . . . . . . . . . . 10 | ||
4.5 Reachability detection . . . . . . . . . . . . . . . . . . 10 | ||
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 | 5. Initiation of DNA Procedures . . . . . . . . . . . . . . . . . 11 | |
5.1 Normative References . . . . . . . . . . . . . . . . . . . 14 | 5.1 Actions Upon Hint Reception . . . . . . . . . . . . . . . 12 | |
5.2 Informative References . . . . . . . . . . . . . . . . . . 14 | 5.2 Hints Due to Network Layer Messages . . . . . . . . . . . 12 | |
5.3 Handling Hints from Other Layers . . . . . . . . . . . . . 13 | ||
5.4 Timer and Loss Based Hints . . . . . . . . . . . . . . . . 13 | ||
5.5 Simultaneous Hints . . . . . . . . . . . . . . . . . . . . 14 | ||
5.6 Hint Validity and Hysteresis . . . . . . . . . . . . . . . 14 | ||
5.7 Hint Management for Inactive Hosts . . . . . . . . . . . . 15 | ||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 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 | ||
A. Summary of Recommendations . . . . . . . . . . . . . . . . . . 16 | 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 | ||
B. Analysis of the response time . . . . . . . . . . . . . . . . 18 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 | |
8.1 Authorization and Detecting Network Attachment . . . . . . 20 | ||
8.2 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 20 | ||
C. Router Advertisement Rates . . . . . . . . . . . . . . . . . . 20 | 9. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 21 | |
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 21 | ||
Intellectual Property and Copyright Statements . . . . . . . . 22 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 | |
11.1 Normative References . . . . . . . . . . . . . . . . . . . 21 | ||
11.2 Informative References . . . . . . . . . . . . . . . . . . 22 | ||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 | ||
A. Example State Transition Diagram . . . . . . . . . . . . . . . 24 | ||
Intellectual Property and Copyright Statements . . . . . . . . 25 | ||
1. Introduction | 1. Introduction | |
Hosts on the Internet may be connected by various media. It has | When operating in changing environments, IPv6 hosts may experience | |
become common that hosts have access through wireless media and are | variations in reachability or configuration state over time. For | |
mobile. The frequency of configuration change for wireless and | hosts accessing the Internet over wireless media, such changes may be | |
nomadic devices are elevated, due to the vagaries of wireless | caused by changes in wireless propagation or host motion. | |
propagation or the motion of the hosts themselves. | ||
Such hosts need to determine if they have moved to a new IPv6 link | Detecting Network Attachment (DNA) in IPv6 is the task of checking | |
rapidly, in order that configuration procedures may be run and | for changes in the validity of a host's IP configuration [15]. | |
application packet delivery services restored. Detecting Network | Changes may occur on establishment or disconnection of a link-layer. | |
Attachment (DNA) is a strategy to assist such configuration changes | For newly connected interfaces, they may be on a link different from | |
by rapidly determining whether they are required. | the existing configuration of the node. | |
Several network-side factors may impact on the effectiveness and | In these and other cases, IP addressing and default routing | |
speed of DNA procedures. This document provides guidelines embodying | configuration of the node may become invalid preventing packet | |
the best current practice for network deployers wishing to support | transfer. DNA uses IPv6 Neighbour Discovery to provide information | |
detection of network attachment by IPv6 hosts. | about the reachability and identity of the link. | |
It should be noted that many already deployed routers will not | DNA focuses on determining whether the current configuration is | |
support these recommendations, and that hosts SHOULD NOT rely on | valid, leaving the actual practice of re-configuration to other | |
their being in place, unless they have particular reason to do so. | subsystems, if the current configuration is invalid. | |
1.1 Terms and Abbreviations | This document presents the best current practices for IPv6 hosts to | |
address the task of Detecting Network Attachment in changing and | ||
wireless environments. | ||
1.1 Structure of this Document | ||
Section 3 of this document provides background and motivation for | ||
Detecting Network Attachment. | ||
Elaboration of specific practices for hosts in detecting network | ||
attachment continues in Section 4, while Section 5 discuss the | ||
initiation of DNA procedures. | ||
Section 6 describes interactions with other protocols, particularly | ||
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 | ||
nature of DNA hosts' Internet connections. | ||
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 | ||
detachment) may cause a link-change. | ||
Cell: A system constituted by the propagation range of a wireless | ||
base station and its serviced hosts. Dependent on topology, one | ||
or many cells may be part of the same link. | ||
Hint: An indication from other subsystems or protocol layers that | ||
link-change may have occurred. | ||
Link: A link is the range across which communications can pass | Link: A link is the range across which communications can pass | |
without being forwarded through a router [1]. | without being forwarded through a router [1]. | |
Link-Change: Link-Change occurs when a host moves from a point-of- | Link-Change: Link-Change occurs when a host moves from a point-of- | |
attachment on a link, to another point-of-attachment where it is | attachment on a link, to another point-of-attachment where it is | |
unable to reach devices belonging to the previous link, without | unable to reach devices belonging to a link, without being | |
being forwarded through a router. | forwarded through a router. | |
Point-of-Attachment: A link-layer base-station, VLAN or port through | Point-of-Attachment: A link-layer base-station, VLAN or port through | |
which a device attempts to reach the network. Changes to a | which a device attempts to reach the network. Changes to a | |
host's point-of-attachment may cause link-change. | host's point-of-attachment may cause link-change. | |
Reachability Detection: Determination that a device (such as a | Reachability Detection: Determination that a device (such as a | |
router) is currently reachable, over both a wireless medium, and | router) is currently reachable, over both a wireless medium, and | |
any attached fixed network. This is typically achieved using | any attached fixed network. This is typically achieved using | |
Neighbor Unreachability Detection procedure [1]. | Neighbor Unreachability Detection procedure [1]. | |
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. | |
1.2 Relevant Host Issues | 3. Background & Motivation for DNA | |
Hosts attempting to discover link change are likely to send Router | ||
Solicitations (RSs) in order to identify the routers and prefixes | ||
available on a link. Additionally, they may wish to send Neighbour | ||
Solicitations (NSs) to known routers for reachability detection | ||
purposes. | ||
The following is a list of critical issues for hosts undertaking link | ||
change detection in IPv6: | ||
Hosts require Router Advertisements (RAs) rapidly in order to | ||
minimize reconfiguration latencies in the case of link change or | ||
link failure. | ||
Host wishes to identify if their current prefix is still valid on | Hosts on the Internet may be connected by various media. It has | |
a link before the prefix expires. Existing IPv6 Neighbour | become common that hosts have access through wireless media and are | |
Discovery procedures make this difficult. If the host can | mobile, and have a variety of interfaces through which internet | |
determine that the target router is still reachable through a | connectivity is provided. The frequency of configuration change for | |
NS/NA exchange, it does not mean that the prefix is still valid. | wireless and nomadic devices are high due to the vagaries of wireless | |
Conversely, if host sends an RS, the RA received in response may | propagation or the motion of the hosts themselves. Detecting Network | |
not contain the prefix of interest for the hosts. | Attachment is a strategy to assist such rapid configuration changes | |
by determining whether they are required. | ||
Hosts wish to detect if a particular router is reachable in order | Due to these frequent link-layer changes, an IP configuration change | |
to use it for routing. | detection mechanism for DNA needs to be efficient and rapid to avoid | |
unnecessary configuration delays upon link-change. | ||
Hosts may require some assurance that a device is actually | In an wireless environment, there will typically be a trade-off | |
present, and is authorized to act as a router. | between configuration delays and the channel bandwidth utilized or | |
host's energy used to transmit packets. This trade-off affects | ||
choices as to whether hosts probe for configuration information, or | ||
wait for network information. DNA seeks to assist hosts by providing | ||
information about network state, which may allow hosts to | ||
appropriately make decisions regarding such trade-offs. | ||
Consideration for these issues underlie the practices recommended in | Even though DNA is restricted to determining whether change is | |
this document. | needed, in some circumstances the process of obtaining information | |
for the new configuration may occur simultaneously with the detection | ||
to improve the efficiency of these two steps. | ||
1.3 Relevant Router Issues | 3.1 Issues | |
The IPv6 Neighbour Discovery RFC [1] provides mechanisms where | The following features of RFC 2461 make the detection of link | |
hosts can send Router Solicitations and receive Router | identity difficult: | |
Advertisements, from each of the routers on a link. | ||
Responses may either be unicast or multicast, but in all cases, a | Routers are not required to include all the prefixes they support | |
random delay of between 0 and 500 milliseconds is required before | in a single router advertisement message [1]. | |
responses are sent. This is to prevent multiple routers | ||
responding at the same time, and also may mitigate the effects of | ||
simultaneous solicitations. This results in a basic time delay | ||
incurred by hosts receiving response RAs, which cannot be avoided | ||
within current standards [1]. | ||
As described in Section 2.1, additional delays may occur if | The default router address is link-local address and hence may | |
multicast responses are required. | only be unique within one link [1]. | |
Routers should also be careful not to increase the network | While neighbor cache entries are valid only on a single link, | |
overhead by frequently transmitting router advertisements (see | link-local addresses may be duplicated across many links, and only | |
Section 2.4). | global addressing can be used to identify if there is a link | |
change. | ||
Routers should include all advertised prefixes within the same RA | 4. Detecting Network Attachment Steps | |
and indicate whether a previous advertised prefix is not valid | ||
anymore. Multiple prefixes advertised in different RAs by a | ||
single router may lead to host configurations errors. | ||
1.4 Summary | 4.1 Making use of Prior Information | |
The practices embodied in this document are considered to provide | A device that has recently been attached to a particular wireless | |
minimal support for hosts wishing to detect network attachment. | base station may still have state regarding the IP configuration | |
Current work within the DNA working group aims to provide | valid for use on that link. This allows a host to begin any | |
substantially improved performance for link change detection. | configuration procedures before checking the ongoing validity and | |
security of the parameters. | ||
Existing limitations in base protocols such as IPv6 Neighbour | The experimental protocols FMIPv6 [19] and CARD [20] each provide | |
Discovery preclude support of real-time applications in some | ways to generate such information using network-layer signaling, | |
environments. Future deployers and implementers are encouraged to | before arrival on a link. Additionally, the issue is the same when a | |
consider the protocols under development at this time in order to | host disconnects from one cell and returns to it immediately, or | |
provide a generic service to support hosts detecting change. | movement occurs between a pair of cells (the ping-pong effect). | |
2. Configuration Practices for DNAv6 Routers | 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 | ||
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 | ||
host is using, the host SHOULD conclude that it has changed link and | ||
initiate a new configuration procedure. | ||
Routers which are being deployed to support hosts' change detection | If the host finds the prefix it is using in the stored record, a host | |
procedures should attempt to use appropriate configurations, which | MAY conclude that it is on the same link, but SHOULD undertake | |
limit advertisement latency, and provide appropriate service | reachability testing as described in Section 4.5. In this case, the | |
considering the constraints of the deployed access network | host MUST undertake Duplicate Address Detection [3][8] to confirm | |
technology. | that there are no duplicate addresses on the link. | |
This section describes several configuration parameters which may | The host MUST age this cached information based on the possibility | |
exist on IPv6 routers, and how their tuning may affect DNA hosts. | that the link's configuration has changed and MUST NOT store | |
information beyond either the remaining router or address lifetime or | ||
(at the outside) MAC_CACHE_TIME time-units. | ||
2.1 Multicast and Unicast RA Responses | If the assumptions attached to the stored configuration are incorrect | |
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. | ||
While IPv6 Neighbour Discovery assumes that responses to | 4.2 Duplicate Address Detection | |
solicitations will be sent multicast, the specification allows any | ||
router to respond to RS message with a unicast RA if it desires [1]. | ||
The advantage in responding with an unicast RA message is to allow | When a host connects to a new link, it needs to create a link-local | |
the IP host to conclusively infer bi-directional reachability from | address. But to ensure that the link-local address is unique on a | |
the RS-RA exchange. Neighbour Discovery does not provide any | link, Duplication Address Detection (DAD) MUST be performed [3] by | |
mechanism to match multicast RA responses with their solicitation, | sending NS targeted at the link-local address undergoing validation. | |
and therefore it is not possible for the hosts to find out whether at | ||
least one of its RS messages was received and processed by the | ||
router. Since unicast RAs are only sent in response to solicitation, | ||
a host can infer that at least one of its Router Solicitations | ||
reached the router. | ||
The dis-advantage in sending unicast RA is that the router will not | Optimistic Duplicate Address Detection allows addresses to be used | |
be able to aggregate its response for multiple RS messages from | while they are being checked, without marking addresses as tentative. | |
multiple hosts received during the waiting period before RA | Procedures defined in optimistic DAD [8] ensure that persistent | |
transmission. | 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. | ||
Where many unicast responses are scheduled awaiting transmission, | Link-local addresses SHOULD be treated as either optimistic or | |
Routers MAY consider aggregating them into a single multicast | tentative, and globally unique addresses SHOULD NOT be used in a way | |
response if a multicast advertisement may be sent before the | which creates neighbor cache state on their peers, while DNA | |
advertisements' scheduled transmission time. | procedures are underway. | |
It is noted that computational requirements for SEND may preclude | While hosts performing DNA do not know if they have arrived on a new | |
this subsequent aggregation in some environments. | 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. | ||
Where multiple unicast transmissions for the same destination await | In the case that the host has not changed link and if the time | |
transmission, routers MAY remove all transmissions after the first | elapsed since the hint is less than the DAD completion time (minus a | |
without ill-effect, if a multicast RA is scheduled for the next | packet transmission and propagation time), the host MAY reclaim the | |
possible response time. | 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. | ||
For multicast Router Advertisements, a minimum separating delay | If a host has not been present on a link to defend its address, and | |
exists so that these RAs may not be scheduled close to each other. | has been absent for a full DAD delay (minus transmission time) the | |
When a host solicits and attempts to schedule a multicast RA within | host MUST undertake the full DAD procedure for each address from that | |
MIN_DELAY_BETWEEN_RAS (or MinDelayBetweenRAs from Mobile IPv6 [3]) of | link it wishes to configure [3][8]. | |
the previous multicast Router Advertisement, the scheduling of a | ||
response will be deferred until the minimum separation expires. | ||
This separation delay does not affect unicast Router Advertisement | 4.3 Link identification | |
responses. Routers MAY choose to respond to RS messages with a | ||
unicast RA response to avoid the delay introduced by the | ||
MIN_DELAY_BETWEEN_RAS restriction [1]. | ||
In some cases it is not possible to provide unicast responses, since | 4.3.1 Same link | |
solicitations may be sent with an unspecified address, or | ||
solicitations do not provide enough link-layer addressing information | ||
to send an unicast response without neighbour discovery exchange. In | ||
these cases, a router may need to send multicast responses, even if | ||
the expected delay is greater. | ||
2.1.1 Recommendations | An IP host MUST conclude that it is on the same link if any of the | |
following events happen. | ||
Routers SHOULD respond to a RS message with unicast RS message. | 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 | ||
address of the router. | ||
Routers SHOULD aggregate RA messages into a multi-cast RA message | Reception of a RA from a known router's global address, present in | |
if more than 3 unicast RA messages are queued for transmission. | a Prefix Information Option containing the R-"Router Address" flag | |
[5]. | ||
Where multiple unicast transmissions for the same destination | A host SHOULD conclude that it is on the same link if any of the | |
await transmission, routers MAY remove all transmissions after the | following events happen. | |
first without ill-effect. | ||
2.2 Router Advertisement Parameters | Reception of a RA with a prefix that is known to be on the current | |
link. | ||
Where hosts have changeable connectivity, there may be a number of | Reception of data packets addressed to its current global address | |
prefixes or routers stored in the host's memory, which are no longer | if the message was sent from or through a device which is known to | |
directly reachable. This additional storage may make movement | be fixed (such as a router). | |
detection slower where hosts rapidly pass through networks, or pass | ||
through networks which have very long advertised timeouts. | ||
Routers SHOULD be configured to advertise non-default Valid and | Confirmation of a global address entry with the Router 'R' flag | |
Preferred lifetimes in order to provide DNA hosts with link-specific | set in its neighbor cache[1]. | |
address lifetime information. | ||
Administrators are advised to set the advertised Preferred and Valid | 4.3.2 Link change | |
timers of prefixes to the maximum duration for which any host may be | ||
required to continue functioning without receiving a particular | ||
advertised prefix. | ||
Where hosts with ongoing transactions, or well known services (such | A host makes use of Router Discovery messages to determine that it | |
as DNS) are present on a network, this duration SHOULD be greater | has moved to a new link. Since the content of an existing received | |
than the maximum expected outage time (for example 9 hours for 0.999 | RA is not sufficient to identify the absence of any other prefix, | |
uptime, with a single outage/year). | additional inference is required for fast and accurate link-change | |
detection. | ||
Upon links where fixed hosts are unlikely to be present, | Complete Prefix Lists provide a robust mechanism for link-change | |
administrators SHOULD reduce the Router Lifetime, and Prefix Valid | detection with even unmodified non-DNA routers if link-layer | |
and Preferred Lifetimes on routers used to support DNA. | indications are available [24][18]. These procedures provide | |
mechanisms to build confidence that a host knows all of a link's | ||
prefixes and so may rapidly identify a newly received RA as being | ||
from a different link. | ||
One potential configuration heuristic would be to configure lifetimes | A host SHOULD maintain a complete prefix list as recommended by | |
to be a low number (for example: 15) of times the MaxRtrAdvInterval, | [24] to identify if the link has changed. | |
or greater than the lower quartile cell residence time of hosts on | ||
the network (if known). This allows reuse of configuration in the | ||
case where hosts are moving back and forth rapidly between links, but | ||
allows rapid timeouts of old configurations. | ||
The Router Lifetime MUST NOT be advertised as less than the | 4.4 Multicast Listener State | |
MaxRtrAdvInterval unless the router is not to be used as a default | ||
[1]. | ||
Routers MUST NOT be configured with Valid or Preferred lifetime | Multicast routers on a link are aware of which groups are in use | |
values lower than the MaxRtrAdvInterval. | within a link. This information is used to undertake initiation of | |
multicast routing for off-link multicast sources to the link [9] | ||
[11]. | ||
These minima ensure that lifetimes do not expire in between periodic | When a node arrives on a link, it may need to send Multicast Listener | |
Router Advertisements. | 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 | ||
change reports upon arrival on a link [11]. | ||
2.2.1 Recommendations | 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 [9] [11]. | ||
Routers SHOULD be configured to advertise non-default Valid and | For link scoped multicast, reporting needs to be done to ensure that | |
Preferred lifetimes in order to provide DNA hosts with link- | packet reception in the link is available due to multicast snoopers. | |
specific address lifetime information. | 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 7.4. | ||
Upon links where fixed hosts are unlikely to be present, | 4.5 Reachability detection | |
administrators SHOULD reduce the Router Lifetime, and Prefix Valid | ||
and Preferred Lifetimes on routers used to support DNA. | ||
The Router Lifetime MUST NOT be advertised as less than the | If an IP node needs to confirm bi-directional reachability to its | |
MaxRtrAdvInterval unless the router is not to be used as a default | 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 | ||
of whether the messages are addressed 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, using IPv6 Neighbour Discovery procedures, 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 | ||
[1]. | [1]. | |
Routers MUST NOT be configured with Valid or Preferred lifetime | +-----------------+----+----+----+-----+ | |
values lower than the MaxRtrAdvInterval. | | Exchanges: |Upstream |Downstream| | |
+-----------------+----+----+----+-----+ | ||
2.3 Router Advertisement Options | | multicast NS/NA | Y | Y | | |
+-----------------+----+----+----+-----+ | ||
When receiving a Router Advertisement from a particular router for | | unicast NS/NA | Y | Y | | |
the first time, a host needs to determine if the information | +-----------------+----+----+----+-----+ | |
contained in the RA indicates link change or that the transmitting | | RS/multicast RA | N | Y | | |
router is part of the same link as another router it has already | +-----------------+----+----+----+-----+ | |
seen. It is not possible to do this unless global prefix information | | RS/unicast RA | Y | Y | | |
is included in the advertisement. | +-----------------+----+----+----+-----+ | |
Routers SHOULD include at least one global Prefix Information Option | ||
in every Router Advertisement. | ||
Mobile IPv6 introduced a new option for Router Advertisements, which | ||
indicates the current MaxRtrAdvInterval of router [3]. Reception of | ||
this option allows hosts to estimate whether they have missed Router | ||
Advertisements, and allows them to check reachability or discover new | ||
routers. | ||
Routers SHOULD include Advertisement Interval options in Router | ||
Advertisements. | ||
Mobile IPv6 adds the Router Address 'R' Flag to Prefix Information | ||
options [3]. This flag, when set indicates that the router's entire | ||
global address is configured and sent in the prefix information | ||
option. Bits beyond those specified in the prefix length field | ||
identify the router's Interface Identifier [6]. | ||
Hosts which are detecting network attachment can use a global router | ||
address to uniquely identify the router and link, rather than using | ||
link-local source addresses, which may be present on multiple links. | ||
Routers SHOULD advertise at least one global address consistently in | ||
a Prefix Information Option, by setting the Router Address 'R' Flag. | ||
2.3.1 Recommendations | ||
Routers SHOULD include at least one global Prefix Information | Successful exchange of the messages listed in the table indicate the | |
Option in every Router Advertisement. | 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 an ordinary | ||
packet loss event in either direction. | ||
Routers SHOULD include Advertisement Interval options in Router | Link-change detection incorporates message reception which may itself | |
Advertisements. | create neighbour reachability state. When this is the case, a host | |
SHOULD rely upon existing Neighbor Discovery procedures in order to | ||
provide and maintain reachability detection [1]. | ||
Routers SHOULD advertise at least one global address consistently | 5. Initiation of DNA Procedures | |
in a Prefix Information Option, by setting the Router Address 'R' | ||
Flag. | ||
2.4 Triggered Router Advertisements | Link change detection procedures are initiated when information is | |
received either directly from the network or from other protocol | ||
layers within the host. This information indicates that network | ||
reachability or configuration is suspect and is called a hint. | ||
There are proposals for IPv6 Router Advertisements to be sent to | Hints MAY be used to update a wireless host's timers or probing | |
hosts based on network side link-layer information. | behavior in such a way as to assist detection of network attachment. | |
Hints SHOULD NOT be considered to be authoritative for detecting IP | ||
configuration change by themselves. | ||
Where these mechanisms exist they can provide Router Advertisements | In some cases, hints will carry significant information (for example | |
in the quickest possible time without need for Router Solicitation. | a hint indicating PPP IPv6CP open state [4]), although details of the | |
These systems rely upon link-layer facilities are not available in | configuration parameters may be available only after other IP | |
all environments. Therefore, interested readers are referred to the | configuration procedures. Implementers are encouraged to treat hints | |
individual methods' documentation [15]. | as though they may be incorrect, and require confirmation. | |
2.5 Split Advertisements | Hosts MUST ensure that untrusted hints do not cause unnecessary | |
configuration changes, or significant consumption of host resources | ||
or bandwidth. In order to achieve this aim, a host MAY implement | ||
hysteresis mechanisms such as token buckets, hint weighting or | ||
holddown timers in order to limit the effect of excessive hints (see | ||
Section 5.6). | ||
A router may choose to split the options in the RA and send multiple | 5.1 Actions Upon Hint Reception | |
RAs to reduce bandwidth overhead or to reduce the size of the RA to | ||
below the link MTU (section 6.2.3 of [1]). | ||
If such a choice is made, average multicast RA time discussed in | Upon reception of a hint that link change detection may have | |
Appendix C increases for each subset of the prefixes included in the | occurred, a host SHOULD send Router Solicitation messages to | |
split RA messages. | determine the routers and prefixes which exist on a link. Hosts | |
SHOULD apply rate limiting and/or hysteresis to this behaviour as | ||
appropriate to the link technology subject to the reliability of the | ||
hints. | ||
Routers SHOULD consistently include one prefix in both sets of its RA | Router Advertisements received as a result of such solicitation have | |
messages. This provide the host with a unique identifier based on | a role in determining if existing configuration is valid, and may be | |
the combination of link-local address and the constant prefix, to | used to construct prefix lists for a new link [24]. | |
identify the router every time a RA message is received. | ||
2.6 Router Configurations | 5.2 Hints Due to Network Layer Messages | |
Each router can have its own configuration with respect to sending | Hint reception may be due to network-layer messages such as | |
RAs, and the treatment of router and neighbour solicitations. | unexpected Router Advertisements, multicast listener queries or | |
Different timers and constants might be used by different routers, | ICMPv6 error messages [1][9][6]. In these cases, the authenticity of | |
such as the delay between Router Advertisements or delay before | the messages MUST be verified before expending resources to initiate | |
replying to a multicast RS. If a host is changing its IPv6 link, a | DNA procedure. | |
newly seen router on that link may have a different configuration and | ||
may introduce more delay than the previous default router of the | ||
host. | ||
While transitions between links under different administrative | When a host arrives on a new link, hints received due to external IP | |
control are considered to be common, it is RECOMMENDED that network | packets will typically be due to multicast messages. Actions based | |
deployers adopt uniform configuration practices across routers on | on multicast reception from untrusted sources are dangerous due to | |
different links within the same logical domain, in order to provide | the threat of multicast response flooding. This issue is discussed | |
consistent performance. | further in Section 8. | |
3. Topological Practices for DNAv6 Networks | State changes within the network-layer itself may initiate link- | |
change detection procedures. Existing subsystems for router and | ||
neighbor discovery, address leasing and multicast reception maintain | ||
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 | ||
initiate detection of network attachment. | ||
IPv6 does not prefer one particular network topology over another and | 5.3 Handling Hints from Other Layers | |
allows multiple routers and subnet prefixes to exist on one link. | ||
Different deployments of network elements and their configuration may | ||
impact on link change detection though. Effects and recommended | ||
practices for dealing with different network topologies are presented | ||
below. | ||
3.1 Link Extent and Composition | Events at other protocol layers may provide hints of link change to | |
network attachment detection systems. Two examples of such events | ||
are TCP retransmission timeout and completion of link-layer access | ||
procedures [18]. | ||
Most of today's access networks deploy link-layer bridging | While hints from other protocol layers originate from within the | |
technologies in order to extend their logical range beyond a single | host's own stack, the network layer SHOULD NOT treat hints from other | |
Medium Access Control domain. | protocol layers as authoritative indications of link change. | |
Consequently, while many routers will come with traditional wired or | This is because state changes within other protocol layers may be | |
optic-fibre interfaces, packets travelling within the same link may | triggered by untrusted messages, come from compromised sources (for | |
have been bridged across from a wired segment to a wireless segment. | example 802.11 WEP Encryption [21]) or be inaccurate with regard to | |
network-layer state. | ||
In many of cases, the router will not have accurate information about | While these hints come from the host's own stack, such hints may | |
the transmission rates or media of particular segments on the link. | actually be due to packet reception or non-reception events at the | |
Routers with interfaces whose technology is bridgeable SHOULD NOT | originating layers. As such, it may be possible for other devices to | |
assume that all segments and devices on the link have the same | instigate hint delivery on a host or multiple hosts deliberately, in | |
bandwidth available. | order to prompt packet transmission, or configuration modification. | |
3.2 Wireless cell coverage | Therefore, hosts SHOULD NOT change their configuration state based on | |
hints from other protocol layers. A host MAY adopt an appropriate | ||
link change detection strategy based upon hints received from other | ||
layers, with suitable caution and hysteresis, as described in | ||
Section 5.6. | ||
Where the topology of a set of access networks is known to have a | 5.4 Timer and Loss Based Hints | |
single cell per link or subnet, IPv6 hosts may immediately solicit | ||
for Router Advertisements upon notification of cell change. If link | ||
design is also constrained to a single router per cell, RA response | ||
delays may be reduced as described in Section 3.4. | ||
Where link design is not constrained, many cells may exist within the | Other hints may be received due to timer expiry, particularly In some | |
same link. | cases the expiry of these timers may be a good hint that DNA | |
procedures are necessary. | ||
The scalability of a subnet in terms of wireless cell coverage is | Since DNA is likely to be used when communicating with devices over | |
likely to be limited by broadcast/multicast traffic between hosts on | wireless links, suitable resilience to packet loss SHOULD be | |
the link. Where multicast packets may pass from one cell to another | incorporated into the DNA initiation system. Notably, non-reception | |
in the link (even if no multicast listeners for the group exist), | of data associated with end-to-end communication over the Internet | |
constrained wireless segments' performance may become degraded. | may be caused by reception errors at either end or because of network | |
congestion. Hosts SHOULD NOT act immediately on packet loss | ||
indications, delaying until it is clear that the packet losses aren't | ||
caused by transient events. | ||
In this case, it may be necessary to deploy multicast snooping or | Use of the Advertisement Interval Option specified in [5] follows | |
split the link into smaller broadcast domains [13]. | these principles. Routers sending this option indicate the maximum | |
interval between successive router advertisements. Hosts receiving | ||
this option monitor for multiple successive packet losses and | ||
initiate change discovery. | ||
3.3 Multiple Router Links | 5.5 Simultaneous Hints | |
IPv6 Neighbour Discovery allows multiple routers to be advertising on | Some events which generate hints may affect a number of devices | |
the same link [1]. These routers are not required to advertise the | simultaneously. | |
same prefixes as each other. This section provides some guidelines | ||
for deploying multiple routers on the same link. | ||
While many routers may exist on a link, it is preferable to limit the | For example, if a wireless base station goes down, all the hosts on | |
number of advertising routers. There SHOULD NOT be more than three | that base station are likely to initiate link-layer configuration | |
(3) routers advertising on a link. This will provide robustness in | strategies after losing track of the last beacon or pilot signal from | |
the case of RA packet loss, but provides a bound for bandwidth | the base station. | |
consumption. | ||
Multiple routers responding to Router Solicitation will reduce the | As described in [1][6], a host SHOULD delay randomly before acting on | |
mean delay for solicitation, at the cost of additional traffic. For | a widely receivable advertisement, in order to avoid response | |
unicast responses, the delays may be halved for three responding | implosion. | |
routers. | ||
+-----------------------+---------+----------+----------+ | Where a host considers it may be on a new link and learns this from a | |
|Num advertising routers| 1 | 2 | 3 | | hint generated by a multicast message, the host SHOULD defer 0-1000ms | |
+-----------------------+---------+----------+----------+ | in accordance with [1][3]. Please note though that a single | |
|Expected Unicast Delay | 0.250s | 0.167s | 0.125s | | desynchronization is required for any number of transmissions | |
+-----------------------+---------+----------+----------+ | subsequent to a hint, regardless of which messages need to be sent. | |
If using advertising intervals lower than those specified in IPv6 | In link-layers where sufficient serialization occurs after an event | |
Neighbour Discovery, only one router MAY advertise at the elevated | experienced by multiple hosts, each host MAY avoid the random delays | |
rate. Other routers beyond the first SHOULD NOT have | before sending solicitations specified in [1]. | |
MinDelayBetweenRAs, MinRtrAdvInterval or MaxRtrAdvInterval less than | ||
the minima specified in IPv6 Neighbour Discovery [1][3]. | ||
Where it is possible, routers SHOULD include at least one common | 5.6 Hint Validity and Hysteresis | |
prefix in all of their Router Advertisement messages. This allows | ||
hosts to immediately see that both routers are on the same link. | ||
3.4 Point-to-point Links | 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. | ||
IPv6 Router Discovery mandates the delay of RA responses by stating | Additionally, since packet reception at the network and other layers | |
(in section 6.2.6 of [1]): | 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. | ||
"In all cases, Router Advertisements sent in response to a | When experiencing a large number of hints, a host SHOULD employ | |
Router Solicitation MUST be delayed by a random time | hysteresis techniques to prevent excessive use of network resources. | |
between 0 and MAX_RA_DELAY_TIME seconds." | 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). | ||
Cases where the router is on a point-to-point link, this restriction | It is notable, that such hysteresis may cause sub-optimal change | |
is too stringent as the router in question will be the only router on | detection performance, and may themselves be used to block legitimate | |
the link. Routers on such point-to-point links MAY avoid the delay | hint reception. | |
by not waiting for the prescribed random time before responding for | ||
the Router Solicitation message [8] [14]. | ||
3.5 Disjoint Administration | 5.7 Hint Management for Inactive Hosts | |
It is possible that multiple sets of routers may be administered by | If a host does not expect to send or receive packets soon, it MAY | |
different organizations, both advertising on a link. | choose to defer detection of network attachment. This may preserve | |
resources on latent hosts, by removing any need for packet | ||
transmission when a hint is received. | ||
Routers administered by different organizations are likely to have | These hosts SHOULD delay 0-1000ms before sending a solicitation, and | |
different trust models, especially for routing and renumbering. This | MAY choose to wait up to twice the advertised Router Advertisement | |
may prevent alien routers from learning about changes in | Interval (plus the random delay) before sending a solicitation [5]. | |
configuration. Consequently, re-advertisements of learned prefixes | ||
in router advertisements may cause problems for hosts trying to | ||
detect link-change. It is important for deployers to remember that | ||
prefixes belonging to another organization, but valid within a link, | ||
SHOULD NOT be advertised if up-to-date prefix validity or lifetime | ||
data are not available. | ||
4. Security Considerations | 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 active data | ||
sessions. | ||
When operating a network in support of hosts performing link change | When a device begins sending packets, it will be necessary to test | |
detection, both the operational security of the hosts and network | bidirectional reachability with the router (whose current Neighbor | |
infrastructure are important. DNA procedures rely upon rapid | Cache state is STALE). As described in [1], the host will delay | |
delivery of information to hosts using IPv6 Neighbour Discovery. | before probing to allow for the probability that upper layer packet | |
Neighbour Discovery as a critical service in IPv6 networks is subject | reception confirms reachability. | |
to various attacks as described in [7]. | ||
The following sections describe issues and practices to provide | 6. IP Hosts Configuration | |
additional functional security for both operators and hosts. | ||
4.1 Supporting host security | 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. | ||
In DNA, some hosts will begin configuration procedures based on a | Invalidation of router and prefix list | |
single message transmitted by a router. As such the ability of | ||
routing infrastructure to prove its authenticity and authorization is | ||
important to support correct operation of hosts. As described in | ||
Section 4.2, authentication and authorization mechanisms exist which | ||
allow hosts to check security of routers when they receive Router | ||
Advertisements indicating link change. | ||
Today these mechanisms require additional message exchanges and | Invalidation of IPv6 addresses | |
public key operations to check the authorization chain back to a | ||
trusted root. Considering the computational cost for verifying | ||
certificates, it will useful for administrators to attempt to | ||
minimize the length of these authorization chains. | ||
Where a Router Advertisement is sent by a router, it SHOULD contain | Removing neighbor cache entries | |
sufficient information to prove that the router is on the same link | ||
as previously seen advertisers, or is indeed the same router. This | ||
may prevent expensive checks by hosts which will not need to | ||
immediately test the authenticity of the router through signature | ||
verification, or additional transmissions. | ||
As described in section Section 3.3, advertising common prefixes | Completion of DAD for Link-Local Addresses. | |
achieves this goal. | ||
4.2 Providing Router Authorization | Initiating mobility signaling | |
Hosts which wish to have secured exchanges with neighbours and on- | The following sub-sections elaborate on these steps. | |
link routers may use Secured Neighbour Discovery (SEND) [4]. SEND | ||
provides authenticity as well as response matching, using nonces | ||
copied from solicitations into advertisements. | ||
Responses which contain nonces may be matched to one or more | 6.1 Router and Prefix list | |
solicitations (dependent on the number of Nonce Options contained in | ||
the Advertisement), and may be used to provide authenticated | ||
bidirectional reachability confirmation even if received in a | ||
multicast advertisement. | ||
The router digitally signs its advertisements with a key-pair which | Router Discovery is designed to provide hosts with a set of locally | |
was also used to generate the router's transmitting address. This | configurable prefixes and default routers. These may then be | |
guarantees the origin, as well as the freshness of the Router | configured by hosts for access to the Internet [1]. | |
Advertisement transmission. | ||
DNA relies particularly heavily upon router discovery in order to | It allows hosts to discover routers and manage lists of eligible next | |
test the validity of routing and addressing configuration. In | hop gateways, and is based on IPv6 Neighbor Discovery. When one of | |
addition to reachability and configuration parameters, routing | the routers in the router list is determined to be no longer | |
authorization needs to be determined for each router. In SEND [4], | reachable, its destination cache entry is removed, and new router is | |
routing authorization is delegated by certificate authorities. | 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. | ||
SEND Router Advertisement packets contain the router's public key | On determining that link-change has occurred, the default router list | |
from a key pair used to sign the message. Certificate authorities | SHOULD have entries removed which are related to unreachable routers, | |
delegate a portion of their routing authority to the router, tying | and consequently these routers' destination cache entries SHOULD be | |
them to the public key of the router. Hosts need to test the | removed [1]. If no eligible default routers are in the default | |
router's authority to provide routing for the prefixes advertised in | router list, Router Solicitations MAY be sent, in order to discover | |
its RAs in order to ensure safe configuration. | new routers. | |
While it may be onerous to organize and manage key distribution and | 6.2 IPv6 Addresses | |
certificates for routing authorization, the security and robustness | ||
afforded by secured neighbour discovery provides a key advantage for | ||
IPv6 networks over what is available in IPv4. | ||
Routers supporting DNA SHOULD provide secured router discovery | 6.2.1 Autoconfiguration | |
services using SEND [4]. | ||
5. References | 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. | ||
5.1 Normative References | 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]. | ||
[1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery | For any configured address, Duplicate Address Detection (DAD) MUST be | |
for IP Version 6 (IPv6)", RFC 2461, December 1998. | 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. | ||
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement | As described in Section 4.2, messages used in DNA signaling should be | |
Levels", BCP 14, RFC 2119, March 1997. | 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]. | ||
[3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in | 6.2.2 Dynamic Host Configuration | |
IPv6", RFC 3775, June 2004. | ||
[4] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B., and P. Nikander, | Dynamic Host Configuration Procedures for IPv6 define their own | |
"SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-06 | detection procedures [13]. In order to check if the current set of | |
(work in progress), July 2004. | 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. | ||
5.2 Informative References | 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. | ||
[5] Thomson, S. and T. Narten, "IPv6 Stateless Address | Upon link change, any configuration learned from DHCP which is link | |
Autoconfiguration", RFC 2462, December 1998. | or administrative domain specific may have become invalid. | |
Subsequent operation of DHCP on the new link may therefore be | ||
necessary. | ||
[6] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) | 6.3 Neighbor cache | |
Addressing Architecture", RFC 3513, April 2003. | ||
[7] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor | Neighbor caches allow for delivery of packets to peers on the same | |
Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. | 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. | ||
[8] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, | In order to determine which link-layer address a peer is at, nodes | |
December 1998. | 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. | ||
[9] O'Hara, B. and G. Ennis, "Wireless LAN Medium Access Control | When link change occurs, the reachability of all existing neighbor | |
(MAC) and Physical Layer (PHY) Specifications", ANSI/IEEE | cache entries is likely to be invalidated, if link change prevents | |
Std 802.11, 1999. | 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]). | ||
[10] Yamamoto, S., "Detecting Network Attachment Terminology", | Reachability of a single node may support the likelihood of reaching | |
draft-yamamoto-dna-term-00 (work in progress), February 2004. | the rest of the link, for example if a particular access technology | |
relays such messages through wireless base stations. | ||
[11] Manner, J. and M. Kojo, "Mobility Related Terminology", | 6.4 Mobility Management | |
draft-ietf-seamoby-mobility-terminology-06 (work in progress), | ||
February 2004. | ||
[12] Moore, N., "Optimistic Duplicate Address Detection for IPv6", | Mobile IPv6 provides global mobility signaling for hosts wishing to | |
draft-ietf-ipv6-optimistic-dad-02 (work in progress), | preserve sessions when their configured address becomes topologically | |
September 2004. | 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. | ||
[13] Christensen, M., Kimball, K., and F. Solensky, "Considerations | The Mobile IPv6 RFC3775 [5] defines 'movement detection' procedures, | |
for IGMP and MLD Snooping Switches", draft-ietf-magma-snoop-12 | which themselves rely upon Neighbor Discovery, to initiate mobility | |
(work in progress), February 2005. | 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. | ||
[14] "3GPP TS 29.061 V5.5.0 (2003-03) Interworking between the | 7. Complications to Detecting Network Attachment | |
Public Land Mobile Network (PLMN) supporting packet based | ||
services and Packet Data Networks (PDN) (Release 5)", | ||
TS 29.061, March 2003. | ||
[15] Choi, J., "Fast Router Discovery with RA Caching", | Detection of network attachment procedures can be delayed or may be | |
draft-jinchoi-dna-frd-00 (work in progress), July 2004. | incorrect due to different factors. This section gives some examples | |
where complications may interfere with DNA processing. | ||
Authors' Addresses | 7.1 Packet Loss | |
Sathya Narayanan | Generally, packet loss introduces significant delays in validation of | |
Panasonic Digital Networking Lab | current configuration or discovery of new configuration. Because | |
Two Research Way, 3rd Floor | most of the protocols rely on timeout to consider that a peer is not | |
Princeton, NJ 08536 | reachable anymore, packet loss may lead to erroneous conclusions. | |
USA | ||
Phone: 609 734 7599 | Additionally, packet loss rates for particular transmission modes | |
Email: sathya@Research.Panasonic.COM | (multicast or unicast) may differ, meaning that particular classes of | |
URI: | DNA tests have higher chance of failure due to loss. Hosts SHOULD | |
attempt to verify tests through retransmission where packet loss is | ||
prevalent. | ||
Greg Daley | 7.2 Router Configurations | |
Centre for Telecommunications and Information Engineering | ||
Department of Electrical adn Computer Systems Engineering | ||
Monash University | ||
Clayton, Victoria 3800 | ||
Australia | ||
Phone: +61 3 9905 4655 | Each router can have its own configuration with respect to sending | |
Email: greg.daley@eng.monash.edu.au | RA, and the treatment of router and neighbor solicitations. | |
Nicolas Montavont | Different timers and constants might be used by different routers, | |
LSIIT - Univerity Louis Pasteur | such as the delay between Router Advertisements or delay before | |
Pole API, bureau C444 | replying to an RS. If a host is changing its IPv6 link, the new | |
Boulevard Sebastien Brant | router on that link may have a different configuration and may | |
Illkirch 67400 | introduce more delay than the previous default router of the host. | |
FRANCE | The time needed to discover the new link can then be longer than | |
expected by the host. | ||
Phone: (33) 3 90 24 45 87 | 7.3 Overlapping Coverage | |
Email: montavont@dpt-info.u-strasbg.fr | ||
URI: http://www-r2.u-strasbg.fr/~montavont/ | ||
Appendix A. Summary of Recommendations | If a host can be attached to different links at the same time with | |
the same interface, the host will probably listen to different | ||
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 | ||
access network to another. If the node can still be reachable | ||
through its old link while configuring the interface for its new | ||
link, packet loss can be minimized. | ||
It should be noted that many already deployed routers will not | Such a situation may happen in a wireless environment if the link | |
support these recommendations, and that hosts SHOULD NOT rely on | layer technology allows the MN to be simultaneously attached to | |
their being in place, unless they have particular reason to do so. | several points of attachment and if the coverage area of access | |
points are overlapping. | ||
Where many unicast responses are scheduled awaiting transmission, | For the purposes of DNA, it is necessary to treat each of these | |
Routers MAY consider aggregating them into a single multicast | points-of-attachment separately, otherwise incorrect conclusions of | |
response if a multicast advertisement may be sent before the | link-change may be made even if another of the link-layer connections | |
advertisements' scheduled transmission time. | is valid. | |
Where multiple unicast transmissions for the same destination await | 7.4 Multicast Snooping | |
transmission, routers MAY remove all transmissions after the first | ||
without ill-effect, if a multicast RA is scheduled for the next | ||
possible response time. | ||
Routers MAY choose to respond to RS messages with a unicast RA | When a host is participating in DNA on a link where multicast | |
response to avoid the delay introduced by the MIN_DELAY_BETWEEN_RAS | snooping is in use, multicast packets may not be delivered to the | |
restriction [1]. | LAN-segment to which the host is attached until MLD signaling has | |
been performed [9][11] [17]. Where DNA relies upon multicast packet | ||
delivery (for example, if a router needs to send a Neighbor | ||
Solicitation to the host), its function will be degraded until after | ||
an MLD report is sent. | ||
Routers SHOULD be configured to advertise non-default Valid and | Where it is possible that multicast snooping is in operation, hosts | |
Preferred lifetimes in order to provide DNA hosts with link-specific | MUST send MLD group joins (MLD reports) for solicited nodes' | |
address lifetime information. | addresses swiftly after starting DNA procedures. | |
Where hosts with ongoing transactions, or well known services are | 7.5 Link Partition | |
present on a network, this duration SHOULD be greater than the | ||
maximum expected outage time. | ||
Upon links where fixed hosts are unlikely to be present, | Link partitioning occurs when a link's internal switching or relaying | |
administrators SHOULD reduce the Router Lifetime, and Prefix Valid | hardware fails, or if the internal communications within a link are | |
and Preferred Lifetimes on routers used to support DNA. | prevented due to topology changes or wireless propagation. | |
The Router Lifetime MUST NOT be advertised as less than the | When a host is on a link which partitions, only a subset of the | |
MaxRtrAdvInterval unless the router is not to be used as a default | addresses or devices it is communicating with may still be available. | |
[1]. | 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. | ||
Routers MUST NOT be configured with Valid or Preferred lifetime | 8. Security Considerations | |
values lower than the MaxRtrAdvInterval. | ||
Routers SHOULD include at least one global Prefix Information Option | Detecting Network Attachment is a mechanism which allows network | |
in every Router Advertisement. | messages to change the node's belief about its IPv6 configuration | |
state. As such, it is important that the need for rapid testing of | ||
link change does not lead to situations where configuration is | ||
invalidated by malicious third parties, nor that information passed | ||
to configuration processes exposes the host to other attacks. | ||
Routers SHOULD include Advertisement Interval options in Router | Since DNA relies heavily upon IPv6 Neighbor Discovery,the threats | |
Advertisements. | which are applicable to those procedures also affect Detecting | |
Network Attachment. These threats are described in [12]. | ||
Routers SHOULD advertise at least one global address consistently in | Some additional threats are outlined below. | |
a Prefix Information Option, by setting the Router Address 'R' Flag. | ||
A router MAY choose to split the options in the RA and send multiple | 8.1 Authorization and Detecting Network Attachment | |
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]). | ||
While transitions between links under different administrative | Hosts connecting to the Internet over wireless media may be exposed | |
control are considered to be common, it is RECOMMENDED that network | to a variety of network configurations with differing robustness, | |
deployers adopt uniform configuration practices across routers on | controls and security. | |
different links within the same logical domain, in order to provide | ||
consistent performance. | ||
Routers with interfaces whose technology is bridgeable SHOULD NOT | When a host is determining if link change has occurred, it may | |
assume that all segments and devices on the link have the same | receive messages from devices with no advertised security mechanisms | |
bandwidth available. | purporting to be routers, nodes sending signed router advertisements | |
but with unknown delegation, or routers whose credentials need to be | ||
checked [12]. Where a host wishes to configure an unsecured router, | ||
it SHOULD confirm bidirectional reachability with the device, and it | ||
MUST mark the device as unsecured as described in [7]. | ||
There SHOULD NOT be more than three (3) routers advertising on a | In any case, a secured router SHOULD be preferred over an unsecured | |
link. | one, except where other factors (unreachability) make the router | |
unsuitable. Since secured routers' advertisement services may be | ||
subject to attack, alternative (secured) reachability mechanisms from | ||
upper layers, or secured reachability of other devices known to be on | ||
the same link may be used to check reachability in the first | ||
instance. | ||
If using advertising intervals lower than those specified in IPv6 | 8.2 Addressing | |
Neighbour Discovery, only one router MAY advertise at the elevated | ||
rate. Other routers beyond the first SHOULD NOT have | ||
MinDelayBetweenRAs, MinRtrAdvInterval or MaxRtrAdvInterval less than | ||
the minima specified in IPv6 Neighbour Discovery [1][3]. | ||
Where it is possible, routers SHOULD include at least one common | While a DNA host is checking for link-change, and observing DAD, it | |
prefix in all of their Router Advertisement messages. | may receive a DAD defense NA from an unsecured source. | |
Routers on point-to-point links MAY avoid delay by not waiting for | SEND says that DAD defenses MAY be accepted even from non SEND nodes | |
the prescribed random time before responding for the Router | for the first configured address [7]. | |
Solicitation message [8] [14]. | ||
Considering the computational cost for verifying certificates, | While this is a valid action in the case where a host collides with | |
administrators SHOULD attempt to minimize the length of authorization | another address owner after arrival on a new link, In the case that | |
chains. | the host returns immediately to the same link, such a DAD defense NA | |
message can only be a denial-of-service attempt. | ||
Where a Router Advertisement is sent by a router, it SHOULD contain | If a non-SEND node forges a DAD defense for an address which is still | |
sufficient information to prove that the router is on the same link | in peers' neighbor cache entries, a host may send a SEND protected | |
as previously seen advertisers, or is indeed the same router. | 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. | ||
Routers supporting DNA SHOULD provide secured router discovery | Therefore, a SEND host performing DNA which receives a DAD defense | |
services using SEND [4]. | 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. | ||
On access networks supporting Detecting Network Attachment, | 9. Constants | |
administrators SHOULD configure routers to advertise at the shortest | ||
safe intervals. | ||
Appendix B. Analysis of the response time | MAC_CACHE_TIME: 30 minutes | |
In IPv6 Neighbour Discovery, the delay induced by the | 10. Acknowledgments | |
MIN_DELAY_BETWEEN_RAS restriction is up to 3 seconds. This delay may | ||
not be very high if the minimum value (MinDelayBetweenRAs=0.03s) | ||
suggested in Mobile IPv6 is implemented [3]. | ||
The fraction of time which MinDelayBetweenRAs occupies in the Router | Thanks to JinHyeock Choi and Erik Nordmark for their significant | |
Advertisement interval determines the probability of scheduling | contributions. Bernard Aboba's work on DNA for IPv4 strongly | |
delay. | influenced this document. | |
Assuming that the arrival of RS messages is independent of each | 11. References | |
other, and that the arrival of any particular RS is equally likely | ||
across an interval, The probability of delay occurring to a | ||
particular RS is: | ||
P_mcdelay = MinDelayBetweenRAs | 11.1 Normative References | |
---------------------------- | ||
(MinRtrAdvInterval + MaxRtrAdvInterval)/2 | ||
Where the mean interval is defined as the mean delay before | [1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery | |
scheduling an unsolicited Router Advertisement. The probability of | for IP Version 6 (IPv6)", RFC 2461, December 1998. | |
delay with routers using the minimum values from IPv6 Neighbour | ||
Discovery is: 0.851 [1] | ||
Considering the above values, it is also necessary to remember that | [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement | |
all responses will be delayed by a random time between 0 and | Levels", BCP 14, RFC 2119, March 1997. | |
MAX_RA_DELAY_TIME (0.5 s) [1]. | ||
In this case, the expected delay E_mcrsra for a single arriving RS | [3] Thomson, S. and T. Narten, "IPv6 Stateless Address | |
is: | Autoconfiguration", RFC 2462, December 1998. | |
E_mcrsra = P_mcdelay * MinDelayBetweenRAs/2 + MAX_RA_DELAY_TIME/2 | [4] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, | |
December 1998. | ||
Again for RFC2461 minima, the expected delay is thus: 1.535 s. | [5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in | |
IPv6", RFC 3775, June 2004. | ||
The average unicast RA response time of course is 0.250 seconds. | [6] Conta, A. and S. Deering, "Internet Control Message Protocol | |
(ICMPv6) for the Internet Protocol Version 6 (IPv6) | ||
Specification", RFC2463 2463, December 1998. | ||
Assumptions underpinning this approximation hold only if the | [7] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure | |
likelihood of more than one RS arriving within a multicast delay | Neighbor Discovery (SEND)", RFC 3971, March 2005. | |
interval is very low. This depends on the arrival rate (lambda) of | ||
Router Solicitations, and is based on a Poisson distribution. | ||
The probability of more than one RS arriving in the interval t of | [8] Moore, N., "Optimistic Duplicate Address Detection for IPv6", | |
MinDelayBetweenRAs (defaulting to MIN_DELAY_BETWEEN_RAS) is: | draft-ietf-ipv6-optimistic-dad-02 (work in progress), | |
September 2004. | ||
P[X(t) > 1] = 1 - P[X(t) == 1] - P[X(t) == 0] | 11.2 Informative References | |
= 1 - (lambda*t)*exp(-lambda*t)/1! - exp(-lambda*t)/0! | [9] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener | |
Discovery (MLD) for IPv6", RFC 2710, October 1999. | ||
= 1 - ( 1 + lambda*t)* exp (-lambda*t) | [10] Haberman, B., "Source Address Selection for the Multicast | |
Listener Discovery (MLD) Protocol", RFC 3590, September 2003. | ||
For a given load (lambda)=0.05 RS/sec, the probability of multiple RS | [11] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 | |
arrival is 1.01%. | (MLDv2) for IPv6", RFC 3810, June 2004. | |
Adopting the MinDelayBetweenRAs = 0.03s and MaxRtrAdvinterval= 4s the | [12] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor | |
probability of arrival in the MinDelayBetweenRAs interval is 0.0148. | Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. | |
The estimated expected delay for multicast RS/RA exchange is | ||
therefore 0.25022 seconds. | ||
This is comparable to the unicast response delay. | [13] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. | |
Carney, "Dynamic Host Configuration Protocol for IPv6 | ||
(DHCPv6)", RFC 3315, July 2003. | ||
In this case, the chance of additional solicitation arrival during | [14] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) | |
MinDelayBetweenRAs is very low (around 1 in 10^6 for t=0.03, | Addressing Architecture", RFC 3513, April 2003. | |
lambda=0.05). | ||
Please note that if the MaxRtrAdvInterval is also low (making the | [15] Choi, J., "Detecting Network Attachment in IPv6 Goals", | |
mean interval duration low), the solicitor is likely to get get an | draft-ietf-dna-goals-04 (work in progress), December 2004. | |
unsolicited RA due to early scheduling of the RA during the RS/RA | ||
delay period (see Appendix C). | ||
As described in [3], some systems may not provide tunable | [16] Fikouras, N A., K"onsgen, A J., and C. G"org, "Accelerating | |
MinDelayBetweenRAs except that it assumes the value of the minimum | Mobile IP Hand-offs through Link-layer Information", | |
time difference between unsolicited RAs (MinRtrAdvInterval) when | Proceedings of the International Multiconference on | |
MinRtrAdvInterval is less than 3 seconds. Reducing MinRtrAdvInterval | Measurement, Modelling, and Evaluation of Computer- | |
to will increase the rate of RA transmission, but this doesn't need | Communication Systems (MMB) 2001, September 2001. | |
to be a dramatic increase. For example, even if the lowest value for | ||
MinRtrAdvInterval is selected (0.03 s), if the MaxRtrAdvInterval is | ||
kept at its RFC2461 minimum (4 seconds) the mean interval between RAs | ||
is over 2 seconds. This compares with a mean interval of 3.5 seconds | ||
for advertisement only using the RFC2461 minima. | ||
Where the MinDelayBetweenRAs is correspondingly lowered to the | [17] Christensen, M., Kimball, K., and F. Solensky, "Considerations | |
minimum values, the rate of solicited multicast RAs may be elevated | for IGMP and MLD Snooping Switches", draft-ietf-magma-snoop-12 | |
to around 33 per second. This raises the potential for abuse by | (work in progress), February 2005. | |
attackers which can force uniform resource consumption across all | ||
cells in a link. | ||
It is possible to choose delay values which provide significantly | [18] Yegin, A., "Link-layer Event Notifications for Detecting | |
improved expected and worst case delays over RFC 2461 values, and | Network Attachments", draft-ietf-dna-link-information-00 (work | |
have well defined upper bound traffic costs for constrained links. | in progress), September 2004. | |
For example, if a link is able to sustain a maximum of two multicast | [19] Koodli, R., "Fast Handovers for Mobile IPv6", | |
RAs per second, a safe value for MinRtrAdvInterval and consequently | draft-ietf-mipshop-fast-mipv6-03 (work in progress), | |
MinDelayBetweenRAs is t=0.5s. With similar load values to those | October 2004. | |
presented above, the probability of arrival within the interval | ||
P_mcdelay = 0.222, with an expected RS/RA delay of E_mcrsra = 0.305s. | ||
As mentioned above the probability of multiple RS arrival in the | [20] Liebsch, M., "Candidate Access Router Discovery", | |
interval would be 3.07 * 10^-4 with a load (lambda)=0.05. | draft-ietf-seamoby-card-protocol-08 (work in progress), | |
September 2004. | ||
This MinDelayBetweenRAs allows fairly good multicast response | [21] O'Hara, B. and G. Ennis, "Wireless LAN Medium Access Control | |
performance but bounds the number of multicast RAs to two per second. | (MAC) and Physical Layer (PHY) Specifications", ANSI/IEEE | |
Regardless of load, the worst case delay for RA response in this case | Std 802.11, 1999. | |
is no greater than 2*MIN_DELAY_BETWEEN_RAs (1 second). | ||
Appendix C. Router Advertisement Rates | [22] Yamamoto, S., "Detecting Network Attachment Terminology", | |
draft-yamamoto-dna-term-00 (work in progress), February 2004. | ||
Unsolicited Router Advertisements are scheduled to be transmitted at | [23] Manner, J. and M. Kojo, "Mobility Related Terminology", | |
a time between MinRtrAdvInterval and MaxRtrAdvInterval after the last | draft-ietf-seamoby-mobility-terminology-06 (work in progress), | |
multicast Router Advertisement. These parameters may be configured | February 2004. | |
in the way which best suits the network. The table below summarizes | ||
the parameters as described by IPv6 Neighbour Discovery [1]. | ||
+-----------------------+----+----+----+-----+----+-----+ | [24] Choi, J. and E. Nordmark, "DNA with unmodified routers: Prefix | |
| Timer |Maximum |Default |Minimum | | list based approach", draft-j-dna-cpl-00 (work in progress), | |
+-----------------------+----+----+----+-----+----+-----+ | October 2005. | |
| MaxRtrAdvInterval | 1800 | 600 | 4 | | ||
+-----------------------+----+----+----+-----+----+-----+ | ||
| MinRtrAdvInterval | 594 | 198 | 3 | | ||
+-----------------------+----+----+----+-----+----+-----+ | ||
|Avg. Multicast RA time | 1197 | 399 | 3.5 | | ||
+-----------------------+----+----+----+-----+----+-----+ | ||
The load on the network, and the timeliness of any received | Authors' Addresses | |
information updates are therefore influenced by the router's | ||
advertisement parameters. | ||
On access networks supporting Detecting Network Attachment, | Sathya Narayanan | |
administrators SHOULD configure routers to advertise at the shortest | Panasonic Digital Networking Lab | |
safe intervals. Determination of the shortest safe intervals depends | Two Research Way, 3rd Floor | |
on topology, and the composition of the link, as described in | Princeton, NJ 08536 | |
Section 3.1. | USA | |
Mobile IPv6 attempts to address the delays associated with hosts' | Phone: 609 734 7599 | |
movement and change detection by reducing the minimum settings for | Email: sathya@Research.Panasonic.COM | |
MinRtrAdvInterval to 30ms and MaxRtrAdvInterval to 70ms. Not all | URI: | |
IPv6 routers support these configuration values today. Where hosts | ||
have no reactive way of detecting change, and do not solicit for | ||
Router Advertisements, these intervals may allow change detection | ||
sufficiently fast to support real-time applications. | ||
The effect of these timers are summarized in the table below. | Greg Daley | |
Centre for Telecommunications and Information Engineering | ||
Department of Electrical adn Computer Systems Engineering | ||
Monash University | ||
Clayton, Victoria 3800 | ||
Australia | ||
+-----------------------+----+----+----+-----+----+-----+ | Phone: +61 3 9905 4655 | |
| Timer |Maximum |Default |Minimum | | Email: greg.daley@eng.monash.edu.au | |
+-----------------------+----+----+----+-----+----+-----+ | Nicolas Montavont | |
| MaxRtrAdvInterval | 1800 | 600 | 0.07 | | LSIIT - Univerity Louis Pasteur | |
+-----------------------+----+----+----+-----+----+-----+ | Pole API, bureau C444 | |
| MinRtrAdvInterval | 594 | 198 | 0.03 | | Boulevard Sebastien Brant | |
+-----------------------+----+----+----+-----+----+-----+ | Illkirch 67400 | |
|Avg. Multicast RA time | 1197 | 399 | 0.05 | | FRANCE | |
+-----------------------+----+----+----+-----+----+-----+ | ||
Where Mobile IPv6 is supported, the minimum values change, but the | Phone: (33) 3 90 24 45 87 | |
default timers are unmodified. If administrators wish to take | Email: montavont@dpt-info.u-strasbg.fr | |
advantage of shorter intervals between unsolicited RAs, explicit | URI: http://www-r2.u-strasbg.fr/~montavont/ | |
configuration is required. This is because the elevated rate of | ||
multicast RA transmission can have detrimental effects on some | ||
constrained links [3]. | ||
The minimum average for un-solicited Router Advertisements would be | Appendix A. Example State Transition Diagram | |
20 messages per second. Assuming the minimum packet size for an RA | ||
with one prefix as 88 bytes, the bandwidth used will be 14 kbps. | ||
With SEND Options, and (somewhat weak) 1024-bit RSA keys, a single RA | ||
could be around 432 octets. This would consume approximately 69 kbps | ||
without considering link-layer overheads [4]. | ||
As described in Section 2.1, parameters may be chosen to optimize | Below is an example state diagram which indicates relationships | |
solicited behaviour in a way which limits the mean bandwidth overhead | between the practices in this document. | |
for unsolicited RAs. | ||
A good example would be setting a MinRtrAdvInterval (along with | +---------+ +----------+ | |
MinDelayBetweenRAs) as 0.5 s, and the MaxRtrAdvInterval to 4s. This | | Test |< - - - - -| Init |===> | |
makes the mean delay before receiving an unsolicited RA 2.25 seconds, | |Reachable|<-\ | Config |\ | |
and limits the bandwidth utilization for unsolicited RAs (using the | +---------+ +----------+ \ | |
SEND example above) to 1.5 kbps, and the maximum multicast solicited | | \ New ^ \ | |
rate to 6.9 kbps (one multicast RA each 0.5s). | | 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 | |
End of changes. | ||
This html diff was produced by rfcdiff v1.01, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |