>>>>> On Thu, 5 Feb 2004 17:55:08 +0200,
>>>>> Markku Savela <[EMAIL PROTECTED]> said:
>> It should be noted that the Neighbor Solicitation is usually not the
>> first message. As stated above, the sending node must join the
>> solicited-node multicast address prior to sending the Neighbor
>> Solicitation and an MLD report message [9] for the multicast address
>> should have been sent at that time. Unfortunately, RFC 2710 [9] does
>> not request a random delay to avoid race conditions. Thus, if the
>> sending node interpreted the "first message" literally, it would not
>> impose a delay for the MLD report or for the Neighbor Solicitation,
>> making the race conditions worse. This document therefore suggests
>> the following workaround: even if the Neighbor Solicitation is not
>> the first message, the same random delay should be imposed when the
>> sending node knows the Neighbor Solicitation can be synchronized with
>> other nodes. This includes the first Neighbor Solicitation after the
>> MLD report message in the above case.
> This is silly! I thought the reason for the random delay was to
> prevent simultaneus packet sending of all hosts on the link, if they
> boot up at same time (for example after power fail).
> Now, this MLD report is going to be collided (mostly lost anyway),
> because every node is sending on the link at same time.
> If you are not delaying the MLD, there is really no point in delaying
> the DAD either...
Sorry, I don't see the point. With the current RFC2710 and RFC2462 in
the power failure (or something similar) case, MLD reports are
collided, and then NS for DAD are also collied.
With the proposed resolution, MLD reports are collided, but NS for DAD
are not (depending on the variance of random timers).
I proposed the resolution because I thought the former is worse than
the latter. So, I'd see your point if you said the change is *not so
effective* because we still have collisions. But I don't see why you
called it "silly".
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
