[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Question about unsolicited MLD report for Solicited-Node MulticastAddress




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
--------------------------------------------------------------------