>>>>> On Mon, 30 May 2005 13:01:10 +1000,
>>>>> Greg Daley <[EMAIL PROTECTED]> said:
>> Well, here is the scenario I am thinking of: A MN uses unsolicited
>> RAs---neither RSs, nor link-layer triggers---to detect IP-attachment
>> changes. Assuming that routers send their RAs every 50ms on average,
>> which is what RFC 3775 allows them to do, this movement-detection
>> strategy works better than sending RSs. The reason is the random delay
>> for solicited RAs, as you say. Even if the MN would use L2 triggers, it
>> would still have to send an RS and await the random RA-delay in order to
>> find out the new prefix(es).
>>
>> So, RFC 3775's frequent (unsolicited) RAs can be leveraged for movement
>> detection quite nicely. But when it comes to configuring the new
>> address, the MN ends up having to wait for D2 or D3 to send the MLD
>> Report. In other words, eliminating D1 turns out to be useless as long
>> as D2 and D3 are still there.
> The main issue here is that there's an unsolicited RA which many people
> may have received, and no indication of movement from L2, so the host is
> unsure why the change occurred.
> In this case, the host should be conservative in what it sends, and
> make use of a delay in order to prevent DAD contention with other
> unknown configuring hosts.
Thanks, this is exactly what I'm going to explain in this message. I
believe I don't need to say anything more for rejecting the
elimination of D3 *in rfc2462bis*. (Again, this does not preclude
future efforts for optimizing the delay further)
> The delay D1 is not applicable here (no L2 hint), but a single delay
> for DAD NS and MLD may be applicable as you say.
> I guessed that the new text in 2462bis covers this nicely, though.
I agree. If the point is to introduce a single delay for D1 and D2
(note that we cannot make the elimination of D3 for a different
reason), we should be already done.
2461bis-03 reads:
Before a host sends an initial solicitation, it SHOULD delay the
transmission for a random amount of time between 0 and
MAX_RTR_SOLICITATION_DELAY. This serves to alleviate congestion when
many hosts start up on a link at the same time, such as might happen
after recovery from a power failure. If a host has already performed
a random delay since the interface became (re)enabled (e.g., as part
of Duplicate Address Detection [ADDRCONF]) there is no need to delay
again before sending the first Router Solicitation message.
(Notice the last sentence)
and rfc2462bis-08 reads:
If the Neighbor Solicitation is going to be the first message to be
sent from an interface after interface (re)initialization, the node
SHOULD delay joining the solicited-node multicast address by a random
delay [...]
(Notice the "If" condition)
I believe it is pretty clear that these specifications indicate a
single delay only applicable to either D1 or D2.
So, are we done (within the scope of 2461bis/2462bis)?
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
