In many organisations, IPv4 Multicast lies dormant, rarely (if ever) appearing on the network. Yet in IPv6, Multicast is a fundamental building block. So what are the implications of taking what was a niche player in IPv4 and making it central to the functionality of an IPv6 network.

The Theory

The purpose of Multicast is to deliver IP packets to a set of interested hosts on the network. So, in theory at least, making broadcast a special case of multicast, should massively reduce the amount of chatter on the network.

The Practice

Let's take the ubiquitous DHCP as an example. In IPv4 DHCP, a client will start off by broadcasting a DHCP Discover message, which will be flooded to the clients entire L2 segment. Even with a half full /24 subnet, then it's likely >99% of the hosts aren't going to want this message, and will drop it as soon as they have processed it. (The key here though is that the host OS will have to process it)

In DHCPv6, the client will start by sending a DHCP solicit message to the All DHCP Relay Agents and Servers multicast group. (FF02::1:2)

What happens next though is somewhat dependant on the extent to which multicast is supported on the underlying network hardware.

If the network switches are running MLD (Multicast Listener Discover) Snooping, then this packet should only be delivered to the members of this special DHCP multicast group. (This would certainly be an improvement compared to IPv4)

If they're not running MLD Snooping though, then this packet will be flooded to every host on the local L2 segment, much like an IPv4 broadcast.

Flooding IPv6 Multicast packets need not be as intrusive as flooded IPv4 broadcasts however, since we should be able to filter out traffic destined for multicast addresses we're not interested in, on host NIC adapters. (Before it is passed to the host OS)

Are my NICs filtering IPv6 Multicast?

Most server-grade NICs produced in the last 5 years should certainly support it, although I can't profess to having investigated much beyond those that I have used. The extent to which they support it (i.e the number of groups they can filter) though can vary, and finding exact details on this topic can be difficult. (I had to scour through a 1500-page chipset specification document on one such NIC to find this information)

Of course, just because your NIC supports filtering doesn't guarantee it is using it. Multicast group membership is very much dynamic, so you need a driver that can dynamically control these NIC filters. And if you're running virtualisation on your servers (which most people are) then any physical NICs that are connected to a virtual switch will more than likely be running in promiscuous mode anyway.

Am I running MLD Snooping?

Unless you've gone out of your way to configure it, then almost certainly not, and it's not a given that your switch vendor will even support it. (Or the extent to which they will support it.)

Cumulus support MLD snooping and enable it by default. (AFAIK they are only ones who enable it by default.) Juniper and Brocade both support it, although Brocade warn it might thrash the CPU of your switches. Cisco support it on their Catalyst switches, but (as far as I can tell) not on their Nexus switches. And Arista currently don't support it at all. (And told me back in October that they had no plans to) And so on....

Given that IGMP Snooping (the IPv4 equivalent) is a largely standard feature that is enabled by default on most switches these days this is somewhat surprising. However, the main differentiator is the number of multicast groups on a typical IPv4 network compared those on a typical IPv6 network.

NDP and Multicast Groups

The principal reason there are so many Multicast groups in IPv6 is Neighbour Discovery.

If Host A wants to find the physical address of Host B from it's IPv6 address, it's not just a case of sending a Neighbour Solicitation message out to the all-Nodes multicast address. (which would roughly mirror the behaviour of ARP)
Instead Host A sends the Neighbour Solicitation message to the solicited-node multicast address of Host B. (Which is calculated from the last 24 bits of the IPv6 address of Host B)
So in a worst case (and not unlikely) scenario, we could end up in a situation where there is a 1:1 mapping of solicited-node Multicast addresses to each IPv6 address.

Consider a single 10U blade system with 16 blades each running Windows Server 2012 with Hyper-V. If each blade has nine Windows Server 2012 VM's on each host, without even configuring IPv6, (since it is enabled by default in Windows and link-local addresses are mandatory), I have 160 solicited-node multicast groups. If I then allocate an IPv6 address to all 16 hosts and their VM's, I more than likely will end up with 320 solicited-node multicast groups. Virtualise more aggressively, say 39 VMs per host, then I could be up at 1,280 solicited-node multicast groups from a single blade centre.

NDP and MLD Snooping

When we start talking about thousands of solicited-node multicast groups then there may be an argument that the extra work involved from an MLD snooping point of view might somewhat negate the benefits of MLD snooping in the first place.

There may also be concerns that we might end up with more multicast groups on the network than my switch with MLD snooping supports. (In which case, the best case scenario is that the switch will flood the multicast to the whole L2 segment anyway.)

It's a complicated issue. Unless you're absolutely sure you need it, and that your switches are capable of supporting it on your network, then it may be advisable to leave MLD snooping disabled.

IPv6 Basics Part 1 - Address Format & Types
IPv6 Basics Part 2 - Unicast Addressing
IPv6 Basics Part 3 - Protocol Differences
IPv6 Basics Part 4 - Multicast
IPv6 Basics Part 5 - Planning an IPv6 Network