6

I was wondering if anyone can shed some light on when Multicast Listener Discovery (MLD) messages ought to be send during IPv6 Duplicate Address Detection. RFC4862 section 5.4.2 gives a detailed description of which multicast groups an IPv6 host performing DAD should join, namely the all-nodes multicast address and the solicited-node multicast address. It also mentions the use of MLD, however I can't seem to explain the observed behaviour of windows and Linux as I will explain below.

From RFC4863 it is my understanding that a node should not announce its interest in the all-nodes multicast address (as MLD snooping switches will process all-nodes multicast traffic anyway), but that it is advised to send MLD messages for the solicited-node multicast address (as MLD snooping switches can not possibly be aware of all the solicited-node multicast addresses it ought to listen for and forward).

So far so good, however when I look at how Windows, Linux and FreeBSD have implemented MLD message sending during DAD I don't understand why the MLD messages for the solicited-node multicast address are sent twice. Here are three traces showing DAD for the link-local address when bringing up the Ethernet interface of a Linux, Windows and FreeBSD machine respectively.

Some seemingly strange behaviour:

  1. Linux, Windows and FreeBSD all send the MLD message twice. Linux and Windows space them about 300 ms apart, in FreeBSD this is ~2200ms. Why is the second message sent, seeing how it is an exact copy of the first? Is this some form of retransmission?
  2. Linux delays the neighbour solicitation message (SOL) until after the second MLD message, whereas windows and freebsd send the SOL message immediately.
  3. Windows and freebsd send the MLD messages after the neighbour solicitation message. Granted it sends the first MLD message immediately after the SOL message. Also, when windows sends the SOL message, it has most likely already joined the multicast group; only the announcement itself is delayed not the actual joining of the group. Still, wouldn't sending the MLD message first reduce the chance of missing a neighbour advertisement from a host behind a MLD snooping switch?
    1. (Note that windows actually proactively advertises that it has assigned fe80::c14b:8228:ee4:d4aa in message #4, this is however not related to MLD)

So far, I have come to the preliminary conclusion that there are no standardized practices on timing of MLD messages. There are some guidelines that restrict sending MLD messages in order to prevent congestion such as in RFC 4862. Can anyone refer to further material on when to send MLD messages during IPv6 DAD and thereby explain the observations from the traces above? I assume that every OS chooses when to send MLD messages during DAD and that Linux and Windows/FreeBSD made a different choice, however why did all three OSs chose to send MLD messages for the solicited-node multicast address twice (and spaced 300/300/2200ms apart)?

Note that I am aware that MLD messaging is not required for DAD in most cases and that DAD usually works fine when blocking MLD messages (unless there is a MLD snooping switch somewhere). However, some of our students get confused by the erratic behaviour of MLD messaging and I'm at a loss explaining the observed behaviour to them.

  • Very well formed question. Could you attach the PCAPs in a different manner so we can simply download them directly? Maybe use a service like DropBox or some such. – Eddie Dec 10 '14 at 13:47
  • 1
    I didn't realize pcapr does not allow public downloads. They're available at vdna.be/IPv6-DAD-traces.zip – logion Dec 10 '14 at 16:49
  • 1
    @logion I think Eddie is talking about a service such as CloudShark. – Ryan Foley Dec 11 '14 at 21:37
7

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

  • 1
    Nice find in RFC 2710! Could you however update you answer to also include a reference to RFC 3810 (which supersedes RFC 2710). RFC 3810 basically says the same thing on page 29: 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]). – logion Dec 12 '14 at 14:44
  • @logion, Good call! And good find! I don't know if I would have found that paragraph in RFC3810, I got lucky with 2710 with a word search for "repeat" ;). I edited the original post. Let me know if anything else needs to change. – Eddie Dec 12 '14 at 14:56
  • 1
    Thanks for (updating) your answer. This question is now solved :). As for finding newer RFCs, just ask tools.ietf.org for the original RFC and if it is superseded the new RFCs will be shown at the top. Take 2710 for example tools.ietf.org/html/rfc2710, it is updated by 3590 and 3810. – logion Dec 12 '14 at 15:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.