Hi Ralph,
On 10-08-27 10:51 AM, Ralph Droms wrote:
References: <[email protected]> <1b6d0317d3ad964fbf3956defa3524d505c580f...@eusaacms0701.eamcs.ericsson.se>
<[email protected]> <1b6d0317d3ad964fbf3956defa3524d505c5810...@eusaacms0701.eamcs.ericsson.se>
<[email protected]> <1b6d0317d3ad964fbf3956defa3524d505c5810...@eusaacms0701.eamcs.ericsson.se>
<[email protected]> <[email protected]> <[email protected]> <[email protected]>
<[email protected]> <[email protected]> <[email protected]>
<[email protected]> <[email protected]> <[email protected]>!
<[email protected]> <[email protected]> <[email protected]> <5
[email protected]>
<[email protected]>
To: Suresh Krishnan <[email protected]>
X-Mailer: Apple Mail (2.1078)
X-Brightmail-Tracker: AAAAARXElNoReturn-Path: [email protected]
X-OriginalArrivalTime: 27 Aug 2010 14:51:04.0609 (UTC)
FILETIME=6226910:01CB45F7]
Josh Littlefield pointed out where I was confused - I reversed RS and RA, so my
text should have read:
...a further comment on using standard stacks. There is a potential problem with using
RS as "sign of life": if the node receives an unsolicited RA before it sends an
RS, the node will accept that RA and never send an RS. The node waits a random interval
between 0 and 1 seconds before sending an RA and the default delay time between
unsolicited RAs is 600 seconds (all of these details from RFC 4861). If I have the
scenario and details (choosing default values) all correct, that means the node has an
average 0.00083 probability (1/1200) of receiving an RA before sending an RS. So,
roughly 1 in 1,000 nodes will fail to send an RS and trigger the unicast RAs.
There is a SHOULD level requirement on the node to send an RS even in
this case. This is the relevant text from RFC4861 (Section 6.3.7)
"Moreover, a host
SHOULD send at least one solicitation in the case where an
advertisement is received prior to having sent a solicitation.
Responses to solicited advertisements may contain more information
than unsolicited advertisements."
Thanks
Suresh
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------