How about this one? (this may still be controversial, and if so, please continue the discussion. But since the cutoff deadline is looming, I'll submit the draft with the proposed text below anyway.)
If the Neighbor Solicitation is going to be the first message to be sent from an interface after interface (re)initialization, the node should delay joining the solicited-node multicast address by a random delay between 0 and MAX_RTR_SOLICITATION_DELAY as specified in RFC 2461 [5]. This serves to alleviate congestion when many nodes start up on the link at the same time, such as after a power failure, and may help to avoid race conditions when more than one node is trying to solicit for the same address at the same time.
Note that the delay for joining the multicast address implicitly means delaying transmission of the corresponding MLD report message [9]. Since RFC 2710 [9] does not request a random delay to avoid race conditions, only delaying Neighbor Solicitation would cause congestion by the MLD report messages. The congestion would then prevent MLD-snooping switches from working correctly, and, as a result, prevent Duplicate Address Detection from working. The requirement to include the delay for the MLD report in this case avoids this scenario.
In order to improve the robustness of the Duplicate Address Detection algorithm, an interface MUST receive and process datagrams sent to the all-nodes multicast address or solicited-node multicast address of the tentative address while the delaying period. This does not necessarily conflict with the requirement that joining the multicast group be delayed. In fact, in some cases it is possible for a node to start listening to the group during the delay period before MLD report transmission. It should be noted, however, that in some link-layer environments, particularly with MLD-snooping switches, no multicast reception will be available until the MLD report is sent.
Looks very good. Thanks!
--Jari
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
