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.
My conclusion is that the right thing is to update RFC 2710 and require a delay. This removes collisions from both MLD and DAD.
(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.
--Jari
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
