draft-ietf-dna-routers-00.txt | draft-ietf-dna-routers-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: April 26, 2006 G. Daley | |
Monash University CTIE | Monash University CTIE | |
N. Montavont | N. Montavont | |
LSIIT - ULP | LSIIT - ULP | |
June 23, 2005 | Oct 23, 2005 | |
Detecting Network Attachment in IPv6 - Best Current Practices for | Detecting Network Attachment in IPv6 - Best Current Practices for | |
Routers | Routers | |
draft-ietf-dna-routers-00.txt | draft-ietf-dna-routers-01.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 38: | ||
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 26, 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 to do | Hosts experiencing rapid link-layer changes may require to do | |
configuration change detection procedures more frequently than | configuration change detection procedures more frequently than | |
traditional fixed hosts. This document describes practices available | traditional fixed hosts. This document describes practices available | |
Skipping to change at page 2, line 27: | ||
2.2 Router Advertisement Parameters . . . . . . . . . . . . . 7 | 2.2 Router Advertisement Parameters . . . . . . . . . . . . . 7 | |
2.2.1 Recommendations . . . . . . . . . . . . . . . . . . . 8 | 2.2.1 Recommendations . . . . . . . . . . . . . . . . . . . 8 | |
2.3 Router Advertisement Options . . . . . . . . . . . . . . . 8 | 2.3 Router Advertisement Options . . . . . . . . . . . . . . . 8 | |
2.3.1 Recommendations . . . . . . . . . . . . . . . . . . . 9 | 2.3.1 Recommendations . . . . . . . . . . . . . . . . . . . 9 | |
2.4 Triggered Router Advertisements . . . . . . . . . . . . . 9 | 2.4 Triggered Router Advertisements . . . . . . . . . . . . . 9 | |
2.5 Split Advertisements . . . . . . . . . . . . . . . . . . . 9 | 2.5 Split Advertisements . . . . . . . . . . . . . . . . . . . 9 | |
2.6 Router Configurations . . . . . . . . . . . . . . . . . . 10 | 2.6 Router Configurations . . . . . . . . . . . . . . . . . . 10 | |
3. Topological Practices for DNAv6 Networks . . . . . . . . . . . 10 | 3. Topological Practices for DNAv6 Networks . . . . . . . . . . . 10 | |
3.1 Link Extent and Composition . . . . . . . . . . . . . . . 10 | 3.1 Link Extent and Composition . . . . . . . . . . . . . . . 10 | |
3.2 Wireless cell coverage . . . . . . . . . . . . . . . . . . 10 | 3.2 Multiple Router Links . . . . . . . . . . . . . . . . . . 10 | |
3.3 Multiple Router Links . . . . . . . . . . . . . . . . . . 11 | 3.3 Point-to-point Links . . . . . . . . . . . . . . . . . . . 11 | |
3.4 Point-to-point Links . . . . . . . . . . . . . . . . . . . 12 | ||
3.5 Disjoint Administration . . . . . . . . . . . . . . . . . 12 | ||
4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | ||
4.1 Supporting host security . . . . . . . . . . . . . . . . . 12 | ||
4.2 Providing Router Authorization . . . . . . . . . . . . . . 13 | ||
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 | 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | |
5.1 Normative References . . . . . . . . . . . . . . . . . . . 14 | 4.1 Providing Router Authorization . . . . . . . . . . . . . . 12 | |
5.2 Informative References . . . . . . . . . . . . . . . . . . 14 | ||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 | 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |
5.1 Normative References . . . . . . . . . . . . . . . . . . . 12 | ||
5.2 Informative References . . . . . . . . . . . . . . . . . . 13 | ||
A. Summary of Recommendations . . . . . . . . . . . . . . . . . . 16 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 | |
B. Analysis of the response time . . . . . . . . . . . . . . . . 18 | A. Summary of Recommendations . . . . . . . . . . . . . . . . . . 14 | |
C. Router Advertisement Rates . . . . . . . . . . . . . . . . . . 20 | B. Router Advertisement Rates . . . . . . . . . . . . . . . . . . 16 | |
Intellectual Property and Copyright Statements . . . . . . . . 22 | Intellectual Property and Copyright Statements . . . . . . . . 19 | |
1. Introduction | 1. Introduction | |
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. The frequency of configuration change for wireless and | mobile. The frequency of configuration change for wireless and | |
nomadic devices are elevated, due to the vagaries of wireless | nomadic devices are elevated, due to the vagaries of wireless | |
propagation or the motion of the hosts themselves. | propagation or the motion of the hosts themselves. | |
Such hosts need to determine if they have moved to a new IPv6 link | Such hosts need to determine if they have moved to a new IPv6 link | |
Skipping to change at page 6, line 18: | ||
least one of its RS messages was received and processed by the | least one of its RS messages was received and processed by the | |
router. Since unicast RAs are only sent in response to solicitation, | router. Since unicast RAs are only sent in response to solicitation, | |
a host can infer that at least one of its Router Solicitations | a host can infer that at least one of its Router Solicitations | |
reached the router. | reached the router. | |
The dis-advantage in sending unicast RA is that the router will not | The dis-advantage in sending unicast RA is that the router will not | |
be able to aggregate its response for multiple RS messages from | be able to aggregate its response for multiple RS messages from | |
multiple hosts received during the waiting period before RA | multiple hosts received during the waiting period before RA | |
transmission. | transmission. | |
For multicast Router Advertisements, a minimum separating delay | ||
exists so that these RAs may not be scheduled close to each other. | ||
When a host solicits and attempts to schedule a multicast RA within | ||
MIN_DELAY_BETWEEN_RAS (or MinDelayBetweenRAs from Mobile IPv6 [3]) of | ||
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 | ||
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]. | ||
Where many unicast responses are scheduled awaiting transmission, | Where many unicast responses are scheduled awaiting transmission, | |
Routers MAY consider aggregating them into a single multicast | Routers MAY consider aggregating them into a single multicast | |
response if a multicast advertisement may be sent before the | response if a multicast advertisement may be sent before the | |
advertisements' scheduled transmission time. | advertisements' scheduled transmission time. | |
It is noted that computational requirements for SEND may preclude | It is noted that computational requirements for SEND may preclude | |
this subsequent aggregation in some environments. | this subsequent aggregation in some environments. | |
Where multiple unicast transmissions for the same destination await | Where multiple unicast transmissions for the same destination await | |
transmission, routers MAY remove all transmissions after the first | transmission, routers MAY remove all transmissions after the first | |
without ill-effect, if a multicast RA is scheduled for the next | without ill-effect, if a multicast RA is scheduled for the next | |
possible response time. | possible response time. | |
For multicast Router Advertisements, a minimum separating delay | ||
exists so that these RAs may not be scheduled close to each other. | ||
When a host solicits and attempts to schedule a multicast RA within | ||
MIN_DELAY_BETWEEN_RAS (or MinDelayBetweenRAs from Mobile IPv6 [3]) of | ||
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 | ||
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 | In some cases it is not possible to provide unicast responses, since | |
solicitations may be sent with an unspecified address, or | solicitations may be sent with an unspecified address, or | |
solicitations do not provide enough link-layer addressing information | solicitations do not provide enough link-layer addressing information | |
to send an unicast response without neighbour discovery exchange. In | to send an unicast response without neighbour discovery exchange. In | |
these cases, a router may need to send multicast responses, even if | these cases, a router may need to send multicast responses, even if | |
the expected delay is greater. | the expected delay is greater. | |
2.1.1 Recommendations | 2.1.1 Recommendations | |
Routers SHOULD respond to a RS message with unicast RS message. | Routers SHOULD respond to a RS message with unicast RS message. | |
Skipping to change at page 8, line 6: | ||
or greater than the lower quartile cell residence time of hosts on | or greater than the lower quartile cell residence time of hosts on | |
the network (if known). This allows reuse of configuration in the | the network (if known). This allows reuse of configuration in the | |
case where hosts are moving back and forth rapidly between links, but | case where hosts are moving back and forth rapidly between links, but | |
allows rapid timeouts of old configurations. | allows rapid timeouts of old configurations. | |
The Router Lifetime MUST NOT be advertised as less than the | The Router Lifetime MUST NOT be advertised as less than the | |
MaxRtrAdvInterval unless the router is not to be used as a default | MaxRtrAdvInterval unless the router is not to be used as a default | |
[1]. | [1]. | |
Routers MUST NOT be configured with Valid or Preferred lifetime | Routers MUST NOT be configured with Valid or Preferred lifetime | |
values lower than the MaxRtrAdvInterval. | values lower than the MaxRtrAdvInterval. These minima ensure that | |
lifetimes do not expire in between periodic Router Advertisements. | ||
These minima ensure that lifetimes do not expire in between periodic | ||
Router Advertisements. | ||
2.2.1 Recommendations | 2.2.1 Recommendations | |
Routers SHOULD be configured to advertise non-default Valid and | Routers SHOULD be configured to advertise non-default Valid and | |
Preferred lifetimes in order to provide DNA hosts with link- | Preferred lifetimes in order to provide DNA hosts with link- | |
specific address lifetime information. | specific address lifetime information. | |
Upon links where fixed hosts are unlikely to be present, | Upon links where fixed hosts are unlikely to be present, | |
administrators SHOULD reduce the Router Lifetime, and Prefix Valid | administrators SHOULD reduce the Router Lifetime, and Prefix Valid | |
and Preferred Lifetimes on routers used to support DNA. | and Preferred Lifetimes on routers used to support DNA. | |
Skipping to change at page 9, line 44: | ||
all environments. Therefore, interested readers are referred to the | all environments. Therefore, interested readers are referred to the | |
individual methods' documentation [15]. | individual methods' documentation [15]. | |
2.5 Split Advertisements | 2.5 Split Advertisements | |
A router may choose to split the options in the RA and send multiple | A router may choose to split the options in the RA and send multiple | |
RAs to reduce bandwidth overhead or to reduce the size of the RA to | RAs to reduce bandwidth overhead or to reduce the size of the RA to | |
below the link MTU (section 6.2.3 of [1]). | below the link MTU (section 6.2.3 of [1]). | |
If such a choice is made, average multicast RA time discussed in | If such a choice is made, average multicast RA time discussed in | |
Appendix C increases for each subset of the prefixes included in the | Appendix B increases for each subset of the prefixes included in the | |
split RA messages. | split RA messages. | |
Routers SHOULD consistently include one prefix in both sets of its RA | Routers SHOULD consistently include one prefix in both sets of its RA | |
messages. This provide the host with a unique identifier based on | messages. This provide the host with a unique identifier based on | |
the combination of link-local address and the constant prefix, to | the combination of link-local address and the constant prefix, to | |
identify the router every time a RA message is received. | identify the router every time a RA message is received. | |
2.6 Router Configurations | 2.6 Router Configurations | |
Each router can have its own configuration with respect to sending | Each router can have its own configuration with respect to sending | |
Skipping to change at page 10, line 47: | ||
Consequently, while many routers will come with traditional wired or | Consequently, while many routers will come with traditional wired or | |
optic-fibre interfaces, packets travelling within the same link may | optic-fibre interfaces, packets travelling within the same link may | |
have been bridged across from a wired segment to a wireless segment. | have been bridged across from a wired segment to a wireless segment. | |
In many of cases, the router will not have accurate information about | In many of cases, the router will not have accurate information about | |
the transmission rates or media of particular segments on the link. | the transmission rates or media of particular segments on the link. | |
Routers with interfaces whose technology is bridgeable SHOULD NOT | Routers with interfaces whose technology is bridgeable SHOULD NOT | |
assume that all segments and devices on the link have the same | assume that all segments and devices on the link have the same | |
bandwidth available. | bandwidth available. | |
3.2 Wireless cell coverage | 3.2 Multiple Router Links | |
Where the topology of a set of access networks is known to have a | ||
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 | ||
same link. | ||
The scalability of a subnet in terms of wireless cell coverage is | ||
likely to be limited by broadcast/multicast traffic between hosts on | ||
the link. Where multicast packets may pass from one cell to another | ||
in the link (even if no multicast listeners for the group exist), | ||
constrained wireless segments' performance may become degraded. | ||
In this case, it may be necessary to deploy multicast snooping or | ||
split the link into smaller broadcast domains [13]. | ||
3.3 Multiple Router Links | ||
IPv6 Neighbour Discovery allows multiple routers to be advertising on | IPv6 Neighbour Discovery allows multiple routers to be advertising on | |
the same link [1]. These routers are not required to advertise the | the same link [1]. These routers are not required to advertise the | |
same prefixes as each other. This section provides some guidelines | same prefixes as each other. This section provides some guidelines | |
for deploying multiple routers on the same link. | for deploying multiple routers on the same link. | |
While many routers may exist on a link, it is preferable to limit the | While many routers may exist on a link, it is preferable to limit the | |
number of advertising routers. There SHOULD NOT be more than three | number of advertising routers. There SHOULD NOT be more than three | |
(3) routers advertising on a link. This will provide robustness in | (3) routers advertising on a link. This will provide robustness in | |
the case of RA packet loss, but provides a bound for bandwidth | the case of RA packet loss, but provides a bound for bandwidth | |
Skipping to change at page 12, line 5: | ||
If using advertising intervals lower than those specified in IPv6 | If using advertising intervals lower than those specified in IPv6 | |
Neighbour Discovery, only one router MAY advertise at the elevated | Neighbour Discovery, only one router MAY advertise at the elevated | |
rate. Other routers beyond the first SHOULD NOT have | rate. Other routers beyond the first SHOULD NOT have | |
MinDelayBetweenRAs, MinRtrAdvInterval or MaxRtrAdvInterval less than | MinDelayBetweenRAs, MinRtrAdvInterval or MaxRtrAdvInterval less than | |
the minima specified in IPv6 Neighbour Discovery [1][3]. | the minima specified in IPv6 Neighbour Discovery [1][3]. | |
Where it is possible, routers SHOULD include at least one common | Where it is possible, routers SHOULD include at least one common | |
prefix in all of their Router Advertisement messages. This allows | prefix in all of their Router Advertisement messages. This allows | |
hosts to immediately see that both routers are on the same link. | hosts to immediately see that both routers are on the same link. | |
3.4 Point-to-point Links | 3.3 Point-to-point Links | |
IPv6 Router Discovery mandates the delay of RA responses by stating | IPv6 Router Discovery mandates the delay of RA responses by stating | |
(in section 6.2.6 of [1]): | (in section 6.2.6 of [1]): | |
"In all cases, Router Advertisements sent in response to a | "In all cases, Router Advertisements sent in response to a | |
Router Solicitation MUST be delayed by a random time | Router Solicitation MUST be delayed by a random time | |
between 0 and MAX_RA_DELAY_TIME seconds." | between 0 and MAX_RA_DELAY_TIME seconds." | |
Cases where the router is on a point-to-point link, this restriction | Cases where the router is on a point-to-point link, this restriction | |
is too stringent as the router in question will be the only router on | is too stringent as the router in question will be the only router on | |
the link. Routers on such point-to-point links MAY avoid the delay | the link. Routers on such point-to-point links MAY avoid the delay | |
by not waiting for the prescribed random time before responding for | by not waiting for the prescribed random time before responding for | |
the Router Solicitation message [8] [14]. | the Router Solicitation message [8] [14]. | |
3.5 Disjoint Administration | ||
It is possible that multiple sets of routers may be administered by | ||
different organizations, both advertising on a link. | ||
Routers administered by different organizations are likely to have | ||
different trust models, especially for routing and renumbering. This | ||
may prevent alien routers from learning about changes in | ||
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 | 4. Security Considerations | |
When operating a network in support of hosts performing link change | When operating a network in support of hosts performing link change | |
detection, both the operational security of the hosts and network | detection, both the operational security of the hosts and network | |
infrastructure are important. DNA procedures rely upon rapid | infrastructure are important. DNA procedures rely upon rapid | |
delivery of information to hosts using IPv6 Neighbour Discovery. | delivery of information to hosts using IPv6 Neighbour Discovery. | |
Neighbour Discovery as a critical service in IPv6 networks is subject | Neighbour Discovery as a critical service in IPv6 networks is subject | |
to various attacks as described in [7]. | to various attacks as described in [7]. | |
The following sections describe issues and practices to provide | The following sections describe issues and practices to provide | |
additional functional security for both operators and hosts. | additional functional security for both operators and hosts. | |
4.1 Supporting host security | 4.1 Providing Router Authorization | |
In DNA, some hosts will begin configuration procedures based on a | In DNA, some hosts will begin configuration procedures based on a | |
single message transmitted by a router. As such the ability of | single message transmitted by a router. As such the ability of | |
routing infrastructure to prove its authenticity and authorization is | routing infrastructure to prove its authenticity and authorization is | |
important to support correct operation of hosts. As described in | important to support correct operation of hosts. Authentication and | |
Section 4.2, authentication and authorization mechanisms exist which | authorization mechanisms exist which allow hosts to check security of | |
allow hosts to check security of routers when they receive Router | routers when they receive Router Advertisements indicating link | |
Advertisements indicating link change. | change. | |
Today these mechanisms require additional message exchanges and | Today these mechanisms require additional message exchanges and | |
public key operations to check the authorization chain back to a | public key operations to check the authorization chain back to a | |
trusted root. Considering the computational cost for verifying | trusted root. Considering the computational cost for verifying | |
certificates, it will useful for administrators to attempt to | certificates, it will useful for administrators to attempt to | |
minimize the length of these authorization chains. | minimize the length of these authorization chains. | |
Where a Router Advertisement is sent by a router, it SHOULD contain | Where a Router Advertisement is sent by a router, it SHOULD contain | |
sufficient information to prove that the router is on the same link | sufficient information to prove that the router is on the same link | |
as previously seen advertisers, or is indeed the same router. This | as previously seen advertisers, or is indeed the same router. This | |
may prevent expensive checks by hosts which will not need to | may prevent expensive checks by hosts which will not need to | |
immediately test the authenticity of the router through signature | immediately test the authenticity of the router through signature | |
verification, or additional transmissions. | verification, or additional transmissions. | |
As described in section Section 3.3, advertising common prefixes | As described in section Section 3.2, advertising common prefixes | |
achieves this goal. | achieves this goal. | |
4.2 Providing Router Authorization | ||
Hosts which wish to have secured exchanges with neighbours and on- | Hosts which wish to have secured exchanges with neighbours and on- | |
link routers may use Secured Neighbour Discovery (SEND) [4]. SEND | link routers may use Secured Neighbour Discovery (SEND) [4]. SEND | |
provides authenticity as well as response matching, using nonces | provides authenticity as well as response matching, using nonces | |
copied from solicitations into advertisements. | copied from solicitations into advertisements. | |
Responses which contain nonces may be matched to one or more | ||
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 | ||
was also used to generate the router's transmitting address. This | ||
guarantees the origin, as well as the freshness of the Router | ||
Advertisement transmission. | ||
DNA relies particularly heavily upon router discovery in order to | ||
test the validity of routing and addressing configuration. In | ||
addition to reachability and configuration parameters, routing | ||
authorization needs to be determined for each router. In SEND [4], | ||
routing authorization is delegated by certificate authorities. | ||
SEND Router Advertisement packets contain the router's public key | ||
from a key pair used to sign the message. Certificate authorities | ||
delegate a portion of their routing authority to the router, tying | ||
them to the public key of the router. Hosts need to test the | ||
router's authority to provide routing for the prefixes advertised in | ||
its RAs in order to ensure safe configuration. | ||
While it may be onerous to organize and manage key distribution and | ||
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 | Routers supporting DNA SHOULD provide secured router discovery | |
services using SEND [4]. | services using SEND [4]. | |
5. References | 5. References | |
5.1 Normative References | 5.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. | |
Skipping to change at page 18, line 12: | ||
sufficient information to prove that the router is on the same link | sufficient information to prove that the router is on the same link | |
as previously seen advertisers, or is indeed the same router. | as previously seen advertisers, or is indeed the same router. | |
Routers supporting DNA SHOULD provide secured router discovery | Routers supporting DNA SHOULD provide secured router discovery | |
services using SEND [4]. | services using SEND [4]. | |
On access networks supporting Detecting Network Attachment, | On access networks supporting Detecting Network Attachment, | |
administrators SHOULD configure routers to advertise at the shortest | administrators SHOULD configure routers to advertise at the shortest | |
safe intervals. | safe intervals. | |
Appendix B. Analysis of the response time | Appendix B. Router Advertisement Rates | |
In IPv6 Neighbour Discovery, the delay induced by the | ||
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 | ||
Advertisement interval determines the probability of scheduling | ||
delay. | ||
Assuming that the arrival of RS messages is independent of each | ||
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 | ||
---------------------------- | ||
(MinRtrAdvInterval + MaxRtrAdvInterval)/2 | ||
Where the mean interval is defined as the mean delay before | ||
scheduling an unsolicited Router Advertisement. The probability of | ||
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 | ||
all responses will be delayed by a random time between 0 and | ||
MAX_RA_DELAY_TIME (0.5 s) [1]. | ||
In this case, the expected delay E_mcrsra for a single arriving RS | ||
is: | ||
E_mcrsra = P_mcdelay * MinDelayBetweenRAs/2 + MAX_RA_DELAY_TIME/2 | ||
Again for RFC2461 minima, the expected delay is thus: 1.535 s. | ||
The average unicast RA response time of course is 0.250 seconds. | ||
Assumptions underpinning this approximation hold only if the | ||
likelihood of more than one RS arriving within a multicast delay | ||
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 | ||
MinDelayBetweenRAs (defaulting to MIN_DELAY_BETWEEN_RAS) is: | ||
P[X(t) > 1] = 1 - P[X(t) == 1] - P[X(t) == 0] | ||
= 1 - (lambda*t)*exp(-lambda*t)/1! - exp(-lambda*t)/0! | ||
= 1 - ( 1 + lambda*t)* exp (-lambda*t) | ||
For a given load (lambda)=0.05 RS/sec, the probability of multiple RS | ||
arrival is 1.01%. | ||
Adopting the MinDelayBetweenRAs = 0.03s and MaxRtrAdvinterval= 4s the | ||
probability of arrival in the MinDelayBetweenRAs interval is 0.0148. | ||
The estimated expected delay for multicast RS/RA exchange is | ||
therefore 0.25022 seconds. | ||
This is comparable to the unicast response delay. | ||
In this case, the chance of additional solicitation arrival during | ||
MinDelayBetweenRAs is very low (around 1 in 10^6 for t=0.03, | ||
lambda=0.05). | ||
Please note that if the MaxRtrAdvInterval is also low (making the | ||
mean interval duration low), the solicitor is likely to get get an | ||
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 | ||
MinDelayBetweenRAs except that it assumes the value of the minimum | ||
time difference between unsolicited RAs (MinRtrAdvInterval) when | ||
MinRtrAdvInterval is less than 3 seconds. Reducing MinRtrAdvInterval | ||
to will increase the rate of RA transmission, but this doesn't need | ||
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 | ||
minimum values, the rate of solicited multicast RAs may be elevated | ||
to around 33 per second. This raises the potential for abuse by | ||
attackers which can force uniform resource consumption across all | ||
cells in a link. | ||
It is possible to choose delay values which provide significantly | ||
improved expected and worst case delays over RFC 2461 values, and | ||
have well defined upper bound traffic costs for constrained links. | ||
For example, if a link is able to sustain a maximum of two multicast | ||
RAs per second, a safe value for MinRtrAdvInterval and consequently | ||
MinDelayBetweenRAs is t=0.5s. With similar load values to those | ||
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 | ||
interval would be 3.07 * 10^-4 with a load (lambda)=0.05. | ||
This MinDelayBetweenRAs allows fairly good multicast response | ||
performance but bounds the number of multicast RAs to two per second. | ||
Regardless of load, the worst case delay for RA response in this case | ||
is no greater than 2*MIN_DELAY_BETWEEN_RAs (1 second). | ||
Appendix C. Router Advertisement Rates | ||
Unsolicited Router Advertisements are scheduled to be transmitted at | Unsolicited Router Advertisements are scheduled to be transmitted at | |
a time between MinRtrAdvInterval and MaxRtrAdvInterval after the last | a time between MinRtrAdvInterval and MaxRtrAdvInterval after the last | |
multicast Router Advertisement. These parameters may be configured | multicast Router Advertisement. These parameters may be configured | |
in the way which best suits the network. The table below summarizes | in the way which best suits the network. The table below summarizes | |
the parameters as described by IPv6 Neighbour Discovery [1]. | the parameters as described by IPv6 Neighbour Discovery [1]. | |
+-----------------------+----+----+----+-----+----+-----+ | +-----------------------+----+----+----+-----+----+-----+ | |
| Timer |Maximum |Default |Minimum | | | Timer |Maximum |Default |Minimum | | |
+-----------------------+----+----+----+-----+----+-----+ | +-----------------------+----+----+----+-----+----+-----+ | |
End of changes. | ||
This html diff was produced by rfcdiff v1.01, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |