Re: [rfc2462bis issue 274] conflict between MLD and NS delay

[Jari Arkko <jari.arkko@xxxxxxxxxxx>]

JINMEI Tatuya wrote:

> 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
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------