The purpose of this blog post is to elucidate how and why MLD, an IPv6 protocol we’ve been lately talking quite a bit about, is an unnecessarily complex beast . This article should also serve to summarize a couple of points we’ve mentioned during our talks about MLD but which because of time constraints never make it into the main discussion. We’ve talked about other aspects of MLD in previous posts. So, have a look at those if this is a topic which you find interesting. Without further ado, let’s start for today.
The Reason behind our Interest in MLD
During the past two years IPv6 has become an unavoidable topic when discussing networking and information security. ISPs know that there’s no way around it, and they realize that the longer they decide to stay with IPv4, the harder and more painful the deployment of IPv6 might become. We are, as most of you are surely aware, quite glad with the perception shift regarding IPv6, as we’ve been writing about its features and intricacies for a while.
Some might say that deploying IPv6 “partially” is better than deploying no IPv6 at all, a perspective which can certainly be found in the industry. We, however, aren’t big fans of deploying anything without thoroughly understanding it, as this is just bad practice when it comes to secure networking. Implementing something you don’t completely understand in order to support features others will rely on is likely to turn into a source of problems in the long run; both operations- and security-wise.
So, why this preamble you might ask? Well, in the past months we have been discussing some of the quirks which await networking and security professionals in the IPv6 world. Recently, we have talked about:
DHCPv6, Extension Headers, RAs and RA-Guard and other IPv6 topics. Following this line of thinking, one of the protocols we decided to have a look at in the past months was the Multicast Listener Discovery (MLD) protocol. One could think: “why bother looking at it, it isn’t even mentioned in RFCs 2460 or 4291? It surely isn’t that relevant” An certainly this seems to be the way in which MLD is commonly perceived. Well, this might be true, however, there some ideas which certainly seem familiar and should get some questioning going:
1. IPv6 has done away with broadcasting and it has been replaced with multicasting.
2. ICMPv6 serves as the basis for crucial IPv6 signaling protocols such as the Neighbor Discovery (ND) protocol.
3. Unicast is not always the best way to go; inter-domain multicasting can be useful under certain circumstances.
4. If you’ve had a look at a traffic capture on an IPv6 capable network, you have most likely seen datagrams labeled as belonging to the “Multicast Listener Discovery Protocol”. So, instead of ignoring those packets, why not establish what their purpose of the aforementioned protocol is? Answers shouldn’t, or so goes the story, be that hard to find.
Points one to three are thoroughly discussed in RFCs 2460 and 4291, allegedly the most relevant in the whole IPv6 specification. So, the curious reader will now have some questions, which read something like the following:
1. How was broadcasting replaced with multicast? Broadcasting happens not only on layer 3 but also on layer 2, anyway.
2. Are there any other relevant ICMPv6-based signaling protocols in IPv6?
3. In IPv4 we had (but most of us never used) the Protocol Independent Multicasting (PIM) protocol and the Internet Group Management Protocol (IGMP), what do we have in IPv6?
4. If I’m not running inter-domain multicast applications, why do I usually see MLD traffic on my traffic captures?
The MLD Protocol at First Glance
RFC 3810, the successor of RFC 2710 and the one which specifies MLD in its latest version, clearly states in its introduction section:
“The Multicast Listener Discovery Protocol (MLD) is used by IPv6 routers to discover the presence of multicast listeners (i.e., nodes that wish to receive multicast packets) on their directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes.”
So, in short, RFC 3810 discusses: multicasting, routing and discovery of multicast listeners. This leads one to think what the network scenario might look like. The figure shown below illustrates one such scenario, where MLD could be of use as described by the introductory remarks.
Exemplary Inter-Domain Multicast Deployment
A quick glance at RFC 5110, Multicast Routing Overview, supports our assumptions with regard to the typical use case(s) for MLD in IPv6 deployments.
“When a host wants to receive a transmission, it first needs to find out the multicast group address […] using various means […]. Then it will signal its interest to its first-hop router using IGMP (IPv4) or MLD (IPv6). The router initiates setting up hop-by-hop multicast forwarding state to the source […]. When multicast transmission arrives at the receiver’s LAN, it is flooded to every Ethernet switch port unless flooding reduction such as IGMP snooping is employed.”
Up until this point we haven’t actually learned anything new, we have, however, laid out what the purpose of MLD is. MLD is is a protocol meant to enable clients in a LAN to tell their gateways that they are expecting multicast traffic going to a certain group, and that once it arrives through the ingress links, it should be forwarded to the inner side and “flooded to every Ethernet switch port unless flooding reduction such as IGMP snooping is employed.”
With this, questions two and three can somewhat be answered. Yes, there are signaling ICMPv6-based protocols aside from ND which are relevant to IPv6 deployments. Secondly, in IPv6, inter-domain multicasting is still realized using PIM and a signaling protocol on the receivers’ LAN side, MLD.
However, there are two questions which were left unanswered, namely, “how was broadcasting replaced with multicast?” and “if I’m not running inter-domain multicast applications, why do I usually see MLD traffic on my traffic captures?“ These questions and their respective answers will be addressed shortly.
MLD Snooping, the non-standardized Mechanism mentioned and considered in actual Standards
Additionally to what has been mentioned so far, RFC 5110 brings our attention to yet-another mechanism, IGMP Snooping, or in our case, MLD Snooping. In the context of inter-domain IPv6 multicasting, what MLD Snooping enables us to do is simply to prevent that inter-domain multicast traffic is “flooded to every Ethernet switch port” when not every host on the LAN is interested. When a gateway forwards ingress multicast traffic going to a certain multicast IPv6 destination address, the Ethernet destination address in the packet is set to one derived from the IPv6 one. Multicast MAC addresses start with the prefix 33:33, as per IEEE 802, and are followed by the last 32 bits of the destination IPv6 multicast address. IEEE 802 also specifies that when switches receive frames addressed to a MAC address starting with 33:33; such frames are to be broadcasted. That is, unless the switch implements and has a proprietary non-standardized mechanism called MLD Snooping activated, by which the switch learns behind which ports there are listeners interested in the multicast groups whose traffic has been received, and subsequently floods it only to those interfaces.
The relevant facts to be kept in mind in relation to MLD Snooping before continuing are the following:
1. MLD Snooping is not a standard but is implemented by major switch vendors such as Cisco, HP, H3C, etc.
2. MLD Snooping can only be achieved because the switches keep additional state. The size of the multicast forwarding tables available in certain switch models vary greatly as does their behavior once such tables are full. Some of this multicast forwarding tables have been found to have as few as 1024 entries and the same applies for network interfaces; see Wheeler’s exposition of ND problems.
3. MLD Snooping is considered and mentioned in several RFCs, more on this later.
By now it should already be clear how and why MLD, PIM and MLD-Snooping operate in the context of inter-domain multicasting, but what about the other use-case; you know the one where there’s no interdomain-multicasting and applies to most of us anyway?
MLD in IPv6 Deployments not Actively Using Inter-Domain Multicast
Going back to questions one and four, let’s delve first into how multicast has ‘replaced’ broadcast in IPv6. We have discussed this question in previously but for completeness’ sake let’s mention the most relevant ideas behind the ‘transition.’
■ In IPv4 networks, all nodes in a layer two domain have to process ARP messages sent by other nodes, regardless if they are actually the target node whose IPv4 address is to be resolved.
■ The previous point proved to be problematic in the past, especially in big layer two domains and hence was seen as a problem worth solving by the guys involved with the initial IPv6 specification.
■ This problem was ‘solved’ by defining a mechanism called Solicited-Node multicast addresses. These addresses are multicast groups which can be derived from an IPv6 address a given node wants to resolve. Additionally, any IPv6 node is required to join the IPv6 multicast groups associated with its IPv6 addresses during the initialization of its interfaces. It is in this way that we end up with multicast groups, the so-called Solicited-Node addresses, which only have one member and to which messages meant only for that given member can be sent by taking the IPv6 address, deriving the Solicited-Node address and using the latter as IPv6 destination. So, what does this have to do with anything? Well, this mechanism is fundamental to the way the ND protocol works. Instead of behaving like ARP, where everyone has to process everyone’s ARP requests, the IPv6 ND protocol establishes that ND-Solicitation messages are to be sent to the Solicited-Node multicast address of the node whose address resolution is to be performed.
We’ve talked about a certain feature which is not a standard, is proprietary, vendor dependent, and to our knowledge not widely used, that mechanism is MLD Snooping. The question then turns into: What would happen to the most critical IPv6 signaling protocol, ND, if MLD Snooping was simply activated?
Well, the answer is simple. When a given node initializes its interfaces, it gets or assigns itself an IPv6 address. According to the IPv6 standard it also has to join its associated Solicited-Node multicast groups and process ND-Solicitation messages which are addressed to said group. But, if MLD Snooping is enabled, the switch won’t know that the node is a member of the Solicited-Node groups corresponding to the IPv6 unicast addresses of its interfaces. So, when another node sends ND-Solicitation messages to the node previously considered, the switch will not forward them to the appropriate port, since, from the perspective of the switch, no one has ‘told’ the network “This MLD message means that I, node X, am expecting to receive multicast traffic going to group Y”.
The result? All IPv6-capable nodes are required to send MLD messages reporting their membership of the Solicited-Node multicast addresses which correspond to the IPv6 unicast addresses of their interfaces during their initialization. With this, question four, “If I’m not running inter-domain multicast applications, why do I usually see MLD traffic on my traffic captures?”, is simply: because you have to, or as RFC 4862 puts it:
“Note that when a node joins a multicast address, it typically sends a Multicast Listener Discovery (MLD) report message [RFC2710] [RFC3810] for the multicast address. In the case of Duplicate Address Detection, the MLD report message is required in order to inform MLD-snooping switches, rather than routers, to forward multicast packets.”
Complexity is Complex, how else could it be?
So far we’ve addressed the RFC side of things relating to MLD. Nonetheless, in our talk at TROOPERS15 and Black Hat Asia we have laid some of the practical implications of MLD, its complexity, state-keeping behavior and associated non-standardized mechanisms in IPv6 deployments. The gist of it is that, put simply, MLD introduces new DoS attack vectors, hinders the predictability of IPv6 deployments and unnecessarily increases the overall complexity of the IPv6 specification, forcing users of baseline IPv6 deployments to run a protocol whose design leaves much to be desired and implementations are immature at best as the following CVEs related to MLD on Cisco devices suggest:
CVEs related to MLD on Cisco Devices
If this post whetted your appetite, be sure to have a look at our TROOPERS15 talk, MLD Considered Harmful, and the discussion which took place with regard to the implications, whether you like to or not and whether you need to or not, of running MLD in your IPv6 deployments.