>>>>> On Fri, 28 May 2004 15:16:42 +0200,
>>>>> "Gerrit van Niekerk" <[EMAIL PROTECTED]> said:
> I am a bit new to this list and could not pick up the specific thread for issue
> 337, but it looks to me like the sending of the NS should be delayed and not
> the joining of the solicited-node multicast address.
No, saying "joining the multicast address" instead of "sending NS" is
intentional and important. Actually, this is the result of solving a
separate issue for rfc2462bis. draft-ietf-ipv6-rfc2462bis-00.txt
explains the rationale in Section 5.4.2:
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, just 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.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
