Picking up from part 1 of the back to basics, let’s jump into the multicast address type and why it is important to IPv6.
As a quick review, the goal of our “back to IPv6 basics” series is to provide a bit more detail on the three main address types in IPv6. They are:
- Unicast
- Multicast
- Anycast
Network operators often have a love/hate relationship with IPv4 multicast. Multicast seems like a dark art for many networking folks: a somewhat mysterious one-to-many packet forwarding technology. Because of this, many networking staff have very strong feelings on whether an enterprise network should or should not operate a multicast service, multicast routing protocols, etc. Luckily, in IPv6, while it can do many of the same traditional multicast functions as IPv4, that really isn’t the primary reason that we need to talk about multicast in IPv6.
The goal of multicast in the original design of the IPv6 protocol was to address some shortcomings in how multicast was designed and built in IPv4.
One example of this would be IPv6 multicast not having any artificial limitations on address to MAC address mapping. IPv4 has to reuse IPv4 multicast-to-Ethernet address mappings, which can cause inefficiencies in bandwidth usage for multicast streams. Additionally, the conventional thinking at the time IPv6 was drafted was that multicast would help address some of the bandwidth growth limitations that were impacting many networks. As Ethernet technology has evolved, the bandwidth problem has largely gone away. Now, the cost benefit analysis of implementing large scale Layer 3 multicast networks has turned in favor of just providing more unicast streams, even if they are of the same content, because there is now enough bandwidth to support that model. Multicast from an architectural perspective has an elegance and simplicity that motivated those drafting IPv6 to decide it was the right tool for replacing some other Layer 2 to 3 operational realities that were considered a bit ugly. For example, the fact that ARP and RARP did a kind of “Layer 2.5” function and were not true Layer 2 or Layer 3 in the OSI model bugged some. IPv6 became a bit of a harbor for purists who wanted to restore the networking protocol to its original intended form. Just realize that the majority of IPv6 multicast actually happens on a local link because of the motivations to “clean up” or improve on the mistakes of IPv4, not necessarily because the method was technically superior to what IPv4 was already doing. You can brush up on IPv4 multicast if you like over at Wikipedia.
IPv6 multicast addresses are defined with the following address space:
FF00::/8
In IPv6, multicast has two major functions that map to how IPv6 multicast addresses are scoped. It has a function that is locally scoped to allow hosts to do things like duplicate address detection (DAD), neighbor discovery, and the ability to self-assign into well-known multicast groups (see Tom Coffeen’s SLAAC blog post that covers these). The second major function is for network-wide multicast, which is the same as the more common IPv4 multicast functions used today (i.e., beyond locally-scoped but within one autonomous routing domain).
Let’s tackle the IPv6 network-wide scope (the IANA scoping would be Organizational-Local or Scope 8) multicast use case because it matches with what is done in IPv4 networks today. At the time of the writing of the IPv6 specifications, multicast was considered an efficient way to do a publish-and-subscribe distributed protocol for applications that had no concept on how to do that with message bus technology like Tibco Rendezvous (at the time) or more modern equivalents like Rabbit MQ, MSMQ, or Consul. Because of the modern microservices application frameworks being utilized today (and how their core functions are being built around a message bus) the need for multicast networks has diminished greatly in the last few years. IPv6 still requires multicast (it is a core address type) but in-depth knowledge of it is likely not as high on the skills list as it was for IPv4.
The use of modern message bus technologies in the move to microservice architectures effectively replaces the need to deploy network wide multicast solutions, regardless of protocol. You may still need to deploy a network wide multicast solution in IPv6 if your applications have not been modernized. Luckily IPv6 has many of the same multicast routing equivalents such as PIM Source Specific Multicast or Any Source Multicast. The good news is that you will have more IPv6 multicast address types to choose from and an easier time mapping those IPv6 addresses to Layer 2 Ethernet multicast frames. The downside is you are still running and operating a multicast network with multicast routing protocols. For many, this is a set-it and forget-it sort of model until something goes wrong or breaks. Still, it is one more thing you are running in your environment which gets away from the simply network operator rules that seem to be the ethos of network philosophy today.
Changing gears, on the local link scope level, IPv6 uses multicast almost immediately. When a host is first bringing its interface up it will use a multicast process to request the global unicast prefix on that link via a Router Solicitation (RS) and then do Duplicate Address Detection (DAD) using ICMPv6 multicast after generating both a global unicast address but also a solicited node multicast address. This solicited node multicast address is how we no longer require an ARP/RARP process like what IPv4 uses. We are able to map an IPv6 multicast address directly to an Ethernet multicast frame. I won’t belabor the technical details here as Scott Hogg has already provided that information in his blog post at FE80::1 is a Perfectly Valid IPv6 Default Gateway. The important point is to understand that EVERY host will have a solicited node multicast address of some kind even if the host only has a link-local address (Check out Denise Fishburne’s excellent blog post series on this topic). It is a function of how the protocol works.
Fundamentally, the really interesting part of how IPv6 uses multicast was the decision to have a preset group of multicast addresses that certain hosts could join based on their function. These multicast addresses are listed out up on the IANA website. Here are a few you might find interesting:
FF02::1 – all nodes
FF02::2 – all routers
FF02::5 – all OSPF SPF router
FF02::6 – all OSPF DR router
FF02::9 – RIP routers
FF02::a – EIGRP routers
FF02::d – PIM routers
FF02::1:2 – All DHCP servers and relay agents
As you can see, having a whole set of well-defined locally scoped multicast addresses makes life a bit easier. In the list above you will notice all the addresses start with the hex digits FF02. There is significance to the bit order value (after the FF portion of the address) and in this case the value 02 indicates that the address is link-local scope in nature. As a general rule of thumb, you will typically see FF02 the majority of the time with some FF08 if an organization decides to deploy network wide organization-local scope multicast services.
So that is it, the quick look at IPv6 multicast. There are fantastic resources to use to dig in more. Check out Wikipedia, or you can watch my IPv6: Introduction to the Protocol course on Pluralsight.
You can find me on twitter as @ehorley and remember…
IPv6 is the future and the future is now!
