JINMEI Tatuya / ???? wrote:
On Thu, 5 Feb 2004 17:55:08 +0200, Markku Savela <[EMAIL PROTECTED]> said:
It should be noted that the Neighbor Solicitation is usually not the first message. As stated above, the sending node must join the solicited-node multicast address prior to sending the Neighbor Solicitation and an MLD report message [9] for the multicast address should have been sent at that time. Unfortunately, RFC 2710 [9] does not request a random delay to avoid race conditions. Thus, if the sending node interpreted the "first message" literally, it would not impose a delay for the MLD report or for the Neighbor Solicitation, making the race conditions worse. This document therefore suggests the following workaround: even if the Neighbor Solicitation is not the first message, the same random delay should be imposed when the sending node knows the Neighbor Solicitation can be synchronized with other nodes. This includes the first Neighbor Solicitation after the MLD report message in the above case.
This is silly! I thought the reason for the random delay was to prevent simultaneus packet sending of all hosts on the link, if they boot up at same time (for example after power fail).
Now, this MLD report is going to be collided (mostly lost anyway), because every node is sending on the link at same time.
If you are not delaying the MLD, there is really no point in delaying the DAD either...
Sorry, I don't see the point. With the current RFC2710 and RFC2462 in the power failure (or something similar) case, MLD reports are collided, and then NS for DAD are also collied.
With the proposed resolution, MLD reports are collided, but NS for DAD are not (depending on the variance of random timers).
I proposed the resolution because I thought the former is worse than the latter. So, I'd see your point if you said the change is *not so effective* because we still have collisions. But I don't see why you called it "silly".
The simultaneous transmission issue is principally a reliability issue. There is some chance on certain link-layers that packets will be significantly delayed or lost when simulataneous transmission occurs.
There are very few reasons why one would require MLD reports on link local solicited nodes addresses.
The only existing reasons to do MLD on these addresses are so that MLD proxies, and snooping switchescan request multicast transport for those addresses. Unless this is performed correctly, the node performing DAD will not receive DAD defence NA's, even if the DAD NS is sent with random delay.
Since there is no random delay with MLD, the reliability issue still exists in these environments. I believe that this may have been what what Markku was trying to communicate.
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.
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.
In some systems, the ordering of MLD-report and NS cannot be guaranteed on the output queue. Before transmitting the DAD NS, the node should ensure that either there has been sufficient time between MLD transmission and NS, in order to guarantee packet ordering on the link. Alternatively, explicit indication that transmission has occurred would achieve the same purpose.
Greg Daley
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
