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. > 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)? > (We could still keep the requirement in 2462bis that if the DAD > message is the first message to be sent then you should add > a delay, but in that case we need to explain that if you > follow the MLD spec then it never is the first message.) > > > In this case, the node could start listenting to the group > > before sending an MLD report. This is different to MLD/MLDv2, > > but will not hurt, since the DAD NS is the principle > > trigger for multicast traffic to that solicited nodes' address. > > > > In snooping environments, the node wouldn't get any messages > > to the group until the MLD report was sent. > > In any case, it avoids the simultaneous transmission problem. > > Listening before you send the MLD report is possible, but should > be optional since, as you say, it does not always work. Since you've not sent any packets on the link, it may not hurt though... Whether it's worth specifying here (listen before you're a listener) is another matter. Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
