Re: [rfc2462bis issue 274] conflict between MLD and NS delay

[Jari Arkko <jari.arkko at kolumbus.fi>]

Gregory Daley wrote:
> Hi Jari, 
> ----- Original Message -----
> From: Jari Arkko <jari.arkko@kolumbus.fi>
> 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
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------