JINMEI wrote:
On Mon, 09 Feb 2004 06:24:26 -0500, Brian Haberman <[EMAIL PROTECTED]> 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?
In the stacks I am familiar with, once you perform ADD_MEMBERSHIP, the sending of the Report message is out of your control.
1. Would you standardize a mechanism for joining but not reporting?
2. Does the implementation of NDP "control" the MLD state machine?
3. What happens if someone builds a stack from multiple vendors
(e.g. MLD from vendor X and NDP from vendor Y)?Regards, Brian
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
