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.
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:
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.
Jayson,
Nicely written article. In regards to eliminating broadcasts in IPv6, I have heard many espouse the view point that ARP broadcasts were problematic and thus the creation of the Solicited Node Multicast address. However, from Radia Perlman’s Interconnections book, it discusses another problem with broadcasts. If I broadcast a frame, then everyone must look at it regardless of whether they are interested. Not just from an IP point of view, but all nodes on the media in question. Therefore I believe it is preferable to have multicasts only, so if I send out a link-local multicast in IPv6, only IPv6 capable nodes have to look at it. IPv4-only nodes for example, would not.
From a network point of view, I think eliminating broadcasts is good. However, whether or not solicited node multicast addresses are good is another question. I do agree that MLD snooping is problematic (where it is even available). I have seen in some implementations the option to not apply snooping to link-local multicast. That’s one solution to the SNM address problem. The presos from Troopers are great. IMHO though, most of the problems are because IPv6 is still immature and needs more tuning and hardening. In the next 2-3 years I expect most of these problems to be cleaned up.
-Jim
Greetings James,
Broadcasting could certainly be considered problematic when one takes the fact you mention into account. In order not to consume resources on the clients’ side, as you have stated, multicasting seems indeed like the perfect solution. However, one should think about realistic improvements and less about theoretical ones. What I mean with theoretical and realistic improvements is that, it is expected that because of Solicited-Node addresses, MLD and the way ND works, less Neighbor-Solicitation messages reach all endpoints on a given IPv6 broadcast domain. After all, that is the idea behind “goodbye broadcast, welcome multicast.” However, and you are likely already aware of this, multicast traffic is usually handled by layer-two devices in the same way broadcast traffic is. In theory, this is done this way unless you’re using MLD-Snooping.
So, we still haven’t profited from multicast, but in theory we could, we just have to use MLD-Snooping. This, however, differs from reality. A Cisco switch running IOS 15.4 configured to perform MLD-Snooping still leaves traffic related to ND untouched, it is broadcasted. This without offering the possibility to do otherwise. Actually, this wasn’t a surprise, since performing MLD-Snooping on ND traffic would lead to considerable growth in the switches’ state. I would be surprised if other vendors didn’t reach the same conclusion and chose to simply broadcast ND related traffic.
In this regard you could find the following draft interesting: draft-pashby-magma-simplify-mld-snooping-01.txt. It seems like others have also noticed that performing MLD-Snooping on ND traffic is not a good idea. Furthermore, some guys on the V6Ops mailing-list share this opinion, “MLD snooping of ND traffic is a pretty bad idea and there’s really no good reason for the switch to not simply flood ND traffic.” See v6ops/current/msg19929.html.
Wrapping up, and I’m here with you, ARP-like behavior in IPv6 networks is not necessarly a desirable approach. However, due to the way switches handle multicast traffic and vendor(s) have decided to implement MLD-Snooping, the real ‘improvements’ ND, Solicited-Node-Addresses and MLD offer in comparison with ARP-like behavior are practically non-existent. Especially since in common IPv6 deployments the only multicast traffic one will likely find on the network will be related to ND, but it again is handled as if it was ARP.
Thanks for your kind feedback. I’m also sure that we all are following the developments at the IETF with optimism and expect the IPv6 stack to go in a more minimalistic, shall we say pragmatic?, direction.
I hope to have made myself somewhat clear and to have given you some interesting pointers regarding past discussions about MLD.
Let me know if anything and thanks for reading.
Jayson,
Agree that Solicited Node Multicast is problematic, but we’re probably stuck with it. I can’t see a revised RFC switching ND/NS to using all nodes multicast instead of SNM. Or do you think this is actually possible? I haven’t been watching v6ops/6man lately so not sure if this is being contemplated.
However, for switching from broadcast to multicast I believe there are some long term advantages. For one, I can now use hardware level (NIC) filtering which is vastly more efficient that software based filtering. Of course I’m sure you’ll point out that most NICs have limited filtering capabilities at present. However, this can be improved upon if needed in the long term. I suspect we’ll have IPv6 for at least the next 30+ years so this seems like a nice enhancement for the future.
Considering that everything appears to be converging to IP, I believe multicast will become essential. There are some promising new solutions for lack of end-to-end support like AMT. With IOT taking us to trillions of Internet nodes (see Stanford’s trillion sensor vision), we need more scalable communications options. Multicast may just do the trick. Perhaps the biggest problem with multicast is education and abstraction layers. Here’s one potential security perk though – move all nodes to L3 point-to-point links (either physical or virtual by clearing prefix “L” big). All broadcast traffic could then be done with multicast. This is the only way to have scalable plug-n-play networking. With SDN type solutions offering more and more granular controls (e.g. including for multicast) this could be an interesting approach.
That said I will concede I’m speaking with my network optimist hat and not my security one. I hear you on the issues – they need to be addressed.
What do you think? Put away the polyanna glasses or there could be hope for multicast?
–Jim
Greetings James,
Personally, I don’t think it’d be a good idea to flat out broadcast messages which currently are being sent to Solicited-Node-Addresses without careful consideration. Multicast is indeed a useful model, even on the local-link. Nonetheless, from my perspective, it is all a matter of use-cases.
There are people who believe that the cure has created more problems than it has solved and that, while MLD, Solicited-Node-Addresses and MLD-Snooping help preserve bandwidth, they come at a cost too great to bear, increased demands on existent hardware. Furthermore, it has been said that bandwidth consumption due to broadcasted ND traffic is negligible anyway, so why not just go back to ‘ARP’?
It should also be noted that as of today broadcasted ND messages are likely to be more widespread than multicasted ND messages via MLD-Snooping. So, if IPv6 deployments seem to be doing fine, why put so much effort on optimizing a cocktail for a tiny use-case?
As the combination I’ve listed currently stands, it is hard to reap the benefits of multicast on the local-link. Due to this fact, we, and others in the community, have often wondered if the effort required to fix multicast on the local-link is worth it or if ARP-like behavior would do the trick. I’ve often argued that we will likely see bigger layer-two domains in IPv6 than in IPv4, after all IPv6 was built to scale, so the effort put into the optimization of multicasting on the local-link would be helpful.
However, some members of the community aren’t that fond of big layer-two segments and have argued that, even in IPv6, layer-two segments aren’t the best approach. There was a talk at TROOPERS15 about micro-segmentation, a model which would change the scenario I mentioned above and hence the decision for or against ARP-like behavior or optimizing multicast on the local-link.
I totally agree with you here and that’s why I personally like the multicast approach. We’ve already mentioned that the talk about MLD, MLD-Snooping and multicast on the local-link is one which will likely have bigger repercusions in the future than in the IPv6 deployments we have today.
With regard to achieving the ‘multicast ideal’ by relying on point-to-point links, that’d certainly be an interesting approach. In case you aren’t aware of it already, have a look at Ivan’s post on “What is Layer-2 and Why do we need it?”.
Going back to Standford’s vision, the fact that interesting developments are taking place on the multicasting field and both the enterprise and academic community are looking at it with interest is undeniable. However, I don’t think IPv6 multicast is ready for its deployment on vast sensor networks or what have you. It’d be interesting to see what happens when someone starts playing with MLD Queries in some segments of such a sensor-network.
There’s definetly hope for multicast, the use-cases are too many and too interesting to be ignored. In my opinion, the only terrain where the relevance of multicast is unclear is on the IPv6 local-link, that’s where multicast isn’t necessarily the only good approach; mainly because we can’t do away with years of hardware and specifications.
All in all, I would adventure that multicast is here to stay and will find some fertile ground in IPv6’s big networks; e.g. the IOT.