IPv6 multicast background traffic (Part 3) – Multicast and IPv6 Stack Auto-Configuration (Cont.)

By /

If you would like to read the other parts in this article series please go to:

Introduction

In the previous post in this series, we dealt with some key aspects of IPv6 stack auto-configuration on Windows 7 PCs: DHCPv6, IPv6 prefixes, Neighbor Discovery, ICMPv6 and Router Advertisements. In this post we’ll wrap up how multicast is used for IPv6 auto-configuration.

Talk, don’t shout

The final two kinds of ICMPv6 Neighbor Discovery (ND) packets you’ll commonly see on Windows 7 LANs, Neighbor Solicitation and Neighbor Advertisement, are for determining MAC addresses. You’re probably familiar with ARP from IPv4 – IPv6 replaces ARP with a more efficient mechanism that Microsoft describes as follows:

The solicited-node address facilitates efficient querying of network nodes during address resolution. In IPv4, the ARP Request frame is sent to the MAC-level broadcast, disturbing all nodes on the network segment, including those that are not running IPv4. IPv6 uses the Neighbor Solicitation message to perform address resolution. However, instead of using the local-link scope all-nodes address as the Neighbor Solicitation message destination, which would disturb all IPv6 nodes on the local link, the solicited-node multicast address is used. The solicited-node multicast address consists of the prefix FF02::1:FF00:0/104 and the last 24-bits of the IPv6 address that is being resolved.

Here’s an example where a Windows 7 PC wanted the MAC address of an IPv6 router. The router first made its presence known through a standard advertisement:


Figure 1

The Windows 7 PC then issued a Neighbor Solicitation packet to the solicited node address ff02::1:ff + ac:d7c7 (the final 24 bits of the router’s IPv6 address as highlighted above):


Figure 2

And the router responded to the requester’s link-local fe80 unicast address:


Figure 3

A final, and very important, use of Solicited Node packets is establishing IPv6 link-local address uniqueness. Here’s the issue: it’s all well and good to assign yourself a LAN-only address in the fe80 address space at boot time, but how do you know someone else isn’t already using that address? The likelihood of a conflict, though minimal, does exist. The solution is to send a Neighbor Solicitation packet to the Solicited Node address and use a Source IP address of :: (i.e. null, because we’re not yet confident we can use the desired address in the Target field). In all likelihood no one will respond and the host then knows it can safely use the proposed address, but if by chance some host has already claimed the Solicited Node address, it will reply to that effect and the original sender will have to back off and try to use a different address.


Figure 4

Multicast Listener Discovery Reports

The final IPv6 multicast internal bookkeeping packets you’ll frequently see on Windows 7 LANs are Multicast Listener Discovery v2 (MLDv2) Report Messages. I have not been able to ascertain their purpose or find any explanation for the traffic patterns I’ve seen and would welcome feedback from the community.

MLDv2, the IPv6 version of IGMP, is a complex topic but in essence it’s a protocol for informing routers that there are nodes on a given link that are interested in a given multicast address. Because multicast isn’t a point-to-point transmission, the only way a router knows whether or not to pass along multicast traffic is if it knows there is at least one “interested listener” on the next hop. There could be more than one interested listener, but all the router cares about is that there’s at least one.

On Windows 7 LANs, there is a steady hum of a specific type of MLDv2 packet, a Listener Report, to the MLDv2 link-local multicast address ff02::16. There are two kinds of Report messages: Include (which tells the router that the node is interested in traffic to a given multicast address) and Exclude (was interested in such traffic, but no longer). Here’s a typical “exclude” packet that a PC sent to indicate it was no longer interested in traffic to the ff02::1:3 (LLMNR) multicast address:


Figure 5

The first question for which I’ve been unable to find an answer is why a PC would be sending MLDv2 reports about link-local traffic to a router in the first place. For non-link-local multicast it makes sense to send MLDv2 reports, but for link-local traffic, by definition routers are never going to forward it so there is no apparent use a router could make of the instructions in the above packet. It could be that this packet is a side effect of Microsoft’s IPv6 stack design, e.g. perhaps the coding APIs generate MLDv2 reports regardless of whether the multicast address in question is link-local or not.

Even more curious is a typical traffic pattern: a burst of MLDv2 reports that alternately are include and exclude. In the capture below, there are almost a dozen alternating include/exclude MLDv2 reports related to the ff02::1:3 address in the one second preceding the LLMNR lookup. I have not been able to find any documented explanation of this traffic pattern or what its purpose could be.


Figure 6

This concludes our review of how Windows 7 uses IPv6 multicast for stack-autoconfiguration. In the second half of our series, we’ll cover zero configuration networking: what it’s used for, who the players are, and why you should care.

If you would like to read the other parts in this article series please go to:

About The Author

Jeremy spent over 15 years in the enterprise systems engineering trenches. He resurfaced as CTO of a startup focused on the legal sector. In his spare time he ponders the intersection of technology and society.

Read Next

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top