>>>>> On Sat, 07 Feb 2004 22:44:19 +1100,
>>>>> Gregory Daley <[EMAIL PROTECTED]> said:
>> My conclusion is that the right thing is to update RFC 2710
>> and require a delay. This removes collisions from both MLD
>> and DAD.
> I think that the problem there may be that RFC-2710 is
> being replaced by MLDv2.
> The IPv6 node reqs document had a MUST for MLDv1, and
> SHOULD for MLDv2 (last I saw). This could lead to many
> of the hosts exhibiting the colliding behaviour for MLDv1,
> even if the changes go into MLDv2.
Actually, the latest node req document says SHOULD for MLDv2 and MAY
for MLDv1:
Nodes that need to join multicast groups SHOULD implement MLDv2
[MLDv2]. However, if the node has applications, which only need
support for Any-Source Multicast [RFC3569], the node MAY implement
MLDv1 [MLDv1] instead.
(draft-ietf-ipv6-node-requirements-07.txt, Section 4.6)
Unfortunately, MLDv2 is now in the RFC editor queue, and I'm afraid
it's too late to put this kind of change at this stage (even if we
agree that the change itself is a good idea).
Assuming neither MLDv1 nor MLDv2 can soon be updated, we'll have to
deal with the collision issue within rfc2462bis. Possible options,
through discussions so far, are:
1. no change in rfc2462bis (expecting MLDv1 and/or MLDv2 will
eventually be updated with a random delay)
2. the original proposal of mine (expecting MLDv1 and/or MLDv2 will
eventually be updated with a random delay):
impose a random delay even for the first NS after the corresponding
MLD when the sending node knows there is no delay for the MLD.
3. Greg's suggestion:
require a random delay before the first MLD (in rfc2462bis).
Now that we are updating rfc2462bis, I don't think option 1 should be
taken. This way we'd just neglect an obvious problem while we have a
good chance to fix it. The other options may require a change to
existing implementations, but I believe we can accept that.
Regarding option 2:
pro: this can make DAD work if MLD-snooping switches are not used
pro: we can keep the issue separate from the MLD specs (we do not
have to worry about "spec-violation")
con: MLD packets still collide, which also make DAD unworkable if
MLD-snooping switches are used
Regarding option 3:
pro: this is a complete solution of the problem, which works with
MLD snooping switches
con: this can be regarded as spec-violation, and we may have to
worry about conflict with MLD updates in the future
I slightly prefer option 1, considering the deployment status of
MLD-snooping switches. But it's not a strong opinion. If others
prefer option 2 and the wg can agree on this, I'll follow the
decision.
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
--------------------------------------------------------------------
