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

[JINMEI Tatuya / $B?@L at C#:H(B <jinmei at isl.rdc.toshiba.co.jp>]

>>>>> On Mon, 09 Feb 2004 06:24:26 -0500, 
>>>>> Brian Haberman <brian@innovationslab.net> said:

>> I think what Jari asked was not a modification to the semantics
>> of reporting group joins.
>> 
>> I think that what Jari proposed was actually that we delay DAD
>> (which entails both the operation of beginning listening to
>> a group and the NS transmission).

> So, in logic-wise it would look like:

>      1. Generate the solicited-node multicast address
>      2. Wait for random timer expiry
>      3. Perform ADD_MEMBERSHIP call on the socket
>      4. Send DAD

> I think I can live with that for the time being.

In my latest proposal, the behavior is a bit different:

      1. Generate the solicited-node multicast address
      2. Perform ADD_MEMBERSHIP call on the socket (or equivalent) but
         not send MLD, i.e., start listening to the multicast address
      3. Wait for random timer expiry
      4. send MLD
      5. Send DAD

The reason for doing 2 before the random delay is because we need to
listen to the multicast address to improve the reliability of DAD.

The reason for doing 3 (random delay) before sending MLD is for
avoiding collisions.

Would you still live with this?

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@isl.rdc.toshiba.co.jp

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------