Re: Question about unsolicited MLD report for Solicited-Node Multicast Address

["Sha Liu" <liusand@xxxxxxxx>]

Dear Greg,
    Thanks for your explanation!
    Whether can we say that the combination of no delay in sending MLD report and delay in sending first NS is to lessen the racing condition on the link?
    In Linux kernel 2.4.18 source, I found a calling chain listed below:
        addrconf_dad_start() -> addrconf_join_solicit() -> ipv6_dev_mc_inc() -> igmp6_group_added() -> igmp6_join_group() -> igmp6_send()
    But in my tcpdump results, there is no MLD report exists. It is confusing me.

----- Original Message ----- 
From: "Greg Daley" <greg.daley@eng.monash.edu.au>
To: "Liusand" <liusand@sina.com>
Cc: <ipng@sunroof.eng.sun.com>
Sent: Thursday, May 15, 2003 8:34 AM
Subject: Re: Question about unsolicited MLD report for Solicited-Node Multicast Address


> 
> Dear Liusand,
> 
> Liusand wrote:
> > Hello,
> >   When I read RFC2461, 2462 & 2710, I found that RFC2461 & 2462 request
>  >   that a node delays sending first NS message to avoid racing condition
> >   on the link. But according to RFC2710, MLD message for Solicited-Node
> >   Multicast Address ARE sent.    Also from RFC2710, when a node joins a
>  > multicast group, a unsolicited MLD report SHOULD be sent.
> 
> 
> This is a part of the specifications which is not exactly clear.
> 
> The NS message is sent when DAD is to be undertaken.
> Initially, the node has not checked the address and needs to
> solicit in order to check if another node is in posession of this
> address.
> 
> Does the node listen for NA messages for this address before it sends
> the DAD NS?
> 
> If it does, then the MLD message has to be sent as soon as the task
> of listening to the multicast group is begun.  This is because in some
> (future?) environments, valid multicast messages may not be delivered
> to the configuring node, unless the MLD message is sent on the link.
> 
> If the node doesn't listen for NA's before the NS is sent, then there
> is no reason to join the solicited node multicast group for the address
> at a significantly before the DAD NS. Otherwise, we may see the
> situation you describe below.
> 
> All nodes could notice that the link was available, and send MLD 
> messages simultaneously in a way which could hamper the link.
> 
> If the configuring nodes delay joining the multicast group to the
> same time that the DAD NS is sent, then two multicast packets (The MLD
> Report and the DAD NS) are sent at about the same time, and would be
> governed by the same random timer.   In this case it is even more
> important that nodes obey the random delay for DAD!
> 
> 
> > According to  the implementation of Linux kernel 2.4.18 and
>  > USAGI-linux24-stable-20030214, when a node starts DAD procedure to
>  > statelessly autoconfigure its IPv6 address, a MLD report for the relevant
>  > Solicited-Node Multicast Address will be sent immediately even when the
>  > node boots up, while the NS for DAD will be delayed.
> 
> I think that you mean that the 2.4.18 kernel was patched with USAGI.
> I thought that the standard linux 2.4.18 kernel didn't do MLD for
> solicited nodes addresses.
> Is this your understanding too?
> 
> >   Does the implementation above violate the policy of delaying sending
>  >   the first message when a node boots up? I think the undelayed MLD 
> report
>  >   for the Solicited-Node Multicast Address may also cause racing
> >   condition  on the link. So I suggest that this MLD report be delayed
>  >   and be sent just before the NS for DAD. If the problem caused by such
>  > racing condition is not so severe, why not revoke such delay to speed up
>  > the DAD?
> 
> This is a genuine issue with the standards. The RFC text is
> both explicit, and contradictory.
> 
> For Example:
> 
> Section 5.4.2 of RFC 2462:
> 
> "Before sending a Neighbor Solicitation, an interface MUST join ...
>                the solicited-node multicast address"
> 
> RFC 2710 implies this means sending an MLD report.
> and
> 
> "If the Neighbor Solicitation is the first message to be sent from an
>     interface after interface (re)initialization, the node should delay
>     sending the message by a random delay"
> 
> These statements are mutually exclusive, since the MLD report
> will always be sent before the Neighbor Solicitation.
> 
> The statement which means that MLD reports are sent before the delay
> is this Mandatory requirement:
> 
> " 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
>     delaying transmission of the initial Neighbor Solicitation."
> 
> This means that the MLD reports for solicited nodes multicast are
> sent as soon as the node decides to configure the address, and
> effectively defeats the randomization strategy.
> 
> So the USAGI implementation may be correct, if misguided.
> 
> Greg Daley
> 
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to majordomo@sunroof.eng.sun.com
> --------------------------------------------------------------------
> 
> 
>

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------