You don't configure multicast address anywhere.
Some box sends traffic out with multicast destination, this will automatically get L2 multicast address on the link.
This L2 multicast address is normally broadcasted in L2, unless there are some specific features enabled, like IGMP snooping to stop the flooding.
If IGMP snooping is enabled, then the L2 switch will learn which ports want to receive the multicast (they do IGMP join to the multicast group) and will not flood traffic to other than interested ports.
If L3 is involved, then you'll learn via PIM which ports are interested in receiving the multicast.
I can recommend this book for multicast basics, it's not JNPR specific.
If you don't know which addresses to use, if you have 2byte ASN, you should use
233.0.0.0/8 GLOP block (with your ASN in it) if you don't have 2byte ASN your best bet is 239.0.0.0/8 which can be thought has RFC1918 (e.g. 10.0.0.0/8) for multicast.
Key to answering your question is making a very important distinction: Duplicate Address Detection (DAD) and Multicast Listener Discovery (MLD) are completely separate protocols.
Now, that said, I think this paragraph of RFC2710 explains the "duplicate" transmission:
When a node starts listening to a multicast address on an interface,
it should immediately transmit an unsolicited Report for that address
on that interface, in case it is the first listener on the link. To
cover the possibility of the initial Report being lost or damaged, it
is recommended that it be repeated once or twice after short delays
[Unsolicited Report Interval]. (A simple way to accomplish this is
to send the initial Report and then act as if a Multicast-Address-
Specific Query was received for that address, and set a timer
appropriately).
RFC3810 supersedes RFC2710, but still agrees with the above. (Thanks to @logion for pointing this out!). I'm leaving the quote from RFC2710 in place because I think it lends itself to be more easily understood without additional context. In particular, the part of RFC 3810 that confirms the behavior is here:
To cover the possibility of the State Change Report being missed by
one or more multicast routers, [Robustness Variable] - 1
retransmissions are scheduled, through a Retransmission Timer, at
intervals chosen at random from the range (0, [Unsolicited Report
Interval]).
Which leaves us to having to discuss DAD, and specifically, why DAD is completely independent from MLD.
Before an IPv6 node intends to use an IP address, it must first check if the address in use. This check is done by sending a Neighbor Solicitation (NS) message to the Solicited Node Multicast (SNM) address of the target IP address. The SNM is a multicast address that anyone who would own the target IP address would be listening to.
The Destination IP of the Neighbor Solicitation packet is FF02::1:FFyy:yyyy
(where yy:yyyy
is the last 24 bits of the target IPv6 address). And the Source IP is ::
, the "unspecified" IPv6 address. It must use the Unspecified address, to prevent using the target address itself, since it might trigger a duplicate. At this time, the initial host doesn't know whether the address is unique or not.
If another host on the network already owns the target IPv6 address, they would receive the Neighbor Solicitation message described above, and would respond by sending a Neighbor Advertisement (NA) indicating the IP is already in use.
Here is the key: Since the initial NS was sent from the unspecified address (::
), the other host which owns the target IPv6 address will have no way of knowing who to send the responding NA to. As a result, it must send the result to FF02::1
, the "All Nodes" Multicast address.
This is how DAD can still perform, if you are blocking all MLD messages. Because joining the All Nodes multicast group doesn't require a MLD transaction, all switches that understand IPv6 will automatically forward the "All Nodes" destined frames to all ports in the respective VLAN. DAD, does not require listening on a particular multicast group to receive notification of an address already in use.
If no one claims the IPv6 address, DAD then determines the IPv6 address is unique, and allows the initiating Host to start using the address itself. This is what prompts the joining of the correlating SNM group for the target address with some MLD messages sent to the MLD multicast address of FF02::16
. (and according to the RFC above, this message is intended to be sent twice).
The windows capture seems to use the Source IP before sending out the Neighbor Advertisement that claims the IP on the network which occurs at the end of DAD. I can't help but feel this is jumping the gun a little, since the NA is what marks the end of the DAD process, and the confirmation that the address is indeed unique on the network.
The linux capture has MLD messages sent before the DAD NS, but these are sent from the unspecified address, so can't cause an IP conflict. If any MLD Sniffing switches on the network only need to correlate a MAC address to a joined MLD group, then this would work just fine (Disclaimer: I am not intimately familiar with the intricacies of MLD sniffing, and can not claim whether this is exactly how it works)
The BSD capture doesn't include the NA, but the two MLD messages occur .15 seconds after the DAD NS is sent out. Which to me, seems a bit too short, since the DAD process calls for a wait of just shy of a second before considering an address unique (according to the captures and testing I've done).
Best Answer
IPv6 does not use ARP, it uses ND. ARP uses broadcast, which interrupts every host on the LAN, but IPv6 doesn't have broadcast. Instead, each IPv6 interface must subscribe to a solicited-node multicast address for each IPv6 unicast or anycast address configured on the interface. These solicited-node multicast addresses are based on the IPv6 unicast or anycast addresses, so, in all likelihood, the resolution request only interrupts the one host with that IPv6 address, or possibly a very few hosts. This is a better solution than ARP.
See RFC 4291, IP Version 6 Addressing Architecture, Section 2.7.1. Pre-Defined Multicast Addresses:
IPv6 uses the solicited node multicast address for the IPv6 layer-3 unicast or anycast address which it wants to resolve to the layer-2 address. A host will compute the solicited node multicast address for the address to resolve, and it will multicast a Neighbor Solicitation message to the multicast group. The host with the layer-3 address will reply with its layer-2 address.
See RFC 4861, Neighbor Discovery for IP version 6 (IPv6):
To create an IPv6 layer-2 multicast address from an IPv6 layer-3 multicast address you simply use
33-33
and append the last 32-bits of the IPv6 layer-3 multicast address. This gives you a lot more layer-2 multicast addresses than IPv4 has because IPv4 only uses 23 bits of the layer-3 multicast address in the layer-2 multicast address.See RFC 2464, Transmission of IPv6 Packets over Ethernet Networks:
Also, RFC 7042, IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters, Section 2.3.1. Identifiers Prefixed "33-33":