Re: [rfc2462bis issue 274] conflict between MLD and NS delay
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [rfc2462bis issue 274] conflict between MLD and NS delay
Markku,
Markku Savela wrote:
From: Brian Haberman <brian@innovationslab.net>
- desire to avoid packet storms upon booting many nodes simultaneously
2710 accomplishes this by using message suppression. If a node hears a
Report for the same group, it cancels the transmission of any pending
Reports it has for the group.
Above will totally fail with ND multicast groups. Their design goal is
that each host is only on one group. It is highly unlikely that
listening would hear a duplicate join for the solicited node multicast
address.
It is not a failure, it is just not useful for solicited-node multicast
addresses. But, you also snipped a part of the note that pointed out
that ND and MLD were designed with differing techniques to deal with
reliability.
I've already said my differing opinion on this way back earlier, but
apparently I lost the vote. But, just to make clear:
sending MLD messages for link local multicast groups is waste of
time and specification effort. If you have layer 2 sniffers, they
can (and most likely must) sniff the normal ND traffic too. A ND DAD
contains exactly the same information content as MLD join for the
solicited node group.
And the MLD Report for the solicted-node multicast address will cause
the L2 sniffer to forward the ND DAD message to any other port that
has joined the same multicast group. If two nodes are DAD'ing for the
same unicast address, the L2 sniffer will need to forward those NS
messages to all ports where the solicited-node address has been joined.
Regards,
Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.