MLD and Neighbor Discovery. Are They Related?

A few days ago, during my usual montly visit at Heidelberg, we had the opportunity at ERNW to have a full-day discussion about MLD. The discussion was led by Jayson Salazar who writes his thesis on the topic.

For the newcomers to IPv6 world, the purpose of MLD, a subprotocol of IPv6, as defined in RFC 2710, is “to enable each IPv6 router to discover the presence of multicast listeners (that is, nodes wishing to receive multicast packets) on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes.” MLD was updated by MLDv2 in RFC 3810 in order to “add the ability for a node to report interest in listening to packets with a particular multicast address only from specific source addresses or from all sources except for specific source addresses.


We discussed several MLD-related stuff and various potential (or …existing) security implications (which, by the way, are going to be presented at DeepSec in Vienna). However, one of the things that it attracted our attention, not from a security perspective but from an functional one is the question whether MLD is actually required to perform the Neighbor Discovery process. Up to now, none of us had thought about it. There wasn’t such a provision in the initial RFC regarding Neighbor Discovery for IPv6, but in the latest one, in RFC 4861, which obsoletes the previous, it is written in paragraph 7.2.1 that “joining the solicited-node multicast address is done using a Multicast Listener Discovery such as [MLD] or [MLDv2] protocols.”  As you notice, “is done”, a kind of a fact (perhaps not in an RFC-way, strictly speaking, but at least according to human language interpretation). Again, for the newcomers to the IPv6 world the solicited-node multicast address is used during the Neighbor Discovery process to accomplish address resolution. However, nothing in the RFC about how MLD is used in the Neighbor Discovery process.

To clarify it and full of curiosity we booted-up a Linux and a FreeBSD machine and, to our surprise, we found out that MLD messages are actually sent even before the Router Solicitation and Neighbor Solicitation messages. For a such a sample traffic from a Centos 6.5 machine, please see below:



There was only one way to find out: Implement some ip6table rules to block outgoing MLDv2 Report messages (sent by the client) to clarify whether MLD is actually required for the Neighbor Discovery process or not. The following rule is more than enough:

ip6tables -I OUTPUT 1 -p icmpv6 –icmpv6-type 143 -j DROP

So, we blocked outgoing ICMPv6 type 143, which are the MLDv2 Report messages. We booted-up again Centos, and we got the following traffic:



As you can see, no MLD messages now. But still, Neighbor Discovery process takes place without any problem. As we expected, before being confused by RFC 4861.

So, why is it written in the RFC that joining the solicited-node multicast address is done using MLD? We found at least one case. When MLD snooping is enabled in the switches (which is not usually the case, by default). But, that’s another story. For the time being, we can continue relying on Neighbor Discovery without requiring MLD.



Write a comment

Comments: 0