Press "Enter" to skip to content

MLD messages during IPv6 duplicate address detection

Last updated on December 27, 2018

        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. <a href="http://tools.ietf.org/html/rfc4862#section-5.4.2" rel="nofollow" title="RFC 4862">RFC4862 section 5.4.2</a> 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.

Be First to Comment

Leave a Reply

%d bloggers like this: