Last updated on December 27, 2018
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.
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.
- DAD for fe80::20e:8eff:fe3b:23ad in Linux
- DAD for fe80::c14b:8228:ee4:d4aa in Windows
- DAD for fe80::1234 in FreeBSD
- 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?
- Linux delays the neighbour solicitation message (SOL) until after the second MLD message, whereas windows and freebsd send the SOL message immediately.
- 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?
- (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)