Gregory Daley wrote:
Hi Jari,

----- Original Message -----
From: Jari Arkko <[EMAIL PROTECTED]>
Date: Friday, February 6, 2004 10:42 pm
Subject: Re: [rfc2462bis issue 274] conflict between MLD and NS delay


Greg Daley wrote:


I do not think we should be modifying every node to suit
MLD snooping, but it is possible to perhaps suggest
a random delay for _both_ the MLD report _and_ the DAD
NS (but no explicit delay between them). The DAD NS must
come after the MLD report though.

What is important here is to avoid the collisions. The collisions are avoided if there is some random delay before you start sending packets. Given that the protocols impose an ordering (MLD first and DAD after that), a delay in MLD will impose an equivalent delay in DAD.


That's sufficient.

Ok, so now we agree what needs to be done protocol wise, the rest is just a documentation issue ;-)

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.


Will we effectively need MLDv1(the second)?

I see the problem. I do not have a strong opinion on which document should explain what the correct behaviour is, as long as the document boundaries do not force us to specify suboptimal behaviour. For instance, if RFC 2462bis can explain that the delay should actually be before the MLD packet, that would be also sufficient. [If you think it sounds strange that 2462bis would be saying what to do for MLD, lets not forget that MLD is invoked because 2462bis needs the multicast listening service.]

--Jari


-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------

Reply via email to