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/